Python vs. Scala для Apache Spark — ожидаемый benchmark с неожиданным результатом

[pklemenkov]

А почему не использовали pandas_udf? Там же за счет Arrow и векторизации очень большой буст получается. Ну и реализацию самой udf через векторизованные операции очень помогло бы

[dmitrybugaychenko]

Это хорошо может помочь если действительно можно реализовать udf без pandas.apply внутри, на стандартных функциях. Но тогда не очень понятно зачем UDF — базовых функций и в Spark SQL много. Но в нашем случае надо выполнить некоторую логику именно для каждого ряда — с Arrow будет не в 7-8 раз разница, а в 3-4, если без скайлерна, а с ним мрак по любому. Попробую погонять отдельно.

[rssdev10]

Здесь бы было интересно сравнить также vanilla Java-код. И получить ответ на вопрос, стоит ли мучаться с поиском программистов под Scala ради экономии 10% объема кода.

[nehaev]

Между современной джавой и скалой не такая уж адская пропасть. При желании более-менее сеньорный джавер начинает писать вполне идеоматичный скала-код через несколько недель изучения. Конкретно для спарка — это время вообще измеряется часами, поскольку Java API транслируется в Scala практически дословно. Это гораздо проще и быстрее, чем искать людей с нужными скилами на стороне. При этом 10% (хотя мне кажется больше) вы все так же получите.

[rssdev10]

В настоящее время Scala практически не развивается. Именно потому, что Java за последние 10 лет довольно сильно изменилась в лучшую сторону, и возникает вопрос, зачем нужна Scala. Да и остались ли, хоть какие-то API у Spark (как, впрочем, и у любого другого BigData-инструмента), которые не были бы на 100% совместимы с Java?

PS: Я бы не решился сейчас начинать новый проект на Scala. Опыт её использования имеется. Очень дорого обходится в ней контроль за кодом разработчиков. Существенно проще написать write-only код, по сравнению с Java. + чисто скальные проблемы по интеграции разных библиотек, собранных в разных Скалах.

[dmitrybugaychenko]

В плане производительности и Java, и Scala в спарке одно и тоже. АПИ более заточен под Scala, но из Java тоже можно пользовать. Про write-only код согласен полностью, Scala требует куда большей ответственности.

Но если брать Spark, то без скалиста все-таки никуда — надо уметь же внутрь залезть и разобратся почему что не работает и как сделать чтобы заработало. Не важно на чем клиент.

[time2rfc]

В настоящее время Scala практически не развивается.

Очень смелое заявление.

[danslapman]

И к тому-же абсолютно неверное)

[nehaev]

Java действительно сделала огромный рывок вперед за последние годы, но, насколько я понимаю, большая часть этих нововведений уже давно была в Scala, причем сделана там гораздо лучше. Это как Ахиллес и черепаха. Ресурсов у Оракла гораздо больше, и они очень стараются сделать из джавы хотя бы скалу "на минималках" (или колтин "на минималках", кому что больше нравится). Но все равно они никогда не догонят Scala, потому что нельзя из пожилого императивного языка сделать функциональную конфетку.

Я бы не решился сейчас начинать новый проект на Scala.

Ну если проект на Spark, то тут даже думать не надо. Любой вариант кроме Scala требует экстраординарных обоснований.

[sshikov]

Ну почему, Java 8 не требует. Эффект тот же.

[nehaev]

Не совсем. Во-первых, с большой вероятностью придется читать код спарка, который на Scala, т.е. не знать ее нельзя. Во-вторых, если знаешь Scala, зачем писать более многословный, сложночитаемый и склонный к ошибкам код, если можно этого не делать?

[sshikov]

>с большой вероятностью придется читать код спарка
Хм. Один раз читал за два года. Зачем его читать? Что там такого есть, чтобы туда регулярно лазать?

>Во-вторых, если знаешь Scala, зачем писать более многословный, сложночитаемый и склонный к ошибкам код, если можно этого не делать?

