OLTP и OLAP: две стороны дата-инженерии, о которых стоит знать👨‍💻

В последние годы бизнес стал чётко понимать, насколько важны данные. Причём не только «что происходит прямо сейчас», но и вся история: как вёл себя пользователь месяц назад, когда упал спрос, какие товары чаще всего покупают в пятницу вечером.
Те компании, которые научились собирать и использовать такие данные, вырываются вперёд. Остальные — гадают на кофейной гуще.
Вот тут и появляются два типа баз, с которыми мы, как дата-инженеры, работаем каждый день: OLTP и OLAP.

🌐Представь, что ты заказываешь еду в приложении. Ты жмёшь кнопку — и заказ уходит в базу. Вводишь номер карты — сохраняется платёж. Все эти действия происходят в реальном времени — и проходят через OLTP.
OLTP (Online Transaction Processing) — это базы, которые: быстро записывают и обновляют информацию,справляются с тысячами одновременных действий, строго следят за целостностью данных/
Примеры: PostgreSQL, Oracle, MySQL
Они хорошо подходят для продуктовых систем, но не предназначены для анализа больших массивов данных.

💻 OLAP — это уже про аналитику
Теперь представь, что маркетологу нужно понять: как часто люди заказывают роллы по пятницам, сколько заказов в среднем в декабре и как это отличается от января.
Вот такие запросы уже не про одно событие, а про тенденции. Для них нужны другие базы — это OLAP.
OLAP (Online Analytical Processing) — это базы, которые: хранят исторические данные, быстро считают метрики и строят агрегаты,отлично подходят для аналитических дашбордов, BI-систем и витрин
Примеры: ClickHouse, Vertica, Redshift
Эти базы заточены под чтение по столбцам — поэтому отлично справляются с запросами вроде: “покажи средний чек за последние полгода по категориям”.

👨‍💻И вот что важно: на первый взгляд синтаксис в OLTP и OLAP может быть похож — SQL есть SQL, но «под капотом» они работают абсолютно по-разному.
Запрос, который в Oracle выполнится за 50 мс, может в ClickHouse грузиться минуту. И наоборот.
Поэтому одна из ключевых задач дата-инженера — писать оптимальные запросы под конкретную архитектуру. Тут важны не только JOIN’ы и WHERE’ы, но и как ты хранишь данные, как распределяешь, по каким полям сортируешь и партиционируешь.

А какими СУБД вы пользовались и какие возникали проблемы?
#sql #olap #oltp #clickhouse #postgresql #bigdata #analytics

Сегодня поговорим о технологии, которая изменила мир обработки данных, а именно о MapReduce

🖥Как мы начали приручать терабайты:
В условиях стремительного роста объёмов информации традиционные методы обработки данных перестали справляться с поставленными задачами. Компании столкнулись с необходимостью обрабатывать терабайты и даже петабайты данных ежедневно. Именно в ответ на этот вызов и появился MapReduce — революционный подход, ставший фундаментом для распределённых вычислений в рамках экосистемы Hadoop.

❓ Что такое MapReduce?
Это способ обработки больших объёмов данных за счёт разбиения задачи на мелкие подзадачи, которые параллельно обрабатываются на разных машинах в кластере.

Как это работает:
Input — на вход подаётся большой массив данных: текст, логи, последовательности ДНК и т.д.
Splitting — данные делятся на фрагменты, которые обрабатываются независимо.
Mapping — каждый фрагмент проходит через функцию map, которая превращает данные в пары «ключ — значение». Например, слово → 1.
Shuffling — все одинаковые ключи группируются: все «Car» — вместе, все «Bear» — вместе и т.д.
Reducing — к каждой группе применяется функция reduce, которая агрегирует значения. Например, считает, сколько раз встретилось каждое слово.
Result — получается финальный список, например:

Car — 3  
Deer — 2  
Bear — 2

⛏ Где применяется?
MapReduce активно применялся (и до сих пор используется) в индустриях, где нужно перерабатывать огромные объёмы данных, например:

Поисковые системы — Google применял MapReduce для индексации веб-страниц и подсчёта ссылок (PageRank).

