Никита Юрасов, Леонид Кожинов — От хайпа до продакшена: data mesh на Airflow + dbt

https://www.youtube.com/watch?v=OT-Sx-bd-6k
или
https://vkvideo.ru/playlist/-147464741_12/video-147464741_456239390

Сложность: 1/3 (Для тех, кто работал с dbt)

Кому будет интересно: Будет мало понятно, если не слышали про dbt. Но в таком случае про data mesh полезно послушать. Если же с dbt знакомый, то доклад интереснейший)

---

✨ Краткий пересказ и выводы по докладу ✨

Спикеры поделились опытом внедрения Data Mesh в компании, где обрабатывается 530 ТБ данных с использованием Airflow и dbt. Основная цель — управление данными через домены, что позволяет масштабировать процессы и снижать нагрузку на инфраструктуру.
---

🔍 Основные моменты:
1️⃣ Инфраструктура:
• Платформа построена на Azure Databricks, Airflow и dbt.
• Данные поступают из бэкенда через Kafka и внешних источников через Airbyte.
• Для аналитики используются Tableau, Jupyter и другие инструменты.
2️⃣ Управление качеством данных:
• Контроль качества данных осуществляется с помощью dbt tests, Monte Carlo Data (ML для качества данных) и Grafana.
• Мониторинг и управление инфраструктурой выполняются через Docker, Kubernetes и Terraform.
3️⃣ Декомпозиция и домены:
• Платформа разделена на 32 домена, каждый с уникальными ролями и правами доступа.
• Домены помогают управлять сложностью и масштабировать процессы.
4️⃣ Автогенерация и тестирование:
• Используются dbt-airflow для автогенерации моделей и тестов.
• Три уровня тестирования:
◦ Small — блокирующие тесты.
◦ Medium — предупреждения.
◦ Large — редкие тесты, запускаемые в отдельном даге.
5️⃣ Оптимизация и контроль нагрузки:
• dbt targets позволяют контролировать нагрузку на кластер и базу данных.
• Модели должны быть максимально протестированы для предотвращения ошибок.
6️⃣ Среда для аналитиков:
• Аналитики работают в GitHub Codespaces, где все инструменты и библиотеки настроены "из коробки".
• Аналитики не взаимодействуют с Airflow напрямую, что упрощает их работу.
7️⃣ Проблемы и решения:
• Циклические зависимости между доменами требуют постоянного мониторинга.
• Восстановление после инцидентов включает уведомление ответственных лиц и перезапуск упавших доменов.

💡 Плюсы Data Mesh:
• Масштабируемость: Управление большим количеством доменов.
• Скорость деплоя: Быстрое развертывание новых доменов.
• Низкий порог входа: Аналитики могут работать без глубоких технических знаний.

⚠️ Минусы Data Mesh:
• Техническая сложность: Требует постоянного улучшения инфраструктуры.
• Просветительская работа:Необходимость обучения владельцев доменов.

📌 Выводы:
Data Mesh — это мощный подход для управления большими объемами данных, но он требует значительных усилий по поддержке и улучшению. Интеграция Airflow и dbt позволяет эффективно масштабировать процессы, но важно учитывать циклические зависимости и нагрузку на кластер.

Пока готовлю новый пост, буду делиться каналами, которые я сам читаю. Не реклама, личная рекомендация.

https://news.1rj.ru/str/mpp_secrets - один из лучших каналов по Greenplum, где показаны реальные задачи, с которыми автор сталкивается в работе. Я с Greenplum работаю с 2019, кажется, что собрал уже все грабли сам. Автор канала в своих постах регулярно показывает мне, что ещё куча граблей, на которые можно наступить)

✨ Андрей Бородин — Compute/Storage separation в Greenplum

Сложность: 1.5/3

Кому будет интересно:
Специалистам, работающим с Greenplum. Или тем, кто топит за то, что GP не универсальный и дорогой.

---
Ссылка на выступление: https://youtu.be/D22bZCLZOjQ?si=z7wGmhZmKH0bsJQD

Андрей Бородин рассказал о разделении вычислений и хранения данных в Greenplum, что позволяет снизить затраты на хранение данных, используя облачные решения, такие как S3. Основной фокус был на проекте Yezzey, который интегрирует Greenplum с облачным хранилищем.

---

🔍 Основные моменты:

