dmitrybugaychenko Mar 13 2019 at 10:42

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

6 min

30K

VK corporate blogОК corporate blogBig Data*Data Mining*Python*

+34

Comments 62

pklemenkov Mar 13 2019 at 11:56

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

dmitrybugaychenko Mar 13 2019 at 12:00

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

rssdev10 Mar 13 2019 at 12:49

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

nehaev Mar 13 2019 at 13:14

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

rssdev10 Mar 13 2019 at 13:24

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

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

dmitrybugaychenko Mar 13 2019 at 13:35

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

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

time2rfc Mar 13 2019 at 13:50

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

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

danslapman Mar 13 2019 at 14:19

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

nehaev Mar 13 2019 at 14:10

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

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

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

sshikov Mar 13 2019 at 14:24

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

nehaev Mar 13 2019 at 14:30

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

sshikov Mar 13 2019 at 15:22

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

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

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

nehaev Mar 13 2019 at 15:50

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

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

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

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

sshikov Mar 13 2019 at 17:26

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

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

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

rssdev10 Mar 13 2019 at 14:29

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

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

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

nehaev Mar 13 2019 at 14:59

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

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

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

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

rssdev10 Mar 13 2019 at 15:07

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

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

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

nehaev Mar 13 2019 at 16:06

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

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

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

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

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

sshikov Mar 13 2019 at 15:18

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

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

nehaev Mar 13 2019 at 16:15

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

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

sshikov Mar 13 2019 at 17:15

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

Alexey_mosc Mar 13 2019 at 22:30

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

dmitrybugaychenko Mar 13 2019 at 22:37

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

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

Alexey_mosc Mar 14 2019 at 12:26

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

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

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

dmitrybugaychenko Mar 14 2019 at 13:05

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

Alexey_mosc Mar 14 2019 at 13:41

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

biggiemikkie Mar 14 2019 at 16:25

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

Alexey_mosc Mar 14 2019 at 17:37

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

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

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

dmitrybugaychenko Mar 14 2019 at 18:12

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

Alexey_mosc Mar 14 2019 at 18:37

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

dmitrybugaychenko Mar 14 2019 at 18:49

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

Alexey_mosc Mar 15 2019 at 12:26

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

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

dmitrybugaychenko Mar 16 2019 at 21:24

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

biggiemikkie Mar 14 2019 at 13:03

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

Alexey_mosc Mar 14 2019 at 13:37

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

Да!

sshikov Mar 13 2019 at 14:30

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

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

Rhombus Mar 13 2019 at 14:27

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

dmitrybugaychenko Mar 13 2019 at 14:48

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

Stas911 Mar 13 2019 at 17:36

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

dmitrybugaychenko Mar 13 2019 at 18:54

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

Alex_Builder Mar 13 2019 at 23:15

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

Ingas Mar 14 2019 at 07:11

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

slonopotamus Mar 14 2019 at 09:57

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

dmitrybugaychenko Mar 14 2019 at 11:59

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

Alex_Builder Mar 14 2019 at 13:37

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

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

dmitrybugaychenko Mar 14 2019 at 16:28

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

UFO just landed and posted this here

dmitrybugaychenko Mar 15 2019 at 12:01

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

time2rfc Mar 15 2019 at 12:22

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

dmitrybugaychenko Mar 15 2019 at 12:24

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

sshikov Mar 16 2019 at 12:14

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

rotlis Mar 15 2019 at 12:44

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

dmitrybugaychenko Mar 15 2019 at 12:50

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

sshikov Mar 16 2019 at 12:10

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

Stas911 Mar 15 2019 at 15:36

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

dmitrybugaychenko Mar 16 2019 at 21:20

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

sshikov Mar 17 2019 at 17:07

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

CrazyElf Mar 15 2019 at 18:15

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

dmitrybugaychenko Mar 16 2019 at 21:23

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

Sherman81 Mar 20 2019 at 11:03

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

sshikov Mar 20 2019 at 20:42

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

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

Aytuar Apr 6 2022 at 11:58

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