Хорошо осенью любоваться на озёра… на озёра данных. Особенно когда про них говорит спикер Владимир Озеров. В общем, этой осенью, как и раньше, мы проведём конференцию SmartData обо всём, что важно в дата-инжиниринге: от отказоустойчивости до MLOps.

6-7 сентября пройдёт онлайн-часть, а 13-14 сентября встретимся в Москве (но все, кто не готов добраться на московскую площадку, смогут и во второй части поучаствовать удалённо).  

Среди тем — и архитектура дата-платформ, и «внутренности» баз данных, и стриминг, и DataOps, и даже пара «космических» (в буквальном смысле) докладов. А среди спикеров есть те, чьи доклады уже хвалили участники прошлых SmartData — например, Максим Бабенко, Дмитрий Аношин, Евгений Ермаков и Максим Стаценко. Все описания докладов — под катом.

Оглавление

• Инструменты

• Архитектура дата-платформ

• Базы данных «под капотом»

• Use cases

• Стриминг

• Управление данными

• DataOps

• Космос

---

Инструменты

dbt — ядро современной платформы данных

dbt — один из самых быстро набирающих популярность инструментов в сфере построения платформ и хранилищ данных. Сочетание простоты и функциональности этого инструмента подкупило и команду Toloka.ai при создании новой платформы данных. Но серебряных пуль не бывает: как и в любом open source-продукте не обошлось без «доработок напильником». Евгений расскажет про их опыт применения dbt и доработках, которые пришлось сделать.

---

Как перевести отчетность в чат-бота Microsoft Teams, используя Apache Airflow

Выгрузка отчетности на постоянной основе может стать сильной головной болью для DE, которую хочется решить автоматическим процессом. Но встает вопрос: какие инструменты можно использовать, чтобы позволить пользователям самим выгружать требуемые отчеты и перестать дергать DE?

В докладе будет показан кейс автоматизации выгрузок отчетности с использованием Microsoft Teams и Apache Airflow. Наравне с этим будут показаны ограничения системы и почему была выбрана именно эта связка компонентов.

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

---

Apache Flink под капотом: distributed, stateful, realtime

Apache Flink — фреймворк и движок для распределенной stateful-обработки потоков данных. В Авито его используют для realtime-обработки потока событий. Поскольку у них довольно высокая нагрузка, производительность очень важна. За время работы с ним Валентина и ее команда столкнулись с неявными сложностями Flink и осознали, насколько важно понимать устройство фреймворка под капотом. Валентина расскажет, что значит каждая из фич Apache Flink и как правильно с ними работать.

---

CDC. От баззворда к реализации в Data Transfer

CDC (Change data capture) — подход для решения задач интеграции данных. 

Тимофей расскажет про его особенности, рассмотрит рыночные решения и поговорит о том, с какими вызовами столкнулись при его реализации в сервисе Data Transfer в Яндекс Облаке.

---

Возможна ли жизнь с open source BI в большой компании

Больно ли заменять устоявшийся годами BI-инструмент на что-то новое, да еще и open source? Илья расскажет, как они выбирали инструмент, с какими трудностями столкнулись и как на все это реагировали пользователи. Он поделится опытом, насколько сложно дорабатывать open source-продукт и как они собирают фичи от пользователей. Спустя полгода можно с уверенностью сказать, что удалось довести новое BI до состояния полноценной замены проприетарного продукта, но какой ценой…

---

Как сделать так, чтобы вашему Apache NiFi было плохо

NiFi — очень мощный инструмент, и им можно закрыть очень широкий спектр задач. Однако есть задачи, которые заставляют NiFi чувствовать себя не очень хорошо. Бронислав поделится своим взглядом на такие задачи.

---

Разгоним запросы: как быстро готовить ClickHouse

Одна из самых используемых сегодня OLAP open-source баз данных — это Clickhouse. В ней много концептов, которые характерны только для нее. Поэтому легко можно «выстрелить в ногу» и не получить того, зачем ее выбирают многие пользователи — мгновенной скорости обработки запросов. Кузьма рассмотрит 4 основных способа ускорения выполнения запроса и приведет обезличенные примеры о них из опыта траблшутинга технической поддержки Яндекс Облака. Посмотрим на шардирование, проекции, индексы и конфигурации железа в облаке.

---

Apache Flink на примере задачи дедупликации

Александр расскажет о фреймворке потоковой обработки данных Apache Flink. Вы узнаете об архитектуре и основных компонентах Flink на примере дедупликации потока событий.

Основная тема — обсуждение проблем, с которыми можно столкнуться при первом опыте написания Flink-задач, их длительной поддержке на проде, а также при увеличении нагрузки на приложение. Будут затронуты подходы к написанию кода на примере языка Java, механизмы обеспечения High Availability, процессы сериализации и другие внутренние процессы.

---

Mage: волшебный инструмент оркестрации

С появлением новых инструментов становится все сложнее решить, какой технологический стек лучше для начала нового проекта или же миграции с legacy-контура. Для облегчения этого процесса всегда лучше знать о новых возможностях и альтернативных технологиях.

Один из таких новых фреймворков — инструмент оркестрации Mage, о котором пойдет речь в докладе. Валентин также расскажет историю одного переезда с legacy-стека по работе с данными на новый.

---

Поиск без границ. Путь к точному и масштабируемому поиску в каталоге данных

Иван расскажет:

• как в их data-каталоге внедряли поисковый движок ElasticSearch/OpenSearch на замену обычному запросу в базу данных;

• какой способ ранжировать поисковую выдачу они придумали;

• с какими проблемами столкнулись при внедрении;

• куда планируют развивать поиск дальше.

---

Развитие инструмента аналитики DataOps BI на основе open source

Доклад об идее использования open source BI, про пилотирование различных решений, сбор команды BI-инструмента и развитие с учетом требований новых пользователей и команд, мигрирующих из проприетарного ПО (Tableau, Power BI). Отдельно рассматриваются сложности миграции на конкретных примерах.

---

Kafka Connect: что за зверь этот ваш Single Message Transform?

Рассмотрим работу с Single Message Transformations (SMT) в Kafka Connect в общем, и в Debezium в частности. Даниэл расскажет, что такое SMT, как этим пользоваться на практике, рассмотрит процесс реализации с примерами кода. Он расскажет о подводных камнях, обсудит настройку и конфигурирование и приведет примеры использования в реальных сценариях.

---

Визуализация для ELT-процессов в DWH

Виталий расскажет о своем опыте использования dbt, о написании материализаций, DDL-генераторе и проблемах с временными таблицами.

---

Предиктивный анализ паразитной нагрузки на кластерах GreenPlum

Доклад будет посвящен проблеме паразитной нагрузки на кластерах GreenPlum и способах ее предиктивного определения.

Марк расскажет о инструментах и подходах, которые они используют.

---

Архитектура дата-платформ

Моделирование потоков событий в эволюционирующем окружении

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

Николай опишет сложности, альтернативные пути решения, их плюсы и минусы и представит гибридный подход, объединяющий элементы разных подходов. Также будет немного статистики по использованию этого подхода в Snowflake на десятках миллиардов событий.

---

Платформа как продукт: разработать и внедрить сложное технологическое решение внутри компании

Все делают платформы. Платформизация — это очевидный тренд всех крупных организаций, которые стараются максимально ускорить вывод продукта на рынок и оптимизировать затраты. Но прежде чем платформа приведет компанию в светлое будущее с метрикой Time2Market за 000,1 сек, вы, скорее всего, столкнетесь с долгой буксующей разработкой, а потом и с противодействием внедрению от конечных пользователей. В докладе вы услышите про опыт реализации платформы для работы с данными в МТС: как получилось превратить ее в полноценный внутренний продукт и что делали, чтобы сделать пользователей счастливыми.

---

ML System Design