Также один из мощных примеров — анализ геномных данных
Исследования в биоинформатике генерируют терабайты сырых данных: последовательности ДНК, карты мутаций, транскриптомные данные и пр.

✅ Кейс: компания Broad Institute использует MapReduce-подобную архитектуру в своём GATK (Genome Analysis Toolkit) для обработки данных секвенирования человека.

Понимание Map-reduce один из типичных тем на собеседованиях на Дата-инженера.

❓Частые вопросы на собесах:
⏺Как работает MapReduce — опишите все этапы?
⏺Зачем нужен shuffle и почему он дорогой по ресурсам?
⏺Чем Spark отличается от MapReduce?
⏺Где работает MapReduce? (в памяти или на диске)

#bigdata #mapreduce #hadoop #собеседование

Как кластеры делят ядра и гигабайты: управление ресурсами при обработке больших данных?⚙️

📌На самом первом Hadoop всем процессом командовал один-единственный «дирижёр» — JobTracker. Он принимал каждую задачу MapReduce, держал у себя в памяти всё-всё о каждой джобе, сам решал, на каком сервере что запустить, и следил, чтобы все работали. Пока данных было десятки гигабайт — было норм. Но когда логов и кликов накопились терабайты, JobTracker стал узким горлышком: память забивалась, отчёты об ошибках копились, а падение одной машины могло поставить на паузу весь кластер — ведь дирижёр был один.

🔄Чтобы разблокировать рост, в Hadoop 2.x придумали YARN (Yet Another Resource Negotiator). Логика была простая: вынесли две задачи — управление вычислительным процессом и управление ресурсами — в разные контуры:

Контур ресурсов
В центре — ResourceManager. Он воспринимает кластер как пул CPU-ядер и гигабайт памяти, ведёт их учёт, применяет выбранную политику планировщика (FIFO, Fair, Capacity) и решает, на каком узле открыть очередной контейнер.

Контур приложений
Для каждого приложения стартует свой ApplicationMaster. Это «директор программы»: оценивает объём работы, запрашивает у ResourceManager контейнеры нужного размера, раздаёт задачи исполнителям(MapReduce, Spark и др.) и отслеживает сбои.

Узловой слой
На каждом сервере работает NodeManager. Он получает команды от ResourceManager, создаёт и завершает контейнеры, следит за фактическим потреблением ресурсов и регулярно отчитывается о здоровье узла.

Контейнер
Контейнер — минимальная единица выполнения: изолированная среда с заданным лимитом CPU и памяти, в которой крутится конкретная задача (Spark-executor, MapReduce-task и т. д.). Это гарантирует, что приложение не выйдет за выделенные ему рамки и не помешает соседям.

✅Благодаря такому разделению «ресурсы — отдельно, логика — отдельно» исчезло узкое горлышко единственного JobTracker’а. Кластер получил гибкую схему: ResourceManager управляет ресурсами в целом, а десятки ApplicationMaster’ов параллельно руководят своими задачами, не мешая друг другу и не конкурируя за центральный диспетчер.

Пользоваться и следить за ресурсами с помощью YARN очень удобно - у него есть UI -интерфейс, где можно отслеживать статусы своих задачек, смотреть логи, искать ошибки.

❓Частые вопросы на собесах:
⏺Как YARN распределяет ресурсы?
⏺Общие принципы работы YARN?
⏺Что такое ApplicationMaster и какие типы вы знаете?

#Hadoop #YARN #DataEngineering #MapReduce #Spark

Почему Apache Spark вытеснил MapReduce?🤔

Когда‑то MapReduce был спасением для petabyte‑масштаба, но каждая итерация писала данные на диск → заново читала → снова писала. Итеративный ML, стриминг или сложные ETL превращались в марафон с кофе‑брейками. Нужно было что‑то быстрее.

Spark появился в 2009‑м в UC Berkeley и сказал:
«Давайте держать данные в памяти и давать разработчику нормальный API!»
Результат — ускорение ×10‑100 и код в пару строк вместо гирлянды map/reduce‑скриптов.