Это по большей части сильно преувеличено. Таких требований, чтобы обязательно писать на скале, спарк не предъявляет точно. У нас куча проектов в проме, бОльшая часть — Java.

[nehaev]

Один раз читал за два года.

"Один раз — не скалист" — такая логика, что ли :)

Таких требований, чтобы обязательно писать на скале, спарк не предъявляет точно.

Про "обязательно", я вроде и не писал нигде. Можно конечно и на джаве превозмогать, если есть время и желание.

[sshikov]

>Про «обязательно», я вроде и не писал нигде. Можно конечно и на джаве превозмогать, если есть время и желание.

А вот это? На мой взгляд тут примерно тоже самое и написано.
>Любой вариант кроме Scala требует экстраординарных обоснований.

В нашей практике — скорее наоборот, вариант писать на скале потребует показать что у вас в команде достаточно людей, которые ее знают. Для Java этого не нужно (как и знания спарка в принципе). Считается что специалистов много (хотя найти их сложно ;)

[rssdev10]

Ну если проект на Spark, то тут даже думать не надо. Любой вариант кроме Scala требует экстраординарных обоснований.

Запустите опрос о том, кто и на чём на Spark пишет.

Да и, вопрос, если BigData, то Spark ли… И стоит для Ignite или Flink использовать что-то кроме Java?..

[nehaev]

Запустите опрос о том, кто и на чём на Spark пишет.

В ход пошли нетехнические аргументы? Я нашел статистику от датабрикс за 2016 год. Если у кого есть свежее, пожалуйста, делитесь:

Да и, вопрос, если BigData, то Spark ли… И стоит для Ignite или Flink использовать что-то кроме Java?

Обычно инструмент подбирают исходя из задачи, а не из предпочтений относительно ЯП. Если нужен Spark и уже знаете Java — разумнее всего сделать полшага вперед и перейти на Scala. Если конечно это прагматический вопрос, а не религиозный.

[rssdev10]

Если нужен Spark и уже знаете Java — разумнее всего сделать полшага вперед и перейти на Scala. Если конечно это прагматический вопрос, а не религиозный.

Да вот, из чисто прагматических соображений, не кажется разумным делать этот шаг к Scala. Потому что для компании Одерского Scala уже два года как не приоритет.

Для нынешнего Java-кода я могу быть уверен, что найду программистов и через 10 лет. Для Scala — не факт, что и через 5 лет такие найдутся. Тем более, что то, что пишут на Java для Spark, по факту, синтаксически не сильно отличается от Scala.

[nehaev]

К сожалению, не вижу прагматических соображений. Вижу домыслы, основанные на слухах.

Потому что для компании Одерского Scala уже два года как не приоритет.

Одерский занимается dotty (которая Scala 3.0), "компания Одерского" (Lightbend) готовится к релизу Scala 2.13. Если для них Scala уже два года как не приоритет, то что тогда приоритет, неужели Java? И еще вопрос, а для Оракла Java точно приоритет?

Да, ресурсы Oracle и Lightbend несопоставимы, да, Java-community гораздо больше, чем Scala. Но все равно Scala технически круче Java. Это хотя бы факты, а не странные домыслы насчет приоритетов.

Последний параграф, по-моему, несколько противоречит сам себе. Если синтаксически не сильно отличается, откуда возьмутся проблемы с поиском программистов? Ну и плюс Спарк же врядли перепишут на джаву, так что для него аргументы в пользу скалы будут в силе и через 5 лет.

[sshikov]

А это не технический вопрос. Не чисто технический.

У нас кстати в коллективе примерно так же все — большая часть задач пишется на spark + java. Никакого активного желания мигрировать на скалу не наблюдается, при том что спарк шелл вполне используем.

[nehaev]

Ну когда технические вопросы решаются нетехническими аргументами, тут больше вопрос к девелоперам, согласны ли они тратить свое время на такие проекты. Выбор-то всегда есть.