1️⃣ Проблемы и решения:
- Хранение данных в облаке (например, S3) в 10 раз дешевле, чем на локальных дисках.
- Yezzey — расширение для Greenplum, которое позволяет отправлять данные в S3, сохраняя при этом производительность.

2️⃣ Автоматическое охлаждение данных:
- Проект "Автоматическое охлаждение" был разработан для перемещения данных в облачное хранилище.

3️⃣ Производительность:
- На "обычных" запросах разница в времени выполнения между данными в S3 и локальными данными составляет всего 25%, при этом стоимость хранения в S3 в 10 раз ниже.
- На сложных запросах разницы в производительности практически нет.
- Оптимизатор Greenplum не видит разницы между данными в S3 и на локальных дисках.

4️⃣ Проблемы с восстановлением и шифрованием:
- При восстановлении кластера с данными в S3 данные необходимо скачивать и шифровать заново, но это происходит автоматически.

5️⃣ Автоматическое масштабирование:
- Автоматическое масштабирование пока находится на стадии проектирования.
- Планируется возможность сжатия кластера для удобства пользователей.

6️⃣ Требования к инфраструктуре:
- Для эффективной работы Greenplum с S3 требуется мощная сеть, так как производительность ограничивается именно сетью.
- Технология Yezzey недавно выпущена, и есть много планов на будущее, включая улучшение производительности и оптимизацию запросов.

---

💡 Плюсы подхода:
- Экономия на хранении: Использование S3 снижает затраты в 10 раз.
- Масштабируемость: Данные в облаке позволяют избежать проблемы data gravity.
- Производительность: На сложных запросах разницы в производительности практически нет.

---

⚠️ Минусы и ограничения:
- Сеть: Производительность ограничена пропускной способностью сети.
- Автоматическое охлаждение: Подход оказался неэффективным и больше не используется.
- Локальное кэширование: Пока не реализовано.

---

📌 Выводы:
Разделение вычислений и хранения данных в Greenplum с использованием S3 — это мощный подход для снижения затрат на хранение. Проект Yezzey уже показывает хорошие результаты, но требует дальнейшего улучшения, особенно в области локального кэширования и оптимизации сетевого обмена.

✨ Кузьма Лешаков — Разгоним запросы: как быстро готовить ClickHouse

Сложность: 1/3 (для тех, кто знаком с Clickhouse)

Кому будет интересно:
В докладе рассказывают про индексацию, проекции и шардирование в Clickhouse. Про индексы очень интересно послушать, но вот про шардирование и проекции - слишком просто. Но если с Clickhouse не работали (или не использовали проекции/работали с одним шардом), то для знакомства - доклад в самый раз.

---
Ссылка на выступление: https://youtu.be/COBEEbozRqw?si=Qdtfv1lN68EaVPqh
или
https://vkvideo.ru/video-147464741_456239336

---

✨ Кузьма Лешаков — Разгоним запросы: как быстро готовить ClickHouse

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

---

🔍 Основные моменты:

1️⃣ Индексация в ClickHouse:
- Первичный индекс: Создается явно или неявно (через ORDER BY). Рекомендуется использовать 2-3 колонки с возрастающей кардинальностью.
- Вторичные индексы:
- Фильтр Блума:
- Вероятностная структура данных, которая гарантирует отсутствие элемента, но не его наличие.
- Пример: Определение наличия IP-адреса в спам-списке. Без фильтра Блума используется 100 миллионов строк, с фильтром — 32,77 тысячи строк.
- Размер индекса: 74 МБ после компрессии, 100 МБ до компрессии.
- Фильтр МинМакс:
- Фиксирует минимальное и максимальное значение для каждой гранулы.
- Требует корреляции с первичным ключом.
- Пример: Подсчет общего количества просмотров по колонкам response_start и response_end. Без фильтра МинМакс используется 100 миллионов строк, с фильтром — 65 миллионов.
- Размер индекса: 0,01 МБ после компрессии, 0,005 МБ до компрессии.
- Индекс Сет:
- Фиксирует уникальные значения в каждой грануле.
- Подходит для колонок с низкой кардинальностью.
- Пример: Подсчет хитов просмотров с условиями по браузеру. Без индекса Сет используется 100 миллионов строк, с индексом — 41,91 тысяча строк.
- Размер индекса: 0,24 МБ после компрессии, 0,14 МБ до компрессии.

Преимущества вторичных индексов:
- Ускоряют выполнение запросов.
- Нет ограничений по количеству индексов на таблицу.

Недостатки вторичных индексов:
- Занимают дополнительное место, особенно фильтры Блума.
- Могут замедлять вставку данных.
- Требуют вдумчивого подхода: неграмотное использование может замедлить ClickHouse.


2️⃣ Проекции:
- Проекции — это скрытые подтаблицы, которые помогают ускорить запросы, особенно при изменении ключа сортировки или предагрегации данных.
- Пример: создание проекции для агрегации данных по user_id.

ALTER TABLE hits
ADD PROJECTION hits_avg_users (
SELECT
user_id,
count(*)
GROUP BY user_id
)

- Недостатки: Проекции занимают много места и могут быть менее гибкими, чем материализованные представления.

3️⃣ Шардирование:
- Шардирование позволяет распределить данные между несколькими хостами, что повышает производительность и отказоустойчивость.
- Ключ шардирования: Определяет, как данные распределяются между хостами.
- Недостатки: Требует дополнительных вычислительных мощностей и ручной ребалансировки при добавлении новых хостов.

4️⃣ Оптимизация запросов:
- Первичный ключ: Основной способ ускорения запросов.
- Индексы пропуска данных: Ускоряют запросы, но могут замедлять вставку данных и занимать дополнительное место.
- Проекции: Эффективны для предагрегации, но требуют много места.
- Шардирование: Позволяет преодолеть ограничения одного хоста, но требует дополнительных ресурсов.

---

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

P.S. Пожалуйста, делитесь постом с коллегами. Для нас это очень важно)

✨ Иван Клименко (Arenadata) — CDC в банке от источника до хранилища с применением продуктов Arenadata

Ссылка на выступление:

https://youtu.be/nfZdDzr_Y_Y?si=l69ZPYfI0_j5souJ
Или
https://vk.com/video-147464741_456239459

Сложность: 1/3 (уверен, будет понятно, даже если не знаете, что такое CDC)
Кому будет интересно:
• Всем DE. Отличный кейс внедрения cdc.

Иван Клименко рассказал о внедрении CDC (Change Data Capture) в банке Синара с использованием продуктов Arenadata. Основной фокус был на оптимизации загрузки данных из операционных баз в Greenplum.

🔍 Основные моменты:
1️⃣ Что такое CDC:
• CDC отслеживает изменения в базе данных (например, Oracle) и переносит их в целевые системы (Greenplum).
• Используется для инкрементальной загрузки данных, что позволяет избежать полной перезагрузки таблиц.
• Debezium был выбран как оптимальное решение благодаря гибкости, поддержке. Все использованные решения - open source или входят в Arenadata.
2️⃣ Проблемы до внедрения CDC:
• Данные загружались напрямую через PXF, что вызывало проблемы с большими таблицами и не укладывалось в SLA.
• Ежедневная перезагрузка больших таблиц без инкрементальных полей была неэффективной.
3️⃣ Архитектура решения:
• Используется экосистема Arenadata Streaming: Kafka, Nifi и Greenplum.
• Данные из Oracle через Debezium попадают в Kafka, затем преобразуются и загружаются в Greenplum.
4️⃣ Оптимизация пайплайна:
• Переход на бинарный формат Avro вместо JSON для уменьшения объема данных.
• Разделение процесса на два независимых потока для улучшения производительности.
• Использование JOLT Transform для приведения данных к плоскому виду.
5️⃣ Производительность:
• Прирост производительности на исторических данных более чем в 100 раз.
• Загрузка таблицы с 1,6 миллиардами записей занимает менее 10 минут.
• Debezium увеличил нагрузку на Oracle на 7-10% в пиковые дни.
6️⃣ Работа с Greenplum:
• Данные из Kafka загружаются в Greenplum через внешние таблицы и коннектор Kafka2ADB. Конечные витрины сгружаются в Kafka с помощью ADB2kafka коннектора.
• Для минимизации нагрузки на мастер-ноду используется рандомное распределение данных между сегментами и количество партиций в Кафка, кратное количеству сегментов в GP.
• Рекомендуется удалять или архивировать сырые данные.
7️⃣ Первичная загрузка:
• Первичная загрузка данных осуществляется через PXF, что позволяет избежать проблем с локализацией таблиц и схем.
• Возможны дубли данных, но система умеет с ними работать.