🖥Архитектура Apache Spark

Driver Program
  •  инициализирует SparkContext
  •  строит DAG вычислений
  •  делит работу на задачи и шлёт их в кластер

SparkContext
  •  общается с Cluster Manager’ом
  •  следит, чтобы tasks дошли до финиша

Cluster Manager (Standalone / YARN / K8s / Mesos)
  •  ведёт учёт ресурсов
  •  назначает worker‑узлы
  •  стартует executors

Worker Node
  •  хостит один или несколько executors — грузит работу, кэширует данные

Executor
  •  выполняет tasks параллельно
  •  кладёт горячие данные в память
  •  шлёт результаты Driver’у

Task
  •  самый мелкий кусочек работы - обрабатывает партицию данных

Cache / Persistence
  •  RAM (или SSD) для повторного использования данных без дискового тормоза

⌛Как бежит ваш job
1️⃣Пишем код на RDD / DataFrame / Dataset.
2️⃣ Запускаем — Driver поднимает SparkContext.
3️⃣ Spark лениво строит DAG всех операций.
4️⃣ Оптимизатор режет DAG на stages, те — на tasks.
5️⃣Cluster Manager раздаёт executors по worker‑ам.
6️⃣Tasks летят параллельно 🔼, данные шаффлятся только между stages.
7️⃣.cache() → Spark держит данные в памяти, ускоряя итерации.
8️⃣Завершили — результаты собираются у Driver’а и пишутся туда, куда нужно (HDFS / S3 / БД).
—
Сохраняйте, чтобы не забыть, и делитесь с теми, кто ещё путает Driver с Executor!

❓Частые вопросы на собесах:
⏺Что такое Executor и Driver?
⏺Что такое ленивая модель вычислений в Spark?
⏺Какие операции выполняются на Executors, а какие на Drivers?
⏺Для чего в Spark используется cache?
⏺Где выполняются операции в Spark( на диске или в памяти)?
⏺Из-за чего Spark быстрее Map-reduce и чем удобнее?

Поставьте 🔥, если ,было полезно! Делитесь в комментариях своими кейсами по работе со Spark!

#ApacheSpark #BigData #DataEngineering #SparkArchitecture #RDD

Стал соавтором роадмапа для дата-инженеров! Там очень хорошо расписан материал по различным темам👨‍💻Полезно для всех, так что читайте, прокачивайте скиллы!⛏ Постепенно будем расширять эту базу, добавлять другие полезные материалы😊

🥹Экосистема Apache Spark за 2 минуты!

❤️Spark Core
«Сердце» фреймворка. Отвечает за распределение задач по узлам, управление памятью и отказоустойчивость. Именно здесь живёт модель RDD — неубиваемые распределённые коллекции, которые можно хранить в RAM или на диске. Всё остальное в Spark просто вызывает возможности Core, поэтому без него ничего не поедет.

💻DataFrame API
Тонкая прослойка‑упрощение над RDD. Представляет данные как привычные таблицы и даёт SQL‑подобный синтаксис (select, where, join). Внутри работает оптимизатор Catalyst: он переставит фильтры, уберёт лишние колонки и построит эффективный план выполнения. Результат — меньше строчек кода и быстрее запросы.

❔Библиотеки верхнего уровня:
Spark SQL.Распределённый SQL‑движок поверх DataLake: привычные SELECT‑запросы выполняются параллельно и оптимизируются.

Spark Streaming - Тот же DataFrame‑синтаксис, но для непрерывных потоков (Kafka, файловые папки). Решает задачи near‑real‑time ETL и мониторинга.

MLlib. Набор распределённых алгоритмов ML (регрессии, бустинг, ALS‑рекомендации). Позволяет обучать и применять модели на кластере без ручного шардирования данных.

GraphX / GraphFrames. Фреймворк для графовых вычислений.Используется для анализа соц‑графов, логистических сетей и взаимосвязей транзакций.

Spark Packages. Каталог сторонних расширений — коннекторы, форматы, алгоритмы (например, ClickHouse Connector или t‑SNE).

