Ребята, давно хотел обновить свой роадмап по Data Engineering - и вот наконец сделал. Кстати, на канале появилось много новеньких - привет всем, кто только подписался, вы тут вовремя появились👋

Переписал роадмап под реалии 2026: убрал лишнее, добавил актуальные инструменты, прикрепил ссылки на материалы и вилки по каждому грейду. Получилось объёмно, но по делу.

Если заходите в профессию или думаете куда расти 📈

-> ЧИТАЕМ ТУТ

P.S. Буду благодарен за комментарии и лайки, хотелось бы продвинуть статью😋

Правильный ответ:

Разный grain (считают по заказам, а агрегируют по позициям — строки размножаются) 🔄

Почему это происходит?

Представь, что у тебя есть таблица «Заказы» (где 1 заказ = 1 строка) и таблица «Товары в заказе» (где 1 товар = 1 строка) 📦Если в одном заказе купили 3 разных товара, то при объединении (JOIN) этих таблиц одна строка заказа «размножится» на три

В чем косяк? Если ты начнешь считать сумму продаж по такой «раздутой» таблице, SQL сложит сумму одного и того же заказа трижды 🥲 В итоге в отчете цифры будут гораздо выше реальных (тот самый «взрыв дублей»), хотя на самом деле продаж больше не стало 📉

Как исправить? Нужно сначала «схлопнуть» (агрегировать) данные о товарах до уровня заказа и только потом делать JOIN☑️

Снова увидел S3 в требованиях? Давай раз и навсегда разберёмся

🤔 Часто в вакансиях вижу S3. Решил напомнить (или рассказать тем, кто не знает) - что это вообще такое 👇

S3 (Amazon Simple Storage Service) - если совсем просто, это «бездонная бочка». Гигантский виртуальный склад. Кидаешь туда файл любого типа и размера - и не думаешь, что место кончится.

Как оно устроено?

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

🪨Объект - сам файл. Картинка, видео, документ, лог. У него есть:
🔘сами данные
🔘метаданные (размер, тип и прочее)
🔘ключ - уникальный адрес, по которому его найдёшь

📦Бакет - контейнер верхнего уровня, куда складываешь объекты. Название бакета должно быть уникальным во всей системе. Вообще всей.

🔑Ключ - полный путь к файлу. Например,

documents/2023/invoice.pdf. 

Вся строка целиком - это и есть ключ. Похоже на папки, да. Но внутри - нет, просто строка.

Почему S3 все так любят?

♾Место не кончается - терабайты, петабайты. Система сама расширяется, когда ты добавляешь файлы.

💰 Дёшево - в 10–20 раз дешевле, чем хранить то же самое в нормальной базе данных или Data Warehouse.

❤️Никуда не денется - данные копируются между серверами и даже между разными городами (дата-центрами). Риск потерять почти ноль.

Но есть и минусы, куда без них

❌ Неизменяемость - объекты нельзя просто «поправить». Хочешь изменить одно слово в текстовом файле? Качай новую версию целиком, перезаписывай старую. Всё заново.

❌ Не для баз данных - S3 медленнее, чем обычный диск. Не подходит для вещей, где данные надо менять мгновенно (например, для работающей базы интернет-магазина).

⏱ Задержки - доступ к файлу может быть медленнее, чем в обычной файловой системе.

А ещё S3 — это фундамент современной аналитики

Его называют «фундаментом» для Lakehouse. На S3 лежат огромные массивы сырых данных в открытых форматах (типа Parquet). А системы вроде Delta Lake или Apache Iceberg превращают эти файлы в удобные таблицы для аналитиков. Красота 🍾

Сделать вам обзор на Delta Lake и Apache Iceberg (или уже 10 раз про них успели прочитать)?

Первое видео на YouTube! 📹📺

Знаю по своим ученикам (да и по себе), что самое сложное на собеседовании - это уверенно рассказать о своем опыте. Особенно если его объективно мало или вы решили немного приукрасить резюме.

Записал для вас видео, где мы с Катей провели мок-интервью…

В этом видео:
🔷 Как рассказывать о своем опыте?
🔷Как отвечать на вопросы про стек, объемы данных и сложные ETL-процессы?
🔷Что говорить об опыте, если его пока не хватает?
🔷Можно потренироваться отвечать на вопросы

Полезно для тех, кто сейчас активно ходит по собесам или готовится к ним👍

Смотреть тут:
🔥YouTube
💙RuTube

