Ссылка на выступление: https://www.youtube.com/watch?v=iNgsyboLpb0
or
https://vk.com/video-147464741_456239346

Сложность: 1/3 Легко и понятно

Кому будет интересно: всем, кто строит или собирается строить платформу данных.

✨ Краткий пересказ и выводы по докладу Максима Стаценко ✨

На конференции Максим Стаценко предложил революционный взгляд на хранение и обработку данных. Он начал с исторической параллели, сравнив эволюцию физики (от Ньютона до Эйнштейна) с необходимостью менять подходы к данным сегодня.

🔍 Основные проблемы:
1️⃣ Устаревшие методы хранения данных — мозг и древние системы уже не справляются с современными объемами.
2️⃣ Сложности в аналитике — задержки в данных, ручные процессы и отсутствие единой культуры аналитики создают хаос.
3️⃣ Проблемы бизнеса — например, в рекламе: клики с задержкой, антифрод-системы, меняющие данные, и отсутствие актуальности для топ-менеджеров.

🚀 Предложенные решения:
- 4 типа API для работы с данными:
- Первое состояние события.
- Последнее состояние.
- Дельта (изменения).
- Актуальное состояние для запросов.
- Автоматизация процессов — минимизация ручного труда и человеческого фактора.
- Идемпотентность — корректная работа с изменениями данных.
- Культура тестирования — написание тестов для данных и покрытие финансовых расчетов мониторингами.

💡 Выводы:
1️⃣ Данные — это живой организм. Они меняются, и нужно уметь с этим работать.
2️⃣ Технологии — это только половина успеха. Важно менять культуру разработки: писать тесты, автоматизировать процессы и договариваться о новых подходах.
3️⃣ Эффективность = гибкость. Новые API и автоматизация позволяют быстрее реагировать на изменения и снижать задержки.

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

Ссылка на выступление: https://www.youtube.com/watch?v=Wi4-RJq5Q1w

Сложность: 2/3 (Есть технические моменты, но в целом понятно)
Кому будет интересно: администраторам баз данных, инженерам данных, архитекторам Data Platform и всем, кто работает с Greenplum. Если с Greenplum не работали, смотреть не рекомендую.

✨ Краткий пересказ и выводы по докладу Дмитрия Немчина (Tinkoff) — Greenplum Worst Practices ✨

Дмитрий Немчин, руководитель команды администраторов бэк-энда хранилища данных Тинькофф, поделился опытом работы с Greenplum и основными ошибками, которые могут возникнуть при его использовании. Greenplum — это мощная MPP-система, построенная на PostgreSQL, но даже у таких технологий есть свои подводные камни. 🌊

🔍 Основные проблемы:
1️⃣ Параллельность и нагрузка:
• Установка большого количества сегментов на мощных машинах приводит к перегрузке CPU и дисков.
• Система становится нестабильной при высокой нагрузке.
2️⃣ Синхронизация метаданных:
• Автосинхронизация через DataGrip создает лишнюю нагрузку на мастер-ноду.
• Это замедляет выполнение обычных запросов.
3️⃣ Распределение данных:
• Неравномерное распределение данных между сегментами вызывает перекосы.
• Это приводит к проблемам с производительностью.
4️⃣ Администрирование:
• Ошибки, такие как удаление данных всех сегментов, могут привести к падению всей базы.
• Важно учитывать особенности Greenplum при администрировании.
5️⃣ Воркфайлы:
• Маленькие воркфайлы занимают много места на диске.
• Требуется правильная настройка параметров для оптимизации.

🚀 Предложенные решения:
• Равномерное распределение данных:
Ключ к стабильной работе Greenplum.
• Отказ от автосинхронизации метаданных:
Снижает нагрузку на мастер-ноду и ускоряет выполнение запросов.
• Регулярная вакуумация:
Помогает избежать проблем с bloating (пустые места после удаления данных).
• Настройка параметров воркфайлов:
Оптимизация использования дискового пространства.
• Ресурсные группы в Greenplum 5:
Гибкое управление нагрузкой и производительностью.