🌐Data Source API
Универсальный «шлюз» к данным. Одной строчкой читаем и пишем в HDFS, Hive‑таблицы, HBase, Postgres, MySQL, Parquet, JSON, Avro, Elasticsearch и кучу других форматов.

🫡Поддерживаемые языки
Scala — родной для Spark, максимальная производительность.
Java — удобно интегрировать в legacy‑экосистемы.
Python (PySpark) — де‑факто стандарт для дата‑сайентистов
R (SparkR) — для тех, кто в экосистеме tidyverse и Shiny.

Итого: Spark складывается как конструктор. Core даёт масштабирование, DataFrame — удобный SQL, поверх — стриминг, ML и графы, а Data Source API тянет данные откуда угодно.
Всё это доступно сразу на четырёх языках, так что команда аналитиков и инженеров работает в одной экосистеме без барьеров.

❓Частые вопросы по экосистеме:
⏺Что такое DataFrame Api и их разница с RDD?
⏺Где можно использовать spark streaming?

Было полезно? Ставьте 🔥

#ApacheSpark #BigData #DataEngineering #SparkSQL #StructuredStreaming #PySpark

🤔 Что такое брокеры сообщений и зачем они нужны?

В современных системах, особенно построенных на микросервисной архитектуре, важно обеспечить надёжный и масштабируемый обмен данными. Прямые вызовы между сервисами создают жёсткую связность, сложную поддержку и риск отказов при сбоях.

✅Решение — брокер сообщений, промежуточное ПО, которое принимает сообщения от продюсеров (отправителей) и передаёт их консьюмерам (получателям). Он как надёжный почтовый ящик между компонентами системы.

Зачем они нужны?🧐
Асинхронность - продюсер отправляет сообщение и продолжает работу. Консьюмер обработает его позже — когда сможет.
Снижение связности - сервисы не зависят друг от друга напрямую. Это делает систему гибкой, её проще развивать и масштабировать.
Масштабируемость - брокеры позволяют обрабатывать миллионы сообщений в секунду, распределяя нагрузку между несколькими получателями.
Надёжность - сообщения не теряются при сбоях. Брокер может временно хранить их и доставить, когда консьюмер снова станет доступен.

😎Примеры популярных брокеров:
Apache Kafka — для потоковой обработки и больших объёмов данных.
RabbitMQ — универсальный брокер с гибкой маршрутизацией сообщений.
Amazon SQS / Google Pub/Sub — облачные брокеры с auto-scale и отказоустойчивостью.

💻 Брокеры сообщений в дата-инженерии — один из базовых компонентов инфраструктуры, особенно когда речь идёт о реальном времени и масштабировании.

Где применяются👨‍🍳:
🐱Сбор данных - ивенты, логи, клики и другие данные поступают в Kafka или RabbitMQ.
➤События с фронта поступают в Kafka, затем в аналитический пайплайн.

🐱Связка микросервисов - сервисы обмениваются событиями: создание заказа, обновление статуса и т.д.

🤪Реалтайм-аналитика - потоки из брокера обрабатываются Spark, Flink или пишутся в ClickHouse.
➤ Подсчёт просмотров, лайв-метрики, алерты.

👍 Буфер между системами — временное хранилище между источником и DWH.
➤ Kafka + Kafka Connect → выгрузка в S3 или Vertica.


🐈‍⬛ Вывод:
Брокеры сообщений — это клей микросервисов и движок стриминговых данных. Без них невозможно представить современную архитектуру, особенно в data-driven продуктах.Они обеспечивают гибкость, надёжность и высокую производительность всей системы.

Расскажите, какими брокерами вы чаще всего пользовались или с какими хотели бы поработать?🐱

#архитектура #dataengineering #messagebroker #kafka #rabbitmq #etl #streaming #системы

➡️ Оказываю менторские услуги в Дата Инженерии
Если вы на распутье, хотите расти, менять стек или просто не знаете, с чего начать — я могу помочь.

Что делаю:

💬Менторство от точки “где я сейчас” до оффера и помощи на испытательном сроке, а именно:

