Дата-инженер: от источников до витрин данных

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

Если очистить вакансии от модных слов, у профессии останется одно ядро: дата-инженер строит и поддерживает надёжные пайплайны, которые везут данные из мест, где они рождаются, в места, где их используют. Аналитик хочет открыть дашборд и увидеть вчерашнюю выручку. ML-инженер хочет обучить модель на фичах, посчитанных по сырым событиям. Продукт хочет показать пользователю персональную ленту. Между «данные где-то есть» и «данными можно пользоваться» лежит инженерная работа, и это она.

Ключевое слово здесь — надёжность. Написать скрипт, который один раз перелил таблицу из Postgres в хранилище, может кто угодно. Дата-инженерия начинается там, где этот процесс должен повторяться каждую ночь годами, переживать падения источника, перезапускаться без дублей, обрабатывать схему, которая внезапно изменилась, и громко сигналить, когда что-то пошло не так. Большая часть работы — это не «достать данные», а «сделать так, чтобы доставание данных было предсказуемым».

Поэтому хороший ментальный образ дата-инженера — не «программист, который пишет SQL», а инженер по доставке данных как по производственной линии: с контролем качества, обработкой брака, мониторингом простоев и планом действий на случай аварии.

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

Канонический путь данных

У почти любой data-платформы — от стартапа до банка — один и тот же скелет. Меняются названия инструментов, но стадии те же. Это и есть та карта, которую держит в голове дата-инженер.

Источники        Ingestion        Хранение         Трансформация      Serving
(OLTP / API /  → (batch /       → (lake /        → (ELT / dbt)     → (BI / ML /
 события)         stream)          warehouse /                          обратно
                                   lakehouse)                            в продукт)

Разберём по стадиям.

Источники. Это ещё не пайплайн, а его исходная точка. Транзакционные базы приложения (Postgres, MySQL, MongoDB) — здесь живут заказы и пользователи. API внешних сервисов — платёжки, CRM, рекламные кабинеты. Файлы — выгрузки CSV и JSON-логи. И событийные потоки — клики, показы, действия пользователей, которые льются непрерывно. Важная деталь: источник почти никогда не принадлежит дата-команде. Он может измениться без предупреждения, и пайплайн обязан это пережить.

Ingestion — извлечение и доставка. Тут проходит первая большая развилка: тянуть данные пачками по расписанию (batch) или принимать их потоком в реальном времени (stream). Batch проще, дешевле и закрывает большинство задач: раз в час или раз в сутки забрали новые строки и положили в хранилище. Stream нужен там, где задержка критична — антифрод, рекомендации, операционные дашборды. Отдельная тонкость батча — CDC, который позволяет не перечитывать всю таблицу каждый раз.

Хранение. Данные приземляются в одно из трёх (или в их комбинацию). Data lake — дешёвое объектное хранилище (S3 и аналоги) для сырых файлов в любом формате. Data warehouse — аналитическая СУБД со строгими схемами и быстрым SQL поверх колоночное хранение. Lakehouse — гибрид: дешёвое озеро плюс табличный слой с транзакциями и схемой поверх него.

Трансформация. Сырые данные почти бесполезны: их надо очистить, склеить, посчитать агрегаты и привести к удобной модели. Исторически это делали до загрузки (ETL), сейчас чаще — уже внутри хранилища (ELT), потому что современные движки достаточно мощные, чтобы гонять трансформации SQL-запросами прямо на месте.

Serving — подача. Готовые, проверенные, смоделированные данные отдаются потребителям: в BI-дашборды аналитикам, в feature store для ML, в API. Отдельный паттерн — reverse ETL: возврат посчитанных данных обратно в продуктовые системы (например, сегмент пользователей — в систему рассылок).

На стадии хранения и трансформации появляется ещё одно понятие, без которого не обойтись — слои. Сырьё кладут как есть в «бронзовый» слой (его не трогают, он архив правды от источника). Очищенные и приведённые к единым типам данные — в «серебряный». Готовые бизнес-витрины, по которым строят дашборды — в «золотой». Это не догма, а удобная дисциплина: при ошибке в логике всегда есть нетронутое сырьё, из которого можно пересчитать всё остальное, и понятно, на каком слое искать проблему.

ETL против ELT: почему сместился порядок букв

Это не вкусовщина, а следствие экономики железа. Раньше хранилище было дорогим и медленным, поэтому данные сначала трансформировали на отдельном сервере и только чистый результат грузили внутрь — Extract, Transform, Load. Сегодня облачные хранилища дёшевы и масштабируются почти мгновенно, поэтому выгоднее сначала залить сырьё как есть, а трансформировать уже внутри — Extract, Load, Transform.

