§ Архитектура — Оркестрация данных

Оркестрация данных и ETL — почему это разные вещи

Разбор без воды · для заказчиков и архитекторов

На совещаниях регулярно слышно: «у нас же есть SSIS — зачем нам ещё Airflow?» или обратное: «мы на Airflow, ETL нам не нужен». И то, и другое — путаница терминов. ETL-инструмент и оркестратор решают разные задачи. Разбираем, где граница, когда одного хватает, а когда без второго начинается хаос.

Коротко. — ETL-инструмент отвечает на вопрос «как переложить данные и преобразовать». Оркестратор — на вопрос «в каком порядке запустить шаги, что делать если один упал, по какому расписанию, как понять что всё отработало». Это не конкуренты — это два слоя, которые обычно работают вместе. SSIS+SQL Agent — классический пример «всё в одном» для Microsoft-стека. Airflow+dbt — классическое разделение для облака.

Что делает ETL-инструмент

ETL — Extract, Transform, Load. Аббревиатура из трёх глаголов, и каждый важен. Инструмент этого класса умеет:

Читать источник. База данных, файл на сетевой шаре, REST-API, очередь сообщений, выгрузка из 1С, Excel от бухгалтера.
Преобразовывать. Join нескольких потоков, фильтр, агрегация, lookup по справочнику, проверка качества, приведение типов, дедупликация.
Писать в целевую систему. DWH, Data Lake, готовый файл, плоская витрина для Power BI.

Обычно у ETL-инструмента есть визуальный редактор потоков или SQL-first подход. Типичные представители:

SSIS (Microsoft) — пакеты SSDT, Data Flow Task, Control Flow. Стандарт для SQL Server.
Pentaho Data Integration (бывший Kettle) — визуальный редактор, open source.
Apache NiFi — потоковая обработка, упор на data lineage.
dbt — технически ELT, но класс близкий. Трансформации на чистом SQL, версионируется в git, работает внутри базы.
Talend, Informatica PowerCenter, IBM DataStage — корпоративные тяжеловесы с лицензией.

А теперь — чего ETL-инструмент обычно не делает хорошо:

Сложные условные workflow. «Если файл X не пришёл до 10:00 — запустить альтернативную загрузку из резервного источника, а потом дёрнуть уведомление ответственному» — описывается неуклюже.
Цепочка из 15+ зависимых джобов, где одни стартуют по расписанию, другие — после успеха предыдущих, третьи — на появление файла.
Наблюдаемость за всем парком. Лог у каждого пакета свой. Увидеть картину целиком — только через отдельный dashboard, который ещё надо построить.

Это не баг — это зона ответственности. ETL-инструмент делает преобразование потока данных. Управлять парком из 40 потоков — задача другого класса.

Что делает оркестратор

Оркестратор — это дирижёр. Сам данные не трансформирует (или почти не трансформирует). Его работа — управлять запусками:

Расписание. Cron плюс зависимости.
Граф зависимостей (DAG, Directed Acyclic Graph). Джоб Б стартует только после успеха джоба А. Джоб Г ждёт и Б, и В.
Retry-политика. Упал — повторить N раз с экспоненциальной паузой. Если и после этого упал — позвать человека.
Условное выполнение. «Файл пришёл → запускай А, не пришёл к 10:00 → запускай B».
Fan-out / fan-in. Запустить 50 параллельных задач (например, загрузка по каждому региону отдельно), дождаться всех, потом запустить финальный аггрегат.
Backfill. Прогнать весь пайплайн за прошлые даты одной командой. Пропустили неделю — пересобрали неделю.
Мониторинг и алертинг. Dashboard со статусом всех джобов, алерты в Telegram/email/Slack, история запусков.
Управление переменными и секретами. Токены, креды, настройки среды — централизованно.

Что оркестратор обычно не делает сам:

Не преобразует данные. Он вызывает внешние инструменты (SQL-запрос, Python-скрипт, SSIS-пакет, dbt-модель), которые это делают.
Не знает бизнес-логику трансформаций. Для него это чёрные ящики с кодом возврата.

Типичные представители:

Apache Airflow — де-факто open-source стандарт последних лет. DAG описывается на Python.
Prefect — современная альтернатива, ставка на UX и гибридную модель (агенты запускают джобы локально, управление из облака).
Dagster — оркестратор + каталог данных в одной коробке. Хорош там, где важно видеть lineage и ассеты.
SQL Server Agent + SSIS — минималистичный оркестратор Microsoft-стека. Расписание, retry, email — встроено.
Azure Data Factory — cloud-native гибрид: ETL и оркестрация в одном. Граница размыта.
Control-M (BMC), ActiveBatch, Tidal — корпоративные тяжеловесы, исторически в банках, страховых и телекоме.
AWS Step Functions — serverless-оркестрация в облаке Amazon.

