Moscow Spark #6

Создание кастомных Source и Sink для Structured Streaming

Андрей Титов, senior Spark engineer @ NVIDIA

Structured Streaming API, появившийся во второй версии Apache Spark, существенно упростил разработку стриминг приложений. Разработчики Spark подумали и о тех, кому не хватает штатного набора коннекторов. В докладе я расскажу про свой опыт создания стриминг Source и Sink на основе Datasource API​.

Распределенная Байесовская оптимизация гиперпараметров для SparkML и не только

Дмитрий Бугайченко, инженер-аналитик @ OK.ru

Основное преимущество систем распределенной обработки данных, таких как Spark, заключается в возможности использования большого количества вычислительных ядер. Однако в задачах машинного обучения далеко не всегда удается это преимущество реализовать — затраты на коммуникацию между узлами перевешивают выигрыш в процессорном времени. Но есть случаи когда Spark может помочь ML выйти на принципиально новый уровень по скорости – когда нам нужно учить несколько моделей одновременно. Например, если мы подбираем гиперпараметры ML алгоритма. В рамках рассказа мы рассмотрим как задача поиска оптимальных параметров решается в открытом пакете OK-ML с применением методов Байесовской оптимизации и параллельной оценке различных конфигураций.

Бакетирование на стероидах

Лоокуут Стручков, разработчик аналитических систем КХД​ @ МегаФон

В рамках доклада мы вспомним как работает join двух датафреймов в Spark и поймем почему это очень дорогая операция. Попробуем сами оптимизировать данный метод, затем ускорим его с помощью бакетирования. И конечно же сравним по производительности каждый из способов​.

Dataflow-платформа на Spark​

Михаил Славошевский, ведущий дата-инженер @ ЦИАН

Данные от продуктовых команд к нам приходят через Kafka. Как правило это отчётные события об изменении каких-то сущностей в формате JSON. Для того, чтобы впоследствии эти данные можно было использовать для построения обучающих выборок, витрин для BI или построения продуктовых отчётов для пользователей, надо эти события доставлять до HDFS и/или быстрых хранилищ данных типа Сassandra и ElasticSearch. Для этого мы написали лоадер — утилита, которая читает конкретный топик из Kafka и пишет то, что ещё не записано, в целевое хранилище. Храним оффсеты в фениксе для достижения exactly once. Лоадер принимает на вход название файла с конфигом для этого конкретного потока — читает его из HDFS и после парсинга определяет, какой топик читать, куда писать. При этом кладёт JSON не как есть, а применяет к нему SQL-ный запрос для того, чтобы из JSON’а получить DataFrame. При этом для батч-обработки SQL-запросы почти все одинаковые, поэтому тулза сама их генерит по конфигам из JSON’ов. Расскажу подробнее, что пробовали, на какие грабли наступали, к чему пришли, что в планах.​

Как добраться?