Дата Инженер Лаб | Артём Подвальный

Channel photo updated

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) — это уже не просто формат, а стандарт индустрии.

Дата Инженер Лаб | Артём Подвальный pinned «➡️Менторство в Data Engineering Рынок с каждым днём становится все жесче, компании неустанно повышают требования к кандидатам, и без опытного наставника войти в специальность становится все сложнее. Какие навыки необходимы ? Как себя преподнести? Что хотят…»

Дата Инженер Лаб | Артём Подвальный pinned a photo

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

➡️Менторство в 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

🐱И вот настало время разобрать 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-процессинга

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

😎К концу подходит год и найм постепенно уходит в предновогоднюю спячку🥺
А значит самое время для повторить теорию, и с новыми силами пойти в бой в новом году🐈‍⬛🐈‍⬛🐈‍⬛.
ПОЭТОМУ собрал всё самое важное, чтобы не потерять!❕❕❕
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

😮И вот настало время разобрать 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 — журнал всех операций записи. Он позволяет не потерять почти ничего, но увеличивает размер файлов и нагрузку на диск.

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

❓ Сегодня продолжим про 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 недостаточно.

⚙️ Сегодня поговорим о 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 стал стандартом де-факто для аналитических систем.

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

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

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

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

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

🌐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. Это делает модель более гибкой, но и более раздробленной.

🚗 Мама, мы на Хабре!

Один из авторов нашего Roadmap написал статью на Хабре, где неплохо так раскинул, что надо знать на стажера, джуна и мидла. И мне понравилось, как коротко расписано по стеку. Прям все по делу.

Если зареганы на Хабре, то зайдите, поддержите статью. Это не реклама. Я вам отвечаю. Да, я вам тут не это!

Вот статейка.
https://habr.com/ru/companies/ozontech/articles/931360/

В целом, лично я хочу сказать, что самое основное — это умение решать задачи на SQL. Знать, как работают JOIN и базовый синтаксис на python. Вот ровно от этого дальше стоит учить инструменты уже. Потому что оно там друг за другом цепляется.

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

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

https://habr.com/ru/companies/ozontech/articles/931360/ выпустил статью на хабр: роадпам для дата-инженера: читайте, закрепляйте, ставьте звёздочки!

🏗 Архитектура 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

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

Когда события летят непрерывно — клики, транзакции, сенсоры, логи — мы не ждём ночного 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) и пересчитать метрики другой логикой

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