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

🐱И вот настало время разобрать 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 — обсудим!

Отзывы:

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

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

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

Рынок Data Engineering в 2026 — это уже совсем другой уровень!
За этот год требования значительно взлетели.
Теперь на собеседованиях мало просто «понимать технологии» — от тебя ждут реального опыта, глубоких деталей и умения рассказать, как ты решал настоящие проблемы в продакшене.

Типичные вопросы сейчас:
⏺Какой самый сложный ETL-процесс тебе приходилось разрабатывать?
⏺Как организована поставка в прод?
⏺Сколько строк в секунду реально лилось через пайплайн?
⏺На чём был реализован процесс (Spark, Flink, Airflow, dbt, Kafka Streams…)?
⏺Как проходила миграция данных / схем / хранилища?
⏺Какие требования бизнеса / SLA стояли?
⏺Какая была твоя роль на проекте ?

Вкатиться самостоятельно стало в разы сложнее.
Поверхностные знания уже не прокатывают — работодатели копают глубоко и хотят слышать конкретные истории успеха и фейлов.
Но хорошая новость: за последний месяц я с командой проработал много реального материала:
🔘 Собрали настоящие кейсы из жизни дата-инженеров
🔘 Разобрали вопросы по компаниям (от Big Tech до российских продуктовых)
🔘 Составили мощные легенды и структурированные рассказы о проектах
🔘 Подготовили ответы, которые реально цепляют интервьюеров
Результат? Люди проходят сложные этапы и получают долгожданные офферы ❕❕❕
Хочешь такую же детальную легенду под себя + уверенный рассказ о проектах, который не развалится под давлением?
Приходи на менторство.
Последние отзывы от ребят:
https://t.me/it_mentors/6596
https://t.me/it_mentors/6514
Пиши в личку, обсудим твою ситуацию:
В 2026 году офферы берут не те, кто «знает теорию», а те, кто может уверенно рассказать «как я это делал в проде и что было сложно».
Давай сделаем так, чтобы это был ты❕❕❕

Как работает CDC pipeline?

🌐В современных дата-платформах данные редко грузят батчами раз в сутки.
Чаще используют CDC (Change Data Capture) — потоковое получение всех изменений из базы.

Разберём классический пайплайн:

MySQL → Debezium → Kafka → ClickHouse

1️⃣В MySQL все изменения пишутся в binlog (binary log) - по сути журнал транзакций базы.
Каждая операция фиксируется как событие: INSERT,UPDATE,DELETE

2️⃣Debezium — это CDC-коннектор (обычно работает через Kafka Connect)
Он:
➡️подключается к MySQL
➡️читает binlog
➡️превращает события в Kafka messages
➡️пишет события в Kafka топики

3️⃣Kafka: транспортный слой между OLTP и аналитикой которая позволяет довольно продолжительное время накапливать историю

4️⃣Далее все направляется в ClickHouse: аналитическое хранилище
Он читает Kafka через Kafka Engine или ingestion сервис.
Выглядит это примерно так:
Kafka topic
↓
Kafka Engine Table
↓
Materialized View
↓
MergeTree таблица

🧐Почему такая архитектура стала стандартом

Она даёт:
➡️Near real-time данные
➡️минимальную нагрузку на OLTP
➡️возможность replay истории
➡️масштабируемость

Было полезно? Ставьте 🔥
#dataengineering #cdc #debezium #kafka

👋Рад тебя видеть в Дата Инженер Лаб!

Я — Артём Подвальный. Помогаю разобраться в работе инструментов обработки больших данных и как происходят эти процессы в компаниях. Здесь я стараюсь простым языком объяснить самое важное что надо знать начинающему DE и получить заветный оффер.

Самое полезное, что уже можно найти в канале:

🔥 Обязательно для прочтения:
Легендарный Roadmap для DE. Проверь, всё ли из этого ты знаешь

🏗 Все самое полезное для DE

💼 Для тех, кто ищет работу или планирует вкатываться в DE