📝Анализ и план:
— Аудит навыков и опыта
— Индивидуальный roadmap под вашу цель
— Навигация по стеку и индустрии

❕Сопровождение на каждом этапе:
— Подбор нужных материалов и регулярные созвоны
— Теория + практика: учим только то, что реально нужно
— Поддержка при откликах и выборе вакансий

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

Дополнительно:
-Мок-собес по вашему стеку
-Ревью резюме
-Консультация по развитию, стеку, задачам

Пишите в личку @ampodvalniy если чувствуете, что пора что-то менять. Вместе соберём план и дойдём до сочного оффера, который реально радует💵💵💵

Если вас интересует разработка на GO , то рекомендую своего друга-ментора:
Диму Урина

#менторство #dataengineering #датаинженерия #DE #DS

⚙️Apache Kafka — распределённый потоковый брокер сообщений. Она хранит события на диске и позволяет приложениям публиковать (producer) и потреблять (consumer) данные с миллисекундными задержками. Используется для логирования, метрик, real-time-аналитики и связи микросервисов.

❔Почему Data Engineer не обходится без Kafka?
• Real-time: задержка 1–10 мс → онлайн-аналитика и алерты.
• Очень быстро: миллионы сообщений в секунду.
• Гибкое хранение: задаёшь, сколько дней или ГБ держать.
• Рост без боли: добавил брокер — и кластер сам расширился.

👀Где Data Engineer использует Kafka?
⏺ Ingestion: сырые логи и клики летят в Kafka, оттуда — в S3/HDFS.
⏺ CDC: Debezium стримит изменения из PostgreSQL → Kafka → ClickHouse/Snowflake.
⏺ Stream-ETL: Flink/Spark обогащают поток и пишут обратно или в озеро.
⏺ Real-time BI: Druid/Pinot/ClickHouse читают топики напрямую.
⏺ Feature Store: онлайн-фичи для ML передаются через Kafka в Redis/Cassandra

📝Ключевые сущности
• Topic — «папка» для событий.
• Partition — линейный лог внутри топика; порядок гарантирован только здесь.
• Offset — номер сообщения; консьюмер знает, где продолжить.

Продюсер (Producer) — кто отправляет данные в Kafka.
Примеры: микросервис «Заказы», агент логов, IoT-датчик, Debezium.

Консьюмер (Consumer) — кто читает данные из Kafka.
Примеры: Spark-job, сервис e-mail-уведомлений, ClickHouse-sink, ML-пайплайн.

Один топик можно читать многими независимыми группами консьюмеров.

👀 Зачем делят топик на партиции
✔️ Данные лежат на разных брокерах → легко расширять кластер.
✔️ Несколько консьюмеров читают параллельно → выше скорость.
✔️ Параллельная запись/чтение → огромный throughput.

Kafka — это центральная артерия большинства современных data-platform. Хотите near-real-time данные в DWH, фичи для онлайн-ML или просто «подложку» под микросервисы — скорее всего, в середине стека крутится Kafka

Более подробно про кафку я расписал тут

❓Частые вопросы по Kafka:
⏺Что такое log retention и какой он дефолтный?
⏺Как сообщения записываются в партиции в кафке?
⏺Кто может быть продюсером и консьюмером в кафке?
⏺Что такие топики, оффсеты?

Ставьте 🔥 если пост был интересным и полезным)
#Kafka #DataEngineering #StreamProcessing #RealTime #BigData #CDC #ETL #ApacheKafka #DevOps #Microservices

В предыдущем посте я рассказывал об оркестраторах https://news.1rj.ru/str/dataengineerlab/15, теперь хотелось бы уделить внимание "золотому стандарту" среди них, а именно Apache Airflow✈️

🕐 Что такое Apache Airflow и зачем он нужен?

Airflow — это оркестратор задач. Он запускает пайплайны данных по расписанию или по событиям, следит, чтобы всё выполнялось в нужном порядке, и даёт удобный интерфейс для мониторинга.