Где граница размыта

В теории всё чисто. На практике инструменты залезают на территорию друг друга, и это нормально.

SSIS — это ETL с минимальной оркестрацией. Precedence Constraints между тасками задают граф зависимостей внутри пакета. SQL Agent сверху даёт расписание и retry. Для 80% проектов среднего бизнеса этой связки хватает, и отдельный Airflow ставить незачем.
Azure Data Factory позиционируется как оркестратор, но имеет встроенные Mapping Data Flows и Copy Activity — это уже ETL. Можно делать всё внутри одного инструмента.
Airflow теоретически умеет трансформации через PythonOperator, BashOperator, SQLExecuteQueryOperator. На практике так делать не стоит — DAG раздувается, код трансформаций мешается с кодом оркестрации. Лучше вызывать внешний dbt/Python/Spark.
dbt делает трансформации в целевой базе, но сам он себя не запускает по расписанию — нужен оркестратор (dbt Cloud, Airflow, ADF, Dagster) сверху.

Практический вывод: «у нас SSIS, значит оркестратор не нужен» и «мы подняли Airflow, теперь ETL не нужен» — оба утверждения неверны. Верный вопрос: хватает ли возможностей оркестрации в моём текущем инструменте, и если нет — что болит.

Симптомы: когда одного ETL уже мало

Ниже — типовые жалобы, которые слышно на аудите ETL-парка у клиентов. Каждая — про недостающую оркестрацию:

Симптом	Диагноз
«У нас 40 пакетов, они запускаются по таймерам, но если ломается один — падает всё»	Нужен граф зависимостей
«Пропустили один час ночной загрузки — пересобираем вручную за неделю»	Нужен backfill
«Не знаем, успел ли джоб за ночь — утром открываем SSMS и проверяем глазами»	Нужен мониторинг
«Завели 7 копий одного пакета для разных регионов — каждую правим отдельно»	Нужна параметризация + fan-out
«Источник иногда недоступен — повторяем запуск руками»	Нужна retry-политика
«Хотим запускать на событие (появление файла на шаре) — SSIS сам не умеет»	Нужен event-driven оркестратор
«CFO спрашивает, сколько пайплайнов сейчас идут и когда закончат — отвечаем через 20 минут ручной проверки»	Нужен единый dashboard

Один-два симптома — живут многие. Пять и больше — оркестратор перестаёт быть опциональным.

Практический выбор по размеру

Решение зависит не только от симптомов, но и от масштаба. Три типичные ситуации.

Малый и средний бизнес: до 10 пакетов

SSIS + SQL Agent. Никакого отдельного оркестратора. Добавьте прослойку наблюдаемости — простую таблицу dbo.te_Журнал_загрузки в SQL, куда каждый пакет пишет старт/финал/ошибку, плюс одностраничный Power BI-отчёт поверх неё. Этого хватает, чтобы утром за 30 секунд понять, что прошло, а что нет.

Антипаттерн: на этом этапе разворачивать Airflow. Вы получите второй инструмент, который надо администрировать, обновлять, мониторить — а пользы на 10 пакетов от него больше, чем от SQL Agent, не будет.

Средний бизнес: 10–30 пакетов с зависимостями

SSIS + SQL Agent с мастер-пакетом. Один пакет верхнего уровня, который через Execute Package Task запускает остальные в нужном порядке, с условиями (Precedence Constraints) и централизованной обработкой ошибок. SQL Agent вызывает только мастер — внутри он уже разбирается сам.

Бывает и связка SSIS плюс Airflow как внешний оркестратор. Встречается, но в среднем бизнесе это скорее экзотика: ставить Airflow ради 25 SSIS-пакетов — избыточно.

Крупный бизнес: 50+ джобов, несколько технологий, распределённые команды

Здесь уже разделение неизбежно. ETL-инструменты разные (SSIS для SQL Server, dbt для трансформаций в базе, Spark для больших объёмов, Python для нестандартных источников), а оркестратор — один, сверху. Airflow, Prefect, Dagster или Azure Data Factory. Без этого слоя — хаос, где каждая команда пишет свой bash-скрипт на cron и свои email-уведомления.