Нанимая DE или MLE, в больших компаниях часто вставляют секцию под названием ML System Design. Ожидается, что кандидат сможет продемонстрировать свои навыки по дизайну архитектуры ML-системы под сформулированные требования. Большим подспорьем в подготовке к такой секции может стать ознакомление с тестовыми собеседованиями и их детальный разбор.

Павел проведет собеседование в условиях, максимально приближенных к реальным, а кандидат не будет знать задачу заранее.

---

Как строилась экосистема ML в Банке

Андрей расскажет, как они делали полноценный конвейер MLOps и пришли к максимальной автоматизации процесса вывода моделей в промышленную эксплуатацию: как она выглядит и что умеет.

---

Что делать, если DWH растет слишком быстро

Вы сделали инструменты, настроили процессы, научили аналитиков писать витрины и наконец получили, что хотели — хранилище растет, как на дрожжах. Как теперь с этим жить? Управлять ожиданиями и давать гарантии с ростом системы становится все сложнее: влияние инцидентов и борьба за ресурсы под общей крышей мешают давать реалистичные оценки и прогнозировать время готовности данных для тех, кому время особенно критично. 

На примере преодоления проблем роста в хранилище данных Авито Александр расскажет, как они эволюционно пришли к разделению хранилища и как разделенное остается единым. Их опыт поможет лучше понять, как происходит переход к децентрализованному хранилищу и какие проблемы оно решает.

---

Я изменю ваш взгляд на хранилище данных за 30 минут

Во многих бизнесовых задачах мы делаем ставку на наши DWH, Data Lake, LakeHouse и т. д. по образу и подобию того, как это делалось в OLAP-таблицах много лет назад. Но бизнес-задачи и процессы обработки данных с тех пор сильно поменялись, и для некоторых бизнесов этот подход в корне неправильный, так как у них природа данных другая, чем была десятки лет назад.

Максим расскажет про:

• то, чем отличаются данные в современных бизнесах;

• подход, который Google предложил в своей статье 2015 года;

• проблемы, которые этот подход решает;

• новые проблемы, которые он создает, и что с ними делать сейчас.

---

Методы обезличивания данных

Алексей расскажет про методы обезличивания данных, рассмотрит модель оценки рисков, метрики полезности и анонимизации. В написании продукта для обезличивания данных использовался Spark и Python.

---

Многие компании предпочитают выстраивать работу с большими данными на базе Spark, однако в последнее время выбор end-to-end решений, предоставляющих возможность работы на масштабируемых Spark-кластерах в России, оказался ограниченным. Яндекс Облако предоставляет стек технологий, которые закрывают большую часть необходимой функциональности и позволяют параллельно обрабатывать данные с помощью Spark.

Из доклада вы узнаете:

• Как можно выстроить пайплайн обработки данных с помощью сервисов облака (DataProc и DataSphere), настроить взаимодействие со Spark-кластером через Jupyter-ноутбуки и почему удобно делать это в managed-сервисах.

• Как можно научить систему поднимать кластер под вас — именно тогда, когда он нужен, и экономить на этом.

• С какими сложностями сталкиваются компании при миграции, и какие пути решений они находят.

• Какие особенности есть у облачных сервисов.

• К чему надо быть готовым и какие могут понадобиться доработки.

Отдельный акцент будет сделан на взаимодействии инструментов для ML-разработки и кластера Spark.

---

Как навести порядок в логировании продуктовых событий

В Окко 4 фронтенда, разрабатываемых независимыми командами. Каждый отправляет 20 типов событий. Ни один не делает это так, как хотели аналитики. При работе с данными расхождения всплывают постепенно и копятся в виде десятков незакрытых тикетов. Документация — ненадежный источник, так как полностью завязан на человеческом факторе. 

Алексей расскажет, как удалось решить проблему.

---

Платформа управления данными вокруг YTsaurus

В 2023 вышла в опенсорс YTsaurus или просто YT — платформа распределенного хранения и обработки больших данных. Это ядро и сердце инфраструктуры данных в Яндексе.

