Инженер данных: что он строит и как освоить профессию

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

Хранилище, озеро, витрина — и где происходит преобразование

Хранилище данных (DWH) — база, куда данные попадают уже приведёнными к заданной структуре: схема продумана заранее, типы столбцов зафиксированы. Такие базы обычно колоночные, и выигрыш объясняется устройством диска: данные читаются блоками по 4–8 КБ, и в строковой базе вместе с нужным полем приезжает вся строка, а в колоночной «no unnecessary data is loaded» (ClickHouse).

Озеро данных (data lake) — объектное хранилище, куда файлы кладут почти как есть: выгрузки, логи, архивы, а схема применяется при чтении, а не при записи. Положить можно что угодно — в этом же слабое место: без каталога и правил именования озеро за год превращается в склад файлов с неизвестным содержимым. Витрина (data mart) — таблица под конкретный круг вопросов, и напрямую из источников её не строят: staging повторяет источник один к одному, промежуточный слой собирает общую логику, marts объединяют это в сущности бизнеса (dbt Docs).

Отсюда развилка ETL и ELT. Классический порядок предполагает преобразование на отдельном движке до загрузки; ELT грузит сырьё как есть и считает всё средствами базы — dbt данные не перемещает, а превращает SQL-запросы в таблицы внутри хранилища (dbt Docs). Сырой слой остаётся на месте, и ошибку в логике исправляют пересчётом из исходников. ETL живёт там, где преобразовать нужно раньше загрузки: персональные данные маскируют по дороге.

Схема решает: модель данных и цена ошибки в ней

Самая живучая схема аналитического хранилища — «звезда»: измерения описывают сущности (товары, клиентов, сотрудников, календарь), факты хранят события — заказы, платежи, отгрузки (Microsoft Learn). Первое ключевое решение — гранулярность факта: строка на заказ, на позицию заказа или на день и товар дают три разные таблицы, и детализацию держат согласованной. Смешаете строки на заказ и строки на день — суммы начнут двоиться, причём выборочно. Второе — изменения в измерениях: тип 1 перезаписывает значение, тип 2 хранит версии с суррогатным ключом, датами действия и флагом текущей записи.

Разницу показывает учебный пример (ситуация вымышленная). Компания закрыла квартал и согласовала премии по отчёту о выручке в разрезе регионов, а через месяц тот же отчёт за тот же период показал другие числа: у одного региона выручка выросла на несколько миллионов, у другого на столько же упала, и ошибок в логах при этом нет.

Инженер начинает с модели, а не с кода. Измерение «сотрудник» оказывается таблицей типа 1: при ночной загрузке справочника строка перезаписывается целиком, вместе с регионом. Двоих менеджеров недавно перевели, и витрина, присоединяющая факты по табельному номеру, переклеила всю их историю продаж на новые регионы. Дальше по шагам: измерение переводится на тип 2, в факт кладётся ключ той версии сотрудника, которая действовала в день сделки, история восстанавливается из журнала кадровой системы, а в витрину добавляется проверка на единственность текущей версии. Закрытые периоды после этого перестают меняться сами по себе.

Оркестрация: почему «за вчера» — это не вчера

Десяток загрузок ещё живёт в cron. Дальше нужен оркестратор: он описывает зависимости задач, повторяет упавшие шаги и позволяет пересчитать прошлый период. Стандарт отрасли — Apache Airflow.

Здесь спрятана деталь, на которой спотыкаются почти все новички. Запуск привязан не к моменту времени, а к интервалу данных, и планировщик стартует его после того, как интервал закончился: «A Dag run is usually scheduled after its associated data interval has ended». Логическая дата обозначает начало интервала, а не момент исполнения — «denotes the start of the data interval, not when the Dag is actually executed» (Apache Airflow).