💡 Выводы:
1️⃣ Greenplum — мощный инструмент, но требует внимательной настройки.
Ошибки в администрировании могут дорого обойтись.
2️⃣ Мониторинг и оптимизация — ключевые процессы.
Регулярная вакуумация, анализ статистики и настройка параметров помогают избежать проблем.
3️⃣ Используйте все возможности Greenplum.
Ресурсные группы и улучшенное управление нагрузкой делают систему более гибкой.

📌 Итог:
Доклад Дмитрия — это ценный опыт для всех, кто работает с Greenplum. Чтобы избежать проблем, важно не только знать особенности системы, но и регулярно оптимизировать процессы. А еще — учиться на чужих ошибках, чтобы не наступать на те же грабли. 😉

ORC и Parquet. О форматах и их использовании на базе HDFS / Александр Маркачев (билайн)

Ссылка на выступление:
https://www.youtube.com/watch?v=GM8vEhlBbF8
или
https://vkvideo.ru/video-152308462_456239403
Сложность: 2/3 (Есть технические моменты, но в целом понятно)

Кому будет интересно: Не рекомендую смотреть, если никогда не работали ни с одним их этих форматов.
Если при создании датасетов бездумно указывали parquet или ORC и хотите понять в чём же разница между этими двумя форматами, то must have.

✨ Краткий пересказ и выводы по докладу Александра Маркачева (билайн) — ORC и Parquet: форматы и их использование на базе HDFS ✨
Александр Маркачев рассказал о ключевых аспектах работы с форматами данных ORC и Parquet, их структуре, преимуществах и оптимизации для эффективного хранения и обработки данных на базе HDFS.

🔍 Основные тезисы:
1️⃣ Рост данных и задачи дата-инженеров:
• Объем данных растет экспоненциально: 97 зетабайт данных сейчас и 220 зетабайт ежедневно к 2025 году.
• Задача дата-инженеров — эффективно управлять данными, чтобы экономить место и обеспечивать быстрый доступ.
2️⃣ Основные форматы данных:
• Parquet и ORC — колончатые форматы, подходящие для хранения и быстрого доступа.
• Ключевые метрики качества: степень сжатия и скорость доступа.
3️⃣ Структура файлов:
• Parquet:
◦ Состоит из заголовка, групп строк, участков колонок и страниц.
◦ Заголовок содержит магическое число для идентификации.
◦ Группы строк и колонок позволяют читать данные по частям.
• ORC:
◦ Состоит из заголовка, страйпов, участков колонок, страниц и постскрипта.
◦ Постскрипт содержит метаданные в сжатом виде.
◦ Страйпы аналогичны группам строк в Parquet.
4️⃣ Сравнение форматов:
• Parquet:
◦ Лучше подходит для разработки, так как позволяет менять местами столбцы.
◦ Сжимает хуже, но работает быстрее благодаря более слабым алгоритмам сжатия.
• ORC:
◦ Поддерживает более мощные алгоритмы сжатия, что делает его предпочтительным для долгосрочной аналитики.
◦ Имеет поддержку ACID и спецсимволов.
5️⃣ Оптимизация данных:
• Маленькие таблицы:
◦ Оптимизация не имеет смысла, но отключение индексов и сортировка данных могут ускорить работу.
• Средние таблицы:
◦ Сортировка таблицы уменьшает нагрузку на кластер в три раза.
◦ Выбор меньшего блока данных ускоряет чтение.
• Большие таблицы:
◦ Требуют настройки индексов и использования блум-фильтров для уменьшения объема читаемых данных.

🚀 Рекомендации:
• ORC предпочтителен для долгосрочной аналитики благодаря мощным алгоритмам сжатия и поддержке ACID.
• Parquet лучше подходит для разработки и сценариев, где важна скорость доступа.
• Используйте сортировку данных и настройку индексов для оптимизации производительности.
• Для больших таблиц применяйте блум-фильтры и настраивайте размеры блоков.

💡 Выводы:
1️⃣ ORC vs Parquet:
• ORC лучше сжимает и подходит для аналитики, Parquet быстрее и гибче для разработки.
• Выбор формата зависит от задач: аналитика или разработка.
2️⃣ Оптимизация — ключ к эффективности:
• Сортировка данных, настройка индексов и использование блум-фильтров значительно улучшают производительность.
3️⃣ Spark 3.2 улучшил работу с ORC:
• Новые версии Spark оптимизировали работу с ORC, что увеличило скорость обработки данных.

📌 Итог:
Доклад Александра Маркачева — это отличный гайд по выбору и оптимизации форматов данных. ORC и Parquet — мощные инструменты, но их эффективное использование требует понимания их особенностей и правильной настройки.

Основной вывод из доклада

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

Ссылка на выступление:
https://youtu.be/N0VIhpUf4qM?si=_g23HWZ5x07c-See
или
https://vkvideo.ru/video-147464741_456239315

Сложность: 3/3 (Технически насыщенный доклад, требует понимания Apache Flink и потоковой обработки данных)
Кому будет интересно: Всем, кто работает с Apache Flink или планирует его использовать. Подойдёт для первичного знакомства с Apache Flink.

✨ Краткий пересказ и выводы по докладу Валентины Предтеченской — Apache Flink под капотом: distributed, stateful, realtime ✨
Валентина Предтеченская подробно разобрала внутреннюю работу Apache Flink, фокусируясь на трех ключевых аспектах: распределенность (distributed), управление состоянием (stateful) и обработка в реальном времени (realtime). Доклад был ориентирован на практикующих инженеров, уже знакомых с Flink, и содержал множество технических деталей и примеров.

🔍 Основные тезисы:
1️⃣ Введение в Apache Flink:
• Flink — это фреймворк для распределенной обработки данных в реальном времени.
• Основные компоненты: JobManager, TaskManager, Task Slots.
• Flink решает задачи потоковой аналитики, поиска и рекомендаций.
2️⃣ Распределенный движок:
• Пример задачи: подсчет кликов по объявлениям в реальном времени.
• Использование Kafka для обработки событий.
• Работа с событиями пользователей, такими как клики.
3️⃣ Параллелизм и настройка:
• Параллелизм настраивается эмпирически через нагрузочное тестирование.
• Важно закладывать "запас" для надежности системы.
• Рекомендации по настройке параллелизма для конкретных операторов.
4️⃣ Управление состоянием (Stateful):
• Два типа состояния: HashMapState(в памяти) и RocksDBState (в файловой системе).
• Важно указывать TTL (время жизни) для данных, чтобы избежать неограниченного роста.
• Чекпоинты используются для синхронизации состояния между TaskManager'ами.
5️⃣ Реал-тайм обработка:
• Flink поддерживает два типа времени: Processing Time и Event Time.
• Watermark (ватермарка) — это механизм для отслеживания времени в потоке данных.
• Ватермарка помогает обрабатывать события с задержкой и избегать проблем с событиями из "будущего".
6️⃣ Оптимизация и производительность:
• Chaining (чейнинг) — оптимизация передачи данных между операторами в одном Task'е.
• Rebalance (ребаланс) — перераспределение данных между параллельными задачами.
• Использование Broadcast(бродкаст) для фильтрации данных, например, черных списков IP-адресов.
7️⃣ Проблемы и решения:
• События из будущего: могут нарушить логику обработки. Решение — чинить источник данных или отбрасывать такие события.
• Восстановление состояния: при падении TaskManager'а состояние восстанавливается из чекпоинтов.
• Эволюция состояния: изменение типов данных в состоянии требует осторожности, чтобы не потерять данные.

🚀 Рекомендации:
• Используйте чекпоинты для надежного восстановления состояния.
• Настройте TTL для данных, чтобы избежать неограниченного роста состояния.
• Оптимизируйте передачу данных с помощью чейнинга и ребаланса.
• Внимательно работайте с ватермарками, чтобы корректно обрабатывать задержки и события из "будущего".

