На днях мы решили пообщаться c Дмитрием Бугайченко (dmitrybugaychenko), одним из наших преподавателей программы "Анализ данных на Scala", и обсудить с ним актуальные вопросы использования Scala в задачах Data Science и Data Engineering. Дмитрий является инженером-аналитиком в "Одноклассниках".
— Дима, ты работаешь в Одноклассниках. Расскажи, чем ты там занимаешься?
В Одноклассниках я начинал работать в 2011-м году над проектом рекомендаций музыки. Это была очень интересная и непростая задача – большинство сервисов рекомендаций музыки на тот момент базировались вокруг хорошо каталогизированного издательского контента, тогда как у нас был настоящий UGC (user generated content), который надо было сначала причесать и разложить по полочкам. В целом, получившаяся система показала себя достаточно хорошо и опыт решили распространять на другие разделы сайта: рекомендации групп, дружб, ранжирование ленты и т.д. Параллельно с этим росла и команда, развивалась инфраструктура, внедрялись новые алгоритмы и технологии. Сейчас у меня достаточно широкий круг обязанностей: координация усилий дата саентистов, развитие ДС-инфраструктуры, исследовательские проекты и т.д.
— Давно вы начали использовать Spark? В чем возникла потребность?
Первые попытки подружится со Spark были еще в 2013-м году, но успехом не увенчались. У нас была насущная потребность в мощном интерактивном инструменте, позволяющем быстро проверять гипотезы, но Spark того времени не смог обеспечить нужную нам стабильность и масштабируемость. Вторую попытку мы сделали через год, в 2014-м, и в этот раз все получилось гораздо лучше. В тот же год мы стали внедрять и инструменты потоковой аналитики на базе Kafka и Samza, пробовали и Spark Streaming, но тогда он не смог завестись. Из-за относительно раннего внедрения к 2017-му мы на некоторое время оказались в положении догоняющих – большое количество кода на первом Spark мешало нам перейти на второй, но летом 2018-го мы эту проблему решили и теперь работаем на 2.3.3. В этой версии стриминг уже заработал более стабильно и некоторые новые продовые задачи мы уже делали на нем.
— Насколько я понимаю, вы пользуетесь Scala API, а не Python, как большинство. Почему так?
Я искренне не вижу ни одного резона использовать Python для работы со Spark, кроме лени. Scala API гибче и гораздо эффективнее, при этом не сложнее. Если вы пользуетесь стандартными возможностями Spark SQL, то Scala-код практически идентичен соответствующему коду на Python, идентична будет и скорость работы. Но если вы попробуете сделать простейшую пользовательскую функцию, разница становится очевидна – работа кода на Scala остается такой же эффективной, а питоновский код превращает многотысячеядерный кластер в тыкву и начинает сжигать киловатт/часы на совершенно непродуктивную деятельность. На тех масштабах, с которыми нам приходится работать, мы просто не можем позволить себе такую расточительность.
— C Python понятно. А если сравнивать с Java, то Scala чем-то лучше вообще для анализа данных? На Java много чего написано в стэке big data.
Java используется у нас очень широко, в том числе и в машинном обучении. В самые высоконагруженные приложения Scala мы стараемся не тянуть. Но если речь идет об интерактивном анализе и быстром прототипировании, лаконичность Scala становится плюсом. Правда надо всегда иметь в виду, что программируя на Scala, очень легко отстрелить себе ноги по самые уши – многие конструкции могут вести себя не так, как можно было бы ожидать с позиции здравого смысла, а некоторые простые операции вызывать ненужные копирования и попытки материализации огромных датасетов в памяти.
— При всех этих преимуществах почему Scala не настолько популярна еще? Она же явно выигрывает у Python и Java?
Scala – это очень мощный инструмент, который требует достаточно высокой квалификации от того, кто её использует. Кроме того, при командной разработке дополнительные требования накладываются и на общий уровень культуры разработки: код на Scala пишется очень легко, но не всегда с успехом читается даже автором через некоторое время, а под капотом простого API может творить какую-нибудь дичь. Поэтому особое внимание надо уделять поддержанию единого стиля, функциональному и нагрузочному тестированию решения.
Ну, и проводя сравнение JVM-языков, нельзя не упомянуть Kotlin – он набирает популярность, считается многими более «идеологически выверенным», и даже поддерживает Spark в рамках проекта sparklin, пока правда в очень ограниченном виде. Сами мы его для Spark пока не используем, но внимательно следим за развитием.
— Вернемся к Spark. Как я понимаю, вас все равно не устраивала даже эта функциональность Scala API и вы написали какой-то свой форк к Spark?
Называть наш проект PravdaML форком было бы неправильно: эта библиотека не заменяет, а дополняет функционал SparkML новыми возможностями. К тем решениям, которые там реализованы, мы пришли, пытаясь масштабировать и поставить на воспроизводимые рельсы модели ранжирования ленты. Дело в том, что при разработке эффективных распределённых алгоритмов машинного обучения, нужно учитывать много «технических» факторов: как правильно разложить данные по узлам, в какой момент закешировать, задаунсэмплить и т.д. В стандартном SparkML нет возможности управлять этими аспектами, и их приходится выносить за рамки ML-пайплайна, что негативно сказывается на управляемости и воспроизводимости.
— Я помню у вас было два варианта названия…
Да, оригинальное название ok-ml-pipelines показалось ребятам скучным, поэтому мы сейчас в процессе «ребрендинга» с новым названием PravdaML.
— Много людей им пользуются за пределами вашей команды?
Не думаю, что много, но мы работаем над этим. J
— Давай теперь поговорим о ролях и профессиях в сфере работы с данными. Скажи, data scientist должен писать код в продакшен или это уже какая-то другая профессия и роль?
В ответе на этот вопрос есть мое мнение, и есть суровая реальность. Я всегда считал, что для успешного внедрения ML-решений человек должен понимать, куда и зачем это все внедряется (кто пользователь, какие у него потребности, а какие потребности у бизнеса), должен понимать какие математические методы могут быть применены для разработки решения, и как эти методы могут работать с технической точки зрения. Поэтому в Одноклассниках мы до сих пор стараемся придерживаться модели единой ответственности, когда человек выступает с некоторой инициативой, реализует и внедряет её. Конечно, для решения отдельных частных вопросов будь то эффективная СУБД или интерактивная верстка всегда можно привлечь людей с большим опытом в этих областях, но интеграция всего этого в единый механизм остается за дата саентистом, как человеком лучше всего понимающим, что именно и как должно работать на выходе.
Но есть и суровая реальность на рынке труда, который сейчас очень сильно перегрет в области ML, что приводит к тому, что многие молодые специалисты не считают нужным изучать что-либо помимо собственно ML. В итоге найти специалиста «полного цикла» становится все сложнее. Хотя в последнее время появилась неплохая альтернатива: практика показала, что хорошие программисты достаточно быстро и весьма неплохо осваивают ML. J
— Дата инженеру нужно знать Scala? Насколько хорошо кстати? Нужно ли уходить в дебри функционального программирования?
Знать Scala однозначно надо, хотя бы потому что два таких фундаментальных инструмента как Kafka и Spark написаны на ней, и надо уметь читать их исходники. Что касается «дебрей функционального программирования», то я бы настоятельно советовал ими слишком не злоупотреблять: чем большее количество разработчиков могут прочитать и понять код, тем лучше. Даже если для этого иногда приходится «элегантную» функциональную конструкцию развернуть в банальный цикл.
— Вселенная профессий в этой сфере уже перестала расширяться или нам еще ждать возникновения каких-то новых профессий в ней?
Я думаю, что в ML и DS в обозримом будущем предстоит перелом, связанный с автоматизацией: основные паттерны, которыми руководствуются люди при работе с признаками, выборе модели и её параметров, проверке качества, будут автоматизированы. Это приведет к тому, что спрос на специалистов, которые «подбирают параметры», существенно снизится, но станут востребованы AutoML-инженеры, способные внедрять и развивать автоматизированные решения.
— Ты активно преподаешь, как я понимаю. Почему ты считаешь это важным? Какая мотивация за этим?
Все мы когда-нибудь отойдем от дел и качество нашей жизни будет сильно зависеть от того, кто придет нам на смену. Поэтому инвестиции в образование следующего поколения – одни из самых важных.
— На нашей программе "Анализ данных на Scala" ты будешь вести несколько занятий. Расскажи коротко про них. В чем их важность?
На этих занятиях мы как раз и будем изучать то, как стыкуется инженерия и математика: как правильно организовать процесс, не внося излишних барьеров на пути ETL->ML->Prod. Курс будет строится вокруг возможностей Spark ML: основные концепции, поддерживаемые преобразования, реализованные алгоритмы и их ограничения. Затронем и ту область, где существующих возможностей SparkML недостаточно, и возникает необходимость использовать расширения типа PravdaML. Ну, и обязательно будет практика, причем не только на уровне «собрать решение из готовых кубиков», но и о том как понять, что здесь нужен новый «кубик», и как его реализовать.
— Есть какая-то любимая игра слов со Scala? Скалодром, скалолаз, наскальная живопись – используете в своем обиходе?
Разве что эпитет «индоскала», который мы используем в адрес особо примечательных кусков опен-сорса, автор которых явно хотел продемонстрировать недюжие способности конструирования нечитаемого кода с использованием функциональных абстракций.
— Москва или Питер?
В каждом городе есть своя изюминка. Москва – богатый и ухоженный город с быстрым ритмом. Питер спокойнее и наполнен шармом былой европейской столицы. Поэтому я люблю приезжать в Москву в гости, но жить предпочитаю в Питере.