Следствие безобидно ровно до первого пересчёта. Загрузка с логической датой 20 сентября физически стартует в ночь на 21-е. Напишете внутри задачи WHERE date = CURRENT_DATE — при штатной работе всё сойдётся случайно, а при пересчёте прошлой недели каждая из семи задач возьмёт сегодняшние данные и запишет их в семь разных партиций. Таблица будет выглядеть заполненной, ошибки не появится.

Оттуда же требование идемпотентности: задачу трактуют как транзакцию, INSERT заменяют на UPSERT и пишут в конкретную партицию (Airflow Best Practices). Пропущенные интервалы по умолчанию не досчитываются, так что после недельной остановки дыра в данных останется (scheduler.catchup_by_default=False).

Программы, где оркестратор — рабочий инструмент, а не строчка в перечне тем, видно по стеку и объёму практики. Например, курс «Инженер данных» Яндекс Практикума рассчитан на 6,5 месяца и 540 часов, из которых 340 — практика: витрины с инкрементальной загрузкой, ETL в Airflow, хранилище на Vertica, озеро на HDFS и Spark, потоки в Kafka. Вход предполагает SQL, pandas и ООП.

Качество данных и контракт с поставщиком

Пайплайн без ошибок ещё ничего не доказывает: таблица могла приехать пустой, а суммы — удвоиться. Поэтому в загрузку встраивают проверки на уникальность ключа, пропуски и отклонение объёма. Следующий уровень — контракт на схему. В dbt его включают явно: инструмент сверяет столбцы и типы с объявленным, переносит имена, типы и ограничения в DDL таблицы, и модель либо соответствует контракту, либо не собирается — «or it will fail to build» (dbt Docs). В той же таблице документации спрятано то, о чём редко предупреждают: по-настоящему проверяется только not_null, а primary_key, unique и foreign_key можно объявить, но контролировать их платформа не будет. Объявленный первичный ключ от дублей не спасает — за уникальность отвечает отдельный тест.

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

Потоки: когда партий уже не хватает

Большая часть аналитики живёт на суточных и часовых загрузках. Поток нужен там, где решение принимается быстрее, чем приедет следующая партия: блокировка подозрительной операции или пересчёт цены. Цена перехода измерима: в Spark Structured Streaming микропакетный режим даёт задержку порядка 100 мс и обработку ровно один раз, непрерывный — около 1 мс, но с гарантией «не менее одного раза» (Apache Spark). Последняя гарантия означает, что событие может прийти дважды и потребитель обязан это пережить. С учётом опоздавших событий рядом с потоком живёт ночной пересчёт.

Хранение и вычисления как инженерное ограничение

Счёт за инфраструктуру — часть инженерной задачи. Parquet хранит данные по столбцам и блоками: файл делится на группы строк, внутри каждой столбец лежит отдельным куском со своей статистикой; рекомендованный размер группы — от 512 МБ до 1 ГБ, страницы — 8 КБ (Apache Parquet). Движок читает только нужные столбцы и пропускает блоки по минимальным и максимальным значениям, а CSV читается целиком.

Второй рычаг — класс хранилища: чем холоднее, тем дешевле хранение и тем дороже операции. Но у ледяного класса в Yandex Object Storage минимальное тарифицируемое время хранения — 12 месяцев, и при удалении объекта раньше оставшиеся месяцы всё равно оплачиваются (Yandex Cloud). Политика, которая через месяц перекладывает логи в лёд, а через полгода удаляет, обойдётся дороже, чем холодный класс.

Чем и на чём это делают в России

Корпоративные хранилища долго строили на Greenplum — массивно-параллельной СУБД с открытым кодом. В 2024 году Broadcom прекратил её развитие в прежнем виде, и продолжением стали независимые форки: Arenadata DB, входящая в реестр российского ПО (запись №6481) и сертифицированная ФСТЭК по четвёртому уровню доверия, строится на Greengage DB под лицензией Apache 2.0 (Arenadata). Знания по Greenplum не обесценились, но версии и расширения у российских сборок свои.

Граница с соседними ролями и трудные стороны работы