💡 Выводы:
1️⃣ Flink — мощный инструмент для потоковой обработки:
• Подходит для задач, требующих низкой задержки и высокой надежности.
• Управление состоянием и чекпоинты делают его устойчивым к сбоям.
2️⃣ Оптимизация — ключ к производительности:
• Правильная настройка параллелизма, чейнинга и ребаланса значительно улучшает производительность.
• Использование ватермарок помогает корректно обрабатывать задержки в данных.
3️⃣ Эволюция состояния требует осторожности:
• Изменение типов данных в состоянии может привести к потере данных, если не спланировано заранее.
• Используйте сейф-пойнты для безопасного обновления логики без остановки стриминга.

📌 Итог:
Доклад Валентины Предтеченской — это глубокий dive в Apache Flink, который поможет инженерам лучше понять, как работает этот фреймворк под капотом. Flink — это не просто инструмент, а целая экосистема, требующая внимательной настройки и понимания внутренних механизмов.

Субботний вечер, а значит время смотреть конференции

Автоматический подбор параметров для Spark-приложений / Валерия Дымбицкая (OneFactor)

Ссылка на выступление: https://www.youtube.com/watch?v=Ot93PQELdcM
или
https://vk.com/video-152308462_456239627

Сложность: 3/3 (Технически насыщенный доклад, требует понимания Apache Spark, оптимизации ресурсов и машинного обучения)
Кому будет интересно: Тем, кто работает с Spark. Если ни разу не запускали Spark - смело пропускайте данный пост.

✨ Краткий пересказ и выводы по докладу Валерии Дымбицкой (OneFactor) ✨
Валерия представила систему автоматического тюнинга параметров для Spark-приложений, основанную на анализе логов и машинном обучении. Система разработана для оптимизации использования ресурсов в кластере и повышения эффективности выполнения задач.

🔍 Основные тезисы:
1️⃣ Проблемы текущего подхода:
• Кластер ограничен в ресурсах, и даже при большом количестве узлов и памяти их может не хватать.
• Одинаковые ресурсы для всех запусков приводят к недоутилизации и конкуренции за ресурсы.
• Легкие задачи могут занимать все ресурсы, оставляя тяжелые задачи в очереди.
2️⃣ Описание системы литгенерации:
• Включает базу абонентов и Spark-пайплайны для отбора данных.
• Ежедневно запускается около 600 задач, и каждый день добавляются новые триггеры и пайплайны.
• Пайплайны уникальны и создаются дата-специалистами, что усложняет унификацию параметров.
3️⃣ Первый подход: априорный тюнинг:
• Попытка определить параметры перед запуском задачи.
• Проблема: сложность выделения классов задач и необходимость экспериментов на продовой среде.
• Неэффективность из-за затрат времени и ресурсов.
4️⃣ Апостериорный подход: оптимизация на основе логов:
• Использование метрик из логов Spark для определения оптимальных параметров.
• Анализ логов в формате JSON для получения информации о шафлах, спилах и времени в GC.
• Основной фокус на оптимизации параметра Spark Executor Memory.
5️⃣ Правила оптимизации памяти:
• Правило GC: Время сборки мусора не должно превышать 10% от времени работы приложения.
• Правило сброса записи на диск:Избегать сброса данных на диск, что указывает на нехватку памяти.
• Правило использования данных:Объем данных должен укладываться в выделенную память.
6️⃣ Объединение предсказаний:
• Использование взвешенного среднего для объединения предсказаний от трех правил.
• Минимум как метод объединения для определения оптимального объема памяти.
7️⃣ Изотоническая регрессия:
• Построение регрессии для каждого пайплайна.
• Преимущества: легко обучается на малом количестве данных, удобно хранить в базе данных.
• Переобучение после каждого запуска приложения для адаптации к изменениям.
8️⃣ Проблемы и решения:
• Откат при неправильных предсказаниях: Возможность вернуться к предыдущим параметрам.
• Переобучение: Быстрое обновление регрессий после каждого запуска.
• Параллельность: Добавление параллельности для ускорения переобучения.

🚀 Рекомендации:
• Используйте логи Spark для анализа и оптимизации параметров.
• Применяйте изотоническую регрессию для быстрого и эффективного тюнинга.
• Регулярно переобучайте модели для адаптации к изменениям в задачах.
• Оптимизируйте не только память, но и другие параметры, такие как количество шафлов.

