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

Почему формат «симулятор + ментор» работает лучше классических курсов

За последние годы накопилось довольно много наблюдений о том, почему классическое онлайн-обучение по Data Engineering редко даёт нужный результат. Особенно если человек не просто «входит в IT», а хочет реально разобраться в архитектуре пайплайнов, orchestration, хранилищах и потоковой обработке.

Коротко — типовая проблема:

- Видео без связки с задачами → быстро забывается
- Нет контекста, зачем делать то или иное → не формируется мышление инженера
- Самостоятельная борьба с непониманием → упадок мотивации → dropout
- «Игра в проект» вместо приближенной к продовой среды

📍 Поэтому я внимательно посмотрел на новый поток курса «Инженер данных» от Simulative, который стартует 11 июля. И кажется, там как раз попытались обойти эти узкие места.

Курс построен как симулятор рабочей среды:
— Используется стек, который встречается в большинстве дата-платформ:
Spark, Kafka, Airflow, PostgreSQL, CI/CD
— Все задания — это имитация типовых прод-задач
— Формат сопровождения ментором из индустрии, который не просто проверяет, а помогает понять, почему архитектура пайплайна устроена именно так, где искать слабые места, как мыслить в продовом контексте.

Ментор — Александр Дарьин (СберТройка, автор канала «Аналитик на минималках») — сам проходил путь с нуля и работает в инфраструктуре на стеке, близком к тому, что сейчас активно внедряется в крупных DLH-решениях (Kafka → S3 → Lake → витрины).

📌 Вывод, который напрашивается: если задача — не просто «поверхностно пройти курс», а подготовиться к настоящей инженерной работе — формат “симулятора + ментор” даёт больше эффекта, чем набор видео + ТЗ + чат поддержки.

Кстати, если зайдете на поток до понедельника по промокоду DIGEST, получите скидку 25%
🔗 Оставляйте заявку

P.S. Если есть подобные форматы, где действительно моделируются реальные процессы (CI/CD, отказоустойчивость, DAG-и, потоки, мониторинг) — делитесь, интересно собрать такую подборку.