Роадмап дата-инженера: с чего начать и в каком порядке

Дата-инженер двигает данные, а не строит модели

Главная ментальная модель, с которой стоит начать: дата-инженер не предсказывает отток клиентов и не рисует дашборды. Он строит трубы, по которым данные надёжно текут из источников в хранилище и дальше — к аналитикам и ML. Если data scientist отвечает на вопрос “что значат эти данные”, то дата-инженер отвечает на вопрос “как сделать так, чтобы эти данные были на месте, свежими и корректными каждое утро в 7:00, даже когда упал источник”.

Из этого следует всё остальное. Ваша работа — это надёжность, идемпотентность, наблюдаемость и стоимость. Не “знать модный фреймворк”, а понимать, что произойдёт с пайплайном, когда придёт дубль, когда задача упадёт на середине, когда данных станет в 100 раз больше. Поэтому роадмап ниже выстроен не по популярности инструментов, а по зависимостям: каждый следующий слой имеет смысл только тогда, когда предыдущий стал интуитивным.

Большинство роадмапов в интернете — это список из 40 логотипов. Это вредный жанр. Логотипы меняются раз в три года, а фундамент — нет. Ниже — порядок, а не каталог.

Слой 0: фундамент, который не устаревает

Три навыка образуют землю под ногами. Без них любой “большой” инструмент превращается в карго-культ: вы копируете конфиги со StackOverflow, не понимая, что они делают.

SQL — это не “ещё один навык”, это родной язык профессии. 80% реальной работы дата-инженера — это трансформации данных, и они выражаются на SQL. Причём не SELECT *, а оконные функции, GROUP BY с GROUPING SETS, корректные JOIN по составным ключам, понимание NULL и того, почему NOT IN с подзапросом, где есть NULL, возвращает пустоту. SQL надо довести до уровня, когда вы читаете запрос как прозу.

Python — клей между системами. Не для веб-разработки, а как язык, на котором пишутся DAG’и Airflow, кастомные операторы, парсеры API и тесты данных. Базовый уровень: структуры данных, генераторы, работа с файлами и форматами (CSV, JSON, Parquet), pandas или polars для разведки, виртуальные окружения.

Linux и git — гигиена. Дата-пайплайны живут на серверах, а не на вашем ноутбуке. Уметь читать логи через grep, понимать каналы (pipe), cron, переменные окружения, права на файлы — это ежедневная необходимость. git — потому что пайплайны это код, а код живёт в репозитории и проходит ревью.

Эти три блока — ровно то, с чего стоит начать на практике в нашем бесплатном курсе /landing/data-engineering-fundamentals/: там SQL и Python отрабатываются в интерактивном sandbox прямо в браузере, без установки чего-либо.

Маленькая иллюстрация того, как Python и SQL встречаются в реальной задаче — идемпотентная загрузка (можно безопасно перезапускать):

# Идемпотентная загрузка партиции за дату:
# сначала удаляем то, что грузили, потом вставляем заново.
# Перезапуск упавшей задачи не создаёт дублей.
def load_partition(conn, dt: str, rows: list[dict]) -> None:
    with conn.begin():  # одна транзакция: всё или ничего
        conn.execute(
            "DELETE FROM events WHERE event_date = :dt", {"dt": dt}
        )
        conn.execute(
            "INSERT INTO events (event_date, user_id, payload) "
            "VALUES (:event_date, :user_id, :payload)",
            rows,
        )

Слой 1: где данные живут — warehouse, lake, lakehouse

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

Ключевая ментальная модель: schema-on-write даёт дисциплину, но негибок; schema-on-read гибок, но переносит хаос на читателя. Lakehouse — это попытка получить транзакционность warehouse поверх дешевизны lake через табличные форматы вроде Iceberg.

На этом слое не нужно сразу осваивать все облака. Нужно понять модель: разделение хранения и вычисления, колоночные форматы (Parquet), партиционирование. Почему колоночное хранение быстрее для аналитики — это не магия, а то, что аналитический запрос читает 3 колонки из 200, и колоночный формат позволяет не трогать остальные 197. То же про партиционирование: если данные физически разложены по датам, запрос за один день не сканирует год — это называется partition pruning и экономит и время, и деньги в облаке, где вы платите за просканированные байты.

Ещё одна идея, которую стоит усвоить здесь раз и навсегда — слоистость хранилища. Сырые данные приземляются как есть (слой raw/bronze), затем очищаются и приводятся к единому виду (staging/silver), и только потом собираются в бизнес-витрины (marts/gold). Это разделение спасает в момент, когда логика витрины оказалась неверной: вы пересобираете её из сырья, а не идёте заново выкачивать данные из источников, которые могли уже измениться.

Слой 2: batch-обработка — Spark

Когда данных больше, чем влезает в память одной машины, появляется распределённая обработка. Эталон здесь — Apache Spark.

