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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ данных на Scala — суровая необходимость или приятная возможность?

В этом плане приятно когда у тебя прод на Java — можно встраиваться без доп прокладок :)

Анализ данных на Scala — суровая необходимость или приятная возможность?

Накладные расходы. Нам, например, нужно уметь получать тысячи скоров за десятки миллисекунд, поэтому самые критичные блоки работают без REST, а, в идеале, вообще без удаленных вызовов. Хотя при желании многое можно порешать собирая задачи в пакеты.

Анализ данных на Scala — суровая необходимость или приятная возможность?

Нет, внутри была только интерпретация дерева XGBoost-а, параллельность была на уровне вызывающих. Вердикт — то, во что JPPML превращает XGBoost не юзабельно (700мс на скоринг 1000 объектов).

«Не вижу ни одного резона использовать Python для работы со Spark, кроме лени»

Пока не статья, но воспроизвел кейс: www.zepl.com/viewer/notebooks/bm90ZTovL2RtaXRyeWJ1Z2F5Y2hlbmtvLzQ4ODM3YzlmYzMzNzRlNWRhMjdjZWIzMmVkOTk1MGFlL25vdGUuanNvbg

Пока идет процесс подсчета Python честно жжет киловаты на всех 4-х ядрах, в GIL не упирается:


В итоге — PySpark 1 минута 38 секунд, обычный Spark — 2 секунды:


«Доктор, что я делаю не так?»

UPD: Если убрать использования sklearn, то скорость сопоставима. При этом производительность sklearn самого по себе в этом аспекте на уровне.

Вывод такой — Spark умеет UDF до определнной сложности (пока не появляется дополинетльных пакетов) умеет транслировать и запускать почти без оверхеда. Но при появлении использования расширенных пакетов фолбэчится на Python.