Давай общаться!
Задавай вопросы в комментариях к любому посту или пиши мне лично: @ampodvalniy.

Давайте разберем такую ситаацию: твой пайплайн упал и данные за последние 3 часа «испарились», а восстановить их не из чего 💀

Если у тебя стоит RabbitMQ — это реальный сценарий. Если Kafka то проблема может решится парой команд в консоли. Так почему же один брокер будет прощать ошибки, а другой — нет? Разбирем фундаментальную разницу между Smart Broker и Dumb Broker, чтобы вы больше никогда их не путали.

Главное различие — в «интеллекте» системы:

🔘RabbitMQ (Smart Broker): Брокер сам следит за состоянием очередей, маршрутизирует сообщения и удаляет их сразу после подтверждения (ack). Это модель Push: брокер сам «толкает» данные потребителю. Это упрощает код клиента, но нагружает систему при росте данных.

🔘Kafka (Dumb Broker): Это распределенная платформа потоковой передачи, работающая как распределенный коммит-лог. Она просто записывает данные и хранит их. Здесь работает модель Pull: потребители сами запрашивают данные, когда готовы их обработать.

👀 Почему для Data Engineering почти всегда нужна Kafka?

🔛 Гипер-масштабируемость: Кафка переваривает миллионы сообщений в секунду. Секрет в партиционировании (partitions): топики делятся на части и распределяются между брокерами. Это позволяет распараллеливать чтение и запись на петабайтах данных. Мы упоминали это, когда разбирали современный Lakehouse.

🔛 Постоянство данных (Retention Policy): Сообщения не удаляются после прочтения. Они хранятся по времени или объему. Это позволяет нескольким потребителям читать одни и те же данные в разное время.

🔛 Replayability (Повтор): Если в пайплайне баг, ты просто перечитываешь данные заново. В RabbitMQ «съеденное» сообщение пропадает навсегда.

🔛 Гарантии Exactly-once: Кафка умеет доставлять сообщение «ровно один раз», что критично для финансов. Рэббит обычно гарантирует только «хотя бы один раз».

🐰Когда RabbitMQ — это НЕ ошибка?
🔘Сложная маршрутизация: Если нужно раскидывать задачи по куче условий (exchanges: direct, fanout, topic, headers). Кафка в базе так не умеет.

🔘Приоритеты: В RabbitMQ можно пометить сообщение как высокоприоритетное, и оно проскочит очередь. В Кафке порядок строго хронологический внутри партиции.

🔘Низкая задержка на малых данных: При небольших объемах Рэббит может быть быстрее, но при росте нагрузки его задержки растут лавинообразно.

Итого:
Если ты строишь Data Lake, систему аналитики или ETL-пайплайны — твой выбор Kafka. Она идеально ложится в архитектуру Data Vault, сохраняя историю без потерь.

RabbitMQ оставляем для микросервисов и простых очередей (например, фоновая отправка писем).

🔖Что почитать по теме: https://habr.com/ru/companies/slurm/articles/666326/

❓Вопрос к тем, кто учится:

Представь, что тебе нужно собирать логи со 100 серверов и сохранять их в базу для аналитики. Что выберешь после этого поста и почему?

Пиши в комментариях, обсудим! 👇


#Kafka #RabbitMQ #DataEngineering #ITCareer #CareerDE #DataScience

Вопрос по которому часто возникают трудности у кандидатов😐

«Как вы боретесь с дублями в Kafka на проде?». Напиши свой ответ в комментариях и сравнивай:

Ответ: "Три уровня защиты. Producer: enable.idempotence=true — закрывает сетевые ретраи. Consumer: проверяю event_id в Postgres перед обработкой. Транзакции — только для read-process-write между топиками Kafka. Главное правило: check → process → commit offset."

Совпало? Теперь разберем по полочкам, почему это важно: 👇

Почему дубли вообще есть?

1️⃣Producer retry
Producer отправил сообщение → брокер не ответил → producer отправил СНОВА
Kafka получила 2 одинаковых сообщения

