Data Engineering Digest

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

✨ Валентин Пановский — Миграция на Iceberg: как кролик съел зеленую сливу и не умер Сложность: 1/3 (Интересная историческая справка в начале , нет сложного кода, в который необходимо вникнуть. Докладчик рассказывает понятным и доступным языком) https://www.youtube.com/watch?v=YWD7WcfFfk8 Валентин Пановский поделился опытом миграции с монолитного Greenplum на разделенную Lakehouse-архитектуру с Iceberg в страховой компании. 🔍 Проблемы старой системы Монолитная DWH на Greenplum: Высокая стоимость (лицензии + оборудование) Сложности с масштабированием Ограниченная гибкость для аналитиков Гетерогенная среда: 50-70 ТБ данных за 4 года Разные источники: MongoDB, Kafka, классические БД 🚀 Выбор новой архитектуры Требования: ✔️ Разделение storage/compute ✔️ Open Source решения ✔️ Снижение TCO (полная окупаемость к 2025) Выбранный стек: Хранение: S3 (Яндекс.Облако) + Iceberg Compute: Trino (основной) + Greenplum (легаси) Оркестрация: Dagster + dbt Каталог: OpenMetadata ⚙️ Реализация 1️⃣ Миграция данных: Таблицы переносились "в лоб" через Airflow. Самая большая таблица - до 60 ГБ). Основной объем — инкрементально (T+1) 2️⃣ Слои данных: Raw → ODS → DDS → Витрины Исторические данные: срезы раз в неделю + архив (6 месяцев) 3️⃣ Интеграции: MongoDB: CDC через Debezium → Kafka → Greenplum (PXF) Trino: Нативные коннекторы (проще чем в GP) 🛠 Проблемы и решения Деградация JOIN-ов: До 27% в не-OLAP сценариях Кастомные типы данных: Обработка на ETL-уровне Хранимые процедуры: Пришлось переписывать витрины Безопасность: Реализована через Trino + Keycloak 📊 Результаты ✅ Экономия: Снижение затрат на лицензии и оборудование Хранение в 10+ раз дешевле ✅ Гибкость: Разные движки (Trino/GP) работают с одними данными Легкое масштабирование в Kubernetes 🔮 Планы Переход с HMS на Nessie (branch-поддержка) Внедрение Data Vault вместо 3NF Автоскейлинг Trino на основе метрик 🤔 Ответы на вопросы Q: Как настраивали ИБ? A: Вопросы изоляции и безопасности решались на уровне trino через с

✨ Татьяна Дидова — Как мы тестировали 5 способов загрузки данных в Greenplum и что из этого вышло Сложность: 1/3 (Желателен минимальный опыт работы с Greenplum. Тем, кто в GP погружен максимально, вряд ли будет интересно, разве что про то, что sparkом тоже можно писать в GP, не через мастер) YouTube: https://www.youtube.com/watch?v=7EcieM3XoXE VK Video: https://vkvideo.ru/video-147464741_456239454 Татьяна Дидова, Tech Lead Data Engineer в АЭРО, знакомит слушателей со способами загрузки данных в GP. 🔍 Первый кейс: миграция с Oracle на Greenplum - "реализовать не хуже, чем есть на Oracle" 🔍 Второй кейс: Заказчика не устраивает процесс загрузки в ClickHouse, необходима реализация на Greenplum, результат должен быть сильно лучше. Условия: 1️⃣ На первом проекте сотни баз, на втором - около десятка. 2️⃣ Количество баз данных и объем данных растет, объем выгружаемых данных отличается между источниками: в одном источнике десятки гигабайт, в другом - тысячи строк. 3️⃣ При создании базы данных на Greenplum, как правило, есть возможность выбрать оптимальный для данного случая способ загрузки, но при постановке задачи сделать не хуже или лучше, чем уже есть при использовании других технологий, были сформулированы требования по времени загрузки. ⚙️ Способы загрузки данных non-parallel: Insert, Copy ✅ Нужен один сервер для развертки кода загрузчика ✅ Удобство отладки ⭕️ Высокая нагрузка на мастер-узел ⭕️ Низкая эффективность при большом объеме данных parallel: 1️⃣ PXF: ✅ Прямое подключение к источнику ✅ Достаточно знать SQL и credentials для подключения к источнику ⭕️ Сложность администрирования ⭕️ Сокращение ресурсов сегмента ⭕️ Повышение требований к источнику ⭕️ credentials в запросе создают проблемы с информационной безопасностью 2️⃣ Gpfdist: ✅ Оптимизация под работу с Greenplum ✅ Параметризация загрузки данных по сегментам ⭕️ Требовательность к производительности сети ⭕️ Необходимость управления несколькими экземплярами при больших объемах ⭕️ Масштабируемость

