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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

---

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

---

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

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

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

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

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

---

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

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

---

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

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

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

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


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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


---

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

---

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

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

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

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

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

---

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

---

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

---

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

---

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

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

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

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

---

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

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

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

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

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

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

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

---

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

---

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

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

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

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

---

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

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

---

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

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

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

---

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

---

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

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

---

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

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

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

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

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

---

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

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

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

✨ Пётр Гуринов и Сергей Куприков: Опыт внедрения Lakehouse в компании Лемана Тех.

Ссылка на выступление: https://www.youtube.com/watch?v=r70FGQWdEvc&t=950s

Сложность: 2/3 (Сложного кода в докладе нет, но требуется понимание архитектуры DWH/DLH)

Кому будет интересно:
- Вообще всем, кто как-то связан с построением хранилищ данных. DLH это новая реальность, в которую обязательно нужно погрузиться.

---

Компания с масштабной инфраструктурой (600 TB в DWH, 1.5 TB в S3) перешла на Lakehouse-архитектуру. Рассказываем, как, зачем и с какими проблемами столкнулись.

---

🔍 Проблемы старой архитектуры
- Greenplum (Shared Nothing):
- Данные невозможно оторвать от compute
- Ограниченная масштабируемость
- Высокие затраты на хранение

- Pipeline до внедрения DLH:

Источники собираются в Kafka. Flink вычитывает данные, складывает их в S3 в формате avro (слой raw). Далее Spark трансфармирует данные в parquet, складывает данные
в S3 (слой ods). Оттуда данные попадают в GP, который является единой точкой входа всех сотрудников компании (любой сотрудник магазина может запросить доступ к DWH).
   

---

🚀 Переход на Lakehouse
Требования к новой платформе:
✔️ Open Source
✔️ Разделение compute/storage
✔️ Cloud-ready/cloud agnostic
✔️ Низкий порог входа

Выбранный стек:
- Вычисления: Trino (поддержка ANSI SQL, активное комьюнити, лицензирование и гетерогенность источников)
- Табличный формат: Iceberg (выбирали между Iceberg/Hudi/Delta Lake)
- Хранение: S3
- Метаданные: HMS (планы на переход к Nessie для branch-поддержки)

---

⚙️ Реализация:
- Кластеры Trino:
- Ad hoc (пользователи/BI)
- ETL (тех.учетки)
- DQ (Data Quality)

Интеграция:
- Аутентификация через Keycloak + AD
- Управление доступом: file-based ACL

---

🛠 Проблемы и решения
Ограничения технологий:
- Нет коннектора Trino → Greenplum (ходят через Master)
- Iceberg: нет мультитранзакций, сложности с типами данных
- Trino: нет временных таблиц, legacy spill-файлы

🛠 Мониторинг:
- Мониторинг производительности с использованием Prometheus и Grafana. JMX Exporter снимает метрики и преобразует в формат Prometheus. Prometheus operator пушит их в VictoriaMetrics, которые визуализируются в Grafana.
-Мониторинг пользовательских запросов из коробки имеет критическое ограничение: после рестарта вся история удаляется.
Реализовали мониторинг с использованием Kafka event listener, оттуда пишем в CH и визуализируем в Grafana. Дашборды выложены в opensource: https://github.com/rugratko/grafana-trino-overview-preset
- Кастомный сбор метрик запросов через Kafka → ClickHouse

🛠 Управление инфраструктурой:
- GitOps + ArgoCD + Vault
- Автоматические откаты

---

📊 Результаты
✅ Экономия:
- Хранение дешевле в 10+ раз
- Быстрое масштабирование в Kubernetes
- Независимое масштабирование и отсутствие необходимости резервировать место заранее.

✅ Производительность:
- Ускорение расчетов витрин
- Легкий переход запросов с GP на Trino
- Аналитики получают дополнительную точку входа для доступа к данным
- Разные вычислительные движки могут использовать одни и те же данные.
---

🔮 Планы
- Замена HMS на Nessie
- Продуктивизация SCD2-таблиц
- Автоскейлинг Trino на основе метрик
- Копирование Iceberg-таблиц в Greenplum
- Обслуживание (maintenance) Iceberg таблиц. Пока не актуально, так как сейчас данные append only

---

💡 Вывод:
Lakehouse на базе Trino + Iceberg — гибкая альтернатива классическому DWH. Главные преимущества: разделение compute/storage, масштабируемость и экономия.

Отдельного поста заслуживают ответы на вопросы по выступлению команды Лемана Тех про LakeHouse. Я, пользуясь случаем, выражу благодарность комании querify labs (cedrus data) за организацию митапа. И, конечно, ребятам из Лемана Тех за то, что поделились своим опытом и готовы ответить на Ваши вопросы в комментариях к этому посту.

---

Как разделили ресурсы?
Ресурсные группы не настраивали, нагрузку разделили по разным кластерам.

Сравнение производительности Greenplum и Trino?
Trino медленнее Greenplum примерно на 20%, если у GP всё на SSD.

Рассматриваете ли Paimon как каталог?
Пока не тестировали, хотим подходить к вопросу с каталогом итеративно.

Почему выбрали Avro?
Технология удовлетворяла всем требованиям и хорошо знакомы с этой технологией, есть опыт работы.


Данные отправляют вам или вы их запрашиваете?
Команды не настраивают ничего сами, сервисная служба настраивает Debezium, дальше всё льётся в общую шину, а платформа данных уже самостоятельно забирает данные.

Как боретесь с большим количеством файлов в S3?
Сейчас поддерживаем вручную, планируется автоматизация.

Используете ли FTE (Fault-tolerant execution)?
Не используем, слишком медленно — просто перезапускаем при падениях.

Какой функционал Iceberg используете для ускорения запросов?
Индексы не накидывали, используем партиционирование и бакетирование. С сортировкой экспериментировали - большого эффекта не дала.

Как обеспечиваете high availability?
Пока всё в ручном режиме, координатор ни разу не падал.

Почему выбрали HMS?
Нужен был один каталог для работы с паркетами и Iceberg — HMS это закрыл.

---

Задавайте свои вопросы по выступлению) Тема очень актуальная и животрепещущая) Пётр и Сергей, по возможности, ответят на них)

✨ Валентин Пановский — Миграция на 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 через системы аутентификации и политик доступа.

Q: Как решали проблему неконсистентных типов?
A: На ETL-уровне. MongoDB оставили как есть (легаси)

Q: Почему Parquet, а не ORC?
A: Лучшая производительность в наших тестах

Q: FTE не пробовали?
A: Нет, проще перезапускать (макс. запрос — 45 мин)

Q: Используете ли динамическое партиционирование?
A: Пока в бэклоге

💡 Вывод:
Миграция на Iceberg — сложный, но окупаемый процесс. Главные плюсы: гибкость, экономия и возможность использовать лучшие инструменты для разных задач.