Наш опыт на Microsoft-стеке

В большинстве проектов у нас связка SSIS + SQL Agent — это встроенный «ETL + оркестрация» для Microsoft-стека, и в 9 случаях из 10 её хватает. Когда начинает жать — первый шаг не Airflow, а мастер-пакет SSIS: один верхнеуровневый пакет, который оркестрирует остальные, логирует ход работы в отдельную таблицу и централизованно шлёт уведомления.

Полноценный Airflow, Azure Data Factory или Prefect мы разворачиваем только в двух сценариях:

Клиент уже в облаке, SQL Server не является центром вселенной, есть много Python-скриптов, Spark-джобов и внешних API.
Парк превысил 50 пайплайнов, несколько команд работают параллельно, и нужно единое управление плюс прозрачность для IT-директора.

Отдельный важный паттерн — связка SSIS как оркестратор + Python как специализированный ETL. SSIS делает всё, что умеет делать хорошо (расписание, зависимости, логирование в SSISDB, ветвление, email), а Python закрывает те источники, где встроенных Data Flow Task не хватает — нестандартные REST-API, кривые Excel-ы, парсинг XML с вложенностью, CAdES-подпись запросов. Паттерн разобран подробно в статьях SSIS + Python: параметризация через sys.argv и SSIS + C# Script Task с живым журналом.

Решающая таблица: что брать в какой ситуации

Сводно — по профилю стека и размеру:

Ситуация	Рекомендуемая связка
Microsoft-стек, до 20 пакетов, один SQL-сервер	SSIS + SQL Agent
Microsoft-стек, 20–50 пакетов, зависимости между ними	SSIS + SQL Agent + мастер-пакет
Смешанный стек (SQL + Spark + Python), on-premise	Airflow как оркестратор, SSIS/dbt/Python под ним
Облачный стек на Azure	Azure Data Factory + Azure Functions / Databricks
Облачный стек на AWS	Step Functions + Lambda / Glue / EMR
Команда с большими data-science workloads	Prefect или Dagster
Банк, телеком, страховая — batch-обработка по всем системам	Control-M или Tidal
dbt-only проект в облаке, простой расписанию	dbt Cloud

Главное, чего не надо делать — выбирать оркестратор «как у всех модных ребят на Хабре» вместо того, чтобы честно посмотреть на свой стек, размер парка и опыт команды. Airflow, который никто не умеет поддерживать, хуже SQL Agent, который понимают все.

Чек-лист: пора ли задумываться об отдельном оркестраторе

Проверьте по пунктам. Если отметили три и больше — время перерастать «ETL с cron-ом» и выносить оркестрацию в отдельный слой (или хотя бы в мастер-пакет SSIS):

Ручных действий по утрам («проверить, что всё прошло за ночь») — больше одного в неделю.
Один упавший пакет приводит к цепной реакции: другие не стартуют или стартуют с битыми данными, и никто этого не видит сразу.
Backfill за прошлые N дней занимает больше часа и делается руками в SSMS.
Пакетов в проде 20 и больше.
Пайплайны живут поверх нескольких систем — SQL, Python-скрипты, REST-API, иногда Spark.
Команда регулярно жалуется: «не видно, что прошло, а что нет, и где сейчас пайплайн».
Пришёл аудит или ИБ и спросил про журналирование и SLA — нечего показать.

Если отметили 0–2 пункта — всё нормально, оркестрация у вас уже есть (встроенная в SQL Agent или в мастер-пакет), и разворачивать Airflow не надо. Деньги и силы уйдут на поддержку нового инструмента без реальной выгоды.

Итог одной фразой

ETL — про что сделать с данными. Оркестрация — про когда, в каком порядке и что если сломалось. Это два слоя одной архитектуры. На Microsoft-стеке они чаще всего живут вместе в SSIS + SQL Agent. В cloud — расходятся: Airflow/ADF отдельно, dbt/Spark/Python отдельно. Выбор инструмента зависит не от моды, а от размера парка и состава стека.

Связанные материалы

SSIS + Python: параметризация ETL через sys.argv — как SSIS в роли оркестратора вызывает Python в роли ETL
SSIS + C# Script Task: оркестрация с живым журналом — мастер-пакет, который централизованно логирует и управляет запуском Python-модулей
Python внутри хранимой процедуры SQL Server — ещё один слой интеграции между ETL и кодом
Наша методология BI-проекта — где в общей архитектуре живут ETL и оркестрация