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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что ждёт вас:

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

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

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

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

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

А если ты уже полон решимости, то не теряй времени и пиши мне в личку: @ampodvalniy — обсудим ( первым трём написавшим скидка 1️⃣5️⃣🔤)!

Отзывы:

https://news.1rj.ru/str/it_mentors/5628
https://news.1rj.ru/str/it_mentors/5817
https://news.1rj.ru/str/it_mentors/5672
https://news.1rj.ru/str/it_mentors/5664