Learning Platform
Глоссарий Troubleshooting
Урок 03.01 · 20 мин
Начальный
РольОбязанностиКарьера

Кто такой Data Engineer

Data Engineer — это инженер, который доставляет данные из систем-источников в системы-потребители, по дороге их очищая, преобразуя и моделируя. Если коротко: DE строит инфраструктуру данных, на которой работают аналитики, ML-специалисты и продуктовые команды.

Если ещё короче — DE заведует трубами. Аналитик пишет SQL и делает дашборды, ML-инженер строит модель, продукт-менеджер смотрит метрики — все они получают данные из систем, которые построил DE.


Что DE делает в типичный день

NOTE

Дальше будет много новых слов: Airflow, DAG, Parquet, Snowflake, Kafka, idempotency и десяток других. Это нормально и так и задумано — перед тобой карта профессии, а не словарь, который нужно вызубрить прямо сейчас. Просто прочитай сцену как историю и почувствуй ритм работы. Каждый из этих терминов мы спокойно разберём дальше в курсе — отдельным уроком или модулем. Сейчас задача одна: увидеть, из чего складывается день DE, а не понять каждое слово. Самые важные термины из сцены собраны в мини-словарике сразу под ней — наведись на любую карточку, чтобы увидеть короткое объяснение.

Сценарий: ты пришёл в продуктовую компанию (e-commerce, 200 человек). Понедельник, 10 утра.

10:00 — стендап. Команда из 5 человек. У одного аналитика вчера сломался дашборд по продажам — в одной из таблиц вместо order_total пришли NULL. Ты обещаешь разобраться к обеду.

10:30 — разбор инцидента. Открываешь Airflow, видишь, что вчера падал DAG orders_daily. В логах — ошибка от source API: «rate limit exceeded». Стрингуешь причину: в воскресенье катался релиз, который повысил частоту вызовов API в 5 раз. Чинишь retry-логику и backoff. Запускаешь ручной ребэкап.

12:00 — стейкхолдер пишет в Slack: «Нам нужны данные о возвратах в дашборде. Сейчас их там нет». Ты смотришь источники — возвраты живут в отдельном микросервисе, в Postgres. Ingestion для них ещё не настроен. Заводишь задачу в Jira, оцениваешь в 3 дня.

13:00 — обед.

14:00 — code review. Коллега-DE прислал PR в dbt-репозиторий: новая dimension table dim_customer_segment. Ты смотришь модель, тесты и lineage. Замечаешь, что в join нет is_active = true — попадут удалённые сегменты. Комментируешь.

15:30 — собственная разработка. Допиливаешь интеграцию с Stripe. Webhook от Stripe прилетает в RabbitMQ, оттуда консьюмер пишет в S3 как Parquet-файлы, дальше Airflow подхватывает и грузит в Snowflake. Сегодня пишешь idempotency-логику: если webhook прилетел дважды, не дублировать в DWH.

17:00 — встреча с DS-командой. Они хотят real-time feature store для модели рекомендаций. Обсуждаете: Kafka + Flink или Spark Structured Streaming? Решаете прототипировать на Kafka.

18:00 — конец дня. Закрываешь ноут.

Это средний день DE в продуктовой компании. В банке/телекоме больше регламентов и регуляторики. В стартапе — больше пожаров и меньше команды.

Мини-словарик к сцене

Не запоминай — просто наведись на карточку, если слово зацепило. Рядом указано, в каком модуле курса термин разбирается подробно.

Слова из сцены простыми словами
Airflow / DAG
source API / rate limit
retry / backoff
Parquet
Snowflake / DWH
RabbitMQ / очередь
Kafka / Flink / Spark
idempotency

Основные зоны ответственности

Что входит в работу DE
Ingestion
Storage и хранилища
Transformation
Orchestration
Data Quality
Infrastructure

В реальности одна команда не покрывает всё — есть деление. В крупных компаниях:

  • Analytics Engineer — фокус на transformation (dbt) и моделировании.
  • Platform Data Engineer — Airflow, инфра, K8s, cost.
  • ML Data Engineer — feature stores, pipelines для моделей.
  • Streaming Engineer — Kafka, Flink, real-time.

В стартапах один человек делает всё. Это и плюс (быстро учишься), и минус (выгораешь).


Зачем компании DE

Любая компания, где «больше одного источника данных» и «больше двух человек смотрят отчёты», рано или поздно нанимает DE. Причины:

1. Данные размазаны по системам

У типичной компании среднего размера — 10-50 источников: CRM (Salesforce), биллинг (Stripe), маркетинг (Google Ads, Facebook Ads), продуктовая БД (Postgres), события (frontend telemetry в Segment), поддержка (Zendesk). Каждый источник — своя схема, свой API, свой rate limit.

Без DE: аналитик качает CSV из Salesforce, склеивает в Excel с экспортом из Stripe, дашборд в Tableau падает на 100k строк, обновление занимает день. С DE: всё в одном DWH, dbt-модели, дашборд обновляется за минуту.

2. Объёмы переросли «один Postgres»

Когда у тебя 100 транзакций в сутки — хватает SELECT по production-БД. Когда 100 миллионов в сутки — production падает от каждого тяжёлого SQL. Нужен отдельный DWH для аналитики, и кто-то должен туда грузить.

3. ML и продуктовые фичи требуют свежие данные

Рекомендации, антифрод, динамические цены — это всё требует сырых событий + быстрых витрин. Без DE-инфраструктуры (Kafka + feature store) ML-команда не запустит модель в прод.

4. Регуляторика и GDPR

«Удалить все данные клиента X» — простая фраза. Технически это значит: найти его записи в 50 источниках и DWH, удалить, доказать аудиту, что удалил. Это работа DE и Data Governance.


Карьерные грейды (обзор)

ГрейдЧто делает
JuniorПишет таски в Airflow по дизайну старших, читает SQL, чинит мелкие баги
MiddleСамостоятельно проектирует пайплайны end-to-end, ревьюит код
SeniorПроектирует архитектуру для команды, ведёт онбординг джунов
Staff / PrincipalАрхитектура для всей компании, выбор технологий, межкомандные проекты

Подробнее — в модуле 18-de-career.

Apache Airflow: оркестратор пайплайнов DE Apache Spark: архитектура distributed compute

Чем DE НЕ занимается (обычно)

Чтобы убрать путаницу:

NOTE

DE — это не:

  • бизнес-аналитик, который пишет дашборды (это Data Analyst или Analytics Engineer);
  • ML-инженер, который тренирует модели (это ML Engineer);
  • DBA, который тюнит индексы в production-Postgres (это Database Administrator);
  • DevOps, который держит Kubernetes (хотя часто пересекается).

DE работает на стыке этих ролей. От DBA — понимание баз. От DevOps — инфра. От Analytics — SQL и моделирование. От ML — потребности фичей.

SQL: реляционная модель, которую DE должен знать Python для Data Engineer: старт

Зарплатные ориентиры (Россия, 2026)

Грубо:

  • Junior: 100-180k рублей
  • Middle: 200-350k рублей
  • Senior: 350-500k рублей
  • Staff / Principal: 500k+

В международных компаниях / удалёнке — в 2-3 раза выше. В банках и телекоме обычно ниже, чем в IT-продуктах.

Точные цифры зависят от стека: «знает Spark + Kafka + K8s» оплачивается выше, чем «только Airflow + Postgres».


Попробуй сам

  1. Открой LinkedIn / hh.ru. Найди вакансию «Data Engineer» в крупной компании. Выпиши 3 главных обязанности из описания. Совпадают ли они с тем, что описано в этом уроке?
  2. Прочитай один день из жизни DE выше. Что из этого тебя пугает или вдохновляет? Запиши — это сигнал, где тебе будет интересно (или нет).
Проверка знанийKnowledge check
Почему компании нанимают Data Engineer, а не возлагают эти задачи на бэкенд-разработчиков или DBA?
ОтветAnswer
Бэкенд-разработчики оптимизированы под низкую latency для пользовательских запросов и работу с OLTP-нагрузкой (короткие транзакции). Аналитические запросы — это другой профиль: большие объёмы сканирования, агрегации, неструктурированные данные. DBA отвечает за стабильность production-БД, и его убьёт мысль пускать туда аналитические запросы. DE специализируется на «трубах» данных между системами: ingestion из десятков источников, оркестрация, моделирование под аналитику, data quality. Это отдельная инженерная дисциплина с собственным стеком (Airflow, dbt, Spark, Kafka) и подходами (idempotency, batch, streaming). Без специалиста этого профиля данные либо размазаны по системам и недоступны, либо ломают production-БД.

Проверьте понимание

Результат: 0 из 0
Концептуальный
Вопрос 1 из 5. Какая зона ответственности НЕ входит в типичную работу Data Engineer?

Закончили урок?

Отметьте его как пройденный, чтобы отслеживать свой прогресс

Войдите чтобы оценить урок

Прогресс модуля
0 из 5