💡 Выводы:
1️⃣ Автоматизация тюнинга — ключ к эффективности:
• Ручная настройка параметров неэффективна и требует много времени.
• Автоматизация позволяет экономить ресурсы и повышать производительность.
2️⃣ Логи Spark — ценный источник данных:
• Анализ логов помогает выявить узкие места и оптимизировать параметры.
• Использование машинного обучения для анализа логов — перспективное направление.
3️⃣ Изотоническая регрессия — мощный инструмент:
• Простота обучения и интерпретации делает ее идеальной для задач тюнинга.
• Быстрое переобучение позволяет адаптироваться к изменениям в задачах.

📌 Итог:
Доклад Валерии Дымбицкой — это отличный пример того, как автоматизация и машинное обучение могут значительно улучшить эффективность работы с распределенными системами.

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

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

Сложность: 1,5/3. Кода на слайдах нет, рассказывается максимально понятно
Кому будет интересно: подойдёт для знакомства с Lakehouse на примере реальной задачи миграции

Перед пересказом отвечу на главный вопрос в докладе: а что делать то?

Ответ: Переходить в Lakehouse

✨ Краткий пересказ и выводы по докладу Александра Филатова — Что делать, если DWH растет слишком быстро ✨
Александр Филатов поделился опытом решения проблем, связанных с быстрым ростом хранилища данных (DWH) в компании. Основной фокус был на масштабируемости, производительности и выборе подходящих технологий для обработки больших объемов данных.

🔍 Основные тезисы:
1️⃣ Проблемы роста DWH:
• Хранилище данных на базе Vertica состоит из 50 нод, каждая из которых хранит данные локально и выполняет запросы.
• Ежедневно система обрабатывает около 1 миллиона запросов от 200 пользователей.
• Основные проблемы:
◦ Шумные соседи: Конкуренция за ресурсы между пользователями приводит к задержкам.
◦ Масштабируемость: Расширение кластера требует пересоздания таблиц и занимает неделю.
◦ Доступность данных: Сбои в одной ноде вызывают эффект домино, что приводит к простою системы.
2️⃣ Проблемы с загрузкой данных:
• Неполная загрузка данных из-за технических сбоев.
• Баланс между качеством и количеством данных: важно обеспечить доверие к данным для аналитики.
3️⃣ Тестирование новых решений:
• В 2022 году компания тестировала различные инструменты, включая Greenplum, DataBricks, Trino, Starrocks, Spark.
• Starrocks показал лучшие результаты для меньших объемов данных, но не подошел для текущих масштабов компании.
• Trino оказался более производительным и масштабируемым решением.
4️⃣ Переход на Trino:
• Trino состоит из нескольких компонентов: данные в сейфе, сторож, координатор и воркеры.
• Координатор принимает запросы, разбирает их и отправляет на воркеры.
• Проблемы с адаптацией старых запросов и необходимость создания внешних таблиц.
5️⃣ Оптимизация запросов:
• Запросы в Trino отличаются от Vertica, что требует переработки и оптимизации.
• Отсутствие временных таблиц в Trino требует создания эффективной схемы.
6️⃣ Проблемы с консистентностью данных:
• Trino использует транзакции для обеспечения консистентности данных.
• Проблемы с чтением данных из Vertica и использованием полюсовой библиотеки.
• Использование партиций для обеспечения целостности данных.
7️⃣ Текущая ситуация и планы:
• Треть мощности и хранилища используется двумя основными потребителями.
• Планы на год: изолировать "толстяков" и перенести главные расчеты в Trino.
• Trino позволяет быстро восстанавливать данные после сбоев (2 минуты против 45 минут в Vertica).

🚀 Рекомендации:
• Изоляция ресурсов: Изолируйте крупных потребителей данных для предотвращения конкуренции за ресурсы.
• Использование партиций: Применяйте партиции для обеспечения целостности данных и ускорения обработки.


💡 Выводы:
Рост данных требует новых подходов:
• Традиционные системы, такие как Vertica, могут не справляться с быстрым ростом данных.
• Переход на более современные и легковесные решения, такие как Trino, помогает решить проблемы масштабируемости.