Используется в:
— ETL/ELT пайплайнах
— ML-процессах (тренировка, инференс, мониторинг)
— CI/CD для данных
— обработке логов, API, файлов и всего, что можно автоматизировать

🖱 Основная идея: всё описывается как DAG (направленный ацикличный граф) — граф задач, где узлы = задачи, а стрелки = зависимости. Всё пишется на Python 🐍

🖥 Компоненты Airflow:

• Tasks (задачи) — отдельные шаги: например, скачать файл, преобразовать, залить в S3.
• Operators — готовые блоки:
  PythonOperator — запускает ваш питоновский код
  BashOperator — команда в терминале
  EmailOperator, S3Operator, MySqlOperator и др.
• Sensors — ждут условия (например, появления файла в папке или завершения другого DAG-а)
• Hooks — интерфейсы к внешним системам (Postgres, GCP, AWS и т.д.)

🧬 Кастомизация:
Airflow легко расширяется — можно писать свои CustomOperator или CustomSensor, если не хватает встроенных.

class MyAwesomeOperator(BaseOperator):
    def execute(self, context):
        # ваша логика тут

🛠UI и Monitoring:
У Airflow отличный web-интерфейс. Там видно:
• какие DAG-и активны
• какие задачи упали
• сколько заняло времени
• можно перезапустить всё вручную

🕐Запуск DAG-ов
Пайплайны можно запускать:
• по расписанию (cron, @daily, @hourly)
• по появлению данных
• вручную (через UI или CLI)

Почему он крутой?
Airflow = масштабируемость + контроль + гибкость.

❓Частые вопросы по Airflow:
⏺Что такое DAG в контексте Airflow?
⏺Чем отличаются Operator, Task, Hook, Sensor?
⏺Какие типы операторов ты использовал (PythonOperator, BashOperator и т.д.)?
⏺Что такое Xcom?

Понравился пост? Ставьте🔥
Также я провожу консультации по инструментам (Airflow, Spark, Kafka и др.) — пишите в личку, помогу разобраться.

#Airflow #DataEngineering #ETL #MLops #Python #Orchestration #DAG #DataPipeline

💻Что такое объектное хранилище (Object Storage/S3)?
Если очень просто — это не про папки и файлы, а про объекты. Хранилище, где каждый файл — это объект с данными, метаданными и уникальным ключом. Похоже на key-value хранилище, только для больших данных: фото, видео, бэкапы, логи и т.д.

❓Чем отличается от обычной файловой системы?
Объектное хранилище — это не просто «папки и файлы», а совершенно другая логика:

Нет реальных папок — используется плоская структура, где «пути» — это просто части ключей объектов.
Доступ по уникальному ключу, как к записи в базе.
Масштабируется горизонтально — можно добавлять хосты/диски почти без ограничений.
Работает через HTTP API, чаще всего REST-интерфейс, совместимый с Amazon S3.

Каждый объект хранится внутри бакета - логического контейнера, в котором сгруппированы объекты. Он
имеет уникальное имя и определяет правила доступа.
Объекты внутри бакета не имеют вложенности — всё в одной плоскости. Тем не менее, с помощью префиксов в ключах (/) можно имитировать структуру директорий (logs/2024/march.json).

⚙️Что входит в объект?
Объект — это не просто файл. Он включает в себя:
Данные — содержимое: картинка, видео, архив и т.д.
Метаданные — описание: тип контента, дата, кастомные теги.
Object Key — путь к объекту внутри бакета, например images/2023/product.jpg.
Ключ и бакет вместе формируют уникальный адрес объекта в хранилище.

😎Где применяется Object Storage?

Медиафайлы: фото, видео, обложки, аудио
Бэкапы: базы данных, снапшоты, конфиги
Аналитика и логи: nginx, ClickHouse, Prometheus
Микросервисы: хранение индексов, моделей, статуса
Лендинги и фронтенд: статика сайтов, HTML/JS/CSS

🔐 S3 и версии объектов:
Можно включить версионирование. Тогда каждый PUT создает новую версию, и вы:
Можете восстановить старую
Перезаписать без потери истории
Удалить конкретную версию при необходимости