Если вы писали production-level спарк джобы и на скале и на джаве, юзали спарк-шелл, сами скажите, только честно, какой язык больше подходит для спарка?

[sshikov]

В моих проектах разница непринципиальная. На том уровне, на каком нужна скала для спарка (если не включать сюда ML, где все слегка иначе), Java 8 практически не отличается ничем. На скале пишутся прототипы, или утилиты (например, в нашей старой версии Hive не работает как следует MSCK — переписывается на скале). То есть это скриптовый язык, а ля баш.

[Alexey_mosc]

Интересно, что R появился. А ещё, от статистика, почему больше 100% на диаграмме? )

[dmitrybugaychenko]

Больше 100% обычно в опросах где можно выбрать несколько вариантов. R, кстати, не проверял в данной задаче. Опыта нет…

Ну а появился в 2016 потому что до этого нормальной поддержки не было, SparkR появился в 1.4, это июнь 2015-го.

[Alexey_mosc]

Более актуален sparklyr от RStudio. Он удобнее, хотя, что там под капотом, — это фигзнает. Он мимикрирует под синтаксис dplyr с его mutate %>% group_by %>% ..., и позволяет вызывать sql и прочее из библиотек scala (как я понял из примерно 3-х месячного опыта ковыряния оного).

Но в целом есть шероховатости, которые прямо драчовым напильником надо спиливать. Например, не признает функцию median из R stats. То есть, ты ожидаешь, что вызов медиан для расчета чего нибудь на груп-бае должен же работать! А он не работает… Пришлось ее тащить из нутра спарка. Многие чисто фильтровачные и обработачные функции для набора данных не работают, нужно писать на sql в коде Ар… Мешанина с NULL, NA ®, None и т.д… Неожиданные результаты.

В общем, туго идет процесс предобработки данных. Про производительность не знаю, гонял на localhost, но заметил, что операция превращения из длинного в широкий массив шла в десятки раз дольше на датафреймах спарк, чем в памяти R скрипта. Намучился…

[dmitrybugaychenko]

Сравнивать локальный алгоритм в памяти и расспределенный на кластере нестоит — локальный почти всегда выиграет. Но вот вопрос насколько много R в разных вариантах дает оверхеда при использовании UDF открытый (при использовании стандартных конструкций транслирующихся в Spark SQL все понятно). Если кто-то погоняет бенчмарк будет круто.

[Alexey_mosc]

Про оверхед вопрос хороший, я сам не знаю, насколько много там переливаний из пустого в порожнее прежде чем Спарк заводится. У меня остался осадок такого рода, что переписать то, что хорошо работает локально (на классах data.table()) и работает макс.быстро для R, очень муторно под Спарк. То есть, методы, которые должны быть user-friendly (высокоуровненые) вдруг не работают кое-где, и начинаешь вмешивать код SQL который прямо дословно идет в Spark SQL. А это еще страннее выглядит…

[biggiemikkie]

Ну тут на самом деле спорно про максимально быстро и data.table, только если у вас достаточно маленькие объемы данных. Вообще сравнить spark и data.table на локалке слегка не верно. А вот сравнивать iotools/bigmemory и sparklyr и с подкруткой под эти пакеты master-worker и map and reduce парадигм параллизации процессов соответственно, куда логичнее

[Alexey_mosc]

Ну да, не совсем то, или совсем не то. Просто был прецедент, дай как я раскатаю через dcast длииинный тейбл в широчееенный тейбл. Сравним с датафреймом на Spark. Оказалось совсем плохо (для последнего). Потом узнал, что, цитирую, «Spark is not optimized for wide dataframes». Услышал от спикера довольно опытного на конференции ODSC в Бостоне в прошлом году. Он мне говорит, зачем ты вообще такие широкие датафреймы строишь…

Ну и т.д. Это лишь один пример на небольших данных (пару сотен Мб).

