Зачем нужен dbt, если есть Spark и ClickHouse?

Многие до сих пор путают dbt (Data Build Tool) с вычислительными движками. Давайте сразу: dbt сам ничего не считает🚨

Он не заменяет Spark, Trino или ClickHouse. dbt — это инструмент для организации трансформаций внутри вашего хранилища🖥Он превращает разрозненные SQL-скрипты в полноценный инженерный проект с тестами, документацией и зависимостями.

В чем суть?

Без dbt вы сами следите за тем, в каком порядке запускать скрипты. С dbt вы просто описываете модели, а инструмент сам строит DAG.

Например:

stg_users → stg_orders → mart_sales

Зачем нужен dbt 🤔

dbt сам поймет, что витринаpark и ClickHoне соберется, пока не готовы стейджинги, и запустит всё в правильной последовательности.

Что он дает на практике:

✔️ Управление зависимостями: Автоматическое построение графа (DAG).
✔️ Тестирование: Можно из коробки проверять данные на NOT NULL, UNIQUE или проверять внешние ключи.
✔️ Документация: dbt сам генерирует описание моделей и связей между ними.
✔️ Версионирование: Весь ваш SQL живет в Git как код.

Кто тогда считает?

dbt - это мозг, а не мышцы. Он просто отправляет SQL-код в ваш вычислительный движок: Spark, Trino, ClickHouse или Postgres🖥 Именно они делают тяжелую работу (JOIN, GROUP BY), а dbt управляет этим процессом.

Итог: dbt приносит в мир аналитики лучшие практики разработки. Это мастхэв, если вы хотите строить поддерживаемые и надежные витрины, а не просто плодить горы SQL кода🔥

Почитать по теме:
🔗 DBT: трансформация данных без боли
🔗 DBT в продакшене

Flink vs Spark Streaming: что выбрать для Data Lakehouse

Если совсем просто, Flink и Spark Streaming - это инструменты, которые обрабатывают данные на лету➡️

То есть не ждут конца дня, чтобы всё пересчитать, а работают с событиями почти сразу, как только они появляются🌟

🐿Что делает Flink:

Flink нужен там, где данные идут непрерывным потоком: из Kafka, из логов, из CDC, из событий приложения.
Он умеет сразу принимать эти события, обрабатывать их и писать результат дальше, например, в Iceberg, Hudi или Delta Lake.

Проще говоря, Flink - это потоковый двигатель.
Он хорошо подходит для задач, где важна свежесть данных: почти мгновенные обновления, подсчёты по окнам времени, дедупликация, обработка изменений из баз.

Что делает Spark Streaming⭐

Spark Streaming тоже умеет работать с потоком данных, но его подход немного другой. Он исторически вырос из batch-мира, то есть из обработки больших пачек данных.

Поэтому поток он обрабатывает как маленькие батчи (микробатчами), небольшие порции данных, которые идут одна за другой.

Это нормально, если тебе не нужна супер-низкая задержка и если у команды уже вся архитектура построена на Spark.

В чём разница:

➖Flink - когда нужен настоящий live-streaming и минимальная задержка

➖Spark Streaming - когда потоковая обработка нужна, но ты уже живёшь в Spark-экосистеме и хочешь не менять стек

Где, что используют в Data Lakehouse 🟦

В Lakehouse-архитектуре обычно так:

⏺Flink — забирает события, обрабатывает их и пишет в таблицы lakehouse.
⏺Trino — потом читает эти таблицы через SQL.
⏺Spark — часто используют для тяжёлых batch-вычислений и больших пересчётов.

🤓Почитать дополнительно:

⏺Введение в Apache Flink: архитектура и основные концепции

⏺Стриминговые фреймворки: Apache Flink

Было полезно? Ставь 🔥

Собес в бигтех: когда теория уже не спасает

На собесах в классные компании на интервью редко спрашивают только «что такое ETL?». Чаще дают кейс с прода и смотрят, как ты думаешь🧐: где риск дублей, что сломается при ретрае, как найти узкое место и чем лечить проблему.

💡Собрал 5 интересных и реальных вопросов, на которых проверяют реальный опыт:

1️⃣Airflow: задача упала на середине загрузки — что делать?

Не просто  Clear . Сначала проверь идемпотентность: staging,  UPSERT , перезапись партиции, атомарный commit. Повторный запуск не должен портить данные.

🔗 Статья про идемпотентность в Airflow

2️⃣Spark тормозит, хотя ресурсов в кластере много — с чего начнёшь?

