Data Engineering Digest

Следующий Digest доклада будет в выходные про шикарный EL инструмент - airbyte. Пока рекомендую фоном посмотреть дискуссию про будущее Greenpum на T-Meetup: https://www.youtube.com/watch?v=EXRLqI9mx54&list=PLLrf_044z4Jp8l6GauGEmbZXIwABfrbRQ

Самые интересные слайды из доклада про каталог данных)

✨ Наталья Журавлева — Как быстро запустить каталог данных на примере 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 значительно упростило работу с данными в компании.

Скрин архитектуры Data Platform банка из последнего поста. Пожалуйста, делитесь нашими постами с коллегами)

✨ Иван Клименко (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 позволило значительно улучшить процесс загрузки данных.

✨ Кузьма Лешаков — Разгоним запросы: как быстро готовить 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. Пожалуйста, делитесь постом с коллегами. Для нас это очень важно)

Добавлю комментарий от себя: кажется, что технология безумно крутая, но пока сырая. Документация очень скудная. https://yandex.cloud/ru/docs/managed-greenplum/operations/extensions/yezzey Мне искренне не понятно, почему реализовано полное охлаждение таблицы, а не конкретных партиций. Особенно грустными выглядят бенчмарки, которые мало соотносятся с реальностью и предложение «сами попробуйте». P.S. Следующий доклад будет про великий и ужасный ClickHouse

✨ Андрей Бородин — 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 уже показывает хорошие результаты, но требует дальнейшего улучшения, особенно в области локального кэширования и оптимизации сетевого обмена.

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

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

Владимир Озеров — Как работает 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 еще более мощным инструментом для работы с большими данными.

Что делать, если 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.

Субботний вечер, а значит время смотреть конференции Автоматический подбор параметров для 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️⃣ Изотоническая регрессия — мощный инструмент: • Простота обучения и интерпретации делает ее идеальной для задач тюнинга. • Быстрое переобучение позволяет адаптироваться к изменениям в задачах. 📌 Итог: Доклад Валерии Дымбицкой — это отличный пример того, как автоматизация и машинное обучение могут значительно улучшить эффективность работы с распределенными системами.

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 — это не просто инструмент, а целая экосистема, требующая внимательной настройки и понимания внутренних механизмов.

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

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 — мощные инструменты, но их эффективное использование требует понимания их особенностей и правильной настройки.

Ссылка на выступление: 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. Чтобы избежать проблем, важно не только знать особенности системы, но и регулярно оптимизировать процессы. А еще — учиться на чужих ошибках, чтобы не наступать на те же грабли. 😉

Ссылка на выступление: 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 и автоматизация позволяют быстрее реагировать на изменения и снижать задержки. 📌 Итог: Доклад Максима — это не просто про данные, а про новый образ мышления. Чтобы оставаться в тренде, нужно не только внедрять современные технологии, но и менять подходы внутри команд.