Задача была а-ля мешок слов, а он же широкий, да.

[dmitrybugaychenko]

Работа в спарке с текстам делается обычно через переход к колонке-вектору (sparse разумеется) — соответственно все нужные утилиты типа TF-IDF, CountVectorizer, работ с N-gram и т.д. присутствуют. А датафреймы с очень большим количеством колонок он не любит, так как в памяти и при шафле все равно формат рядный, да еще и плотный.

[Alexey_mosc]

Я и хотел колонку-вектор сделать, если не ошибаюсь. Но я ее хотел собрать из предварительно созданных колонок… Ведь их нет изначально, а есть только две колонки — грубо говоря, document id, token. Как же сделать колонку-вектор, не разложив токены по колонкам. Вроде бы так было.

[dmitrybugaychenko]

groupBy(document_id).agg(collect_list/collect_set) а дальше CountVectorizer из SparkML или MultinominalExtractor из PravdaML

[Alexey_mosc]

Ага, спасибо, буду знать.

PravdaML? Это ваш новый фреймворк?

[dmitrybugaychenko]

Да, расширение Spark ML github.com/odnoklassniki/pravda-ml

[biggiemikkie]

Имел небольшой опыт работы с spark через пакет sparklyr. В общем и целом пакет новый, можно нарваться на ошибку и зависнуть над ней надолго, потому что невсегда она очевидна. Хотя синтексис очень близок к обычному dplyr, что конечно удобно, хоть и странно, тот же data.table тут был бы роднее. Мне кажется, многим роднее будет работать через iotools, чем вникать в spark

[Alexey_mosc]

Хотя синтексис очень близок к обычному dplyr, что конечно удобно, хоть и странно, тот же data.table тут был бы роднее.

Да!

[sshikov]

>Да и остались ли, хоть какие-то API у Spark (как, впрочем, и у любого другого BigData-инструмента), которые не были бы на 100% совместимы с Java?

Ну, таких чтобы совсем не, вряд ли. Но такие, где на выходе условно Seq, вы найдете легко, и они доставляют определенные неудобства. Не слишком большие. На ум приходит catalog.

[Rhombus]

python медленнее чем scala — действительно «неожиданный» результат

[dmitrybugaychenko]

Для многих да… Ну а я совсем не ожидал бурной дискуссии Java/Scala в комментах — по мне так это практически родные сестры :)

[Stas911]

Это родные сестры, пока в дебри не углубишься (но, вроде, для типовых задач на Spark это особо и не требуется)

[dmitrybugaychenko]

Характер у сестер, конечно, разный, но с любой можно найти общий язык и жить долго и счастливо. Даже выбирать не надо — вместе хорошо уживаются :)

[Alex_Builder]

А чего удивляться, что интерпретатор модных скриптов для школьников и продвинутых домохозяек aka Питон уступает в десятки раз в скорости чему-то что крутится на скоростной java-машине, которая уже давно известна своей блестящей JIT оптимизацией?

[Ingas]

«Не все так однозначно». В подобных задачах питон — скорее обертка над оптимизированным-переоптимизированным объектным кодом, так что результат действительно может оказаться неожиданным.

[slonopotamus]

В питоне быстро работает то что написано на C (с) я

[dmitrybugaychenko]

Как выяснилось, к сожалению, не всегда. Здесь получилось что быстрее работает без C — это тоже неожиданный результат :)

[Alex_Builder]

> «Не все так однозначно»

Ой да не смешите мои тапки :) Что там может быть неоднозначно?
Вот когда Питон обзаведется своим собственным JIT компилятором, вот тогда и можно его скорость сравнивать с Java-машинами, а пока это похоже на сравнение тёплого с мягким.
Но боюсь, что тогда окажется что нужно еще вводить строгую типизацию для повышения производительности и снижения впустую сжираемой памяти и т.д. и т.п.
Но тогда это будет уже не такой простой скрипт для обучения школьников или для общего скриптописательства (как кроссплатформенная замена VBA), а значит он потеряет свое главное предназначение.