С Spark UI. Ищи  shuffle ,  data skew , лишние мелкие файлы и дорогие UDF. Часто проблема не в памяти, а в плане выполнения.

🔗 Диагностика Spark приложений

3️⃣Kafka: пришёл дубль события — как не сломать витрину?

Офсеты не спасают. Нужны exactly-once на pipeline-уровне и идемпотентная запись в приёмник:  UPSERT ,  MERGE , уникальный ключ.

🔗Идемпотентность и повторные запуски

4️⃣Iceberg: наплодили много мелких файлов — чем это плохо?

Растёт нагрузка на метаданные, а Trino/Spark тратят время на планирование. Нужен  compaction  и нормальный размер файлов.

5️⃣Когда реально нужен real-time?

Бизнес всегда хочет быстрее, но платить за это тоже нужно. Стриминг (Flink/Spark Streaming) нужен только там, где задержка в секунды критична: антифрод, алерты, персонализация. Если можно подождать 5–10 минут обычный batch будет в разы проще и дешевле.

На собесе важнее не угадать инструмент, а показать, что ты понимаешь ограничения архитектуры и умеешь выбирать решение под задачу.

🚀Хочешь оценить свою готовность к рынку?
Пиши мне в личку @ampodvalniy, укажи текущий стек и на какой грейд/ЗП метишь. Посмотрим, где у тебя пробелы и как их закрыть.

Как я стал дата-инженером?

Хочу поделиться своей историей перехода в мир дата-инженерии. Возможно, кого-то это вдохновит и поможет сделать первые шаги 🤝

💡Изначально меня привлекал Data Science с точки зрения ML - обучение моделей, участие в хакатонах по компьютерному зрению, ранжированию и NLP 🤖. Я активно изучал ML, экспериментировал и набирался опыта.

Но всё изменилось, когда я устроился в геномный центр 🧬Именно там я впервые столкнулся с инженерной стороной данных. Вокруг были свои форматы, специфичные инструменты и оркестраторы, разработанные специально для работы с геномными данными. Объёмы данных были по-настоящему впечатляющими: более 10 000 человеческих геномов (каждый весом около 100 ГБ), хранившихся на ленточных хранилищах

Там я начал писать свои первые пайплайны, настраивал сбор и обработку данных. Постепенно понял, что такая разработка мне реально нравится. Даже больше, чем обучение моделей. Было интересно копаться в инструментах, разбираться, как всё устроено, и делать так, чтобы система работала чётко и надёжно. Именно тогда я и решил двигаться в сторону дата-инженерии ⚙️

Чтобы вкатиться по-настоящему, мне пришлось подтянуть базовые навыки:

✔️SQL — базовый навык, который спрашивают на каждом собеседовании. Отличный интерактивный курс на Stepik помог разобраться с этим языком запросов.

✔️Python — умение писать простенькие алгоритмы, знать основы структур данных и объектно-ориентированного программирования. Здесь очень помогли открытые курсы от МФТИ по алгоритмам и структурам данных и ООП(с 5ого по 9ый модули) , хорошо бы освоить хотя бы на теории.

✔️Решение задач уровня medium на Leetcode — отличный способ подготовиться к собеседованиям и улучшить алгоритмическое мышление.

✔️Чтение статей про HDFS, Airflow, СУБД, Spark — чтобы понять, с какими инструментами приходится работать в реальной инженерной практике. О них всех и о том какие этапы я проходил расскажу в следующих постах.

Если было интересно, ставьте 🔥

❗️Вопрос с собеса в BigTech:

«Мы удвоили количество executor ов, но Spark джоба не ускорилась. Почему?»

Это классическая ловушка для тех, кто пытается лечить любую проблему масштабированием 🥸

У тебя есть медленный pipeline. Ты увеличиваешь  количество executor ов в 2 раза, перезапускаешь job, а время выполнения остаётся прежним или даже растёт.

Что происходит?

1️⃣Data skew 🥴

Если один ключ содержит 90% данных, все связанные с ним записи могут попасть в одну shuffle-partition. Один task будет работать 20 минут, пока остальные завершатся за секунды.

В таком случае дополнительные executor’ы не помогут: job ждёт самую медленную task 🐌

В Spark UI сравни  Max  и  Median  по длительности tasks и объёму  Shuffle Read .

Большой разрыв — сигнал проверить перекос данных❗️

2️⃣Узкое место в shuffle🔀

 JOIN ,  GROUP BY  и  repartition  могут вызвать shuffle — перераспределение данных между executor’ами.