Буду рад вашей поддержке: лайки и комментарии очень помогают продвигать видео. И пишите, какие темы разобрать в следующих выпусках — я все читаю 🍾

Новая статья на VC

Кто такой дата-инженер в 2026 году и почему ИИ не заменил нас, а сделал работу дороже.

Спойлер:
✅DE не умер
✅код пишем меньше
✅ошибки стоят дороже
✅зарплаты приятно радуют

👉 Читать тут

Apache Iceberg: почему вокруг него столько шума и зачем он вообще нужен 🧊

Apache Iceberg — это открытый формат таблиц для огромных аналитических наборов данных в data lake.
И если раньше архитектуры на базе Hadoop и Hive нередко превращались в болото данных, то Iceberg придумали как способ сделать такие хранилища более надежными, быстрыми и удобными для аналитики.

Что такое Apache  Iceberg 🤨

Важно сразу понять одну вещь: Iceberg — это не хранилище вроде S3 или HDFS и не движок обработки запросов вроде Spark или Trino.

Это спецификация и набор библиотек, которые отвечают за то, как организованы файлы данных и метаданные. Благодаря этому поверх объектного хранилища можно получить поведение, похожее на работу обычной аналитической базы.

У Iceberg есть несколько сильных сторон 🤔:

ACID-транзакции — читатели не видят частичные или некорректные изменения, а каждое обновление проходит как атомарный коммит.

Time Travel — можно запросить состояние таблицы на конкретный момент времени или по номеру снапшота.

Эволюция схемы без боли — столбцы можно добавлять, переименовывать и удалять без переписывания всей таблицы.

Скрытое партиционирование — Iceberg сам помогает с раскладкой данных по папкам, и не требует вручную постоянно тащить это в запросы.

Главная идея Iceberg — он отслеживает не каталоги, а отдельные файлы данных.
Именно поэтому он так хорошо работает с большими таблицами и сложными сценариями обновлений.

Архитектура Iceberg состоит из трёх слоёв 💠:

1. Catalog layer
Это внешний сервис, который хранит ссылку на текущий файл метаданных таблицы. В этой роли могут выступать Hive Metastore, AWS Glue или REST-каталог подробнее про роль каталога.

2. Metadata layer

Здесь хранится вся логика таблицы:

🔷metadata file — схема, информация о партиционировании и список снапшотов;

🔷manifest list — набор файлов-манифестов для конкретного снапшота;

🔷manifest file — список файлов данных и статистика по ним, включая min/max значения, чтобы движки могли пропускать лишнее при чтении.

3. Data layer

Это сами файлы данных, чаще всего Parquet, которые лежат в объектном хранилище или в HDFS.

Когда Iceberg действительно нужен 🧑‍💻

🔷data lake уже тормозит из-за миллионов файлов;

🔷важна изоляция чтения и записи;

🔷схема таблиц часто меняется;

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

Проще говоря, Apache Iceberg превращает файловое хранилище в полноценную аналитическую систему, но без потери плюсов object storage — дешевизны и масштабируемости

Вы уже пробовали Iceberg? Как вам?🙂

Проверь свою готовность к интервью на DE

Недавно выложил первое видео на 🌐про то, как рассказывать о своём опыте на собеседовании - если ещё не смотрели, держите ссылку.

Захотелось отдельно выложить популярные вопросы с собеседований по опыту для вашей тренировки

Можно попробовать на них ответить. Это отличная практика перед реальными интервью!

Готовы 🤨?

• Расскажите о системах, с которыми вы работали. Откуда поступали данные и куда они передавались? Какие инструменты использовались для этих операций?

• Имели ли вы опыт работы с Apache Kafka?

• Работали ли вы с S3 или аналогичными облачными хранилищами? Опишите ваш опыт.

• В каких форматах приходили данные?

• Какие были объёмы данных?

• Какие движки ClickHouse использовал?

• Какие у тебя были стриминг-потоки?

• Как оптимизировал Spark-джобы?

• Какие проблемы с производительностью возникали и как ты их решал?

Если сейчас на часть вопросов ответить сложно. Это нормально. Всё это можно быстро прокачать, разобрать инструменты и научиться уверенно отвечать на собеседовании.

Я как раз с этим помогаю: упаковываем опыт, тренируем ответы и доводим до спокойного прохождения интервью. За последний год больше 20ти человек с нуля получили офферы и уверенно закрепились на работе!

Кстати, записал для вас вторую часть.Там как раз разбираю ответы на эти вопросы. Выйдет на следующей неделе!



