«Не вижу ни одного резона использовать Python для работы со Spark, кроме лени»

    На днях мы решили пообщаться c Дмитрием Бугайченко (dmitrybugaychenko), одним из наших преподавателей программы "Анализ данных на Scala", и обсудить с ним актуальные вопросы использования Scala в задачах Data Science и Data Engineering. Дмитрий является инженером-аналитиком в "Одноклассниках".


    image


    — Дима, ты работаешь в Одноклассниках. Расскажи, чем ты там занимаешься?

    В Одноклассниках я начинал работать в 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? Скалодром, скалолаз, наскальная живопись – используете в своем обиходе?


    Разве что эпитет «индоскала», который мы используем в адрес особо примечательных кусков опен-сорса, автор которых явно хотел продемонстрировать недюжие способности конструирования нечитаемого кода с использованием функциональных абстракций.


    — Москва или Питер?


    В каждом городе есть своя изюминка. Москва – богатый и ухоженный город с быстрым ритмом. Питер спокойнее и наполнен шармом былой европейской столицы. Поэтому я люблю приезжать в Москву в гости, но жить предпочитаю в Питере.

    New Professions Lab
    68,00
    Обучение в области работы с данными с 2015 г.
    Поделиться публикацией

    Похожие публикации

    Комментарии 16

      +1
      Про медленные функции на Python интересно — это баг Catalyst?
        0
        Нет — это необходимость активировать интерпретатор Python-а
        +1
        Это точно лень?
        «очень легко отстрелить себе ноги по самые уши – многие конструкции могут вести себя не так, как можно было бы ожидать с позиции здравого смысла, а некоторые простые операции вызывать ненужные копирования и попытки материализации огромных датасетов в памяти.»
          +1
          Это если начать заигрывать с лютой функциональщиной. Если держаться в рамках «понятных среднему пользователю» конструкций то все ± безопасно. В Python, кстати, ничем не лучше в этом плане — одно неловкое движение и у тебя в памяти лишняя копия данных да еще и с адским боксингом.
            0
            Если не пользоваться «лютой функциональщиной» — то вообще неясно, зачем тогда использовать Scala — на Java можно писать.
              +1
              Можно и на Java, получится неплохо. Но кода придется написать все-таки побольше — в Scala есть много и не очень лютой, а вполне удобной и безопасной функциональщины :). Да и Java все больше дрейфует в ту сторону.
                +1
                На сегодняшней Java (а для Hadoop это Java 8) вполне можно. Но на скале таки удобнее.
            0
            Да, python — не Scala, да у python есть GIL. Но мне по ответу в интервью кажется, что автор не до конца понимает, как работает интерпретатор в python и почему же все-таки большинство успешно использует Spark API в связке с python, а у него возникают проблемы, где «питоновский код превращает многотысячеядерный кластер в тыкву и начинает сжигать киловатт/часы на совершенно непродуктивную деятельность». Без более конктреных примеров подобные высказывания — это все не более, чем дилетанство
              +1
              Из недавнего — считали per-user AUC, нужно было пройтись по датафрейму, сгруппировать по пользователю записи, собрать списки и скормить roc_auc из scikit (для Python) или своей реализации на Scala. В одной партиции ~1М юзеров. Scala работает за секунды, Python за минуты.
                0
                С удовольствием прочитаю статью, где будет строго спрофилированы одни и те же задачи на одном и том же железе на python и на scala :)
                  +1
                  Попробую. Spark в режиме master=local[*] подойдет? В кластерном режиме Python еще гемора с дистрибуцией пакетов докидывает и другие задачи будут интерферировать.
                    +1
                    Пока не статья, но воспроизвел кейс: www.zepl.com/viewer/notebooks/bm90ZTovL2RtaXRyeWJ1Z2F5Y2hlbmtvLzQ4ODM3YzlmYzMzNzRlNWRhMjdjZWIzMmVkOTk1MGFlL25vdGUuanNvbg

                    Пока идет процесс подсчета Python честно жжет киловаты на всех 4-х ядрах, в GIL не упирается:

                    ![](https://habrastorage.org/webt/7h/h5/vi/7hh5vix5gwzgibisi7w0ry_nkjg.png)

                    В итоге — PySpark 1 минута 38 секунд, обычный Spark — 2 секунды:

                    ![](https://habrastorage.org/webt/xd/br/r3/xdbrr3otn9dno8jjqe96-9kkwzo.png)

                    «Доктор, что я делаю не так?»

                    UPD: Если убрать использования sklearn, то скорость сопоставима. При этом производительность sklearn самого по себе в этом аспекте на уровне.

                    Вывод такой — Spark умеет UDF до определнной сложности (пока не появляется дополинетльных пакетов) умеет транслировать и запускать почти без оверхеда. Но при появлении использования расширенных пакетов фолбэчится на Python.
                  +2
                  скорее дилетантство сомневаться. спарк читает данные в jvm, что бы отдать интерпретатору питона придется каждый байт прокачать через не быстрый интерфейс, распарсить, превратить в объект. глупо сомневаться что этот бесполезный труд не затормозит процесс во многие разы.
                  0

                  Python vs Scala в данном контексте это скорее культурный, нежели технический конфликт. Так уж сложилось, что мир JVM настолько ушел в сторону от условного мира PHP/Python/Ruby/Go, что разработчики друг друга с трудом понимают вообще. И когда в BigData рядом оказались Java/Scala и Python/R у обоих сторон вышел культурный шок.

                    +1
                    Нет тут никакого культурного конфликта. Вот я постоянно пишу на Java, немножко на скала. Но при этом у имею примерно 10 лет опыта Python. И когда мне начинают рассказывать, как там все удобно, уж позвольте мне не верить — потому что я реально знаю, что как язык, к примеру, тот же groovy (а сегодня котлин) ни в чем питону не уступают, а во многом его и превосходят. И они мне все при использовании спарка доступны. И тот же юпитер (или Zeppelin) поддерживают по большому счету что скалу, что питон одинаково. Разница есть, ясное дело, как не быть — но она по большому счету в библиотеках.

                    Ну или посмотрите на недавнюю статью про то, как все клево можно делать в пандас. При этом речь идет о примерно 15Gb наборе данных. Откуда у меня должен быть культурный шок, если мои задачи на работе выглядят примерно как «обработать вон тот 30Tb набор за час, и не выжрать при этом больше 1000 ядер»?
                      0
                      Так еще относительно недавно это был технический аспект, ибо поддержка Питона там была такая, что только обнять и плакать.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое