Как работает 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

👋Рад тебя видеть в Дата Инженер Лаб!

Я — Артём Подвальный. Помогаю разобраться в работе инструментов обработки больших данных и как происходят эти процессы в компаниях. Здесь я стараюсь простым языком объяснить самое важное что надо знать начинающему DE и получить заветный оффер.

Самое полезное, что уже можно найти в канале:

🔥 Обязательно для прочтения:
Легендарный Roadmap для DE. Проверь, всё ли из этого ты знаешь

🏗 Все самое полезное для DE

💼 Для тех, кто ищет работу или планирует вкатываться в DE

Давай общаться!
Задавай вопросы в комментариях к любому посту или пиши мне лично: @ampodvalniy.

Давайте разберем такую ситаацию: твой пайплайн упал и данные за последние 3 часа «испарились», а восстановить их не из чего 💀

Если у тебя стоит RabbitMQ — это реальный сценарий. Если Kafka то проблема может решится парой команд в консоли. Так почему же один брокер будет прощать ошибки, а другой — нет? Разбирем фундаментальную разницу между Smart Broker и Dumb Broker, чтобы вы больше никогда их не путали.

Главное различие — в «интеллекте» системы:

🔘RabbitMQ (Smart Broker): Брокер сам следит за состоянием очередей, маршрутизирует сообщения и удаляет их сразу после подтверждения (ack). Это модель Push: брокер сам «толкает» данные потребителю. Это упрощает код клиента, но нагружает систему при росте данных.

🔘Kafka (Dumb Broker): Это распределенная платформа потоковой передачи, работающая как распределенный коммит-лог. Она просто записывает данные и хранит их. Здесь работает модель Pull: потребители сами запрашивают данные, когда готовы их обработать.

👀 Почему для Data Engineering почти всегда нужна Kafka?

🔛 Гипер-масштабируемость: Кафка переваривает миллионы сообщений в секунду. Секрет в партиционировании (partitions): топики делятся на части и распределяются между брокерами. Это позволяет распараллеливать чтение и запись на петабайтах данных. Мы упоминали это, когда разбирали современный Lakehouse.

🔛 Постоянство данных (Retention Policy): Сообщения не удаляются после прочтения. Они хранятся по времени или объему. Это позволяет нескольким потребителям читать одни и те же данные в разное время.

🔛 Replayability (Повтор): Если в пайплайне баг, ты просто перечитываешь данные заново. В RabbitMQ «съеденное» сообщение пропадает навсегда.

🔛 Гарантии Exactly-once: Кафка умеет доставлять сообщение «ровно один раз», что критично для финансов. Рэббит обычно гарантирует только «хотя бы один раз».

🐰Когда RabbitMQ — это НЕ ошибка?
🔘Сложная маршрутизация: Если нужно раскидывать задачи по куче условий (exchanges: direct, fanout, topic, headers). Кафка в базе так не умеет.

🔘Приоритеты: В RabbitMQ можно пометить сообщение как высокоприоритетное, и оно проскочит очередь. В Кафке порядок строго хронологический внутри партиции.

🔘Низкая задержка на малых данных: При небольших объемах Рэббит может быть быстрее, но при росте нагрузки его задержки растут лавинообразно.

Итого:
Если ты строишь Data Lake, систему аналитики или ETL-пайплайны — твой выбор Kafka. Она идеально ложится в архитектуру Data Vault, сохраняя историю без потерь.

RabbitMQ оставляем для микросервисов и простых очередей (например, фоновая отправка писем).

🔖Что почитать по теме: https://habr.com/ru/companies/slurm/articles/666326/

❓Вопрос к тем, кто учится:

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

Пиши в комментариях, обсудим! 👇


#Kafka #RabbitMQ #DataEngineering #ITCareer #CareerDE #DataScience

Вопрос по которому часто возникают трудности у кандидатов😐

«Как вы боретесь с дублями в Kafka на проде?». Напиши свой ответ в комментариях и сравнивай:

Ответ: "Три уровня защиты. Producer: enable.idempotence=true — закрывает сетевые ретраи. Consumer: проверяю event_id в Postgres перед обработкой. Транзакции — только для read-process-write между топиками Kafka. Главное правило: check → process → commit offset."

Совпало? Теперь разберем по полочкам, почему это важно: 👇

Почему дубли вообще есть?

1️⃣Producer retry
Producer отправил сообщение → брокер не ответил → producer отправил СНОВА
Kafka получила 2 одинаковых сообщения

2️⃣Consumer crash
Consumer прочитал сообщение → начал обработку → УПАЛ
При рестарте читает то же сообщение СНОВА

3️⃣Rebalance группы (80% проблем на проде!)
Consumer A обработал партицию → Consumer B взял её → обработал СНОВА

Как это можно решить:

🔵Настройка продюсера

Кафка выдает тебе Producer ID (PID) и заставляет нумеровать сообщения. Если брокер видит сообщение с номером, который уже был - он его просто выкидывает.

Настройка: enable.idempotence=true.

Почти не влияет на скорость. Включай всегда по умолчанию.

🔵Транзакции

Объединяет чтение и запись в одну неделимую операцию (Read-Process-Write). Если что-то упало - вся цепочка откатится, и дублей в конечном топике не будет.

Настройка: transactional.id + isolation.level=read_committed.

Добавляет задержку (latency). Используй только там, где критичен идеальный порядок.

🔵 Идемпотентность консьюмера

Кафка не знает, что в твоей базе. Если сервис записал данные, но «упал» до фиксации оффсета - кафка пришлет дубль. Поэтому проверяй уникальность ключа на входе в базу.

Пример: INSERT ... ON CONFLICT DO NOTHING в Postgres или SET NX в Redis.

Самый надежный способ, который спасет, даже если настройки кафки не помогли.

🤔Какой следующий вопрос разобрать?

#Kafka #DataEngineering #ITCareer #CareerDE #DataScience

Страшно начинать с нуля 😱

Это первая мысль, когда решаешь уйти из другой сферы или только заканчиваешь универ…

📌Но вот в чём штука — ты и не начинаешь с нуля

Ноль — это когда нет ничего. А у тебя есть: годы учёбы или работы, насмотренность, понимание того, как устроены процессы, люди, системы. Это не обнуляется от того, что ты открыл первый туториал по Python⚠️

Именно прошлый опыт часто становится скрытым преимуществом:

Умение структурировать хаос🌪
Пайплайны, зависимости, ошибки, потоки данных — это управляемый хаос. Если умел наводить порядок в процессах, документах или хотя бы в своих курсовых — здесь будет понятна логика.

Коммуникация
DE — это не только код. Объяснить аналитику, почему данные «поехали», согласовать с бизнесом приоритеты — это добрая половина работы 🍻

Проектное мышление 🖥
Привычка доводить задачи до конца, держать сроки и не теряться в приоритетах — это видно сразу и ценится высоко.

Внимание к «скучным» деталям
Бухгалтерия, документирование процессов, контроль качества — там, где без проверок нельзя. Этот «занудный» навык в DE превращается в суперсилу 👀

Гибкость в освоении нового
Если ты уже менял роли или сферы, твой мозг умеет перестраиваться. Новый стек, новая терминология уже не шок 🧑‍💻

Опыт работы с документацией
Умеешь читать инструкции, регламенты, стандарты? Значит, разобраться в API, логах и метриках — вопрос времени, а не способностей.

🏫А если ты только из универа?
Учился на экономиста, биолога, физика, юриста — неважно. Ты уже умеешь разбираться в сложных системах, работать с большим объёмом информации и доводить задачи до результата под дедлайн. Это и есть база, на которую ляжет DE.

Твой опыт, абсолютно любой — это актив. Его стоит ценить и использовать!

📱 SQL, Python, облака и оркестрацию выучить можно. А умение не паниковать, когда всё горит, чувствовать бизнес и структурировать хаос — это приходит с опытом, который у тебя уже есть

Если сейчас стоишь перед этим шагом и не знаешь, с чего начать — пиши в личку @ampodvalniy 👋

Расскажешь про свой
бэкграунд, разберём вместе: что уже есть, что нужно подтянуть и как выстроить путь без хаоса👍

📊Ты считаешь ежедневных юзеров, и вдруг DAU (Daily Active Users) подскочил на 25%! Команда празднует вирусный рост, а ты хватаешься за дебаггер ⚠️

Ребята, давно хотел обновить свой роадмап по Data Engineering - и вот наконец сделал. Кстати, на канале появилось много новеньких - привет всем, кто только подписался, вы тут вовремя появились👋

Переписал роадмап под реалии 2026: убрал лишнее, добавил актуальные инструменты, прикрепил ссылки на материалы и вилки по каждому грейду. Получилось объёмно, но по делу.

Если заходите в профессию или думаете куда расти 📈

-> ЧИТАЕМ ТУТ

P.S. Буду благодарен за комментарии и лайки, хотелось бы продвинуть статью😋

Правильный ответ:

Разный grain (считают по заказам, а агрегируют по позициям — строки размножаются) 🔄

Почему это происходит?

Представь, что у тебя есть таблица «Заказы» (где 1 заказ = 1 строка) и таблица «Товары в заказе» (где 1 товар = 1 строка) 📦Если в одном заказе купили 3 разных товара, то при объединении (JOIN) этих таблиц одна строка заказа «размножится» на три

В чем косяк? Если ты начнешь считать сумму продаж по такой «раздутой» таблице, SQL сложит сумму одного и того же заказа трижды 🥲 В итоге в отчете цифры будут гораздо выше реальных (тот самый «взрыв дублей»), хотя на самом деле продаж больше не стало 📉

Как исправить? Нужно сначала «схлопнуть» (агрегировать) данные о товарах до уровня заказа и только потом делать JOIN☑️

Снова увидел S3 в требованиях? Давай раз и навсегда разберёмся

🤔 Часто в вакансиях вижу S3. Решил напомнить (или рассказать тем, кто не знает) - что это вообще такое 👇

S3 (Amazon Simple Storage Service) - если совсем просто, это «бездонная бочка». Гигантский виртуальный склад. Кидаешь туда файл любого типа и размера - и не думаешь, что место кончится.

Как оно устроено?

В отличие от компбютера(файловой системы) где файлы лежат в папках, тут всё плоское. Без иерархий. Вот три основных понятия, которые надо знать:

🪨Объект - сам файл. Картинка, видео, документ, лог. У него есть:
🔘сами данные
🔘метаданные (размер, тип и прочее)
🔘ключ - уникальный адрес, по которому его найдёшь

📦Бакет - контейнер верхнего уровня, куда складываешь объекты. Название бакета должно быть уникальным во всей системе. Вообще всей.

🔑Ключ - полный путь к файлу. Например,

documents/2023/invoice.pdf. 

Вся строка целиком - это и есть ключ. Похоже на папки, да. Но внутри - нет, просто строка.

Почему S3 все так любят?

♾Место не кончается - терабайты, петабайты. Система сама расширяется, когда ты добавляешь файлы.

💰 Дёшево - в 10–20 раз дешевле, чем хранить то же самое в нормальной базе данных или Data Warehouse.

❤️Никуда не денется - данные копируются между серверами и даже между разными городами (дата-центрами). Риск потерять почти ноль.

Но есть и минусы, куда без них

❌ Неизменяемость - объекты нельзя просто «поправить». Хочешь изменить одно слово в текстовом файле? Качай новую версию целиком, перезаписывай старую. Всё заново.

❌ Не для баз данных - S3 медленнее, чем обычный диск. Не подходит для вещей, где данные надо менять мгновенно (например, для работающей базы интернет-магазина).

⏱ Задержки - доступ к файлу может быть медленнее, чем в обычной файловой системе.

А ещё S3 — это фундамент современной аналитики

