Комментарии 17
Большое спасибо за статью!
Для меня остается загадкой — почему Data-Scientists все еще пишут код? Очевидно же, что занимаются сильно шаблонизированными операциями на конвейере. Почему до сих пор не автоматизировали это все и не свели в единую информационную систему? Зачем весь этот мартышкин труд в виде ручной обработки данных?
И да, так и не увидел не надуманных преимуществ Scala перед Python. Реклама Золотого молотка?
И да, так и не увидел не надуманных преимуществ Scala перед Python. Реклама Золотого молотка?
Насчет мартышкиного труда в точку — именно тот факт что этот мартышкин труд пока не автоматизирован и приводит к перегреву рынка ДС. Но ситуация меняется и термин auto-ml звучит все чаще. В рамках того же PravdaML мы уже начинаем внедрять разные его аспекты.
Ну и в этом же кроется и ответ в чем Scala лучше Python — в Python все работает быстро только до тех пор, пока вы пользуетесь стандартными бибилотеками через стандартный API. Как только появляется необходимость сделать что-то нестандартное, хотя бы apply(lambda ...) в Pandas, производительность падает в разы — приходится подключать интерпретатор к массовой обработке. Когда вы используете Scala — смело можно креативить, негативного эффекта на производительность не будет.
Ну и в этом же кроется и ответ в чем Scala лучше Python — в Python все работает быстро только до тех пор, пока вы пользуетесь стандартными бибилотеками через стандартный API. Как только появляется необходимость сделать что-то нестандартное, хотя бы apply(lambda ...) в Pandas, производительность падает в разы — приходится подключать интерпретатор к массовой обработке. Когда вы используете Scala — смело можно креативить, негативного эффекта на производительность не будет.
Я думаю, главный плюс Scala не в скорости исполнения, а в статической типизации. Компилятор проверяет типы за вас, что исключает целый класс ошибок. Плюс первоклассная поддрежка immutability, что исключает еще один класс ошибок. Но подобные вещи обычно выходят на первый план на масштабах чуть больших, чем пара ноутбуков в зеппелине.
>И да, так и не увидел не надуманных преимуществ Scala перед Python.
А то что Scala (для определенности — в случае Spark, но и в некоторых других случаях, кроме например nympy) по производительности лучше на порядок-другой-третий — для вас разве не преимущество?
Кроме того, вот вам еще явное преимущество — языки на платформе JVM не требуют установки пакетов как таковой. То есть, вы можете запуститься на любом узле кластера, ничего там заранее не настраивая. Правда, это применимо к кластерам, типа Hadoop.
А то что Scala (для определенности — в случае Spark, но и в некоторых других случаях, кроме например nympy) по производительности лучше на порядок-другой-третий — для вас разве не преимущество?
Кроме того, вот вам еще явное преимущество — языки на платформе JVM не требуют установки пакетов как таковой. То есть, вы можете запуститься на любом узле кластера, ничего там заранее не настраивая. Правда, это применимо к кластерам, типа Hadoop.
dmitrybugaychenko, спасибо, крутейшая статья! Также как и PravdaML — присматриваемся к этому продукту.
Есть вопрос — вы описали Pipeline, включающий в себя подготовку данных, векторизацию фич, и прочее. Этот Pipeline применяется только в batch-обработке через Spark, или доступен в real-time предсказаниях?
Мы у себя внедряем Pipeline на Spark, но для исполнения модели используем JPMML и MLEAP движки (существенно быстрее дают предсказания чем Spark с master=local[*]). Как следствие, у нас нет таких вкусных трансформеров как SQLTransformer (требует Spark-контекст, и довольно забагованная реализация, и только у JPMML). В связи с этим интересно узнать, как вы у себя строите сервисы для real-time предсказаний?
Есть вопрос — вы описали Pipeline, включающий в себя подготовку данных, векторизацию фич, и прочее. Этот Pipeline применяется только в batch-обработке через Spark, или доступен в real-time предсказаниях?
Мы у себя внедряем Pipeline на Spark, но для исполнения модели используем JPMML и MLEAP движки (существенно быстрее дают предсказания чем Spark с master=local[*]). Как следствие, у нас нет таких вкусных трансформеров как SQLTransformer (требует Spark-контекст, и довольно забагованная реализация, и только у JPMML). В связи с этим интересно узнать, как вы у себя строите сервисы для real-time предсказаний?
Мы пробовали JPMML, но не завелся совсем по скорости. В итоге пришли к тому что пока в прод выдергиваем только «ядро» — бинарник хгбуста или матрицы весов. Но! Сейчас смотрим в сторону варианта со Structured Streaming — основная проблема с использованием батч режима и master=local[*] в том что постоянно крутится постороение плана и оптимизация, а в стриминге он построится один раз. Но пока готового решения нет — когда допилим, отдельно расскажем.
а вы как jppml запускали? как полагается, внутри спаркового датасета? а то я смотрю многие рисуют рест сервисы и долбят по рест, удивляясь чего так медленно.
Здесь Женя Малютин рассказывал на примере хгбуста: vk.com/video-133150806_456239018 Там даже датасета как такового не было — просто попытали XGBoost завернуть в типа model-agnostic обертку и кормили её векторами с ложечки. Без реста — все инпроцесс в яве.
Поясните, пожалуйста, почему использование JPMML через REST это плохо?
Что значит «как полагается, внутри спаркового датасета»?
Что значит «как полагается, внутри спаркового датасета»?
Накладные расходы. Нам, например, нужно уметь получать тысячи скоров за десятки миллисекунд, поэтому самые критичные блоки работают без REST, а, в идеале, вообще без удаленных вызовов. Хотя при желании многое можно порешать собирая задачи в пакеты.
У нас ситуация, когда встраивание model-evaluation (Java) в application-сервер (PHP) не доступно. Я хотел понять, почему Yo1 называл это анти-паттерном для JPMML. В случае batch-обработки я бы, наверное, оставил бы Spark + master=local[*] для пайплайнов. Но у нас ситуация с единичными предсказаниям. В сравнении JPMML и MLEAP пока побеждает первый, с примерно 100ms на запрос. Пытался понять, можно ли для такого кейса где-то подшаманить, чтобы сделать 10ms :)
я имел ввиду не единичный вызов, а батч обработку миллионов клиентов. что-то типа такого
т.е. датасет на каждом узле кластера поднимает тучи параллельных воркеров в каждом свои копии моделей и вся обработка в параллель. при этом jpmml и данные в едином jvm процессе. нет оверхеда с копированием данных в соседний процесс или чего хуже на соседний сервер с парсингом json + rest.
но у вас с Дмитрием похоже другой юзкейс. вам надо не миллионы прожувать за минуты, а один один за миллисекунды. тут мне кажется спарк ничем не поможет особо.
Dataset<Row> scores = mydata
.map((MapFunction<Row, Tuple3<String, Long, Double>>) row ->
chooseModel(row, models).getScore(row), Encoders.tuple(Encoders.STRING(), Encoders.LONG(), Encoders.DOUBLE()))
.toDF("client", "model", "score");
т.е. датасет на каждом узле кластера поднимает тучи параллельных воркеров в каждом свои копии моделей и вся обработка в параллель. при этом jpmml и данные в едином jvm процессе. нет оверхеда с копированием данных в соседний процесс или чего хуже на соседний сервер с парсингом json + rest.
но у вас с Дмитрием похоже другой юзкейс. вам надо не миллионы прожувать за минуты, а один один за миллисекунды. тут мне кажется спарк ничем не поможет особо.
Огромное спасибоа за статью. Сам уже 5 лет пишу на Scala для задач Data Science и ML. Но это в продакшн, поэтому Scala нам больше подходит. Сотни тысяч строчек кода.
PS: С удовольствием бы пообщался с выпускниками на предмет трудоустройства у нас
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анализ данных на Scala — суровая необходимость или приятная возможность?