💡 Плюсы решения:
• Инкрементальная загрузка: Уменьшает время загрузки и нагрузку на источники данных.
• Масштабируемость: Использование Kafka и Greenplum позволяет эффективно распределять данные.
• Производительность: Значительное ускорение загрузки и обработки данных.

⚠️ Минусы и ограничения:
• Нагрузка на источники: Debezium незначительно увеличивает нагрузку на операционные базы данных и требует обсуждений с ИБ и инфраструктурой.
• Сложность настройки: Требуется тщательная настройка коннекторов и пайплайнов.

📌 Ответы на вопросы:
1️⃣ Использование коннекторов Confluent и их безопасность:
• Используются только библиотеки, выложенные под лицензией Apache. Платные решения Confluent не применяются. Все использованные решения open source или входят в поставки Arenadata.
2️⃣ Почему не использовали Oracle для хранилища?
• Решение связано с политикой импортозамещения.
3️⃣ Как распределяются данные между сегментами в Greenplum при загрузке из Kafka?
• Рекомендуется использовать рандомное распределение, чтобы данные из партиций Kafka сразу попадали на свои сегменты. В противном случае потребуется редистрибуция. Количество партиций в Кафка должно быть кратно количеству сегментов в GP.
4️⃣ Производительность коннектора Kafka:
• За 15 секунд считывается около миллиона записей в формате JSON.
5️⃣ Первичная загрузка через PXF:
• Включается Debezium, данные загружаются через PXF. Возможны дубли, но система умеет с ними работать.

📌 Выводы:
Внедрение CDC с использованием Debezium, Kafka и Greenplum позволило значительно улучшить процесс загрузки данных.

Скрин архитектуры Data Platform банка из последнего поста.

Пожалуйста, делитесь нашими постами с коллегами)

✨ Наталья Журавлева — Как быстро запустить каталог данных на примере DataHub

Ссылка на выступление: https://youtu.be/nCt4gYVQdqc?si=Fbwab0cQxgMl4g3a
или
https://vkvideo.ru/video-147464741_456239425

Сложность: 2/3 (Техники очень мало, но теория и концептуальное погружение в доклад требуется. В фоне смотреть тяжело, нужно погружаться)

Кому будет интересно: Аналитикам и архитекторам. Если Вам интересна только техника - пропускайте доклад, примеров по технике и коду в нём нет. Но я очень рекомендую доклад посмотреть, так как Наталья очень интересно рассказывает про проблемы всех хранилищ и как облегчить боль непосредственных пользователей от работы с ними. И не могу не отметить, что Наталья очень захватывающе рассказывает, одно удовольствие её слушать :)


---

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

---

🔍 Ключевые идеи доклада:

1️⃣ Проблемы без каталога данных:
- Дублирование данных и непонимание структуры
- Зависимость от экспертов и "устных традиций"
- Документация в Confluence быстро устаревает

2️⃣ Логическая модель — фундамент каталога:
- Три уровня моделирования:
• Концептуальный (бизнес-сущности)
• Логический (атрибуты и связи)
• Физический (реализация в БД)
- В якорной модели логическую схему можно сгенерировать в полу автоматическом режиме
- Хранится в YAML-файлах с версионностью через merge-реквесты

3️⃣ Процесс работы с моделью:
1. Аналитик описывает сущность в YAML
2. Разработчик реализует маппинг на физическую модель
3. Каталог автоматически подхватывает изменения

4️⃣ Выбор технологий:
- Отказ от Confluence в пользу специализированного решения
- Выбор DataHub вместо OpenMetadata
- Интеграция проверок качества данных (DQ)

---

💡 Преимущества подхода:
✅ Сокращение времени на документирование на 60%
✅ Автоматическое обновление каталога
✅ Обнаружение ошибок в существующей логике хранилища
✅ Единый источник правды для всех команд

---

⚠️ Сложности и ограничения:
- Создание логической модели требует времени
- Трудности единой модели для всех хранилищ
- Необходимость дополнительных инструментов моделирования

---

📌 Практические советы:
1. Начинайте с логической модели, пишите документацию всегда и сразу.
2. Автоматизируйте процесс наполнения каталога
3. Для разных хранилищ используйте разные модели
4. Внедряйте DQ-проверки прямо в каталог

---

🤔 Ответы на вопросы из зала:

Q: Как бизнес-пользователи работают с каталогом?
A: Через концептуальный уровень, который описывает данные в бизнес-терминах

