Классификация больших объемов данных на Apache Spark с использованием произвольных моделей машинного обучения

[Akson87]

Спасибо за статью, интересно как другие люди с этим мучаются!

Я читал бегло и мог что-то упустить, но я сходу так и не понял, классификация у вас происходит на спарке или живет своей жизнью? Этот внешний сервис где запущен?

[alextokarev]

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

[Cerium]

Очень подробно и классно рассказано. А будет с конкретными практическими кейсами? Помню вашу замечательную историю про анализ женских блогов, там эта же модель использовалась? Есть ли какие-то практические примеры из ритейла, например?

Не в тему, но просьба. И ещё очень бы хотелось услышать, как заказчики относятся к большим данным, видят ли они в этом практический смысл, используют ли выводы и решения? Очень интересная коммерческая сторона осовремененной бигдаты.

[alextokarev]

Спасибо! Вообще, это статья не столько про Data Science и его коммерческое применение, сколько про Software Engineering, поэтому основной акцент я сделал в первую очередь на технологиях, а не практических кейсах. Теоретически, в этой схеме может быть использована любая модель.

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

[art_pro]

Спасибо, что помните о нас! Мы действительно используем корпус женских блогов для того, чтобы наши модели лучше понимали описания продуктов в бьюти-индустрии. Ряд предсказательных и рекомендательных моделей сейчас нами был объединен в самостоятельное решение, про которое мы недавно писали в статье: habr.com/company/lanit/blog/358238. Там же мы разобрали один свежий практический пример про то, как можно научить модель понимать реакцию людей на рассылки.

Описанный в статье подход мы применяли в другом направлении нашей деятельности: на бирже данных 1DMC (http://cleverdata.ru/data-marketing-cloud/), масштабы которой нередко требуют нетипичных и изобретательских решений.

[andrey_kudryavets]

Большое спасибо! Очень интересная статья, с интригой в конце, буду с нетерпением ждать продолжения!
У меня осталось два вопроса:
1. Зачем в статье описываются основы Spark? Кажется, что этого малова-то для целостного понимания работы Spark, а для понимания статьи, вроде как, слишком много подробностей:)
2. Я не совсем понял, зачем приводятся расчеты про ядра, память и количество блоков?

[alextokarev]

При расчете ядер, памяти и количества блоков я хотел наглядно показать, какой максимальный уровень параллелизма нам может позволить YARN на одной машине. Но так, как нам приходится взаимодействовать с внешними сервисами, то возникает простой основных потоков и этого уровня становится недостаточно (смотри рисунки 5 и 6). А описание работы Spark я привел для того, чтобы показать, как запускается задача на машинах кластера на уровне JVM процессов. Это нам пригодится в следующей части.

[Yo1]

какой странный дизайн. зачем же выносить модель с yarn кластера, если было бы много эффективней прямо в спарковском датасете дергать какую-нибудь жава ML библиотеку посерьезней? например jppml дает вполне приличный набор ML алгоритмов.

[alextokarev]

Согласен. Если можно использовать jpmml — то так и нужно поступить. Но в нашем случае была немного другая история:

1. Мы использовали для тренировки модели библиотеку fastText, в которой нет опции сохранения в PMML, а только в бинарный формат.
2. Мы тренировали модель на достаточно большой обучающей выборке, поэтому сама модель получилась порядка 8ГБ в бинарном виде. Мы посчитали, что это будет достаточно накладно хранить ее на каждой машине кластера, и, кроме того, при работе ее приходилось бы полностью загружать в оперативную память, а это значит что на каждой машине мы теряли бы не менее 8 ГБ ОЗУ.

Поэтому было принято решение вынести модель на отдельную машину. Это дало следующие преимущества:

1. Команда Data Scientist-ов получила возможность использовать абсолютно любые средства для своей работы, так как интеграция идет через стандартный HTTP-протокол.
2. Если этот сервис становится узким местом, мы легко можем его горизонтально масштабировать просто добавляя дополнительные машины и равномерно распределяя нагрузку между ними.