💡 Почему не RAID?
RAID — это про локальные диски. А Object Storage:

Легко масштабируется
Реплицирует данные по серверам / ДЦ
Сам себя лечит после сбоев
Идеален для неструктурированных данных

🛠Популярные реализации Object Storage:

⏺ Amazon S3

⏺ MinIO (open source)

⏺ Ceph (через RADOS Gateway)

⏺ Azure Blob

Было интересно? Ставьте 🔥
#ОбъектноеХранилище #ObjectStorage #S3 #AmazonS3 #MinIO #Ceph

🗡Что такое Debezium?

Debezium — это инструмент, который следит за изменениями в базе данных и превращает их в поток событий.
Он подключается к PostgreSQL, MySQL, Oracle, MongoDB и другим БД, читает их журналы транзакций (binlog, WAL и т.д.) и создаёт события на каждую операцию INSERT, UPDATE, DELETE.

➡️Например:

{
  "op": "u",
  "before": { "id": 1, "status": "new" },
  "after": { "id": 1, "status": "paid" }
}

❕Зачем это нужно?
Debezium помогает строить real-time системы, где всё, что происходит в БД, сразу доступно другим сервисам и системам.

😮Как это работает?
1. Debezium подключается к вашей БД и читает журнал транзакций
2.Он превращает изменения в JSON-события
3.События летят в Kafka (или Pulsar, Kinesis и др.)
4.Другие системы получают эти события и действуют

🔍Где используется?
🟣В больших микросервисных системах (для передачи бизнес-событий)
🟣В BI-платформах (витрины, отчёты, дашборды)
🟣В архитектурах CQRS, Event Sourcing
🟣Для быстрой репликации данных между системами

😮Примеры применения:
⚫️Обновлять витрины в ClickHouse / Elastic сразу после изменений
⚫️Уведомлять пользователей о событиях (например, "заказ оплачен")
Синхронизировать несколько БД без ETL
⚫️Реализовать outbox-паттерн без потерь и дублирования
⚫️Обновлять Redis-кэш в реальном времени
⚫️Вести аудит изменений без триггеров

☺️Плюсы применения:
✔️ Без нагрузки на БД (читает только логи)
✔️ Надёжно: сохраняет offset, можно воспроизвести изменения
✔️ Гибкая настройка: фильтрация данных, маскирование, трансформации
✔️ Реальное время — задержка ≈ 1–2 секунды

Debezium — это мост между вашей базой данных и остальными системами. Всё, что меняется в БД — тут же становится событием, которое можно использовать: от уведомлений до витрин и репликации.
Пример реализации можно найти тут

Расскажите про ваши примеры применения Debezium🤯 и ставьте 🔥
#Debezium #CDC #Kafka #DataEngineering #PostgreSQL #MySQL #ClickHouse #RealtimeData

Сегодня коснемся того, как устроен стриминг данных, и где он реально нужен?? 📝

Когда события летят непрерывно — клики, транзакции, сенсоры, логи — мы не ждём ночного ETL. Мы «жуем» поток сразу. Разберёмся по блокам и кейсам.

➡️Как работает такой архитектурный конвейер
1️⃣ Источники данных в данном случае это:
веб/мобилки, платежи, IoT, маркет-фиды
2️⃣От них данные летят в Брокер сообщений (Kafka/Pulsar/RabbitMQ) - своеобразный буфер, который накапливает информацию
3️⃣Далее с помощью движка потоковой обработки (Flink/Spark Streaming/Kinesis/Kafka Streams) мы можем аггрегировать и фильтровать данные или просто непрерывно перекладывать в хранилища
4️⃣Потом мы можем положить их в Data Lake (S3/HDFS), где данные будут хранится в сыром виде для различных задач( например ML) и в OLAP или другие БД (ClickHouse/Redis/Postgres) для быстрой аналитики

В итоге это отправится в конечные сервисы: визуализация, нотификации, триггеры бизнес-логики