Его называют «фундаментом» для Lakehouse. На S3 лежат огромные массивы сырых данных в открытых форматах (типа Parquet). А системы вроде Delta Lake или Apache Iceberg превращают эти файлы в удобные таблицы для аналитиков. Красота 🍾

Сделать вам обзор на Delta Lake и Apache Iceberg (или уже 10 раз про них успели прочитать)?

Первое видео на YouTube! 📹📺

Знаю по своим ученикам (да и по себе), что самое сложное на собеседовании - это уверенно рассказать о своем опыте. Особенно если его объективно мало или вы решили немного приукрасить резюме.

Записал для вас видео, где мы с Катей провели мок-интервью…

В этом видео:
🔷 Как рассказывать о своем опыте?
🔷Как отвечать на вопросы про стек, объемы данных и сложные ETL-процессы?
🔷Что говорить об опыте, если его пока не хватает?
🔷Можно потренироваться отвечать на вопросы

Полезно для тех, кто сейчас активно ходит по собесам или готовится к ним👍

Смотреть тут:
🔥YouTube
💙RuTube

Буду рад вашей поддержке: лайки и комментарии очень помогают продвигать видео. И пишите, какие темы разобрать в следующих выпусках — я все читаю 🍾

Новая статья на VC

Кто такой дата-инженер в 2026 году и почему ИИ не заменил нас, а сделал работу дороже.

Спойлер:
✅DE не умер
✅код пишем меньше
✅ошибки стоят дороже
✅зарплаты приятно радуют

👉 Читать тут

Apache Iceberg: почему вокруг него столько шума и зачем он вообще нужен 🧊

Apache Iceberg — это открытый формат таблиц для огромных аналитических наборов данных в data lake.
И если раньше архитектуры на базе Hadoop и Hive нередко превращались в болото данных, то Iceberg придумали как способ сделать такие хранилища более надежными, быстрыми и удобными для аналитики.

Что такое Apache  Iceberg 🤨

Важно сразу понять одну вещь: Iceberg — это не хранилище вроде S3 или HDFS и не движок обработки запросов вроде Spark или Trino.

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

У Iceberg есть несколько сильных сторон 🤔:

ACID-транзакции — читатели не видят частичные или некорректные изменения, а каждое обновление проходит как атомарный коммит.

Time Travel — можно запросить состояние таблицы на конкретный момент времени или по номеру снапшота.

Эволюция схемы без боли — столбцы можно добавлять, переименовывать и удалять без переписывания всей таблицы.

Скрытое партиционирование — Iceberg сам помогает с раскладкой данных по папкам, и не требует вручную постоянно тащить это в запросы.

Главная идея Iceberg — он отслеживает не каталоги, а отдельные файлы данных.
Именно поэтому он так хорошо работает с большими таблицами и сложными сценариями обновлений.

Архитектура Iceberg состоит из трёх слоёв 💠:

1. Catalog layer
Это внешний сервис, который хранит ссылку на текущий файл метаданных таблицы. В этой роли могут выступать Hive Metastore, AWS Glue или REST-каталог подробнее про роль каталога.

2. Metadata layer

Здесь хранится вся логика таблицы:

🔷metadata file — схема, информация о партиционировании и список снапшотов;

🔷manifest list — набор файлов-манифестов для конкретного снапшота;

🔷manifest file — список файлов данных и статистика по ним, включая min/max значения, чтобы движки могли пропускать лишнее при чтении.

3. Data layer

Это сами файлы данных, чаще всего Parquet, которые лежат в объектном хранилище или в HDFS.

Когда Iceberg действительно нужен 🧑‍💻

🔷data lake уже тормозит из-за миллионов файлов;

🔷важна изоляция чтения и записи;

🔷схема таблиц часто меняется;

🔷не хочется каждый раз переписывать терабайты данных из-за очередного изменения структуры.

Проще говоря, Apache Iceberg превращает файловое хранилище в полноценную аналитическую систему, но без потери плюсов object storage — дешевизны и масштабируемости

Вы уже пробовали Iceberg? Как вам?🙂