В Такси, Еде, Лавке и Доставке строится платформа управления данными и постоянно адаптируется к быстро меняющимся требованиям бизнеса и внешним факторам. Несколько раз менялась архитектура и аналитические базы данных. И все эти годы только YT выглядит залогом стабильности и постоянства. Он был в 2016 и есть в 2023. Где-то в середине-конце 2019 к нему подключили Spark, а недавно та же участь постигла и Flink.

Владимир поделится опытом построения платформы управления данными вокруг YT, расскажет, где он хорош, а где его можно дополнить различными фреймворками или другими аналитическими базами. Эта тема может быть полезна архитекторам и дата-инженерам, которые собираются строить новое DWH или пересматривать архитектуру имеющегося, и стоят перед тяжелым вопросом выбора технологий из мира Open Source.

---

Базы данных «под капотом»

Планирование миллиардов задач каждый день

Еще один доклад про YTsaurus. Система позволяет сохранять и обрабатывать петабайты данных каждый день. На таком масштабе планировщик должен справляться с аллокацией миллиардов задач каждый день на кластере, состоящем более чем из 10 000 хостов.

Игнат и Егор расскажут историю планировщика в системе YTsaurus: как он из небольшого приложения, в котором все решения об аллокациях принимаются в одном потоке исполнения, превратился в высоконагруженный распределенный сервис.

Вы узнаете о вызовах, с которыми пришлось столкнуться, а также об идеях и подходах, которые применили в команде для масштабирования планировщика.

---

Как мы адаптировали динамические таблицы YTsaurus для хранения блобов

YTsaurus, как и многие другие системы, использует технику LSM (log-structured merge tree) для хранения и обновления данных в KV-таблицах. При некоторых паттернах нагрузки, однако, она показывает себя не с лучшей стороны. Например, если в ячейках таблицы хранятся блобы достаточно крупного размера, то фоновые процессы compaction вынуждены постоянно перезаписывать их, тратя впустую сеть, CPU и ресурсы дисковой подсистемы.

Для того чтобы повысить эффективность работы системы, команда реализовала альтернативный подход, который позволил вынести блобы и хранить их отдельно от «обычных» табличных данных. При этом пришлось особым образом модифицировать алгоритмы compaction, чтобы, тем не менее, уметь собирать «мусор» среди блобов и обеспечить подходящий трейдофф между занимаемым местом на диске (space amplification) и объемом постоянно перезаписываемых данных (write amplification).

В качестве бонуса применили данный подход для ряда таблиц, которые по требованиям латентности чтения, были вынуждены держать в RAM. В итоге удалось вынести (под видом блобов!) часть их данных на диски и в разы сократить потребление RAM, сохранив при этом низкое время чтения на высоких квантилях. В процессе внедрения пришлось значительно доработать IO-стек, перейдя на io_uring, и слой блоб-хранилища, добавив в него алгоритм consistent hashing для выбора метода расположения реплик данных.

---

Конкурентный контроль в базах данных, построенных на акторной модели

Доклад представляет исследование применения конкурентного контроля в базах данных, основанных на акторной модели. Акторная модель представляет собой архитектурный подход, где параллельные вычисления выполняются с помощью акторов — небольших, автономных и независимых единиц исполнения. Контроль над конкурентными операциями в таких базах данных является важным аспектом для обеспечения целостности данных и предотвращения конфликтов.

---

ACID-транзакции в Apache Cassandra 5.0

Александр рассмотрит реализацию, применение и ограничения ACID-транзакций в Apache Cassandra 5.0. Доклад будет интересен тем, кто работает с распределёнными базами данных и интересуется технологическими разработками в этой отрасли. Вы получите информацию о последних разработках в Apache Cassandra и узнаете, какие новые возможности открываются для децентрализованных СУБД.

---

Архитектура распределенного SQL-движка для аналитических запросов

Сервис YQL предоставляет доступ к системам хранения и обработки данных с помощью SQL-диалекта. Изначально SQL-запросы исполнялись с помощью Map/Reduce операций в системе YTsaurus.