На какой из этих вопросов вам сейчас сложнее всего ответить

Готовитесь к собеседованиям или уже активно ходите по ним? ⚠️🧑‍💻

Один из лучших способов прокачаться - слушать, как отвечают другие. Это помогает подсмотреть правильную логику, перенять профессиональный сленг и уверенные формулировки 🔐

Я записал второе видео, где в формате мок-интервью отвечаю на конкретные технические вопросы🤔Если вам не хватает своих кейсов или вы хотите звучать убедительнее - можете брать мои ответы и адаптировать их под себя.

Внутри разбор по этим пунктам:

⏺Опыт работы с Apache Kafka и стримингом.
⏺Работа с S3 и облачными хранилищами.
⏺Форматы и реальные объемы данных.
⏺Движки ClickHouse: что и когда использовать.
⏺Оптимизация Spark-джоб и решение проблем с производительностью.

Смотреть тут:
⛔️ YOUTUBE
📹 RUTUBE

Поддержите видео лайком и пишите в комментариях на какую тему снимать следующее видео! 🔽

Как договориться о зарплате повыше, когда тебе уже сделали оффер 💵

Многие боятся торговаться 😱 Кажется, что компания сразу передумает и наймет кого-то другого. На самом деле, если вам уже прислали оффер, значит, вы им подходите, и они уже потратили кучу времени на собеседования. Им проще докинуть вам денег, чем начинать поиск заново.

Вот как я советую делать, чтобы получить условия получше 🍪:

1. Сначала узнайте реальные цифры 🔺
Поспрашивайте в чатах или у знакомых, сколько на самом деле платят в этой компании на вашей позиции. Нужно понимать их потолок, чтобы не просить невозможного, но и не скромничать.

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

Что сказать HR 🧑‍💻:

«имя», привет! Спасибо за оффер, мне всё нравится по задачам, и я бы очень хотел работать именно у вас. Но у меня на руках есть оффер в X на N рублей. При этом ваша команда мне ближе по духу. Давайте подумаем, как нам сойтись по деньгам, чтобы я мог сразу выйти к вам и закрыть вопрос с поиском?

Вы не просто просите денег, а показываете, что вы ценный кадр. HR гораздо проще сходить к начальству и выбить для вас бюджет, если есть весомый повод 🗣

Кандидат отличный, хочет к нам, но его переманивают деньгами

В 80% случаев вам либо дадут всю сумму, либо предложат какой-то бонус или пересмотр зарплаты через пару месяцев. В любом случае, вы ничего не теряете. От офферов из-за вежливого торга не отказываются

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

Раньше дата инженер просто перекладывал данные из одной папки в другую. Сейчас этого стало мало…

Раньше от нас ждали только работающие пайплайны. В 2026 году нужно понимать, как устроена вся платформа целиком 📚Где данные лежат, как они меняются и почему бизнес может им доверять. Специалист теперь должен быть более универсальным

Сейчас рынок требует понимания инструментов, которые актуальны и могут навести порядок в данных🌪

Собрал подборку, что надо знать, чтобы быть в тренде:

⏺Lakehouse и Apache Iceberg: С увеличением количества данных и требованиям к их консистентности такой вид хранилища становится все более предпочтительным.
⏺Trino: универсальный движок для подключения к разным бд.
⏺dbt: необходим, чтобы логика трансформаций была прозрачной и с тестами, а не превращалась в черный ящик.
⏺OpenMetadata: необходим, чтобы через месяц не гадать, откуда пришла эта таблица и кто её наполнил.
⏺Kubernetes: платформа на которой сейчас крутится почти всё - от Airflow до Spark.

Важный момент: Успешно растет тот, кто умеет собрать систему, которая не падает каждые пять минут и понятна всей команде ☝

Если хотите разобраться, какие именно инструменты учить на вашем уровне, чтобы не тратить время впустую: загляните в мой роудмап 📍. Там я подробно расписал стек под каждый грейд: от стажера до сеньора.

❗️Забирайте роудмап здесь: ЧИТАТЬ

Кстати, какой инструмент из списка вы уже используете, а какой кажется переоцененным? Пишите в комментариях, обсудим

Почему UPDATE в ClickHouse плохая идея 👎 (и чем его заменить)

⚠️полезно для собесов👇

Многие приходят в ClickHouse из классических баз типа Postgres и поэтому очень хочется написать привычный UPDATE. В ClickHouse это очень плохая идея! 🚮

ClickHouse - это OLAP. Он создан для быстрой записи и чтения миллиардов строк, а не для того, чтобы менять одну ячейку в середине таблицы.

