Эта статья для владельцев бизнеса, директоров 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 и отредактирован Даниилом Ковехом.