На днях решили пообщаться с Дмитрием Бугайченко ( Дмитрийбугайченко ), одного из наших преподавателей программы Data Analysis in Scala, и обсудить с ним актуальные вопросы использования Scala в задачах Data Science и Data Engineering. Дмитрий — инженер-аналитик в «Одноклассниках».
— Дима, ты работаешь в «Одноклассниках».
Скажи мне, что ты там делаешь? Я начал работать в Одноклассниках в 2011 году над проектом музыкальных рекомендаций.
Это была очень интересная и сложная задача — большинство музыкальных рекомендательных сервисов в то время основывались на хорошо каталогизированном издательском контенте, тогда как у нас был настоящий UGC (пользовательский контент), который нужно было сначала прочесать и отсортировать.
В целом получившаяся система работала достаточно хорошо, и они решили распространить этот опыт на другие разделы сайта: рекомендации групп, дружбу, рейтинг ленты и т. д. При этом команда росла, инфраструктура развивалась, появлялись новые алгоритмы и были внедрены технологии.
Сейчас у меня достаточно широкий круг обязанностей: координация усилий специалистов по обработке данных, развитие инфраструктуры ЦОД, исследовательские проекты и т. д. — Как давно вы начали использовать Spark? Какая была необходимость? Первые попытки подружиться со Спарком были еще в 2013 году, но успеха не имели.
У нас была острая потребность в мощном интерактивном инструменте, который мог бы быстро проверять гипотезы, но Spark в то время не мог обеспечить необходимую нам стабильность и масштабируемость.
Вторую попытку мы предприняли год спустя, в 2014 году, и на этот раз все получилось гораздо лучше.
В этом же году мы начали внедрять инструменты потоковой аналитики на базе Kafka и Samza, пробовали также Spark Streaming, но тогда он не смог запуститься.
Благодаря относительно раннему внедрению, к 2017 году мы на какое-то время оказались в догоняющей позиции — большой объём кода на первом Спарке не позволил нам перейти на второй, но летом 2018 года мы решили эту проблему и сейчас работаем над 2.3.3. В этой версии стриминг уже начал работать более стабильно и мы уже проделали над ним некоторые новые производственные задачи.
— Насколько я понимаю, вы используете Scala API, а не Python, как большинство людей.
Почему это? Честно говоря, я не вижу никакой причины использовать Python для работы со Spark, кроме лени.
API Scala более гибок и гораздо более эффективен, но при этом не усложнен.
Если вы используете стандартные возможности Spark SQL, то код Scala практически идентичен соответствующему коду Python, а скорость будет идентична.
Но если попытаться сделать простейшую пользовательскую функцию, разница становится очевидной — код Scala остается столь же эффективным, тогда как код Python превращает многотысячный кластер в тыкву и начинает сжигать киловатты/часы на совершенно непродуктивные действия.
.
В тех масштабах, с которыми нам приходится работать, мы просто не можем позволить себе такую расточительность.
— Питон понятен.
А если сравнивать с Java, Scala чем-то лучше подходит для анализа данных? В Java многое записывается в стек больших данных.
В нашей стране Java используется очень широко, в том числе в машинном обучении.
Мы стараемся не задерживать самые загруженные приложения Scala. Но когда дело доходит до интерактивного анализа и быстрого прототипирования, краткость Scala становится плюсом.
Однако всегда следует помнить, что при программировании на Scala очень легко выстрелить себе в ногу — многие проекты могут вести себя не так, как можно было бы ожидать с точки зрения здравого смысла, а некоторые простые операции вызывают ненужное копирование и попытки материализовать огромные наборы данных в памяти.
— При всех этих преимуществах, почему Scala пока не так популярна? Он явно превосходит Python и Java, верно? Scala — очень мощный инструмент, требующий достаточно высокой квалификации от того, кто его использует. Кроме того, при командной разработке накладываются дополнительные требования к общему уровню культуры разработки: код Scala пишется очень легко, но не всегда читается через некоторое время даже автором, а под капотом простого API какие-то безумные вещи.
может случиться.
Поэтому особое внимание следует уделить поддержанию единого стиля, функциональному и нагрузочному тестированию решения.
Ну и при сравнении JVM-языков нельзя не упомянуть Kotlin — он набирает популярность, считается многими более «идеологически выверенным» и даже поддерживает Spark в рамках проекта sparklin, хотя пока в очень ограниченном виде.
Сами мы пока не используем его для Spark, но внимательно следим за развитием.
— Вернёмся к Спарку.
Я так понимаю, вас всё равно не устроил даже этот функционал Scala API и вы написали какой-то форк для Spark? Назовите наш проект ПравдаМЛ форк был бы неправильным: эта библиотека не заменяет, а скорее дополняет функциональность SparkML новыми возможностями.
Мы пришли к решениям, которые там реализованы, пытаясь масштабировать и поставить модели ранжирования ленты на воспроизводимые рельсы.
Дело в том, что при разработке эффективных алгоритмов распределенного машинного обучения необходимо учитывать множество «технических» факторов: как правильно распределять данные по узлам, в какой момент кэшировать, понижать дискретизацию и т. д. В стандартном SparkML нет возможности контролировать эти аспекты, и их приходится вынимать из конвейера МО, что негативно влияет на управляемость и воспроизводимость.
— Я помню, у вас было два варианта имени.
Да, оригинальное название ok-ml-pipelines показалось ребятам скучным, поэтому сейчас мы проводим «ребрендинг» с новым названием PravdaML. — Много ли людей используют его за пределами вашей команды? Я не думаю, что это много, но мы над этим работаем.
Дж — Давайте теперь поговорим о ролях и профессиях в области науки о данных.
Скажите, а должен ли Data Scientist писать код на производстве или это какая-то другая профессия и роль? В ответе на этот вопрос содержится мое мнение и суровая реальность.
Я всегда считал, что для успешного внедрения ML-решений человек должен понимать, где и зачем это все внедряется (кто пользователь, каковы его потребности и каковы потребности бизнеса), должен понимать, какие математические методы могут могут быть использованы для разработки решения, а также то, как эти методы могут работать с технической точки зрения.
Поэтому мы в «Одноклассниках» по-прежнему стараемся придерживаться модели единой ответственности, когда человек выдвигает какую-то инициативу, реализует ее и реализует. Конечно, для решения отдельных конкретных вопросов, будь то эффективная СУБД или интерактивная верстка, всегда можно привлечь людей с большим опытом работы в этих областях, но интеграция всего этого в единый механизм остается за датасайентистом, как человеком, который лучше всего понимает, что именно и как должно работать на выходе.
Но есть и суровая реальность на рынке труда, который сейчас очень перегрет в сфере ML, что приводит к тому, что многие молодые специалисты не считают необходимым изучать что-либо помимо самого ML. В результате найти специалиста полного цикла становится все сложнее.
Хотя недавно появилась хорошая альтернатива: практика показала, что хорошие программисты достаточно быстро и неплохо осваивают ML. Дж — Нужно ли дата-инженеру знать Scala? Кстати, насколько хорош? Стоит ли идти в дебри функционального программирования? Знать Scala обязательно нужно хотя бы потому, что на ней написаны два таких фундаментальных инструмента, как Kafka и Spark, и нужно уметь читать их исходный код. Что касается «дикости функционального программирования», то я бы настоятельно советовал не злоупотреблять ею: чем больше разработчики смогут прочитать и понять код, тем лучше.
Даже если для этого иногда требуется расширить «изящный» функциональный дизайн до банального цикла.
— Мир профессий в этой сфере уже перестал расширяться, или нам все же следует ожидать появления в нем каких-то новых профессий? Я думаю, что в ML и DS в обозримом будущем наступит переломный момент, связанный с автоматизацией: будут автоматизированы основные закономерности, которыми руководствуются люди при работе с фичами, выборе модели и ее параметров, проверке качества.
Это приведет к тому, что спрос на специалистов, которые «подбирают параметры», существенно снизится, но востребованными станут AutoML-инженеры, способные внедрять и разрабатывать автоматизированные решения.
— Вы, насколько я понимаю, активно преподаете.
Почему вы думаете, что это важно? Какова мотивация этого? Когда-нибудь мы все выйдем на пенсию, и качество нашей жизни будет во многом зависеть от того, кто нас заменит. Поэтому инвестиции в образование следующего поколения являются одними из важнейших.
- В нашей программе «Анализ данных в Scala».
вы будете преподавать несколько классов.
Расскажите вкратце о них.
Почему они важны? На этих занятиях мы будем изучать, как именно сочетаются инженерия и математика: как правильно организовать процесс, не создавая лишних барьеров на пути ETL-> ML-> Prod. Курс будет построен на возможностях Spark ML: базовых концепциях, поддерживаемых преобразованиях, реализованных алгоритмах и их ограничениях.
Затронем также ту область, где существующих возможностей SparkML недостаточно и возникает необходимость использования расширений типа PravdaML. Ну и практика обязательно будет не только на уровне «сборки решения из готовых кубиков», но и того, как понять, что здесь нужен новый «куб», и как его реализовать.
— Есть ли у вас любимый каламбур со Scala? Стенка для скалолазания, скалолаз, наскальная живопись – используете ли вы это в повседневной жизни? Возможно, эпитет «индоскал», который мы используем по отношению к особенно замечательным фрагментам открытого исходного кода, автор которых явно хотел продемонстрировать замечательную способность строить нечитаемый код с помощью функциональных абстракций.
- Москва или Санкт-Петербург? В каждом городе есть своя изюминка.
Москва – богатый и ухоженный город с быстрым темпом жизни.
Санкт-Петербург более спокойный и наполнен очарованием бывшей европейской столицы.
Поэтому я люблю приезжать в Москву в гости, но жить предпочитаю в Питере.
Теги: #Машинное обучение #python #Большие данные #java #spark #scala #production
-
Женское Тело Как Инструмент Btl-Рекламы
19 Oct, 24
