🎁Что такое Lakehouse и зачем он нужен?

Lakehouse — это архитектура, которая объединяет плюсы Data Warehouse (DWH) и Data Lake.
Она появилась, потому что у классических решений были сильные ограничения:

DWH отлично подходит для аналитики, но хранить в нём большие объёмы данных дорого, он требует жёстких схем и часто привязывает вас к вендору.

Data Lake дешев и гибок, можно хранить любые данные (от CSV и JSON до картинок и логов), но там нет транзакций, контроля качества и удобного SQL — в итоге аналитики сталкиваются с «грязными» данными и хаосом.

Компании хотели решение, которое совмещает лучшее из двух миров: хранение как в Data Lake и удобство работы как в DWH. Так родилась концепция Lakehouse.

⚡️Ключевые принципы Lakehouse

Единое хранилище данных: сырые и обработанные данные вместе в одном озере (S3/HDFS/облако) в форматах Parquet или ORC.

Наличие ACID-транзакций и схемы таблиц: такая возможность появилась благодаря «табличному слою» (Delta Lake, Iceberg, Hudi), своего рода надстройкой над файлами Parquet или ORC, которая позволяет безопасно обновлять, удалять и версионировать данные, храня метаданные в другом месте

Появление SQL для аналитиков : привычные аналитические запросы теперь можно осуществлять через Trino, Spark SQL, Databricks SQL и BI-инструменты прямо на S3/HDFS и др.

Разделение compute и storage: данные живут в S3, а считаются отдельно на движках — Spark, Trino, Flink, Dremio.

🗂Основные технологии Lakehouse

Delta Lake (Databricks)

Apache Iceberg (Netflix → Apache Foundation)

Apache Hudi (Uber → Apache Foundation)

Они добавляют поверх файлового озера слой таблиц с транзакциями, снапшотами и метаданными.

📌 Как это выглядит на практике
Сырые события из Kafka пишутся в S3.
Spark сохраняет их в Delta Lake таблицы.
Аналитики запускают SQL-запросы через Trino или Databricks SQL.
Data Scientists берут те же самые таблицы для обучения моделей.
Все работают с единым источником правды.

📝Итог
Lakehouse — это универсальная архитектура данных нового поколения.
Она делает хранение дешёвым и масштабируемым, как в Data Lake, а аналитику — удобной и надёжной, как в DWH.
Поэтому крупные компании всё чаще уходят от классических хранилищ в сторону Lakehouse — это и про экономию, и про гибкость, и про скорость работы с данными.

Ставь 🔥 если было полезно

🌐Data Vault и Anchor Modelling

Когда проектируют хранилища данных (DWH), всегда важно обеспечить гибкость, масштабируемость и сохранение истории изменений. Для этого используются специальные методологии моделирования. Две из самых популярных — Data Vault и Anchor Modelling.

❓Что такое Data Vault?

Data Vault — это метод проектирования хранилища в котором всё строится из трёх простых кирпичиков:

Hub (Хаб) – хранит уникальные бизнес-ключи. Например: Клиенты, Товары, Заказы. В таких таблицах только ID и метаданные о загрузке.

Satellite (Сателлит) – хранит атрибуты этих сущностей (например, имя клиента, адрес, телефон) и историю изменений.

Link (Линк) – хранит связи между хабами. Например, «Клиент сделал Заказ» или «Заказ содержит Товар».

👀Пример: есть интернет-магазин, как он будет хранить инфу о клиенте следуя Data Vault

HUB_CUSTOMER → таблица только с customer_id
SAT_CUSTOMER_INFO → таблица с имем, email, адресом клиента
LINK_CUSTOMER_ORDER → таблица соединения клиентов и заказов

🤔Зачем так?

🔘История изменений сохраняется (старые версии не теряются).
🔘Новые данные добавляются без ломки старой модели (просто создаётся новый сателлит).
🔘Удобно интегрировать данные из разных систем.

❓Что такое Anchor Modelling?

Anchor Modelling похож на Data Vault, но идёт ещё дальше: модель становится ещё более гибкой и атомарной.
Каждая таблица отвечает только за одну маленькую часть информации.

Основные элементы:

Anchor (Якорь) – ядро сущности (например, Клиент, Заказ, Товар). Таблица содержит только ключ (client_id, order_id).

Attribute (Атрибут) – свойства сущности (имя клиента, цена товара). Они хранятся отдельно, всегда с историей (valid_from, valid_to).

Tie (Связь) – соединяет разные якоря (например, Клиент - Заказ). Может тоже хранить временной период действия.

Knot (Узел) – справочники, которые часто повторяются (пол, валюта, статусы).

👀Пример: тот же интернет-магазин хранящий данные о клиенте по принципу Anchor Modelling

ANCHOR_CUSTOMER — одна таблица с ключом.
ATTR_CUSTOMER_NAME → имя клиента (с историей).
TIE_CUSTOMER_ORDER → кто сделал заказ.
KNOT_GENDER → пол клиента (M/F).

🧐В чем удобства?

🔘История встроена по умолчанию — каждое свойство можно отследить во времени.
🔘Легко расширять: новый атрибут = новая таблица, при этом модель остаётся стабильной.
🔘Отлично подходит для Agile-подхода: можно начать с маленькой схемы и постепенно её развивать.

🤯Сравнение подходов

Data Vault работает через Hub–Satellite–Link, давая баланс между нормализацией и удобством.

Anchor Modelling идёт глубже и разбивает всё на Anchor–Attribute–Tie–Knot. Это делает модель более гибкой, но и более раздробленной.

📌Возвращаясь к теме Data Lakehouse, написал о нем более подробно тут.

Почему это вообще важно?

🫢Общаясь с представителями разных компаний, замечаю все бОльший тренд на переход к этой архитектуре. Поэтому понимание его концепций, станет для вас большим плюсом на собеседованиях( его все чаще стали спрашивать). Кроме того, необходимо понимать на каком формате данных в большинстве случаев строиться Lakehouse(если он не в AWS облаке) - это ICEBERG, краткое руководство по которому я также написал.

Частые вопросы на собеседовании по этой теме🕺:
🔘Расскажи про концепцию Lakehouse?
🔘Какие слои данных в нем есть?
🔘В чем его преимущество и какие форматы данных позволяют его получить?
🔘Чем iceberg удобнее и быстрее Hive?
🔘Что такое списки и файлы Манифестов?

Более подробно разбираю эту и другие темы у себя на менторстве, так что если хотите войти в дата инженерию, но есть затыки - обращайтесь, разберем)

⚙️ Сегодня поговорим о ClickHouse - современной колоночной бд

Эта СУБД была создана в Яндексе, чтобы быстро обрабатывать огромные объёмы аналитических данных.
Она идеально подходит для метрик, логов, аналитики поведения пользователей и realtime-дашбордов.

❓ Почему ClickHouse стал необходим?

Обычные реляционные базы (PostgreSQL, MySQL) хранят данные построчно.
Это удобно для транзакций (добавить заказ, обновить статус),
но неэффективно, когда нужно просканировать миллиарды строк и посчитать среднее.

ClickHouse решает эту задачу:

🔘 У него колоночное хранение — данные читаются по колонкам, а не по строкам.
Если запрос использует 3 столбца из 100, остальные даже не читаются.

🔘 Векторная обработка данных— операции в Clickhouse выполняются сразу на блоках строк (по 65 000 штук), а не по одной.

🔘Используется сжатие ZSTD/LZ4 из-за чего хранит данные в 5–10 раз компактнее.

🖥 Какие основные Архитектурные компоненты Clickhouse:
🟣У него есть Block — единица работы в памяти.
ClickHouse всегда работает блоками, чтобы максимально использовать CPU-векторизацию.
🟣Данные хранятся на диске Part'ами — кусками данных, создающимися при каждом INSERT и уже отсортированными по ORDER BY.
Старые парты не изменяются, а фоновые потоки их потом объединяют (merge).
🟣 MergeTree — сердце ClickHouse
Это семейство движков, которое обеспечивает сортировку, дедупликацию и индексацию.
Например: ReplacingMergeTree, SummingMergeTree, AggregatingMergeTree — варианты под разные задачи.
🟣 Primary Key ≠ уникальный ключ.
В ClickHouse он нужен для сортировки и ускорения диапазонных запросов.
🟣Skip-индексы и minmax-индексы
Хранят диапазоны значений по каждому парту —
чтобы быстро «пропускать» ненужные куски данных при чтении.

🎹 Как масштабируется ClickHouse?

🟡Sharding (шардирование) — данные делятся на части по ключу, чтобы разные узлы обрабатывали свои диапазоны.
🟡Replication (репликация) — каждая часть дублируется на другом сервере для отказоустойчивости.
🟡Distributed-таблицы — объединяют шарды и позволяют выполнять запросы «как по одной большой таблице».
И всё это работает параллельно и прозрачно для пользователя.


ClickHouse — это философия «читать быстро и много».
Он не заменяет PostgreSQL или OLTP-базы —
он решает другую задачу: аналитику на огромных данных, где важна скорость чтения, а не запись.
🧱 Каждая таблица — part, каждый запрос — блоки, каждая секунда — миллионы строк.
Вот почему ClickHouse стал стандартом де-факто для аналитических систем.

❓ Сегодня продолжим про ClickHouse — на этот раз про гранулы, ORDER BY и индексы

В прошлом посте мы посмотрели на ClickHouse в целом: колоночное хранение, Block’и, Part’ы и MergeTree.
Теперь разберёмся, как именно ClickHouse читает данные так быстро — за счёт организации данных внутри Part и индексов.

Что такое гранула в ClickHouse?
🔘Внутри каждой Part данные делятся на гранулы (granules) — минимальные куски чтения.По умолчанию index_granularity = 8192 строк.
То есть Part логически разбивается на блоки по ~8192 строк.
🔘ClickHouse всегда читает данные гранулами, а не по одной строке.
Если запрос зацепил хотя бы одну строку в грануле — на диск идёт чтение всего блока (но только нужных колонок).

⚙️ORDER BY и Primary Key

ORDER BY (...) в MergeTree — это кластеризационный ключ. Он Определяет физический порядок строк внутри Part.
PRIMARY KEY обычно тот же самый ORDER BY и нужен для ускорения диапазонных запросов, а не для уникальности.

📎Primary index

Primary index в ClickHouse — это разреженный индекс по гранулам: Для каждой гранулы хранится значение ключа ORDER BY первой строки. По WHERE ClickHouse выбирает только те гранулы, которые могут подойти, и читает с диска только их. Индекс не ищет строку, он помогает пропустить лишние куски данных.

📝Skip-индексы.Помимо primary index, существуют skip-индексы (data skipping indexes) — дополнительные структуры, которые помогают ещё агрессивнее пропускать гранулы.

⏺minmax - Сохраняет минимум и максимум по колонке внутри гранулы.
Если min(price) > 1000, а запрос ищет price < 500, эту гранулу можно не читать вообще.

⏺ set - Хранит множество значений (до лимита).
Если в set-индексе по грануле нет искомого значения — гранула отбрасывается.

⏺bloom_filter / ngrambf_v1 / tokenbf_v1 - Индексы для IN (...), текстового поиска, LIKE и т.п.
Они позволяют не лезть в гранулу, если точно понятно, что внутри нет нужного токена / хеша.
Важно: skip-индексы работают поверх гранул, а не по строкам.
И их имеет смысл добавлять только там, где колонка часто участвует в фильтрах WHERE, и распределение значений позволяет реально отбрасывать куски данных.

Где это использовать?

➡️PARTITION BY - Используется для грубого разбиения данных (по датам, бизнес-ключам).
Партиции позволяют сразу выбросить огромные куски таблицы (например, старые месяцы).
➡️ ORDER BY - Определяет, как строки лежат внутри партиции.
Первый столбец в ORDER BY обычно выбирают под самый частый и селективный фильтр (например, user_id, category_id, date — зависит от витрины).
➡️ Primary index - Работает по тому же выражению, что ORDER BY, и решает, какие гранулы читать.
Чем более «упорядочены» данные относительно реальных запросов, тем меньше гранул будет затронуто.
➡️ Skip-индексы. Используются точечно — для тяжёлых фильтров (по тексту, IN (...), длинным спискам и т.д.), когда простого порядка ORDER BY недостаточно.

😮И вот настало время разобрать Redis — легендарное in-memory хранилище!

На Redis держат кеш карточек товаров и профилей пользователей в маркетплейсах, очереди фоновых задач в бэкендах, хранение корзин и сессий в интернет-магазинах, realtime-счётчики просмотров и лайков в соцсетях.

Благодаря микросекундным задержкам и богатым структурам данных Redis стал универсальным инструментом для быстрого доступа и обработки данных в реальном времени.

🤔Как Redis устроен внутри?
✏️ Однопоточная модель выполнения - Redis работает через один event-loop: команды выполняются строго последовательно, без гонок и блокировок. Это делает операции быстрыми и предсказуемыми, но привязывает производительность к одному CPU-ядру. Как только нагрузка упирается в процессор — спасает только шардирование.

✏️Хранение данных в оперативной памяти - Все данные находятся в RAM, поэтому Redis отвечает за миллисекунды и держит десятки тысяч запросов в секунду даже на одном сервере. Он использует компактные структуры (ziplist, intset, quicklist), чтобы экономить память. Но есть естественное ограничение: Redis хранит только то, что умещается в оперативку.

✏️Наличие различных структуры данных - В Reddis это не просто key–value, а множество быстрых и удобных структур данных(String,Hash,List ,Set, Sorted Set) которые позволяют эффективно строить очереди, рейтинги, счётчики, компактные хранилища объектов и полноценные потоковые логи прямо внутри одной системы.

✏️Персистенция: RDB и AOF. Redis сохраняет данные двумя способами:
RDB — периодические снимки памяти. Они компактные и быстрые, но для их создания Redis делает fork(). На больших инстансах (20–30 ГБ) форк может занимать секунду, и в это время мастер подвисает, увеличивая latency. Поэтому в проде RDB — всегда компромисс.
AOF — журнал всех операций записи. Он позволяет не потерять почти ничего, но увеличивает размер файлов и нагрузку на диск.

Было интересно? Ставьте 🔥

😎К концу подходит год и найм постепенно уходит в предновогоднюю спячку🥺
А значит самое время для повторить теорию, и с новыми силами пойти в бой в новом году🐈‍⬛🐈‍⬛🐈‍⬛.
ПОЭТОМУ собрал всё самое важное, чтобы не потерять!❕❕❕
Spark - https://t.me/dataengineerlab/21, https://t.me/dataengineerlab/25
Kafka - https://t.me/dataengineerlab/29
Airflow - https://t.me/dataengineerlab/33
Debizium - https://t.me/dataengineerlab/35
Streaming - https://t.me/dataengineerlab/36
Flink- https://t.me/dataengineerlab/37
Lakehouse - https://t.me/dataengineerlab/39
Data vault - https://t.me/dataengineerlab/44
Clickhouse - https://t.me/dataengineerlab/52, https://t.me/dataengineerlab/54

🐱И вот настало время разобрать Trino — мощный distributed SQL-движок для аналитики на больших данных. Изначально он разрабатывался компанией Facebook, как замена Hive, но за десятилетие своего развития Trino прошел большой путь от "замены Hive" до полноценного федеративного движка общего назначения, который позволяет пользователям легко интегрировать данные из различных систем без болезненного ETL.

😮На Trino строят:
🔘ad-hoc аналитику поверх data lake
🔘витрины и BI (Presto/Trino + Superset/Tableau)
🔘федеративные запросы между DWH и OLTP
🔘feature-engineering для ML
🔘проверку и валидацию данных без ETL

🤔Как Trino устроен ?
✏️MPP-архитектура (Coordinator + Workers)
Trino — это распределённый движок.
➡️Coordinator парсит SQL, строит план запроса и управляет выполнением
➡️Workers исполняют куски плана (stages / tasks) параллельно
➡️Запрос автоматически масштабируется на десятки и сотни нод — чем больше воркеров, тем выше throughput.
➡️Федеративные запросы через коннекторы
Trino не хранит данные сам. Он читает их через connectors:
Hive, Iceberg, Delta, Kafka, ClickHouse, Postgres и десятки других.
Можно спокойно написать:

SELECT *
FROM hive.events e
JOIN postgres.users u ON e.user_id = u.id
JOIN clickhouse.orders o ON o.user_id = u.id;

И всё это выполнится в одном SQL-запросе.
➡️ Векторизованное выполнение и columnar-подход
Trino читает данные батчами, работает с колонками и активно использует CPU cache.
Минимум overhead — максимум скорости для агрегаций, join’ов и window-функций.
Поэтому Trino отлично чувствует себя на Parquet / ORC / Iceberg.
➡️Умный query planner и cost-based optimization

Trino умеет:
✅pushdown фильтров и агрегаций в источники
✅reordering join’ов
✅dynamic filtering (сильно ускоряет star-schema)
✅spill на диск при нехватке памяти
В результате сложные аналитические запросы выполняются на порядки быстрее, чем «в лоб».

➡️Memory-based execution (и за это его любят и боятся)
Trino очень быстрый, потому что активно использует память.
Но:
плохо настроенные запросы → OOM
JOIN без фильтров → боль
Поэтому в проде важны:
memory limits, query queues, resource groups и грамотный SQL.

💡Когда Trino — лучший выбор?
🔘данные уже лежат в data lake
🔘нужен быстрый SQL без ETL
🔘много источников и много аналитиков
🔘BI и ad-hoc важнее batch-процессинга

Было интересно? Ставьте 🔥

➡️Менторство в Data Engineering

Рынок с каждым днём становится все жесче, компании неустанно повышают требования к кандидатам, и без опытного наставника войти в специальность становится все сложнее.
Какие навыки необходимы ? Как себя преподнести? Что хотят услышать от меня работодатели? Если вы тысячу раз задавали себе эти вопросы, и все никак не можете на них ответить — тогда вам точно ко мне!

✅ Я в менторстве уже больше года. За это время уже 15+ человек получили офферы. Последний оффер ученика - 370к. Я решаю настоящие, «живые» кейсы и с каждым работаю индивидуально.

Также, за год работы я

📈 Улучшил свою программу
🗂 Собрал большую базу собесов в различные компании (25+)
🤝 Создал комьюнити, где можно обмениваться опытом и поддерживать друг друга

Что ждёт вас:

💬 Полное сопровождение от А до Я:
Анализ вашего уровня → индивидуальный roadmap → подготовка к собеседованиям → получение оффера → поддержка на испытательном сроке. Я не бросаю после контракта — я с вами до конца адаптации.

📝 Отработанная система обучения:
— Решаем реальные практические кейсы, которые встречаются в работе
— Разбираем реальные вопросы с собеседований в топовые компании (с готовыми ответами)
— Готовимся не только к технической части, но и к тому, как себя подать, прокачиваем soft skills