Аналитик данных отвечает на вопрос бизнеса и работает с готовыми витринами; Data Scientist строит модель, ML-инженер отвечает за её работу в проде. Инженер данных отвечает за то, чтобы данные доехали, сошлись по ключам и не стоили как отдельный отдел. Признак простой: Airflow, партиционирование и срок готовности витрины к утру — это инженерия; дашборды и A/B-тесты — аналитика.

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

Сколько платят

Самый прозрачный по методике публичный источник — калькулятор «Хабр Карьеры»: анкеты специалистов за скользящее окно в шесть месяцев, общий доход с премией, медиана как основной показатель (методика сервиса).

По специализации «Инженер по данным» на сентябрь 2026 года медиана по всем уровням — 248 083 ₽ в месяц, выборка 387 анкет. По грейдам: Junior — 133 833 ₽ (64 анкеты), Middle — 234 166 ₽ (195), Senior — 361 666 ₽ (74) (Хабр Карьера). Регионального разреза сервис не даёт: данные относятся к России в целом и смещены к крупным городам. Соседи по цеху на ту же дату: у аналитика по данным медиана 170 416 ₽ (1 125 анкет), у ML-разработчика — 227 500 ₽ (564). Медиана по всему IT за первое полугодие 2026 года, по отчёту «Хабр Карьеры» на 45 226 зарплат, — 191 000 ₽: 235 000 ₽ в Москве и 160 000 ₽ в регионах (Хабр, июль 2026).

Оговорки обязательны. Это самооценки работающих специалистов, а не суммы из объявлений о вакансиях, где диапазоны шире и указаны до вычета налога; выборка в несколько десятков анкет на грейд невелика. Проверяйте цифры сами: фильтруйте вакансии по региону и опыту, смотрите медиану, различайте «до вычета» и «на руки». Онлайн-курс не гарантирует ни трудоустройства, ни дохода.

С чего начинать и что показать работодателю

База — SQL, и глубже, чем обычно предполагают: оконные функции, соединения на больших таблицах, чтение плана запроса. Дальше Python на уровне скриптов и API, командная строка Linux, git, Docker.

Порядок освоения удобно выстроить так. Сначала модель данных: возьмите открытый набор и спроектируйте звезду, честно выбрав гранулярность факта. Потом напишите скрипт загрузки и убедитесь, что повторный запуск не создаёт дублей. Затем перенесите его в Airflow с партициями и датой из интервала запуска, добавьте Parquet и тесты качества. Kafka и Spark оставьте напоследок.

Когда базы ещё нет, длинная программа с нуля даёт более ровный маршрут, чем набор коротких курсов. Про курс «Инженер данных с нуля» от Karpov.Courses на странице обзора указаны цена 99 000 ₽ вместо 118 200 ₽ и рассрочка, а длительность и модули не раскрыты — уточняйте их на сайте образовательной платформы.

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

Тем, у кого SQL и Python уже рабочие, подходят программы без вводной части: курс «Инженер данных» от Karpov.Courses заявлен на странице обзора за те же 99 000 ₽ при базовой цене 129 200 ₽, модули там тоже не указаны.

Убедительнее сертификата один законченный проект в репозитории: схема хранилища с пояснением гранулярности, пайплайн в Airflow, корректно пересчитывающий прошлый период, тесты на уникальность и полноту. Хорошо читается и разбор учебной поломки: вы испортили входные данные и показали, какая проверка сработала.

Сравнить программы по составу практики помогает рейтинг онлайн-школ по инженерии данных на Учи.Онлайн: семь школ с оценками по стоимости, практике, поддержке наставника и карьерной помощи.

Оценить готовность можно по одному вопросу. Умеете написать запрос с нужной метрикой, но не знаете, откуда берётся таблица, в которую он смотрит, — не хватает инженерной половины. А если вам интереснее ответ, чем доставка, честнее идти в аналитику: инженер данных редко узнаёт, что показали его цифры.