Эта простая и надежная схема имеет ряд недостатков, которые привели к появлению собственного движка выполнения запросов внутри YQL.

Движок делит запрос на стадии, а каждую стадию на задачи. Каждая задача выполняется на узле кластера. Задачи передают результаты вычислений друг другу по сети. Данный подход отличается от Map/Reduce-подхода, в котором данные между этапами передаются с помощью записи на диск. Из интересных возможностей движка стоит отметить кросскластерные запросы (например, можно делать запросы в которых одновременно присутствуют таблицы из кластеров ClickHouse и YTSaurus), возможность выполнения пользовательских функций на различных языках программирования.

Движок доступен в виде open source-библиотеки в рамках проекта YDB Platform. Библиотека предоставляет примитивы для работы с AST-деревом запроса, вычислительные примитивы, а также набор микросервисов для запуска и управления задачами на кластере. На текущий момент библиотека работает в рамках трех инсталляций: внутренний YQL-сервис, YDB в Yandex Cloud и Yandex Query в Yandex Cloud.

---

Быстрая обработка данных в Data Lake с помощью Trino и CedrusData

Trino — это массивно-параллельный SQL-движок для обработки больших данных из различных источников, а CedrusData — это форк Trino с дополнительными улучшениями производительности. Одним из ключевых сценариев использования Trino является интерактивный анализ информации из озер данных. Так как узлы Trino не хранят данные, возникает сложный вопрос: как обеспечить высокую производительность обработки хранящейся на удаленных серверах информации? И насколько такой подход конкурентоспособен по сравнению с классическими хранилищами данных?

Владимир рассмотрит реализацию и практическое использование ключевых оптимизаций, которые позволяют Trino и CedrusData быстро «перемалывать» данные из вашего озера: использование метаданных Parquet и ORC для уменьшения количества зачитываемых данных (project/filter/aggregate pushdown), динамическая фильтрация (runtime filtering), поздняя материализация колонок (late materialization), а так же целых три локальных кэша: кэш метаданных, кэш данных и кэш промежуточных результатов запросов.

---

Сжатие, шифрование и не только: меняем поведение и гарантии распределенной базы данных

В Apache Ignite де-факто есть 3 механизма сжатия данных, и все нужные. Могло быть и несколько механизмов шифрования, фильтрации или любого другого вида трансформации данных.

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

Сжимать данные мы можем в памяти и на диске, встроенным в базу данных движком и подключаемым плагином. Целью сжатия может быть хранение максимального объема данных, повышение быстродействия системы или даже выполнение SLA.

На реальных примерах с выводами, основанными на бенчмарках, оценим преимущества и недостатки разных подходов к трансформации данных. Проследим движение информации по распределенной базе данных во время ее работы. Разберем успешные и не очень стратегии использования и доработки open source-продуктов.

---

Интеграция OLTP- и OLAP-функций в распределенной базе данных — преодоление традиционных барьеров в направлении универсального решения. Алексей расскажет про их процесс разработки такого решения, которое сочетает в себе функциональность OLTP и OLAP для выполнения одновременно транзакционных и аналитических запросов — YDB (Yandex Database). Он рассмотрит основные архитектурные особенности такой системы, сравнит его с ClickHouse и другими стандартными решениями, а также поделится опытом реализации и использования этой базы данных в реальных проектах.

---

Чего стоит достижение линеаризуемости в распределенной системе

Сейчас нельзя себе представить базу данных без репликации. Репликация повышает сохранность данных в случае сбоев и позволяет распределить нагрузку на чтение (а иногда и на запись) между несколькими узлами.

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

Для некоторых приложений такое поведение распределенных систем не представляет трудностей, но другие требуют более строгих гарантий.

Уровень консистентности linearizable призван спрятать все эти тонкости от пользователя, чтобы можно было пользоваться преимуществами хранения данных на нескольких узлах и не беспокоиться об аномалиях, возникающих в распределенной системе.