❕ Активная подготовка к интервью:
— Мок-собеседования в боевых условиях
— Разбор прошедших собеседований: что сработало, где ошибки, как исправить
— Правка резюме под конкретный стек и позицию
— Помощь с выбором вакансий и откликами

🤝Сообщество менти:
Вы получаете доступ к активному сообществу — нетворкинг, обмен опытом, поддержка людей на одной волне с вами. Это работает.

Если ты все еще сомневаешься и думаешь, довериться ли мне — заходи на мою страничку, тут ты найдешь больше информации обо мне!

А если ты уже полон решимости, то не теряй времени и пиши мне в личку: @ampodvalniy — обсудим!

Отзывы:

https://t.me/it_mentors/5628
https://t.me/it_mentors/5817
https://t.me/it_mentors/5672
https://t.me/it_mentors/5664

Цены:
Обучение с нуля до оффера:
60000₽ +120% от оффера
Консультация: 6000₽
Составление резюме: 6000₽

+79036383742

Рекомендую статью https://t.me/Shust_DE по Airflow🐱🐱🐱. Очень подробно разобрал, мне кажется хватит для подготовки к любому собесу‼️ и помощи в работе🥳. В общем читаем, ознакамливаемся и набирается опыта😎😎😎

Parquet и ORC — что это вообще такое❓❓❓

Сегодня оба формата воспринимаются как стандарт для Data Lake.
Но появились они как ответ на реальные боли Hadoop-эры.
Начало 2010-х.
В экосистеме Apache Hadoop данные лежат в HDFS, аналитика делается через Apache Hive.
Проблема простая:
🔴CSV / TSV занимают много места
🔴Full table scan работает медленно
🔴Компрессия слабая
🔴Нет нормальной статистики по данным
🔴Hive буквально читает всё подряд.
Команда Hive понимает: нужен формат, который будет ускорять аналитические запросы.
Так в 2013 году появляется Apache ORC(Optimized Row Columnar).

Что такое ORC?🤔

📝ORC — это колоночный формат хранения данных. Файл в ORC логически делится на Stripes — крупные блоки данных, внутри которых хранятся сами колоночные данные и индексная информация. В конце файла находится Footer с общей метаинформацией и PostScript, содержащий служебные данные о структуре файла и параметрах компрессии. Внутри ORC хранится статистика по данным — min/max индексы по колонкам, встроенные Bloom filters для ускорения фильтрации, а также используется продвинутая схема компрессии, позволяющая эффективно сжимать данные разных типов. Изначально ORC создавался как «ускоритель Hive» и отлично подходит для тяжёлых DWH-нагрузок и сценариев с full table scan, где важно максимально оптимизировать чтение больших объёмов данных.

Параллельно Cloudera и Twitter понимают: Нужен формат, который будет работать не только с Hive. В том же 2013 году появляется Apache Parquet.
Его идея — универсальность:
🟣поддержка разных движков
🟣сложные nested структуры
🟣хорошая совместимость
🟣кросс-платформенность

Что такое Parquet🤔

📝Parquet — это колоночный формат хранения данных, в котором файл логически разделён на Row Groups — крупные блоки строк, внутри которых данные организованы по колонкам в виде Column Chunks, а минимальной единицей хранения являются Pages. В конце файла находится Footer, содержащий схему и метаданные. В footer хранится статистика по каждой колонке: минимальные и максимальные значения, количество строк, число null-значений и другая служебная информация.

Когда движок, например Apache Spark, выполняет запрос, он сначала читает footer, анализирует статистику и определяет, какие Row Groups можно пропустить. Затем он считывает только те блоки, где потенциально есть подходящие данные, и загружает только нужные колонки. Такой механизм называется predicate pushdown, column pruning и data skipping. Благодаря этому существенно уменьшается объём чтения с диска и снижается нагрузка на CPU и сеть, поэтому Parquet в разы быстрее обычных строковых форматов вроде CSV.