Практический выигрыш ELT в том, что сырьё остаётся в хранилище. Изменилась бизнес-логика — пересчитываете витрины из того же сырья, не дёргая источник заново. Этот сдвиг и породил современный стек, центром которого стал dbt.

Современный стек: кто за что отвечает

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

Две вещи, которые важно не перепутать. Первое: оркестратор вроде Airflow не двигает данные сам, он лишь говорит другим задачам, когда и в каком порядке стартовать. Второе: Iceberg, Delta и Hudi — это не базы данных, а табличные форматы, которые добавляют файлам в озере свойства настоящих таблиц. Именно они делают возможным lakehouse.

Минимальный Airflow-пайплайн выглядит так — обратите внимание, что код описывает только порядок шагов, а не саму обработку:

from airflow.decorators import dag, task
from datetime import datetime

@dag(schedule="@daily", start_date=datetime(2026, 1, 1), catchup=False)
def daily_orders():
    @task
    def extract():
        return fetch_orders_since_last_run()

    @task
    def load(rows):
        write_to_warehouse(rows, table="raw.orders")

    load(extract())

daily_orders()

А трансформация поверх загруженного сырья живёт отдельно, на стороне dbt, и описывается обычным SQL:

-- models/marts/daily_revenue.sql
select
    date_trunc('day', created_at) as day,
    count(*)                      as orders,
    sum(amount)                   as revenue
from {{ ref('raw_orders') }}
where status = 'paid'
group by 1

DE против DA, DS и ML Engineer

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

Грубое, но рабочее правило: дата-инженер строит трубы, аналитик пьёт из крана, дата-сайентист ищет в воде закономерности, ML-инженер строит насосную станцию, которая качает воду обратно в продукт. Дата-инженер — тот, без кого у остальных трёх просто нет чистых данных.

В компании на 10 человек все четыре роли часто совмещает один специалист, который и трубы тянет, и дашборды рисует. По мере роста объёмов и команды роли расходятся: сначала из общей кучи выделяется аналитик, затем — отдельный дата-инженер, когда пайплайнов становится слишком много, чтобы поддерживать их между делом. Поэтому вакансия «дата-инженер» в стартапе и в крупном банке — это две разные работы: в первом случае ближе к фуллстеку по данным, во втором — узкая специализация на платформе и инфраструктуре.

С чего начать

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

1. SQL до автоматизма. Это рабочий язык всей профессии. Не только SELECT, а JOIN, агрегации, оконные функции и понимание, почему запрос медленный.
2. Python на уровне скриптов. Чтение API, парсинг файлов, работа со списками и словарями. Без академизма — ровно столько, чтобы писать задачи в пайплайне.
3. Один оркестратор. Возьмите Airflow и соберите на нём один настоящий ежедневный пайплайн с зависимостями и перезапусками. Не пять инструментов — один, но до конца.
4. Один движок хранения. Один warehouse (например, ClickHouse или BigQuery) и один способ трансформации (dbt). Соберите цепочку «источник → загрузка → витрина → дашборд» целиком.

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

Когда этот скелет собран руками хотя бы раз, всё остальное укладывается на готовую карту: Kafka — когда понадобится стрим, Spark — когда данные перестанут влезать в один движок, Iceberg — когда озеру понадобятся транзакции. А чтобы не учить эти концепции вразнобой по статьям, есть бесплатный курс Data Engineering для джунов: он проходит ровно по этой карте — от источников и форматов хранения до ELT, dbt и современного стека — и даёт ландшафт, после которого можно осознанно углубляться в конкретные технологии. Все материалы и направление целиком живут в разделе направления Data.

Куда дальше

Дата-инженерия — это не про знание двадцати инструментов, а про умение видеть путь данных целиком и держать его надёжным. Источники, ingestion, хранение, трансформация, serving — пять слов, в которые укладывается любая платформа. Освоив этот каркас и собрав один сквозной пайплайн руками, вы будете понимать чужие архитектуры с первого взгляда и осмысленно выбирать инструменты под задачу, а не под хайп.

Хороший следующий шаг — пройти бесплатный курс Data Engineering для джунов. Он полностью бесплатный, RU-first, с интерактивной песочницей, где запросы и пайплайны можно запускать прямо в браузере, не настраивая ничего у себя. Это самый короткий путь от «понимаю в теории» к «собрал сам».