Кейсы применения👊
🔘 Фрод-мониторинг в финтехе:
Каждая транзакция → Kafka.
Flink проверяет паттерны: скорость операций, гео-аномалии.
Подозрение? Сразу алерт/блокировка карты.
Исторические данные уходят в S3 для обучения антифрод-моделей

🔘Рекомендации в e-commerce:
Клики и просмотры идут потоком
Spark Streaming считает «топ похожих товаров за последние 10 минут», обновляет фичи для онлайн-ML
Результат кешируется в Redis → фронт показывает персональные блоки «вам тоже понравится…»

🔘IoT и промышленность
Сенсоры оборудования шлют телеметрию каждые N секунд
Flink считает скользящее среднее температуры/вибрации, ловит отклонения
Аномалия → алерт инженеру + запись в Data Lake для дальнейшего анализа отказов

😒Зачем нужны потоковые архитектуры?
Реакция в секунды: ловим проблемы до того, как они задолбают клиентов
Свежие данные для ML: модели едят не вчерашние CSV, а потоковые фичи
Масштабирование: каждый блок вертикально/горизонтально масштабируется
Гибкость: можно «переиграть» поток (replay) и пересчитать метрики другой логикой

🔍Сохраняйте себе - эти кейсы отлично подойдут для легенды в резюме🔥

🏗 Архитектура Apache Flink

Flink — это не просто «ещё один стриминговый движок». Он спроектирован так, чтобы выдерживать высокую нагрузку, работать без простоев и обрабатывать события в реальном времени даже тогда, когда данные приходят с задержкой.

🫡В основе Flink — несколько ключевых компонентов.
JobManager это мозг кластера, который принимает задачи, планирует их выполнение и следит за состоянием приложения.
TaskManager это рабочие процессы, выполняющие конкретные операции с данными, от простых фильтров до сложных join’ов.
За надёжность отвечает Checkpoint Coordinator, который регулярно сохраняет состояние приложения (checkpoints, savepoints) и гарантирует exactly-once обработку даже при сбоях.

🕺Поток данных в Flink
В типичном пайплайне есть источники — Kafka, Kinesis, базы данных или файловые системы. Данные проходят через цепочку операторов (map, filter, join, window), где они обогащаются, фильтруются или агрегируются, и попадают в приёмники (Sinks) — будь то аналитическая витрина, хранилище в S3 или база данных.

📌Flink умеет хранить состояние (stateful обработка), и это одно из его главных преимуществ. Состояние может жить в памяти или в RocksDB, а его снимки асинхронно сохраняются, чтобы можно было безболезненно восстановиться после сбоя. Для контроля времени событий используются watermarks — они позволяют корректно обрабатывать опаздывающие данные.

🐈‍⬛Масштабирование и развёртывание
Масштабироваться Flink может как горизонтально (увеличением parallelism), так и вертикально (добавлением CPU/памяти TaskManager-ам).

Разворачивать его можно по-разному:
Standalone — свой кластер на виртуалках или металле.
YARN — если уже есть Hadoop-инфраструктура.
Kubernetes — самый популярный вариант сегодня. Здесь можно выбрать:
Session Cluster — один долгоживущий кластер для нескольких задач.
Per-Job Cluster — отдельный кластер на каждую джобу, максимальная изоляция.
Application Mode — приложение стартует прямо внутри кластера без внешнего клиента.

🛠На чём пишут Flink-приложения
Flink даёт несколько API:

DataStream API (Java/Scala) — полный контроль: ключи, состояние, таймеры, кастомная логика.
Table API / Flink SQL — декларативный способ описать обработку данных, особенно удобен для агрегаций и окон.
PyFlink — позволяет писать SQL/Table API на Python и подключать Python UDF.

❔Когда важна скорость разработки и простота — выбирают SQL/Table API. Когда нужна сложная бизнес-логика, работа с event-time join’ами или кастомная обработка — берут DataStream API. А PyFlink — хороший компромисс, если команда живёт в Python, но хочет использовать стриминг SQL.

Было полезно? Ставьте 🔥
#dataengineering #flink #streaming #architecture #realtime

🎁Что такое 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 — это и про экономию, и про гибкость, и про скорость работы с данными.

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