🎁Что такое 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