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

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

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

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

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

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

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

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

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