Data Engineering Digest

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