Сергей расскажет, как может быть реализован уровень linearizable на примере СУБД Tarantool и какие накладные расходы влечет его использование.

---

Применение TLA+ для эффективного тестирования распределенных систем

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

В докладе подробнее изучим проблему разработки и тестирования распределенных систем, рассмотрим язык спецификации TLA+ и его применение для верификации программ. Дополнительно опишем метод тестирования распределенных систем, построенных на акторной модели, совмещающий в себе плюсы и фаззинга, и TLA+.

В качестве примера рассмотрим систему распределенной координации Барсик, которая активно разрабатывается ВКонтакте и основана на алгоритме репликации данных Viewstamped Replication.

---

Use cases

Примеры реальных аналитических решений и дата-команд в западных компаниях

Дмитрий работает кем-то вроде консультанта по внедрению современных аналитических решений как open source, так и коммерческих — Databricks, Snowflake. Кроме создания аналитических решений и архитектур для обработки сотен терабайт данных в различных индустриях, он также уделяет внимание аналитическим командам.

Он не будет вас учить, что правильно, а что нет, или как лучше создать аналитическое решение — в облаке AWS или Azure. Он поделится рабочим опытом и наблюдениями из разных проектов. Для каждого проекта он расскажет про типовую архитектуру, взаимоотношения с бизнес-пользователями и размер аналитической команды, а также про соотношение инженеров\аналитиков\менеджеров. А еще поговорит про косяки и другие забавные вещи.

---

Как мы переезжали с PostgreSQL на Data Lake в AWS

В Whoosh работают на стеке AWS — PostgreSQL, S3, Redshift, а все модели данных строят в dbt и немного Python. BI — Tableau и Grafana. Этот год для команды инженеров данных можно назвать годом переезда. У них была глобальная идея переехать с одного хранилища (PostgreSQL) — а это включает в себя всю отчетность для бизнеса и модели dbt — на рельсы Data Lake. Цель — оптимизация расходов, потому что Аврора (PostgreSQL) записывает в расход каждый запрос, тогда как Redshift — это MPP-колоночная БД, расходы которой постоянны — n$/час (и работает она быстрее, да). Однако вследствие переезда выяснилось, что для геозадач это решение не подходит совсем: Redshift строится на базе 8-й версии PostgreSQL (внезапно!), которая не поддерживает геометрию, обрезает значения в ячейке больше определенной длины и совсем не дружит с JSON-ключами.

Из доклада вы узнаете про грабли, как их в итоге победили и куда они двигаются дальше. Возможно, в процессе дополнительно вы услышите про то, как они настроили тестовый контур, CI/CD и работу с гитом, как используют Dagster (оркестратор) и как планируют его использовать дальше. Хочется порассуждать на тему «будущего» оркестратора и изменения данных в потоке при поступлении свежей порции данных, а не работы по расписанию.

---

Слабоумие и отвага, или Как мы за два месяца объединили данные Delivery Club и Яндекс Еды

В 2022 году произошло заметное событие для всей индустрии фудтеха в России: интеграция двух крупнейших сервисов по доставке еды — Delivery Club и Яндекс Еды. Масштаб события уникален не только для локального рынка, но и для мировой практики. Кроме слияния бизнесов, осуществили и интеграцию данных: теперь все данные лежат на единой технологической платформе. Обычно такие проекты масштабные и занимают много месяцев на подготовку, оценку скоупа, выбор решений и реализацию. Но перед командой стояла амбициозная задача: за восемь с небольшим недель объединить два полноценных хранилища данных Delivery Club и Яндекс Еды и, до интеграции бэкендов, обеспечить отчетность основными бизнес-метриками и данными по Delivery Club.

Ольга расскажет, как они реализовали этот проект, как собирали скоуп задач, оценивали их и корректировали в процессе. Она также рассмотрит техническую реализацию доработок на DWH: какую архитектуру решения придумали, на каком стеке остановились и почему. Конечно, без граблей не обошлось: обсудим, на какие наступили и как можно их избежать.