🐱Parquet и ORC появились не ради «ещё одного формата». Они стали ответом на практическую проблему: читать терабайты CSV — дорого, медленно и неэффективно. Строковые форматы заставляют движок загружать весь файл целиком, даже если в запросе нужны всего несколько колонок.

Колоночное хранение изменило экономику аналитики: стало меньше I/O, меньше нагрузки на CPU, сократился shuffle и в целом подешевела инфраструктура. Движки начали читать только нужные колонки и пропускать ненужные блоки данных, что кратно ускорило запросы.

Именно поэтому сегодня почти любой современный Data Lake строится поверх Parquet (реже ORC) — это уже не просто формат, а стандарт индустрии.

Рынок Data Engineering в 2026 — это уже совсем другой уровень!
За этот год требования значительно взлетели.
Теперь на собеседованиях мало просто «понимать технологии» — от тебя ждут реального опыта, глубоких деталей и умения рассказать, как ты решал настоящие проблемы в продакшене.

Типичные вопросы сейчас:
⏺Какой самый сложный ETL-процесс тебе приходилось разрабатывать?
⏺Как организована поставка в прод?
⏺Сколько строк в секунду реально лилось через пайплайн?
⏺На чём был реализован процесс (Spark, Flink, Airflow, dbt, Kafka Streams…)?
⏺Как проходила миграция данных / схем / хранилища?
⏺Какие требования бизнеса / SLA стояли?
⏺Какая была твоя роль на проекте ?

Вкатиться самостоятельно стало в разы сложнее.
Поверхностные знания уже не прокатывают — работодатели копают глубоко и хотят слышать конкретные истории успеха и фейлов.
Но хорошая новость: за последний месяц я с командой проработал много реального материала:
🔘 Собрали настоящие кейсы из жизни дата-инженеров
🔘 Разобрали вопросы по компаниям (от Big Tech до российских продуктовых)
🔘 Составили мощные легенды и структурированные рассказы о проектах
🔘 Подготовили ответы, которые реально цепляют интервьюеров
Результат? Люди проходят сложные этапы и получают долгожданные офферы ❕❕❕
Хочешь такую же детальную легенду под себя + уверенный рассказ о проектах, который не развалится под давлением?
Приходи на менторство.
Последние отзывы от ребят:
https://t.me/it_mentors/6596
https://t.me/it_mentors/6514
Пиши в личку, обсудим твою ситуацию:
В 2026 году офферы берут не те, кто «знает теорию», а те, кто может уверенно рассказать «как я это делал в проде и что было сложно».
Давай сделаем так, чтобы это был ты❕❕❕

Как работает CDC pipeline?

🌐В современных дата-платформах данные редко грузят батчами раз в сутки.
Чаще используют CDC (Change Data Capture) — потоковое получение всех изменений из базы.

Разберём классический пайплайн:

MySQL → Debezium → Kafka → ClickHouse

1️⃣В MySQL все изменения пишутся в binlog (binary log) - по сути журнал транзакций базы.
Каждая операция фиксируется как событие: INSERT,UPDATE,DELETE

2️⃣Debezium — это CDC-коннектор (обычно работает через Kafka Connect)
Он:
➡️подключается к MySQL
➡️читает binlog
➡️превращает события в Kafka messages
➡️пишет события в Kafka топики

3️⃣Kafka: транспортный слой между OLTP и аналитикой которая позволяет довольно продолжительное время накапливать историю

4️⃣Далее все направляется в ClickHouse: аналитическое хранилище
Он читает Kafka через Kafka Engine или ingestion сервис.
Выглядит это примерно так:
Kafka topic
↓
Kafka Engine Table
↓
Materialized View
↓
MergeTree таблица

🧐Почему такая архитектура стала стандартом

Она даёт:
➡️Near real-time данные
➡️минимальную нагрузку на OLTP
➡️возможность replay истории
➡️масштабируемость

Было полезно? Ставьте 🔥
#dataengineering #cdc #debezium #kafka