Почему обычный UPDATE — это дорого?

Классические обновления в ClickHouse работают через мутации. Если упростить: база не меняет значение на месте, а переписывает целые куски данных (parts) на диске. Хотели поменять статус у пары юзеров - заставили сервер перелопатить гигабайты данных ☹️ Если таких апдейтов много, очередь мутаций забьет диск и база просто встанет.

Как делать правильно:

1️⃣ReplacingMergeTree для Upsert-сценариев.
Не обновляем старую строку, а вставляем новую версию. ClickHouse сам схлопнет их при фоновом мерже. Идеально для CDC-потоков и профилей пользователей. Да, в запросах может понадобиться FINAL, но это честная цена за производительность.

2️⃣Append-only для событий.
Если у заказа меняется статус (создан -> оплачен -> доставлен), не надо менять одну строку. Пишите историю событий. Текущее состояние вынимается через argMax за доли секунды.

3️⃣Агрегаты через Materialized Views.
Вместо того чтобы обновлять счетчик покупок, пишите сырые события, а суммы считайте через агрегирующие движки (AggregatingMergeTree).

4️⃣CollapsingMergeTree. Он работает через специальную колонку Sign: строка с Sign = 1 считается актуальным состоянием, а строка с Sign = -1 “отменяет” старую запись. При merge ClickHouse схлопывает такие пары строк с одинаковым ключом. Это полезно, когда у вас поток изменений устроен как добавить новое состояние и погасить старое, но для базового upsert чаще проще начать с ReplacingMergeTree.

Итог: ClickHouse любит не изменения старых строк, а правильную модель записи новых.

Было полезно, ставьте 🔥

Периодически спрашивают, где можно почитать отзывы о менторстве

Чтобы не искать, собрал всё в одном месте 👀

Там есть кейсы как ребят с опытом, так и тех, кто заходил в Data Engineering с нуля

🔗 ССЫЛКА НА КАНАЛ

Словари в ClickHouse: как ускорить аналитику и разгрузить базу

🖥 В ClickHouse есть полезный инструмент, о котором часто забывают - Dictionaries (словарь)

Если совсем просто:

Это маленький справочник, который хранится в памяти и помогает не делать JOIN для небольших таблиц. Вместо JOIN с маленькой справочной таблицей (например, users, country, user_id) вы просто используете `dictGet`, чтобы быстро подтянуть нужные значения: country, category, segment и так далее.

dictGet('users', 'country', user_id).

🤓Здесь:
users — имя словаря
country — имя колонки (атрибута), которую хочешь получить
user_id — ключ, по которому ищем (например, id пользователя)

Это часто работает быстрее, потому что:

⏺Данные уже подготовлены для быстрого поиска

⏺ClickHouse не тратит лишние ресурсы на большой JOIN там, где нужен только один атрибут

⏺В некоторых случаях может использоваться очень быстрый механизм join-подобного доступа.

Когда dictionaries особенно полезны:
✅Когда нужно обогатить события: например, подтянуть страну, сегмент или категорию товара

✅Когда справочник небольшой и часто используется

✅Когда нужен простой поиск по ключу, а не сложное соединение таблиц

Когда лучше не использовать:
❌Если вы часто фильтруете по значению из словаря, например WHERE dictGet(...) = 'DE'
В таких случаях лучше хранить нужное поле прямо в основной таблице

❌Если справочник очень большой и плохо помещается в память

❌Если нужна мгновенная синхронность с источником данных

📖Если хотите закрепить, советую прочитать эту статью

А вы пользовались словарями?

Код теперь за нас пишет нейронка. А дебажить кто будет?

Честно говоря, я уже не помню, когда последний раз писал даг с нуля своими руками… Теперь пользуюсь нашими друзьями ChatGPT( Claude и др) 🐶 Они набросают скелет и расставит операторы за вас за секунды!

Но в этом и ловушка. ИИ не несет ответственности за ваш прод 💻 Он не знает про лимиты ресурсов, не понимает логику logical_date и не видит, как два процесса в фоне убивают друг друга

Умение писать код сейчас базовый навык 🤍 Но именно умение видеть архитектурные ошибки и понимать, как всё работает под капотом делает вас дата инженером 👊

Подготовил 3 кейса на дебаг и отладку Airflow из реальной практики ❤️⚠️

1) Про даты: почему datetime.now() - это мина замедленного действия

2) Про backfill: как одной кнопкой запустить 500 дагов и положить планировщик