Николай Ижиков — One More Way to Make Backup in Ignite Сложность: 3/3 (Обязательно к прослушиванию, если вам интересна работа с OLTP-нагрузкой и технические подробности снятия бэкапов) Николай Ижиков, Platform V DataGrid Tech Lead, а также контрибьютор в Apache Kafka и участник PMC Apache ignite, рассказывает нам, как реализованы бэкапы в Platform V DataGrid, а главное — про cache dumps. YouTube: https://www.youtube.com/watch?v=A3EkvdGK4Jg VK Видео: https://vkvideo.ru/video-147464741_456239442 🔍 Условия: Кластер процессинга: 32 узла, 700 ГБ RAM на узел, 40к RPS на узел. Кластер токенизатора: 5 узлов, 550 ГБ RAM на узел, 500к RPS. ⚙️Падение СУБД 1️⃣ Однонодовая СУБД — после падения приложение не работает, Запросы не обслуживаются, данные теряются при простое. 2️⃣ Распределенная СУБД — спектр последствий разный. Может снижаться перфоманс, может теряться часть данных. ⚙️Метрики восстановления после аварии Recovery Point Objective — целевая точка восстановления, после которой мы теряем данные. Мы оцениваем время, в течение которого мы теряем данные за этой точкой. Recovery Time Objective — с её помощью мы оцениваем время, затраченное на восстановление системы после аварии. 🛠 Способы формирования бэкапов (рекомендуется изучить презентацию к докладу): 1️⃣ Apache Ignite: ребаланс данных, позволяет сохранить данные, если количество упавших нод меньше бэкап-фактора. 2️⃣ DataGrid: при ребалансе данных распределение партиций такое, что у стойки есть дублер. Позволяет восстановиться при падении стойки. 3️⃣ Apache Ignite: CDC обеспечивает асинхронную логическую репликацию данных. RPO ➡️ секунды, RTO ➡️ 0. Данные реплицируются в другой кластер через WAL, доступ к данным открывается после перемещения сегмента в архив. Из-за этого RPO сдвигается. 4️⃣ Data Grid: Online CDC внутри ноды есть буфер данных, который наполняется событиями и из него данные стримятся в соседний кластер. RPO ➡️ 0, RTO ➡️ 0. Растет потребление памяти, при переполнении используется классичес

✨ Станислав Лысиков — StarRocks как ядро современной платформы данных Станислав Лысиков рассказал о внедрении StarRocks в продуктовом финтехе с данными до петабайта. Доклад — это честный разбор опыта перехода на новую аналитическую СУБД. Дисклеймер: Рекомендую не читать этот пост, а посмотреть доклад самим) Смотрится легко и очень интересно) YouTube: https://www.youtube.com/watch?v=oiPXIbX-cTw VK Видео: https://vkvideo.ru/video-147464741_456239483 Сложность: 2/3 (Технически насыщенный доклад, требует понимания архитектуры аналитических баз данных) Кому будет интересно: • Дата-архитекторам и инженерам • Всем, кто выбирает аналитическую СУБД для высокой нагрузки 🔍 Проблемы, которые привели к StarRocks • Старый стек: Микросервисы на MySQL + Go, но аналитика не масштабировалась • Требования к новой БД: ✔️ Дешевое внедрение и масштабируемость ✔️ Высокая скорость на потоковых данных ✔️ Open Source с активным сообществом 🏗 Архитектура и установка Два режима работы: 1 Share Nothing (данные + вычисления на одних нодах) 2 Share Data (отдельное хранилище) Минимальные требования: • 3 ноды для продакшна (рекомендуется 5) • NVMe диски, RAID не требуется • Репликация на уровне серверов Управление: • Готовность к Kubernetes (есть операторы) • Простое ручное развертывание через Helm ⚡️ Ключевые особенности StarRocks Производительность: • Разработан для лямбда-архитектуры • Высокая скорость запросов (сравнима с ClickHouse, быстрее Vertica/Spark) Поддержка форматов: • Нативные коннекторы к HDFS, Iceberg, JSON • Работа с Hive Metastore Уникальные фичи: • Data Recovery — восстановление случайно удаленных данных • Частичные UPDATE по условию • Хранение Kafka-оффсетов в БД (независимость от consumer groups) 🔄 Интеграция с данными Потоковая загрузка: • Нативная поддержка Kafka • Проблема с порядком сообщений решена через таймштампы Работа с Go: • Прямая работа с Go-структурами (команда без Java/.NET специалистов) 🛠 Проблемы и решения 1️⃣ Шардирование данных: