Airflow в 2026? На каком движке построить DWH

Эта статья для владельцев бизнеса, директоров e-commerce и техдиров, которые торгуют на маркетплейсах и думают о своём хранилище данных.

Мы работаем с компаниями, у которых суммарный оборот по маркетплейсам от 100 млн ₽ в год. Ниже этой планки, честно сказать, полноценный DWH редко окупается. Выше — уже больно жить в Excel, выгрузках из кабинета и «сводной табличке, которую делает Вася».

В этой статье объясню, что происходит внутри ETL-движка, зачем вообще нужен Airflow, чем он отличается от простого cron и почему дата-инженер не должен сидеть у вас в штате фулл-тайм годами.

1. Зачем вообще нужен отдельный движок для ETL

Чтобы хранилище данных работало, нужно каждый день делать три простые вещи:

1. Забрать данные из источников: Ozon, Wildberries, Яндекс.Маркет, реклама, внутренняя бухгалтерия/ERP.
2. Привести их в порядок: почистить, разложить по таблицам, связать между собой.
3. Сложить в DWH — в то место, где аналитик или отчёт BI найдёт всё за секунды.

Вот этот конвейер и есть ETL-движок. Даже если сегодня вы «просто выгружаете CSV и загружаете в Excel», у вас уже есть ETL — просто он живёт в головах и руках сотрудников.

Проблема в том, что:

• люди устают, ошибаются и уходят,
• правила маркетплейсов меняются,
• API ломаются,
• а данные вам нужны каждый день и ночью.

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

2. Почему «systemd + cron» — это тупик, а не решение

Мы тоже когда-то начали с минимализма. Скрипты на Python, systemd-таймеры, немного логов в файлы — и поехали.

На старте это красиво:

• ничего лишнего,
• нет лишних зависимостей,
• админ понимает, что где запускается.

Но через несколько месяцев у вас уже не три скрипта, а сотни задач:

• вы тянете цены,
• остатки по FBO и FBS,
• транзакции и операции,
• рекламные расходы,
• ставки и карточки,
• отзывы, претензии и жалобы.

Каждый источник — со своей периодичностью и своим характером ошибок.

И вот здесь начинаются проблемы.

Что начинает болеть

• Логи. Они лежат в файлах. Чтобы понять, что сломалось, надо залезть на сервер, открыть правильный лог, вспомнить формат.
• Мониторинг. Хочется понять: «Сегодня всё собралось или нет?», а не лазить по каталогам и grep’ом искать “ERROR”.
• Повторный прогон периода. В январе Ozon внёс изменения в API. Полмесяца вы собирали данные неправильно. Теперь нужно пересчитать только январь. В systemd это превращается в магию с параметрами и руками в консоли.
• Зависимости. Скрипт транзакций должен запускаться только после того, как обновились справочники товаров. Cron и systemd не умеют в это по-человечески.

Даже если прикрутить Grafana и Prometheus, вы всё равно видите только «упало / не упало». Понять «где и почему» — отдельный квест.

Вывод. systemd и cron подходят как временное решение или для одной-двух простых задач. Но для стабильного DWH продавца маркетплейсов этого мало.

3. Почему не взять Enterprise-решение и забыть

На рынке полно больших красивых решений:

• Azure Data Factory
• Microsoft Synapse / Integration Services
• Snowflake с их пайплайнами
• Databricks и прочие крупные платформы

У них есть плюсы:

• удобный интерфейс,
• куча интеграций,
• готовые коннекторы.

Но есть три «но»:

1. Цена. Для оборота 100–500 млн ₽ в год это часто слишком тяжёлая пушка. Подписка, лицензии, консалтинг — счёт идёт на десятки и сотни тысяч евро в год.
2. Юрисдикция и доступность. Часть решений недоступна для компаний, связанных с Россией. Ограничения, санкции, вопросы комплаенса.
3. Избыточность. Вам не нужен Greenplum-кластёр, Spark-ферма и Kafka-зоопарк, если вы работаете с данными одной компании, а не всего рынка.

Наши клиенты обычно хотят простую, понятную и свою систему:

• которая живёт на их серверах или в их облаке,
• которую можно объяснить владельцу бизнеса за 10 минут,
• которую не страшно поддерживать несколько лет.

Отсюда логичный выбор — open-source движок, который можно развернуть, настроить и забыть.

4. Почему мы используем Airflow

Airflow — это открытый инструмент Apache для оркестрации ETL-процессов. Работает по простому принципу:

• вы описываете задачи на Python,
• объединяете их в DAG (граф),
• Airflow сам решает, что, когда и в каком порядке запускать.

Что важно для бизнеса:

• Есть UI. Не нужно заходить на сервер и читать логи в vim. Открыл браузер — видишь, какие задачи зелёные, какие красные.
• Видно дерево задач. Понятно, что за чем идёт: сначала справочники, потом транзакции, потом витрины.
• Есть история. Можно посмотреть, что происходило вчера, месяц назад, год назад.
• Есть перезапуск. Можно выбрать интервал (например, январь), нажать пару кнопок — и пересчитать только его.

Современный Airflow уже не выглядит как «страшная панель для хакеров». Интерфейс стал нормальным рабочим инструментом, который понимает даже менеджер: зелёное — хорошо, красное — плохо, на задачу можно нажать и прочитать, почему она упала.

5. Как Airflow решает реальные проблемы e-commerce

Возьмём Ozon.

Там десятки видов операций в отчётах: продажи, возвраты, списания, логистика, услуги, штрафы, комиссии. Документация не всегда полная. Часто ошибки описаны одной строкой или не описаны вовсе.

Что происходит в реальной жизни:

• вы написали код за пару часов;
• он работает на тесте;
• на проде начинает падать из-за новых редких ошибок и особых типов операций;
• половину времени вы тратите не на разработку, а на ловлю исключений.

Airflow сильно облегчает эту боль.

Примеры того, как он помогает

• Retry’и. Если Ozon временно возвращает ошибку или лимит запросов исчерпан, задача сама попробует ещё раз через заданный интервал.
• Разные ветки поведения. Можно описать логику: — если ошибка вот такая — попробуй другой API-ключ; — если вот такая — подожди и повтори; — если совсем критично — остановись и пошли уведомление.
• Уведомления. Упала задача по транзакциям — Airflow может отправить сообщение в Telegram или на почту ответственного.
• Чёткое место падения. Вы видите не просто «скрипт transactions.py упал». Вы видите: «задача “Загрузка транзакций за 2025-01-18” упала на шаге “Запись в таблицу fact_transactions” из-за такой-то ошибки».

Вместо хаоса вы получаете список конкретных задач, с которыми можно работать.

6. Для техдиров: что происходит под капотом

Для техдиров. Если кратко, мы используем Airflow как оркестратор поверх обычного Python-кода.

Типичный стек для продавца маркетплейсов:

• PostgreSQL для «операционного» слоя и части витрин;
• ClickHouse для тяжёлой аналитики по транзакциям и длинной истории;
• коннекторы к Ozon / Wildberries / рекламным сетям;
• Airflow управляет расписанием и зависимостями.

Почему без тяжёлой артиллерии вроде Greenplum и Kafka можно жить спокойно:

• мы работаем с данными одной компании, а не всего рынка;
• размеры данных обычно измеряются десятками/сотнями миллионов строк, а не миллиардами в день;
• нагрузка предсказуемая: ночные джобы, дневные дельты, иногда — ближе к real-time по узким местам.

Чаще всего хватает схемы:

• staging — сырые JSONB из API;
• core — нормализованные fact/ dim таблицы;
• marts — витрины под аналитику и отчёты.

Airflow при этом:

• запускает пайплайны по расписанию или по событиям;
• даёт единый слой наблюдаемости;
• позволяет безопасно дорабатывать DAG’и и возвращаться к старым версиям логики.

Нам важнее, чтобы система была простой и прозрачной, чем гипер-оптимальной и сложной.

7. Как устроено хранилище продавца Ozon (и чем тут помогает SCD2)

В хранилище маркетплейсов есть два типа таблиц:

1. Измерения (dim). Товары, бренды, категории, склады, партнёры.
2. Факты (fact). Транзакции, остатки, цены, рекламные показы/клики/расходы.

У измерений есть неприятная особенность: всё постоянно меняется.

• название товара правят маркетологи;
• карточка переезжает в другую категорию;
• меняется бренд, упаковка, поставщик.

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

Поэтому мы используем SCD-2 (slowly changing dimensions, тип 2):

• старая версия строки помечается как «историческая»;
• новая версия создаётся с актуальными данными и датами действия.

Выглядит страшно только на словах. На практике:

• в каждой dim-таблице немного объектов,
• изменения случаются не так часто,
• нагрузка на SCD-обновления невысокая.

Зато бизнес видит честную картину:

• как выглядел ассортимент год назад,
• какие бренды тогда были активны,
• какие цены были реально в тот период.

Airflow здесь нужен как «оркестратор, который не забудет»:

• сначала обновить измерения (SCD2),
• затем факты транзакций,
• затем витрины.

8. Что видит владелец бизнеса в итоге

После внедрения нормального ETL-движка и DWH у вас появляется не «таблица ради таблицы», а несколько очень конкретных эффектов:

1. Один источник правды. Больше нет споров «в Excel одно, в личном кабинете другое, в отчёте директора третье». Все смотрят в одни и те же витрины.
2. Прозрачная юнит-экономика. Можно честно посчитать: какой SKU в плюс, какой в минус, где маркетинг сжирает маржу, а где помогает.
3. Контроль остатков и заказов. Можно видеть, где вы «висящие» товары, где опасность out-of-stock, где наоборот излишки на складах.
4. Адекватная аналитика рекламы. Расходы, показы, клики, заказы и маржа оказываются в одной таблице, а не в пяти разных выгрузках.
5. Понятная картина по каналам. Ozon, Wildberries, Яндекс.Маркет и другие источники складываются в общую картинку, а не живут отдельными мирками.

И главное — вы перестаёте зависеть от отдельных людей и их файлов. Система становится частью инфраструктуры, как склад или бухгалтерия.

9. Сколько реально нужен дата-инженер

Самый частый страх: «Сейчас мы залезем в эту историю с DWH, и потом нам всю жизнь придётся держать дорогого дата-инженера на фулл-тайм».

Мы считаем, что это неправильная постановка вопроса.

Идеальная картина выглядит так:

1. 0–12 месяцев. Идёт активное внедрение:

   • проектирование архитектуры,
   • интеграции с маркетплейсами и внутренними системами,
   • построение DWH,
   • настройка Airflow и всех пайплайнов,
   • первые витрины и отчёты.

   Здесь действительно нужна плотная работа дата-инженера. Это инвестиционный этап.

2. После запуска. Система стабилизируется. Основные пайплайны работают, ошибки пойманы и обработаны, архитектура понятна.

   Дальше объём задач резко падает:

   • иногда подключить новый отчёт или API;
   • доработать схему под новый продукт;
   • оптимизировать тяжёлый запрос;
   • адаптировать систему под рост бизнеса.

В большинстве случаев для компании с оборотом от 100 млн ₽ в год достаточно около 200 часов работы дата-инженера в год.

Это примерно полтора месяца плотной занятости, растянутых на двенадцать месяцев.

Остальное время:

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

Важно честно проговорить это с самого начала:

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

10. Роль аналитиков: как экономить КАПЕКС и не зависеть от подрядчика

У многих компаний сейчас сильные аналитики. Они умеют:

• писать SQL;
• работать в BI-инструментах;
• понимать бизнес-вопросы.

Мы считаем неправильным строить систему, в которой аналитик ничего не может без дата-инженера.

Поэтому мы проектируем DWH и ETL так, чтобы:

• аналитик мог сам заводить новые витрины, не ломая архитектуру;
• типовые операции (новый KPI, дополнительный срез, фильтры) не требовали вмешательства дата-инженера;
• документация и схемы были понятны внутри компании.

Это экономия КАПЕКС и OPEX:

• вы платите за сложную работу архитектору/дата-инженеру,
• а дальнейшая эксплуатация обходится дешевле, потому что большую часть задач закрывают сотрудники, которые и так у вас в штате.

11. Для техдиров: как мы строим пайплайны в Airflow

Для техдиров. Немного конкретики.

DAG’и и переиспользуемые блоки

Мы стараемся, чтобы внутри DAG’ов:

• шаги были максимально типовыми;
• повторяющиеся куски логики оформлялись в общие функции и классы;
• конфигурация (какие отчёты тянуть, какие таблицы обновлять) жила отдельно от кода.

Так получается библиотека блоков:

• «забрать отчёт из Ozon»,
• «проверить лимиты API»,
• «загрузить в staging»,
• «обновить SCD2-измерение»,
• «пересчитать витрину».

DAG при этом становится не монолитом на 500 строк, а комбинацией понятных шагов.

Ошибки, лимиты и токены

Маркетплейсы любят:

• менять форматы отчётов;
• вводить новые типы операций;
• ограничивать число запросов в секунду.

Поэтому в DAG’ах мы:

• описываем retry-стратегии для разных типов ошибок;
• учитываем лимиты по API (например, не более N запросов в секунду);
• закладываем использование нескольких ключей с разными ролями, чтобы не блокировать аналитику.

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

12. Наш опыт: что мы уже пережили за вас

Мы строили пайплайны для разных компаний, которые торгуют на маркетплейсах. В процессе:

• столкнулись с неполной документацией Ozon и Wildberries;
• ловили редкие ошибки в операциях, о которых в доках не было ни слова;
• разбирались с лимитами и особенностями отчётности;
• понимали, что сначала код пишется за несколько часов, а вот вычищать исключения можно целый месяц.

На этой базе мы:

• собрали набор типовых блоков и подходов для Airflow;
• сформировали архитектуру хранилища, которая хорошо живёт именно в e-commerce;
• привыкли проектировать систему так, чтобы через год она не требовала тотальной переделки.

13. Чек-лист для владельца бизнеса перед решением

Если вы сейчас думаете о своём DWH и ETL-движке, попробуйте ответить на несколько вопросов:

1. Ваш оборот по маркетплейсам выше 100 млн ₽ в год? Если да — хранилище почти точно окупится.
2. Сегодня у вас есть один источник правды по выручке, марже и остаткам? Или в компании несколько разных таблиц «с настоящими цифрами»?
3. Вы можете открутить время назад и честно посмотреть, как выглядел ассортимент и цены год назад?
4. Что происходит, если сотрудник, который ведёт вашу Excel-таблицу, уйдёт? Система останется или рухнет?
5. Сколько людей и часов в месяц уходит на ручные выгрузки, своды, перепроверки?

Если на эти вопросы неприятно отвечать — вероятно, пора думать о нормальном DWH и движке для ETL.

Airflow — не единственный вариант. Но это разумный баланс между:

• контролем,
• прозрачностью,
• стоимостью владения.

Мы в Koveh Studio выбрали его как основной инструмент для оркестрации. И наша главная задача — не привязать вас к себе навечно, а так построить систему, чтобы через год она жила на 200 часов дата-инженера в год и усилиях ваших аналитиков.

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

Текст записан на диктофон, улучшен через ChatGPT-5.1 и отредактирован Даниилом Ковехом.