2️⃣Consumer crash
Consumer прочитал сообщение → начал обработку → УПАЛ
При рестарте читает то же сообщение СНОВА

3️⃣Rebalance группы (80% проблем на проде!)
Consumer A обработал партицию → Consumer B взял её → обработал СНОВА

Как это можно решить:

🔵Настройка продюсера

Кафка выдает тебе Producer ID (PID) и заставляет нумеровать сообщения. Если брокер видит сообщение с номером, который уже был - он его просто выкидывает.

Настройка: enable.idempotence=true.

Почти не влияет на скорость. Включай всегда по умолчанию.

🔵Транзакции

Объединяет чтение и запись в одну неделимую операцию (Read-Process-Write). Если что-то упало - вся цепочка откатится, и дублей в конечном топике не будет.

Настройка: transactional.id + isolation.level=read_committed.

Добавляет задержку (latency). Используй только там, где критичен идеальный порядок.

🔵 Идемпотентность консьюмера

Кафка не знает, что в твоей базе. Если сервис записал данные, но «упал» до фиксации оффсета - кафка пришлет дубль. Поэтому проверяй уникальность ключа на входе в базу.

Пример: INSERT ... ON CONFLICT DO NOTHING в Postgres или SET NX в Redis.

Самый надежный способ, который спасет, даже если настройки кафки не помогли.

🤔Какой следующий вопрос разобрать?

#Kafka #DataEngineering #ITCareer #CareerDE #DataScience

Страшно начинать с нуля 😱

Это первая мысль, когда решаешь уйти из другой сферы или только заканчиваешь универ…

📌Но вот в чём штука — ты и не начинаешь с нуля

Ноль — это когда нет ничего. А у тебя есть: годы учёбы или работы, насмотренность, понимание того, как устроены процессы, люди, системы. Это не обнуляется от того, что ты открыл первый туториал по Python⚠️

Именно прошлый опыт часто становится скрытым преимуществом:

Умение структурировать хаос🌪
Пайплайны, зависимости, ошибки, потоки данных — это управляемый хаос. Если умел наводить порядок в процессах, документах или хотя бы в своих курсовых — здесь будет понятна логика.

Коммуникация
DE — это не только код. Объяснить аналитику, почему данные «поехали», согласовать с бизнесом приоритеты — это добрая половина работы 🍻

Проектное мышление 🖥
Привычка доводить задачи до конца, держать сроки и не теряться в приоритетах — это видно сразу и ценится высоко.

Внимание к «скучным» деталям
Бухгалтерия, документирование процессов, контроль качества — там, где без проверок нельзя. Этот «занудный» навык в DE превращается в суперсилу 👀

Гибкость в освоении нового
Если ты уже менял роли или сферы, твой мозг умеет перестраиваться. Новый стек, новая терминология уже не шок 🧑‍💻

Опыт работы с документацией
Умеешь читать инструкции, регламенты, стандарты? Значит, разобраться в API, логах и метриках — вопрос времени, а не способностей.

🏫А если ты только из универа?
Учился на экономиста, биолога, физика, юриста — неважно. Ты уже умеешь разбираться в сложных системах, работать с большим объёмом информации и доводить задачи до результата под дедлайн. Это и есть база, на которую ляжет DE.

Твой опыт, абсолютно любой — это актив. Его стоит ценить и использовать!

📱 SQL, Python, облака и оркестрацию выучить можно. А умение не паниковать, когда всё горит, чувствовать бизнес и структурировать хаос — это приходит с опытом, который у тебя уже есть

Если сейчас стоишь перед этим шагом и не знаешь, с чего начать — пиши в личку @ampodvalniy 👋

Расскажешь про свой
бэкграунд, разберём вместе: что уже есть, что нужно подтянуть и как выстроить путь без хаоса👍

📊Ты считаешь ежедневных юзеров, и вдруг DAU (Daily Active Users) подскочил на 25%! Команда празднует вирусный рост, а ты хватаешься за дебаггер ⚠️