Q: Почему выбрали DataHub?
A: Сравнивали с OpenMetadata — DataHub показался более зрелым решением

Q: Сколько ресурсов потребовалось?
A: Команда из 6 аналитиков, 1 разработчика и 1 DevOps за 6 месяцев

---

📌 Выводы:
Внедрение каталога данных через логическую модель и DataHub значительно упростило работу с данными в компании.

Следующий Digest доклада будет в выходные про шикарный EL инструмент - airbyte.

Пока рекомендую фоном посмотреть дискуссию про будущее Greenpum на T-Meetup: https://www.youtube.com/watch?v=EXRLqI9mx54&list=PLLrf_044z4Jp8l6GauGEmbZXIwABfrbRQ

✨ Александра Попова — Airbyte: 2 года в продакшене

Ссылка на выступление: https://youtu.be/fgaBGc3VWWQ?si=jvH4kmqF8lyjc70-
или
Ссылка на выступление: https://youtu.be/fgaBGc3VWWQ?si=jvH4kmqF8lyjc70-

Сложность: 2/3 (Практико-ориентированный доклад, требует базового понимания ETL-процессов)

Кому будет интересно:
- Архитекторам и простым инженерам, которые понимают, как дотащить данные от источника в хранилище.

---

Александра поделилась опытом внедрения и эксплуатации Airbyte в СберЗдоровье с 2022 по 2024 год. Airbyte - один из мощных инструментов modern data stack, очень рекомендую к ознакомлению)

---

🔍 Ключевые моменты внедрения:

1️⃣ Проблемы до Airbyte (2021):
- Разнородные скрипты для забора данных
- Неэффективное управление ETL-процессами
- Отсутствие стандартизации

2️⃣ Выбор Airbyte:
- Большое комьюнити и готовые коннекторы
- Python CDK для кастомных разработок
- Поддержка инкрементальной синхронизации и CDC (на базе Debezium)

3️⃣ Архитектурные особенности:
- Микросервисная архитектура (ядро на Java, коннекторы на Python/Java)
- Развертывание в Kubernetes с разделением статических/динамических подов

---

⚙️ Функциональность Airbyte:
✔️ Методы синхронизации:
- Full refresh
- Incremental (с дедупликацией)
- CDC (PostgreSQL, MySQL, SQL Server, MongoDB)

✔️ Расписания:
- По временному интервалу
- Cron (добавлен в 2023)
- Ручной запуск

---

🛠 Практический опыт:

Проблемы и решения:
1. Отсутствие коннектора к Greenplum → Разработан кастомный коннектор на основе PostgreSQL
2. Потеря точности времени → Переход на CDC для инкрементальных синхронизаций
3. Ограничения UI → Использование API и YAML-конфигов для управления
4. Проблемы с расписанием → Решены в новых версиях airbyte через cron
5. Мониторинг → Настройка через sql-exporter

Производительность:
- Обработка до 100 ГБ данных
- Разделение нагрузки в Kubernetes
- Оптимизация через cleanup-политики

---

📊 Текущая архитектура (2024):
- Источники: БД (через CDC) и API
- Назначения: Greenplum, ClickHouse (с предварительным созданием ReplicatedMergeTree-таблиц)
- Оркестрация: Dagster для управления пайплайнами

---

💡 Преимущества Airbyte:
✅ Упрощение ETL-процессов
✅ Готовая поддержка 300+ коннекторов
✅ Гибкость через Python CDK
✅ Удобство мониторинга

⚠️ Ограничения:
- Нет встроенного механизма бэкфила
- Требует доработок для специфичных случаев
- Cloud-функции (ролевая модель) недоступны в open-source

---

🤔 Ответы на вопросы:

Q: Почему Airbyte вместо Airflow?
A: Готовые коннекторы и унификация процессов

Q: Как решается проблема бэкфила?
A: Периодической полной перезаписью данных

Q: Проблемы с CDC?
A: Нет проблем со скоростью репликации

Q: Почему не PXF для Greenplum?
A: Ограничения ИБ и сложность поддержки

---

📌 Выводы:
Airbyte отлично подходит для:
- Забора данных из БД и API
- Стандартизации ETL-процессов
- Быстрого старта с минимальной разработкой

Не подходит для:
- Стриминговых сценариев
- Сложных бэкфил-процессов

И приятный бонус. Александра любезно согласилась ответить на Ваши вопросы по докладу про airbyte в комментариях к этому посту)