📌 Итог:
Доклад Александра Филатова — это ценный опыт для всех, кто сталкивается с проблемами роста хранилищ данных и рассматривает переход в Lakehouse.

Владимир Озеров — Как работает Apache Iceberg на примере Trino

https://www.youtube.com/watch?v=hsCtWz8JDRc
или
https://vkvideo.ru/video-147464741_456239437

Сложность: 2/3 (Очень сложно, но очень понятно)

Кому будет интересно: Будущее (а может уже и настоящее) совремнных Data Patform - Iceberg и Trino. Слышали про Iceberg и Trino и хотите понять, как они работают? Тогда обязательно к просмотру.

---

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

Владимир Озеров, руководитель компании Querify Labs, подробно разобрал, как работает Apache Iceberg, и показал его интеграцию с Trino.

---

🔍 Основные тезисы:

1️⃣ История и значение Iceberg:
- Iceberg был создан для решения проблем атомарных обновлений и консистентности данных в дата-лейках. Изначально разработан Netflix для работы с большими объемами данных.

2️⃣ Основные концепции Iceberg:
- Iceberg моделирует транзакции поверх таблиц в дата-лейках.
- Использует файлы данных и метаданные для обеспечения консистентности.
- Основан на журнале изменений, аналогично PostgreSQL и Kafka.

3️⃣ Метаданные и транзакции:
- Метаданные описывают файлы и их консистентные состояния.
- Iceberg поддерживает транзакции только в рамках одной таблицы. Поддержка транзакций между таблицами пока не реализована, но обсуждается.

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

5️⃣ Метаданные и их структура:
- Метаданные в Iceberg разбиты на четыре типа файлов:
- Metadata
- Manifest list (avro)
- Manifest (json)
- Статистики (Puffin)

6️⃣ Атомарная запись и публикация данных:
- Атомарная запись данных позволяет избежать проблем с консистенцией.
- Возможен атомарный апдейт, что устраняет проблемы с Eventual Consistency.

7️⃣ Каталоги и их реализация:
- Каталоги в Iceberg хранят информацию о схемах и таблицах. Самые популярные:
- HMS (Hive Metastore) — самый популярный вариант.
- REST-каталог рассматривается как будущее.

8️⃣ Работа с данными в Iceberg:
- Подходы к удалению записей: Copy-on-Write и Merge-on-Read.
- Merge-on-Read позволяет быстро читать данные, но замедляет запись.

9️⃣ Партишин-трансформ:
- Партишин-трансформ — это функция, которая принимает одну или несколько колонок и возвращает значение для ключа партии.
- В отличие от Hive, где каждая колонка позиционирования была реальной, в Iceberg это виртуальные таблицы.

🔟 Технические аспекты Iceberg:
- Iceberg — это библиотека, которая не запускает процессы, а предоставляет методы для работы с метаданными.
- Iceberg не поддерживает материализованные представления, но Trino позволяет строить их поверх Iceberg.
- Для работы с Iceberg необходимо реализовать два ключевых интерфейса:
- Интерфейс для общения с хранилищем.
- Интерфейс для атомарной публикации изменений метаданных (каталог).

---

💡 Выводы:

Iceberg — мощный инструмент для аналитики:
- Предоставляет транзакционность и консистентность данных в дата-лейках.
- Подходит для работы с большими объемами данных и сложными аналитическими запросами. Не подходит для OLTP
- Trino использует Iceberg для атомарной публикации изменений метаданных и статистики.
- Trino поддерживает чтение, запись, дата-скипинг, предикат пуш-дауны, партишинг и тайм-тревел.

📌 Итог:

Доклад Владимира Озерова — это глубокий dive в Apache Iceberg, который помогает понять, как этот инструмент обеспечивает транзакционность и консистентность данных в аналитических системах. Интеграция с Trino делает Iceberg еще более мощным инструментом для работы с большими данными.

Никита Юрасов, Леонид Кожинов — От хайпа до продакшена: 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 позволило значительно улучшить процесс загрузки данных.