Доклад будет полезен тем, кто объединяет бизнес или поглощает новые компании с их данными; кому интересно послушать про организацию проекта с объемным скоупом и короткими сроками.

---

Стриминг

Spark Streaming: брать или не брать?

Все чаще продуктовым командам приходится решать задачи потоковой обработки данных в связи с потребностью бизнеса обрабатывать данные в режиме реального времени или близком к реальному. Инструментов для решения задач потоковой обработки данных много, и каждый из них способен достаточно эффективно решать свои задачи. Одним из самых популярных решений на данный момент является Apache Spark Streaming, который достаточно универсален и имеет богатую функциональность. Но часто встречаются и такие задачи, где Spark Streaming — это не лучшее решение, и он может впоследствии стать больше обузой, чем эффективным решением. Евгений расскажет про преимущества и недостатки Spark Streaming: когда стоит применять именно этот инструмент, а когда лучше рассмотреть другие варианты. Он составит чек-лист по применению Spark Streaming в проектах. Доклад будет интересен специалистам, которые еще не имели дела со Spark Streaming, но хотели бы его использовать для решения своих задач.

---

Streaming Data Integration — ETL-инструмент для создания near realtime-процессов

Василий опишет их подход к реализации ETL-инструмента на базе Apache Flink и платформе Kubernetes, даст общую архитектуру решения, подходы к реализации расширяемого набора преобразований, тестированию и практические рекомендации по реализации near realtime-процессов. Доклад ориентирован на data-инженеров, занимающихся вопросами realtime-обработки данных, а также руководителей data-подразделений, ищущих инструменты для решения near realtime-задач.

---

From Data Streams to High Quality Predictive Models. The Secret to Offline Feature Engineering

Юрий расскажет, как Serverless, Kappa architecture и Python могут помочь в создании простой, но эффективной платформы для конструирования признаков и обучения моделей. Используя простые концепции, такие как CQRS и Event Sourcing, вместе мы разработаем систему обработки данных, которая позволит создавать и тестировать новые признаки, а также понимать их ценность для ML-моделей.

---

Управление данными

Эволюция схемы данных. Носим данные из реляционной СУБД в Hadoop

Знакома ли вам такая ситуация: построили замечательный ETL, витрины и красивые дашборды. На очередной отчетной встрече о работе вашей компании докладчик открывает дашборд, а там вместо графиков красные буквы (в лучше случае) или драматическое снижение ключевых показателей. Все охают, хватаются за сердце, а вы понимаете, что кто-то просто обновил продуктивную систему, не предупредив отдел отчетности... В докладе будет про эволюцию схемы реляционных данных. Как не сломать downstream своими обновлениями, как защититься от ломающих обновлений в upstream системе. Стек: Hadoop, Spark. Форматы: Avro, Parquet, ORC. И немного про схемы и технологии их обновления.

---

Обеспечение качественных ETL на Vertica

Стандартная практика при работе с аналитическими данными — это предоставление пользователям возможности создавать собственные ETL и ставить их на регулярное выполнение. Если этот процесс не контролировать, то вычислительный кластер, вне зависимости от конкретной технологии, начнет деградировать и комфортное кооперативное обслуживание станет невозможным. Александр расскажет про испытания, которые преодолевала компания при выстраивании многоцелевой вычислительной платформы на Vertica. В докладе будут освещены как организационные, так и технологические аспекты достижения «клиентского счастья».

Технологический упор будет сделан на «дефекты» (неоптимальный дизайн) структур данных и запросов. Эти нюансы объяснены на примере конкретно Vertica, однако являются применимыми также и к другим системам класса MPP.

---

Как сделать аналитику по событиям 100 млн пользователей и не умереть

Доклад про построение платформы данных с нуля, со спецификой Минцифры. Более подробно спикер остановится на внедрении практик анализа данных в работу продуктовых направлений, внедрение практик DataMesh. Он также расскажет про их open source-инструментарий, в особенности для работы с потоками данных и построении сложной аналитики в режиме реального времени с событиями, генерируемыми 100 млн. активных пользователей. И, конечно, перечислит грабли, на которые они наступали, и как этого избежать.

