Comments 15
Python и Java обмениваются друг с другом данными
Чего только не сделают, чтобы не ходить на овощную базу (с) старый советский анекдот.
А поделитесь, что вас держит при работе на спарке в связке с питоном? Скажем, скала дает легкий доступ к куче фич той же HDFS, к Hive Metastore, и многому другому. Я помню, как тут кто-то опубликовал кусок кода на питоне строк на 50, вся цель которого была в том, чтобы построить список схем или таблиц. И что в скале со спарком делается буквально в две строки (в реальности — в одну). Готов допустить, что питоновское решение там было не самое эффективное, но разница в 25 раз...
Понятно что всегда есть старый опыт, и если знаешь питон — то наверное проще на нем. Но моя практика показывает, что для эффективного пользования спарк шеллом достаточно знать скалу в пределах процентов от всех возможностей языка, то есть за неделю вполне можно научиться. И не иметь множества проблем связки питон — Java, который в хадупе таки мешают жить довольно сильно.
Привет! Спасибо за комментарий)
Да, я согласен, что скала для спарка, это несколько процентов от скалы. Я на самом деле тоже оч топлю за скалу. Но порог входа все-таки высокий. Я причем имею выборку из довольно большого количества людей, которые учились писать на спарке, в том числе переходили с питона на скалу. Когда я еще в Сбере работал, мы обучили порядка 50 человек, примерно половина из которых до этого не умела писать на питоне особо даже (sql+excel)
Скала к тому же не покрывает всех задач аналитиков и ds-ов. Обычный пайплайн: собрал витринку, сделал toPandas, строишь графики обычным питоновским стеком, модели обучаешь и тд. Дмитрий Бугайченко я помню активно топил за анализ данных прямо на скале (https://habr.com/ru/companies/vk/articles/442688/ например) и даже в ньюпролабах был такой курс. Но это все-таки не мейнстрим.
Но порог входа все-таки высокий.
Ну я 50 человек не учил, у нас всего примерно пятеро подопытных, большинство из которых аналитики, то есть не разработчики (то есть примерно с таким же опытом, как у вас, наверное). В принципе, необходимый уровень скалы — это умение писать функции (по сути — просто оформлять код как функцию), и их комбинировать, практически так же, как в спарке — то есть, map/flatMap/filter, где-то так. Изредка бывают нужны коллекции. Остальное что нужно — ну это вообще базовые вещи типа переменных, типов данных (числовые и строки), регулярки… то есть это может непривычно — но вообще не сложно.
Во времена моей работы в Сбере, у нас все продовые витрины были на скале, и на скале писали ноутбуки аналитики из команды витрин. Но все остальные сидели на pySpark.
В Авито же мы сидим только на pySpark, ибо количество людей тут меньше и объем работы на человека больше. Дата инженеров мало. Аналитик сам должен докатить витрину до airflow и даже тесты написать. Нашими инженерами было принято решение дополнительную технологию пока не затаскивать. Хотя смотря на некоторые монструозные питоновские udf я кусаю локти))
Понятно. Ну да, наличие людей и знание ими технологий — это очень важный факто, который определяет выбор этих самых технологий.
строишь графики обычным питоновским стеком, модели обучаешь и тд
Про графики я почти ничего не знаю, как-то давно не приходилось сталкиваться (но как по мне, неужто для скалы нельзя найти аналоги?). А вот про модели — Spark ML же есть, он прямо совсем-совсем не тянет на замену питоновским инструментам? (Я далек от ML — поэтому вопрос может быть глупый).
Какие-то библиотеки для скалы конечно есть, но по уровню их развития и сообщества несравнимы. Можно сказать, что питоновские либы отлажены на сотнях тысяч если не миллионах пользователей.
Ну меня скорее удивляет то, что многие "питоновские" либы — они же на самом деле написаны на C, к примеру. Или вообще может на фортране :) Ну то есть, сделать к ним еще одну обертку для скалы — в общем задача не сильно сложная. Должна бы быть.
Да, на C много low-level алгоритмов. Но это как правило специальный код, где используются питоновские типы данных. Вот, например, преобразование фурье в numpy. Там его ну никак не отделишь..
Есть библиотеки вроде xgboost или catboost, который написан на cpp и имеют биндинги к нескольким языкам. У них есть версии для JVM. Но это довольно ограниченный набор библиотек
Но также очень много кода (интерфейсного) написано на чистом питоне. И тут вообще никак не отделить
Ну и Spark ML - оч достойный, но узкоспециализированный фрейморк. Он содержит небольшой набор алгоритмов. Популярность не оч высокая. Алгоритмы только параллельные (а не все алгоритмы хорошо параллелятся, поэтому параллелизация дает трейдоффы)
Есть конечно, например, catboost для spark, который мы даже запускали. Но там не все фичи поддерживаются и мы отказались в итоге
Я думаю, основное непонимание возникает из-за различий в специфике работы. Для аналитики разница в уровне проработанности библиотек и развитости коммьюнити между Python и Scala колоссален. Если брать базовую работу аналитика - сделать несколько запросов в БД, определить алгоритм соединения таблиц, в процессе несколько раз проверить count-ы в разных разрезах, вывести сэмплы и подготовить финальную выборку для дальнейшего анализа, то автоматом приходим к тому, что писать надо в ноутбуке, а исторически это Python, хотя все вышеперечисленное можно с успехом написать и на Scala. Но найти на рынке умеющих в Python гораздо легче и можно работать сразу, не перекчивая.
Но вот что касается дальнейшей работы аналитика - построить несколько графиков с выводами, вызвать несколько статистических либ для проведения А/В- теста, или тем более обучить модель - нормальных либ на Scala на данный момент почему-то нет, очевидно из-за комьюнити. И делать это в разных ноутбуках - в одном готовить данные, а в другом обрабатывать - не слишком удобно.
При этом в некоторых кейсах Scala дает кратное преимущество. Например недавно решали DS задачу на графах, и на Scala получилось практически за линейное время обсчитать сотни джойнов с использованием внутреннего rdd-представления - но такие задачи все же возникают редко. Зато чаще возникает необходимость обсчитать например трендовые фичи и в Scala начинаются танцы с бубнами там, где в Python одна строчка)
Да, полностью согласен!
А что за задача если не секрет?)
Ну я бы тут так сказал — конечно, есть смысл писать удобно, но потом же это надо внедрять. И внедрять возможно на другом стеке? Никто же ноутбуки не внедряет, все равно это переписывать в каком-то виде, особенно если данных более-менее много? Ну то есть, аналитик все-таки должен представлять, на каком стеке задача будет решаться в проме.
Но найти на рынке умеющих в Python гораздо легче
Ну это да. На сегодня найти питониста стало (да пожалуй что и было) сильно легче, чем скалиста. Которых, в общем-то, никогда особо много и не было. Я скорее тут про то, что наш скромный опыт показывает, что для использования спарка скалы нужно ну совсем немножко. И человек умеющий на чем-то программировать, само это подмножество может изучить достаточно быстро. Но да, у нас нет ML, как такового, у нас все чуть попроще.
Последняя рекомендация получилась довольно мудреной, да и не всегда на кластере есть хранилище с достаточным объемом памяти, чтоб каждый пользователь мог выгружать такое большие csv. Почему бы не читать parquet пандасом напрямую из файловой системы hdfs?
PySpark для аналитика. Как выгружать данные с помощью toPandas и его альтернатив