«Не вижу ни одного резона использовать Python для работы со Spark, кроме лени» |
||
МЕНЮ Искусственный интеллект Поиск Регистрация на сайте Помощь проекту ТЕМЫ Новости ИИ Искусственный интеллект Разработка ИИГолосовой помощник Городские сумасшедшие ИИ в медицине ИИ проекты Искусственные нейросети Слежка за людьми Угроза ИИ ИИ теория Внедрение ИИКомпьютерные науки Машинное обуч. (Ошибки) Машинное обучение Машинный перевод Реализация ИИ Реализация нейросетей Создание беспилотных авто Трезво про ИИ Философия ИИ Big data Работа разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика
Генетические алгоритмы Капсульные нейросети Основы нейронных сетей Распознавание лиц Распознавание образов Распознавание речи Техническое зрение Чат-боты Авторизация |
2019-03-07 08:31 На днях мы решили пообщаться c Дмитрием Бугайченко (dmitrybugaychenko), одним из наших преподавателей программы "Анализ данных на Scala", и обсудить с ним актуальные вопросы использования Scala в задачах Data Science и Data Engineering. Дмитрий является инженером-аналитиком в "Одноклассниках". — Дима, ты работаешь в Одноклассниках. Расскажи, чем ты там занимаешься? — Давно вы начали использовать 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. J — Дата инженеру нужно знать Scala? Насколько хорошо кстати? Нужно ли уходить в дебри функционального программирования? Знать Scala однозначно надо, хотя бы потому что два таких фундаментальных инструмента как Kafka и Spark написаны на ней, и надо уметь читать их исходники. Что касается «дебрей функционального программирования», то я бы настоятельно советовал ими слишком не злоупотреблять: чем большее количество разработчиков могут прочитать и понять код, тем лучше. Даже если для этого иногда приходится «элегантную» функциональную конструкцию развернуть в банальный цикл. — Вселенная профессий в этой сфере уже перестала расширяться или нам еще ждать возникновения каких-то новых профессий в ней? Я думаю, что в ML и DS в обозримом будущем предстоит перелом, связанный с автоматизацией: основные паттерны, которыми руководствуются люди при работе с признаками, выборе модели и её параметров, проверке качества, будут автоматизированы. Это приведет к тому, что спрос на специалистов, которые «подбирают параметры», существенно снизится, но станут востребованы AutoML-инженеры, способные внедрять и развивать автоматизированные решения. — Ты активно преподаешь, как я понимаю. Почему ты считаешь это важным? Какая мотивация за этим? Все мы когда-нибудь отойдем от дел и качество нашей жизни будет сильно зависеть от того, кто придет нам на смену. Поэтому инвестиции в образование следующего поколения – одни из самых важных. — На нашей программе "Анализ данных на Scala" ты будешь вести несколько занятий. Расскажи коротко про них. В чем их важность? На этих занятиях мы как раз и будем изучать то, как стыкуется инженерия и математика: как правильно организовать процесс, не внося излишних барьеров на пути ETL->ML->Prod. Курс будет строится вокруг возможностей Spark ML: основные концепции, поддерживаемые преобразования, реализованные алгоритмы и их ограничения. Затронем и ту область, где существующих возможностей SparkML недостаточно, и возникает необходимость использовать расширения типа PravdaML. Ну, и обязательно будет практика, причем не только на уровне «собрать решение из готовых кубиков», но и о том как понять, что здесь нужен новый «кубик», и как его реализовать. — Есть какая-то любимая игра слов со Scala? Скалодром, скалолаз, наскальная живопись – используете в своем обиходе? Разве что эпитет «индоскала», который мы используем в адрес особо примечательных кусков опен-сорса, автор которых явно хотел продемонстрировать недюжие способности конструирования нечитаемого кода с использованием функциональных абстракций. — Москва или Питер? В каждом городе есть своя изюминка. Москва – богатый и ухоженный город с быстрым ритмом. Питер спокойнее и наполнен шармом былой европейской столицы. Поэтому я люблю приезжать в Москву в гости, но жить предпочитаю в Питере. Источник: habr.com Комментарии: |
|