3) Про конкурентность: почему данные дублируются при параллельных запусках

🎁Забирайте файл, пробуйте разобраться сами: ССЫЛКА

Как вам такой формат? Делать еще вам такие файлики с заданиями👇

Шпаргалка по собесам, которую не стыдно перечитать за день до

Прошёл через десятки интервью и как кандидат, и как тот, кто помогает с этим другим. Вот что реально работает:

👀 Тебя оценивают до первого вопроса
Свет, фон, ракурс камеры считывается за первые секунды. Свет перед лицом и камера чуть выше глаз. Минута настройки, которая меняет первое впечатление.

👀 Исследуй компанию глубже, чем остальные
Не просто почитай сайт. Найди технический блог, статьи на Habr от их инженеров. Упомяни это на собесе. Сразу видно человека, который хочет именно сюда, а не просто рассылает резюме всем подряд

📵 Резюме под каждую вакансию
Большинство отправляет одно резюме всем. Если в вакансии написано Spark и Airflow - эти слова должны быть в твоём резюме на видном месте. ATS-системы отсеивают кандидатов ещё до живого человека.

🔖Не рассказывай, а показывай стек
Работал с большими данными слышат все.

Попробуй иначе:
Собирал данные из ClickHouse и Kafka, строил пайплайны на Spark, оркестровал в Airflow, мониторил через Grafana
Интервьюер уже видит твой стек, без дополнительных вопросов.

✅Готовь истории, а не ответы
На расскажи про сложный кейс шпаргалка не поможет. Заранее вспомни 2-3 реальные ситуации: что была за задача, что пошло не так, как решил. Это универсальная заготовка под половину вопросов на любом собесе.

😅 Говори про ошибки
Вопрос про провалы будет точно. Расскажи, что упало, как починил и что изменил после. Именно так выглядит человек, которому можно доверять.

💵 Зарплата - называй цифру
Диапазон - приглашение торговаться вниз. Одна конкретная сумма, спокойный тон, без оправданий. Если давят - мои ожидания такие, готов обсуждать остальные условия)

❓Задавай вопросы сам/а
В конце собеса спроси что-то про команду или процессы:
— Как выглядит типичный пайплайн в вашей команде?

— Как устроен онбординг?

— Какие задачи будут первые три месяца?

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

💬 После собеса напиши короткое сообщение
Просто: Спасибо за разговор, было интересно узнать про X. Пишут не многие. Уточняй сроки и не жди молча

В конце спроси: Когда примерно ждать обратную связь? Если в срок не ответили - напиши первым. Это не навязчивость, это нормальный контроль процесса.

🗂Записывай вопросы после каждого собеса
Завёл отдельный файл - записываешь всё, что спросили. Через 5-6 собесов у тебя будет личный банк реальных вопросов именно по твоему уровню и стеку. Это лучше любого списка из интернета.

Это база, но именно на ней чаще всего и спотыкаются😎

💾Сохрани себе - пригодится перед следующим собесом)

Что делать, если твой Spark-кластер из 200 воркеров работает как один 🐌

Запускаешь джобу на 200 воркеров, а вся нагрузка едет на одном узле, пока остальные 199 простаивают🥺

Это data skew - неравномерное распределение данных по партициям. Spark делит данные по ключу (обычно при join или groupBy), и если один ключ встречается в разы чаще остальных - весь воркер, который его обрабатывает, становится бутылочным горлышком. Время выполнения джобы определяет не средний воркер, а самый перегруженный.

Заметить просто: открой Spark UI - один или несколько тасков выполняются заметно дольше остальных, иногда доходит до OOM (out of memory) на конкретном экзекьюторе.

Что с этим делать 🤔

Adaptive Query Execution - начни отсюда ▶️

В Spark 3.x можно включить adaptive query execution со skew join handling прямо в конфиге. Spark сам на лету разобьёт перегруженные партиции. Закрывает большинство случаев без единой строчки кода.

Broadcast join, если одна таблица маленькая📊

Можно разослать маленький датасет на все экзекьюторы и обойтись без шаффла полностью. Часто проще и быстрее, чем что-либо солить.

Salting, если ничего не помогло🧂

Добавляешь к перегруженному ключу случайное число - соль. Один огромный партишн превращается в несколько поменьше. Для join большую таблицу солишь, а маленькую размножаешь под каждое значение соли. Это последний инструмент, не первый — усложняет код, и если есть способ попроще, лучше им и обойтись.

🔖полезно почитать дополнительно

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