---

Common Data Index. Как построить поисковую систему по открытым данным такую же, как Google Dataset Search, но проще и быстрее

В мире существует немного поисковых систем по наборам данных. Самая известная из них — это Google Dataset Search, также существуют китайский проект FindData.cn, поиск по научным данным в DataCite и ряд экспериментальных проектов.

Большая часть поисковых систем по данным построены или вокруг поиска по научным данным, или универсального поиска любых датасетов, опубликованных по стандарту Schema.org. Так работает Google Dataset Search, например.

Однако в реальности данных гораздо больше, существуют тысячи порталов открытых данных, геоданных, данных для машинного обучения и многих других данных. Далеко не все эти данные попадают в существующие поисковые системы, и это существенно ограничивает их использование.

Доклад Ивана будет о создании проекта построения поисковой системы по всем доступным данным в мире путем нескольких шагов: создания каталога порталов данных, сбора метаданных, их анализа и построения единого индекса.

---

Пара слов о том, как мы Data Observability готовим

Спикеры расскажут о вечной проблеме с качеством данных и подробно о том, почему и каким образом они построили платформу качества данных в СберЗдоровье. Они раскроют работу с great expectations, интеграцию с каталогом данных (DataHub) и расскажут, что происходит после того, как они нашли «сломанные» данные.

---

Путь Model Serving: от Flask к своей MLOps-платформе

Алина сравнит новые решения, которые появились на рынке, и их новые фичи со старыми.

---

От сырого кликстрима к чистым датасетам, или История развития Feature Storage в Lamoda

Доклад посвящен истории развития Feature Storage в Lamoda: инструменту для дата-аналитиков по работе с данными. Спикеры расскажут, с какими проблемами столкнулись и как пришли к архитектуре, которая позволяет эффективно хранить и обрабатывать терабайты данных о пользователях и товарах.

---

Hadoop в Облаке — это ОК

Для OK Hadoop — это ключевой компонент инфраструктуры: он активно используется как для реализации продуктовой аналитики, так и для продакшена рекомендательных систем. С точки зрения объемов это более 200 PB в HDFS, 70k vcores, 200 TB RAM.

Вся инфраструктура в Одноклассниках(и не только) разворачивается во внутреннем контейнерном облаке и этому есть причины:

• унификация эксплуатации как железа, так и приложений

• кардинальное повышение утилизации доступного железа

В этом году очередь дошла и до Hadoop. Михаил расскажет:

• о причинах отказа от классических подходов по развертыванию и эксплуатации hadoop кластеров;

• о том провести миграцию сотен петабайт так, чтобы пользователи этого не заметили;

• о сложности жизни с соседями (теперь на одной машине с Hadoop может поселиться другая программа, претендующая на ресурсы);

• и конечно же, о том, какие преимущества получили в итоге (спойлер — значительные).

---

Космос

Создание группы сервисов по анализу космических снимков с помощью машинного обучения

Уроки, извлеченные при разработке сложных продуктов в условиях ухода с рынков иностранных партнеров, а также инструменты для разработки, которые создали в компании, чтобы упростить студиям и freelance-разработчикам выход на рынок.

---

Телескопы XXI века: от железа и софта к данным и результатам

Современные астрономические инструменты — телескопы — выглядят далеко не так, как сотни и даже десятки лет назад. Наблюдательные данные быстро растут в объеме и скорости получения, сокращается требуемое время реакции — это создает новые требования к системам обработки. Будут приведены как астрономические задачи, для решения которых требуется все больше возможностей телескопов, так и подходы к решению возникающих проблем на конкретных примерах.

---

В завершение

Напомним, что конференция пройдет 6–7 сентября в онлайне и 13–14 сентября в Москве. Вас ждут не только доклады, но и море дискуссий и нетворкинга. Для тех, кто не сможет приехать на площадку, будет трансляция. Расписание и билеты — на сайте конференции.