[dmitrybugaychenko]

Ну тут дело в том, что часто расспределение времени работы между питоном и «бэкендом» 1/999. Например, когда тренируем нейросетку, или когда работаем со спарком, но в рамках Spark SQL. В таких задачах все работает максимально быстро. Но как только баланс работы смещается хотя бы к 1/9 уже становится заметна разница.

[dmitrybugaychenko]

Попробовал с PyPy — 55 секунд Python, 30 секунд PyPy, 7 секунд Scala. Т.е. разница уже не 7-8 раз, а всего 4-5 раз :)

[time2rfc]

Не могу понять отчего люди используют слово ВСЕГО при обсуждении такой разницы, у нас scala код считает отчет месячный чуть меньше суток, разница между сутками и половиной неделе совсем не ВСЕГО

[dmitrybugaychenko]

Ну это ирония была если что :). Для нас тоже 4-5 раз это сотни миллионов дополнительных трат.

[sshikov]

Ну там же смайл был… а так вы правы конечно, если мы должны за сутки обработать некоторый поток данных, то разница даже между восемью часами и четырьмя совсем не маленькая. Ну или уменьшение потребления ресурсов во столько же раз.

[rotlis]

Холивар в чистом виде с попытками предьявить «unbiased» аргументацию. Как тут не поучаствовать? Тим-лидю небольшой BigData проект в телекоме. Толковых работящих людей на рынке понимающих как делать биг дату и писать на питоне в разы больше чем людей которые могут на скале написать «hello world». Если проект подразумевает развитие и поддержку то выбор скалы имеет риск что в один прекрасный день вы все будете тащить один плача после очередного неудачного интервью.

[dmitrybugaychenko]

Ну, по опыту собеседований, Java разработчики, которые могут написать не только hello world на Scala, на рынке есть. Они стоят дороже питонистов, но при этом результат который они создадут будет куда как надежнее чем поделка среднестатистического питониста. К сожалению, средний уровень базовых программистких скилов в среде питонистов существенно ниже… В том числе из-за набежавших на хайп «датасаентистов тюню xgboost за 300 к/c».

[sshikov]

У нас вменяемые не слишком опытные java разработчики вполне пишут на спарке. Может не сразу, но обычно стандартного месяца вполне хватает, чтобы включиться, а месяц все равно нужен, чтобы в бизнес вникнуть.

[Stas911]

А вот такой вопрос — все ли пакеты Python, использованные в UDF, были заранее установлены на всех нодах?

[dmitrybugaychenko]

Да. Тестировал на одной ноде.

[sshikov]

А вы считаете, что если их нет, то кто-то (спарк?) их установит?

[CrazyElf]

И всё же без профайлера не очень понятно, что именно в питоне тут тормозит. Может там вообще parse тормозит, или использование Series из Pandas как-то не оптимально работает. Когда преобразований всяких много тяжело понять, где же узкое место.

[dmitrybugaychenko]

Ну, если говорить про спарк, то ± понятно, в порядке убывания импакта причины следующие:
1. Стык Python/C при вызове «пакетной» функции для каждого ряда
2. Стык Scala/Python
3. Интерпретатор Python

[Sherman81]

Спасибо, что сделал эту работу, а то люди регулярно этот вопрос задают :-)
Можно еще добавить с каждой новой версией jvm мы полчаем все новые оптимизации, которые есть в compiler/runtime для jvm.

[sshikov]

Это вы про что? Поясню на всякий случай — на главной странице у спарка написано Java 8, а поскольку Hadoop является одной из основных сред развертывания, то его требования тоже приходится учитывать. Ну и… там тоже Java 8 пока что.

Есть такой опыт?

[Aytuar]

Очередной раз убеждаюсь что питон для приложений не годиться. Пару скриптов написать норм, но не более.