Ментальная модель Spark: вы описываете что посчитать (трансформации над DataFrame), а движок сам решает, как распределить это по кластеру. Критично понять две вещи. Первая — lazy evaluation: трансформации копятся в план и исполняются только на action. Вторая — shuffle: перемешивание данных между узлами при join и groupBy. Shuffle — это almost всегда самая дорогая операция, и значительная часть оптимизации Spark сводится к тому, как его избежать или удешевить.

На этом слое легко закопаться в тюнинг раньше времени. Сначала — модель исполнения (план запроса, партиции, узкие и широкие трансформации), и только потом — настройки памяти и spark.sql.shuffle.partitions.

Слой 3: оркестрация — Airflow

Пайплайн — это не один скрипт. Это десятки задач с зависимостями: “выгрузи из источника, потом трансформируй, потом проверь качество, потом обнови витрину, и только если всё прошло — отправь уведомление”. Оркестратор отвечает на вопросы “что после чего”, “что делать при сбое”, “как перезапустить вчерашний день”.

Стандарт индустрии — Apache Airflow. Его ментальная модель — DAG: граф задач, где рёбра — зависимости. Два понятия, без которых Airflow не понять: idempotency (перезапуск не должен ломать данные) и backfill (прогон пайплайна за прошлые даты). Если задачи идемпотентны, перезапуски безопасны, и вся жизнь дата-инженера становится спокойнее.

Важно: Airflow оркестрирует, но сам не обрабатывает большие данные. Типичная ошибка джуна — тянуть гигабайты через pandas внутри задачи Airflow вместо того, чтобы запустить Spark и дождаться результата. Оркестратор дирижирует, а играют инструменты. На уровне ментальной модели Airflow — это конечный автомат состояний задач (queued, running, success, failed, up_for_retry) плюс планировщик, который раз в интервал смотрит, какие задачи готовы к запуску по своим зависимостям и расписанию. Когда вы это видите, перестаёт быть загадкой, почему задача “висит” — она просто ждёт свободного слота исполнителя или незавершённую вышестоящую задачу.

Слой 4: стриминг — Kafka и Flink

До сих пор всё было про batch: данные приходят порциями по расписанию. Но часть задач требует реакции в секунды — антифрод, рекомендации, мониторинг. Здесь появляется стриминг.

Kafka — это не “очередь”, а распределённый лог: упорядоченный журнал событий, который читатели проходят в своём темпе. Flink — движок обработки этих потоков с гарантиями exactly-once и оконными агрегациями по времени события.

Честный совет: стриминг — это слой, который не нужно учить в начале пути. Он сложнее batch концептуально (время события vs время обработки, опоздавшие данные, state management) и требуется реже. Освойте его, когда batch стал рутиной.

Слой 5: моделирование и трансформации — dbt

Данные лежат в хранилище — но как превратить сырьё в понятные бизнесу витрины, поддерживаемо и с тестами? Здесь правит dbt.

Ментальная модель dbt: трансформации — это код, а не клики в BI. Вы пишете SELECT-модели на SQL, dbt разрешает зависимости между ними, материализует как таблицы или вьюхи, и — критично — даёт встроенные тесты данных (unique, not_null, relationships) и автодокументацию. dbt привнёс в дату инженерные практики: версионирование, тестирование, CI. Это не отдельный движок — он компилирует SQL и отдаёт его вашему warehouse.

Слой 6: internals — то, что отличает senior

Junior умеет собрать пайплайн из готовых блоков. Senior понимает, что происходит внутри блоков, и поэтому отлаживает то, что для остальных — чёрная магия: почему Spark-джоб разлился в disk spill, почему consumer group в Kafka бесконечно ребалансится, почему запрос к Iceberg сканирует все файлы вместо одной партиции.

Internals — это про модель исполнения: как планировщик Airflow выбирает задачи, как Spark строит физический план и почему broadcast join дешевле shuffle join, как устроен MergeTree в ClickHouse, как Flink хранит state в чекпойнтах. Этот слой учат не по роадмапу, а по проблемам, которые приходят из прода. Именно поэтому он идёт последним — у него должны быть якоря в реальном опыте.

Чего НЕ учить сразу (и почему)

Самая частая ошибка новичка — распыление. Вот что осознанно стоит отложить:

Принцип простой: глубина важнее ширины. Один инструмент, понятый до internals, ценнее десяти, по которым вы прошли туториал. Работодателю не нужен список логотипов в резюме — ему нужен человек, который починит упавший пайплайн в пятницу вечером.

Как пройти этот путь на практике

Чтение роадмапа не делает дата-инженером — практика делает. Порядок прохождения: доведите до автоматизма SQL и Python, разберитесь с моделью хранилищ, потом batch и оркестрация, и только затем — стриминг и internals.

Начать стоит с бесплатного курса /landing/data-engineering-fundamentals/: SQL, Python, Linux/git и первые пайплайны отрабатываются в интерактивном sandbox прямо в браузере — без установки окружения, бесплатно. А когда захочется увидеть всю карту направления целиком — от джуна до senior-internals — загляните в /directions/data/, где курсы выстроены ровно в том порядке зависимостей, что описан выше.

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