Если bottleneck (узкое место) находится в shuffle, добавление машин не убирает саму пересылку, сортировку и запись промежуточных данных на диск.

Сначала нужно проверить план и объём shuffle, а затем рассмотреть broadcast join, предварительную агрегацию, фильтрацию до join и настройку числа shuffle-partitions.

3️⃣Недостаточно задач для параллелизма🟰

Количество executor’ов само по себе не создаёт работу. Если в stage всего несколько крупных tasks, дополнительные executor’ы будут простаивать.

Поэтому нужно смотреть не только на число executor’ов, но и на количество tasks, размер partition и соотношение доступных ядер к параллельной работе.

4️⃣Слишком много мелких файлов💛

Миллион файлов по 10 КБ — это не много вычислений, а много служебных операций: listing, планирование и запуск tasks.

Масштабирование кластера проблему не устранит. Нужно менять стратегию записи и объединять мелкие файлы.

5️⃣Memory pressure, GC и spill🕳

Если tasks обрабатывают слишком большие partition, executor может тратить время на сборку мусора или сбрасывать промежуточные данные на диск ( spill ).

 Spill  не всегда означает ошибку — это допустимый механизм Spark. Но если он массовый, а  GC Time  высокий, нужно проверить размер partition, shuffle и конфигурацию памяти.

Как отвечать на собеседовании 🧐

Я бы сказал:

☑️«Сначала открою Spark UI и найду самый долгий stage».
☑️«Сравню  Max  и  Median  длительности tasks».
☑️ «Проверю  Shuffle Read/Write , spill и  GC Time ».
☑️ «Посмотрю, хватает ли tasks для загруженных ядер».
☑️«Только после диагностики буду менять конфигурацию или добавлять ресурсы».

Главная мысль: больше executor’ов ускоряют job только тогда, когда есть достаточно независимой работы. Если причина в skew, shuffle, мелких файлах или memory pressure, масштабирование лишь увеличит стоимость, но не устранит bottleneck.

📚Для изучения:

⏺ Руководство для начинающих по Spark UI

⏺Оптимизируем Shuffle в Spark

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

С нуля в Data Engineering: Путь до оффера в BigTech 🚀

Записал интервью со своим учеником. Это честный разговор о том, как реально сменить профессию и устроиться дата инженером в 2026 году.

Важно: Личность и голос Антона изменены для сохранения его анонимности на текущем месте работы. Все результаты — подлинные, верифицированные отзывы есть в канале.

О чем видео:
⏺Сколько времени занял переход с нуля до оффера
⏺Как мы прорабатывали легенду для резюме
⏺Страхи на первых собесах
⏺Совет тем, кто думает вкатываться

📺Смотреть:

YOUTUBE

RUTUBE

ИИ в проде: что агенты уже могут делать в Data Engineering

Про ИИ-агентов сейчас много шума. Иногда агентом называют обычный чат с LLM 😺, хотя разница довольно простая.

Чат отвечает. Агент может сам сходить за информацией и что-то сделать 🤖

Например, ночью упал DAG. Агент открывает логи, смотрит прошлые запуски, проверяет схему и пытается понять, где всё сломалось. После этого может предложить retry, backfill или завести инцидент.

То есть это уже не просто скинь ошибку в ChatGPT. Агент получает доступ к Airflow, мониторингу, каталогу данных и другим инструментам.

🧐Звучит удобно, но сразу появляется вопрос: а стоит ли давать ему самому что-то менять в проде?

Прочитать логи и найти подозрительное место — нормально. Удалить данные, изменить схему или запустить большой backfill без подтверждения человека — уже страшновато😱

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

Сейчас самые понятные сценарии выглядят так:

⏺описание таблиц и колонок;
⏺поиск связей между данными;
⏺генерация SQL;
⏺разбор логов и упавших пайплайнов;
⏺поиск аномалий и причин алертов.

Например, MWS запустила
Data Scout. Агент анализирует метаданные, ищет связи между таблицами и помогает наполнять каталог данных.

Пока агенты не заменяют дата-инженеров. Скорее, становятся еще одним слоем над платформой🧠

Всё упирается в качество платформы данных. Без описаний, связей и контроля доступа агент может неправильно понять данные, выбрать не ту таблицу или получить лишние права.

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

💡Кстати, в программе появилось видео про ИИ в проде: как агенты сейчас устроены и работают на реальной платформе в крупном бигтехе. + Сейчас планируем видео курс (для менти) про внедрение ИИ агентов в проект 😎