От хаоса в 1С к инкрементальному DWH: Postgres, Airflow, dbt и Kafka для быстрой аналитики

Представьте компанию, где основная операционная система – 1С. Если это вам знакомо, то вы легко поймете, с какими сложностями мы сталкивались в процессе получения данных для аналитики пару лет назад.

Вот как это выглядело:

"Репликация и сложности загрузки"

Проблема №1: Полная репликация. Раз в сутки мы копировали всю базу 1С в MS SQL Server. Этот процесс занимал 3-4 часа и часто завершался сбоями из-за нагрузки на 1С, сетевых проблем или других факторов. Утром аналитики нередко задавались вопросом: "Данные сегодня загрузились?".
Нагрузка на систему: Полная выгрузка создавала значительную нагрузку на рабочую систему 1С, особенно в конце дня, что вызывало недовольство пользователей.
Проблема №2: Отсутствие инкрементальной загрузки. Данные в 1С часто корректировались задним числом, что делало невозможным использование инкрементального подхода. Каждый раз приходилось обрабатывать весь объем данных с самого начала, что существенно замедляло процесс и создавало проблемы с производительностью.
Итог этапа: Долгий, нестабильный и ресурсоемкий процесс, ограниченный фундаментальной проблемой отсутствия инкремента при изменяемой истории.

"Сложные SQL-скрипты для обработки данных"

Если репликация завершалась успешно, данные передавались на обработку в самописный SQL-скрипт. Мы столкнулись с архитектурными нагромождениями: код был перегружен логикой, что делало его нечитаемым. Попытки воссоздать структуру метаданных 1С превращали SQL-запросы в запутанный лабиринт из десятков JOIN-ов. Внести изменения или добавить новую витрину было задачей на несколько дней с непредсказуемым результатом.
Производительность: Скрипт обрабатывал полный объем данных, что занимало еще 2-3 часа. Причина – отсутствие инкрементального подхода.
Итог этапа: Медленный, сложный и рискованный процесс, который был лишь началом цепочки обработки.

KNIME: Инструмент не для нашего масштаба

Основная трансформация данных происходила в бесплатной версии KNIME – ключевой ETL-платформе на тот момент. Здесь формировались финальные витрины, но исходные данные всегда были полными из-за отсутствия инкремента.
Ресурсоемкость: Запуск процессов в KNIME требовал до 40 ГБ оперативной памяти, что в сочетании с бесплатной версией и сложными трансформациями приводило к деградации производительности. Несмотря на всю мощность KNIME, в нашей конфигурации он стал узким местом, так как не был рассчитан на постоянную переработку колоссальных объемов данных без инкремента.

Итоговые проблемы

Задержки данных: Вся цепочка обработки (репликация 3-4 часа, SQL-скрипты 2-3 часа, тяжелый ETL в KNIME) приводила к тому, что свежие данные утром были недоступны.
Аналитикам приходилось работать с данными двухдневной давности. Доверять цифрам стало невозможно без длительных ручных проверок. BI-инструментам требовалось либо прямое подключение к реплике (что «вешало» базу), либо томительное ожидание витрин из KNIME
Качество данных: Сложность процессов и необходимость пересчета всего объема данных делали логику непрозрачной, а ошибки – трудноуловимыми. Доверять цифрам можно было только после долгих проверок.
BI-инструменты: Power BI Report Server приходилось либо подключаться напрямую к реплике MS SQL (с риском для производительности и несогласованности данных), либо ждать витрины из KNIME, которые были не всегда актуальны и качественны.
Итог: Разрозненные отчеты, несогласованные метрики и постоянные споры о достоверности данных.

Итог сложного периода:

Данные устаревшие: Без инкремента свежесть данных была недостижима.
Ненадежность: Сбой на любом этапе означал отсутствие данных утром.
Высокие затраты ресурсов: До 40 ГБ ОЗУ и часы CPU на полный пересчет, плюс нагрузка на 1С.
Сложность поддержки: Изменения в SQL или KNIME требовали много времени и несли риски.
Архитектурные ограничения: Отсутствие инкремента при исторических правках делало систему неэффективной.
Напряжение в команде нарастает: аналитики сталкиваются с задержками и ошибками, из-за чего срываются сроки подготовки важных отчётов. Дата-инженеры борются с нестабильностью процессов, что приводит к частым сбоям и необходимости повторной обработки данных. Пользователи 1С наблюдают замедление системы, что вызывает у них недовольство и снижение производительности.

Всё это приводит к серьёзным последствиям:

Задержки в принятии решений на основе данных из-за некорректных или запоздалых отчётов.
Задержки в оперативном планировании и координации проектов.
Снижение общей эффективности работы отделов.
Прямое негативное влияние на выручку бизнеса из-за упущенных возможностей и снижения качества обслуживания клиентов.
Ситуация может привести к потере важных контрактов и снижению конкурентоспособности компании на рынке.

Почему я так подробно описываю эти трудности? Чтобы показать, с какими вызовами мы столкнулись и как их преодолели. Если вы узнаете в этом описании свою ситуацию, оставайтесь с нами – дальше расскажем, как нашли выход из этого положения.

Осознание проблемы: Целевая архитектура платформы

Осознав ограничения прежней архитектуры, мы определили четкие требования к новой системе. Это были не просто пожелания, а ключевые принципы, необходимые для создания эффективной data-платформы:

Надежность как приоритет: Данные должны обновляться ежедневно без сбоев. Утром не должно возникать вопросов вроде "Данные загрузились?".
Скорость как стандарт: Цикл ETL должен стать значительно короче, чтобы обновления могли происходить чаще, чем раз в сутки.
Качество как основа: Уникальные и неизменяемые идентификаторы для всех сущностей, согласованность данных между витринами, хранение истории изменений ключевых атрибутов (SCD2) для анализа трендов и аудита.
Удобство разработки и поддержки: Модульная структура, понятный код, простота внесения изменений, чтобы работа дата-инженеров стала более эффективной.
Удобство для аналитиков: Единая точка доступа к свежим и готовым для анализа витринам с понятной документацией. Никаких прямых запросов к необработанным данным.
Прозрачность и документация: Четкое понимание структуры данных – что где находится, откуда берется и как связано. Поиск и анализ должны занимать минуты, а не часы.

Строим фундамент: Экстрактор 1С в BI и инкремент – первые шаги к изменениям

Первым важным шагом стало создание стейдж-слоя (Staging). Нам нужно было устранить фундаментальную проблему прошлого – отсутствие инкрементальной выгрузки из 1С.
Полный пересчет базы больше не был приемлемым вариантом.
Мы быстро поняли, что писать свой надежный механизм CDC (Change Data Capture) для 1С с нуля — это месяцы разработки, тестирования и отладки краевых сценариев. Бизнес не готов был столько ждать.

Поэтому мы пошли по пути использования готового решения и выбрали инструмент "Экстрактор 1С в BI" от "Денвик Аналитики", который стал основой новой архитектуры.

Почему именно этот инструмент?

Инкрементальность: Инструмент умеет отслеживать изменения в 1С, включая корректировки задним числом, и выгружает в стейдж только дельты (новые и измененные записи). Это решило ключевую проблему старой системы.
Удобство настройки: Выгрузка больше не требует сложных SQL-скриптов. Таблицы и поля для стейджа настраиваются через понятный интерфейс, что ускоряет и упрощает процесс.

Преимущества для базового слоя:

Снижение нагрузки: Минимальное воздействие на рабочую систему 1С и сеть, так как выгружаются только изменения.
Скорость: Выгрузка дельт занимает минуты или десятки минут вместо часов.
Стабильность: Процесс стал более предсказуемым и надежным.
Технология стейджа: Мы выбрали PostgreSQL – надежное и хорошо интегрируемое решение. Данные из 1С через Экстрактор 1С поступают сюда в "сыром" виде, но уже с возможностью инкрементального обновления.

Сердце системы: DDS-слой и Airflow – порядок и управление данными

Стейдж-слой – это только начало. Нам требовался следующий уровень, где "сырые" инкрементальные данные превращаются в чистые, согласованные бизнес-сущности с сохранением истории изменений.
Так появился DDS (Detail Data Store) слой, также реализованный на PostgreSQL.

Задачи DDS:

Уникальные идентификаторы: Каждой сущности (заказ, клиент, товар) присваивается неизменяемый ID, понятный бизнесу (суррогатный или стабильный бизнес-ключ).
Очистка и стандартизация: Приведение данных к единым форматам, устранение несоответствий.
Сохранение истории: Использование Slowly Changing Dimensions Type 2 (SCD2) для ключевых атрибутов (например, изменение статуса заказа или цены товара), чтобы отслеживать, когда и что именно изменилось.

Инструмент оркестрации: Apache Airflow. Почему именно он?

Централизованное управление: Весь процесс преобразования данных из стейджа в DDS управляется через единый DAG (Directed Acyclic Graph) в Airflow.
Принципы обработки:
Инкрементальность: Обрабатываются только новые или измененные данные из стейджа (благодаря дельтам от данного продукта), что обеспечивает масштабируемость при росте объемов.
Эффективность: Один DAG управляет обновлением около 50 таблиц в DDS-слое. Логика структурирована внутри DAG, что упрощает контроль и делает процесс более прозрачным по сравнению с разрозненными скриптами или проектами KNIME.
Надежность: Airflow предоставляет инструменты для мониторинга, алертинга и повторного выполнения задач, гарантируя успешное завершение процессов.

Результат DDS-слоя: Чистые, согласованные бизнес-сущности с уникальными ID и полной историей изменений (SCD2), готовые для построения аналитических витрин. Это стало основой для качества и доверия к данным.

Выбор Airflow – это только первый шаг. Чтобы обеспечить надежность и плавное внедрение изменений в DDS-слой, мы разработали структурированный процесс разработки и деплоя:

Две изолированные среды:

Airflow-TEST: Развернута на Docker. Это среда для разработки и тестирования новых DAG'ов или изменений в существующих. Здесь можно безопасно проверять логику и выполнение задач на тестовых данных.
Airflow-PROD: Также на Docker, но на отдельном, более мощном сервере. Это рабочая среда, отвечающая за регулярное обновление DDS-слоя. Её стабильность имеет критическое значение.

Процесс разработки и деплоя (CI/CD через GitLab):

Шаг 1: Разработка или изменение DAG. Инженер создает новый DAG или вносит правки в существующий в своей локальной среде или отдельной ветке Git.
Шаг 2: Тестирование на Airflow-TEST. Обновленный код отправляется в GitLab. Airflow-TEST обновляется из этой ветки (автоматически или вручную). Инженер проверяет выполнение DAG на тестовых данных, анализирует логи, убеждается, что логика работает корректно, не нарушает существующие таблицы и эффективно обрабатывает инкрементальные данные.
Шаг 3: Код-ревью и слияние. После успешного тестирования код проходит проверку коллегами. После подтверждения качества изменения сливаются в основную ветку репозитория (например, main или master), где хранится код Airflow (DAG'и, скрипты, конфигурации).
Шаг 4: Автоматический CI/CD на PROD. Срабатывает пайплайн GitLab CI/CD, который: Собирает новый Docker-образ для Airflow-PROD с актуальным кодом из основной ветки. Разворачивает этот образ на продакшен-сервере Airflow-PROD. Старый контейнер останавливается, а новый запускается с обновленными DAG'ами.
Шаг 5: Мониторинг PROD. После деплоя мы следим за выполнением DAG'ов в Airflow-PROD, особенно в первые запуски после изменений. Airflow предоставляет инструменты для мониторинга и уведомлений о проблемах.

Преимущества такого подхода:

Быстрое и безопасное внедрение изменений: Тестирование в изолированной TEST-среде снижает риск ошибок на продакшене.
Надежность PROD: Автоматизированный CI/CD-пайплайн гарантирует, что на продакшене используется только проверенный код из основной ветки. Ручное вмешательство минимизировано.
Удобство тестирования: Разработчики могут экспериментировать и проверять идеи в TEST-среде без риска для основной системы.
Контроль версий и история: Код Airflow (DAG'и) хранится в GitLab, что обеспечивает полную историю изменений, возможность отката и совместную работу.
Управление через Docker: Контейнеризация упрощает развертывание, изоляцию сред и переносимость.

Итог: Процесс работы с Airflow – это не просто запуск DAG'ов, а полноценный инженерный цикл (Dev/Test/Deploy), основанный на принципах CI/CD и разделения сред.
Это обеспечивает надежность и скорость разработки, которые были заложены в цели новой архитектуры.

Изменения в DDS-слое вносятся быстро и предсказуемо.

Почему это эффективно:

Четкая последовательность: Описан пошаговый процесс от разработки до деплоя.
Фокус на изоляции: Разделение TEST и PROD сред – основа безопасности.
Детали CI/CD: Указаны конкретные шаги пайплайна (сборка образа, деплой).
Связь с целями: Подчеркнуто, как процесс поддерживает надежность и скорость разработки.
Инструменты: Упоминание Docker, GitLab и CI/CD делает описание понятным для технической аудитории.
Профессиональный подход: Показана зрелость процесса, который не строится на импровизации.
Логика повествования: Это естественное продолжение истории о создании надежной системы.

Результат реализации:
Мы превратили Airflow в надежный инструмент управления процессами. Благодаря докеризации, разделению сред TEST/PROD, автоматизации CI/CD и контролю версий через GitLab, мы можем быстро и безопасно развивать DDS-слой – добавлять новые сущности, улучшать логику SCD2 или оптимизировать обработку данных без риска для продакшена.

Это полная противоположность сложностям поддержки прежних решений.

Сравнение с прошлым:

Критерий	Раньше (KNIME/SQL)	Сейчас (Airflow + CI/CD)
Тестирование	Практически невозможно, "на проде"	Изолированная среда Airflow-TEST
Деплой	Ручное копирование скриптов	Автоматический CI/CD через GitLab
Воспроизводимость	Зависимость от локальных настроек	Docker-образы + контроль версий
Надежность	Частые сбои при обновлениях	Стабильный процесс с откатом
Скорость изменений	Дни или недели	Часы (от теста до продакшена)

Пример для понимания:
Раньше добавление новой таблицы в DDS требовало нескольких дней работы над сложным скриптом с высоким риском ошибок.

Теперь процесс выглядит так:

Создание DAG: один день.
Тестирование на Airflow-TEST: пару часов.
Отправка кода в GitLab: 20 минут.
Запуск на продакшене: код уже работает.
Доступ аналитиков: на следующее утро.

Этот подход создает основу для следующего этапа – внедрения dbt для работы с витринами.

Реальный эффект:

Сокращение времени разработки с нескольких дней до 24 часов.
Минимизация риска ошибок благодаря тестированию.
Быстрое внедрение изменений и доступ к новым данным для аналитиков.
Создание основы для дальнейшего внедрения dbt и оптимизации работы с витринами данных.

Покоряем гигантов: Как мы справились с 300M строк стоков с помощью Kafka и партиций

Вызов: Среди всех данных особое место занимала сущность "стоки" (остатки товаров), которая стала серьезным испытанием для нашей системы:

Высокая детализация: Данные хранятся с гранулярностью до серийного номера, что приводит к огромному количеству записей.
Ретроактивные изменения: Постоянные правки задним числом из-за инвентаризаций, переоценок и исправлений ошибок.
Масштаб данных: На момент перехода – десятки миллионов строк, сейчас – около 300 миллионов, и объем продолжает расти.
Требование бизнеса: Обновление остатков каждый час для оперативного управления логистикой.

Почему стандартный подход (Экстрактор 1С в BI → Postgres DDS) оказался недостаточным:

Частые массовые изменения: Даже небольшие обновления могли затрагивать значительные объемы исторических данных из-за ретроактивности.
Инкрементальная выгрузка через Экстрактор 1С в Postgres работала, но не справлялась с такой нагрузкой.
Проблемы с производительностью записи на стейдж-слой: При прямой загрузке больших объемов данных в Postgres на стейдж-слой возникали сложности с производительностью:
Высокая нагрузка на диск из-за интенсивной записи.
Значительное потребление IOPS при обработке миллионов записей.
Невозможность частых обновлений (каждые 10 минут или час) без ухудшения производительности всей DWH.

Наше решение: Kafka через Confluent и партиции в Postgres.
Мы разработали специализированный конвейер для обработки стоков, комбинируя готовые возможности и собственные разработки.

Kafka как система передачи изменений:
Мы использовали встроенный Kafka-коннектор в "Экстрактор 1С в BI" для выгрузки событий об изменениях стоков (новые или обновленные записи) в Kafka-топик по расписанию, вместо прямой записи в Postgres стейдж-слой. Для работы с Kafka мы применили платформу Confluent.

Почему Kafka?

Буферизация: Kafka эффективно справляется с пиками изменений.
Надежность: Гарантирует доставку всех сообщений.
Масштабируемость: Позволяет легко увеличивать объем обработки данных.
Изоляция процессов: Отделяет обработку стоков от основного контура DWH, снижая нагрузку на Postgres при записи.

Самописные модули для обработки данных:

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

Для этого создали два ключевых DAG в Airflow:

DAG для стейдж-слоя (stock_turn_processor): Считывает сообщения из Kafka-топика, создает партиции по месяцам в таблице utd_stg.stock_turn и выполняет вставку или обновление данных с помощью INSERT ... ON CONFLICT. Этот процесс работает с частотой каждые 10 минут, обрабатывая данные батчами (до 30,000 записей за раз).
DAG для DDS-слоя (stock_turn_incremental_dds): Инкрементально загружает измененные данные из стейдж-слоя в DDS-слой (utd_dds.fact_stock_turn), создавая партиции по месяцам для каждой даты, если их еще нет. Этот процесс выполняется каждый час и также обрабатывает данные батчами (по 50,000 записей). Особенность этого DAG – динамическое создание задач: он определяет список измененных дат и создает отдельные таски для каждой даты, что позволяет параллельно загружать данные в разные партиции, повышая эффективность обработки.

Основная логика обработки (разработана нами):

Агрегация изменений: События из Kafka группируются в батчи для минимизации операций записи.
Динамическое партицирование: Данные стоков в таблицах Postgres хранятся в партициях по дате (stock_date). Партиции создаются автоматически на основе дат из поступающих данных. Эта логика реализована нами с нуля.
Эффективный UPSERT: Вставка и обновление данных выполняются с использованием оператора INSERT ... ON CONFLICT UPDATE, затрагивая только нужные партиции. Это позволяет обрабатывать только измененные данные, снижая нагрузку.
Оптимизация VACUUM: Настроен усиленный autovacuum для партиций с частыми изменениями.
Очистка старых данных: В стейдж-слое предусмотрена очистка данных старше 3 недель для контроля объема.

Результат:

Скорость и стабильность при 300M строк
Часовые обновления: Система стабильно обрабатывает изменения стоков каждый час на DDS-слое, с промежуточной обработкой каждые 10 минут на стейдж-слое.
Масштабируемость: Партицирование позволяет эффективно работать с объемом в 300 миллионов строк и выше.
Эффективность ресурсов: Нагрузка на Postgres значительно снижена благодаря:
Обработке данных батчами.
Использованию партиций для работы только с актуальными данными.
Параллельной загрузке по датам в разные партиции через динамические таски.
Буферизации через Kafka.
Отказоустойчивость: Kafka гарантирует, что ни одно изменение не будет потеряно, даже при временной недоступности загрузчика.

Почему это эффективно:

Мы адаптировали архитектуру под специфику данных стоков, которые характеризуются ретроактивными правками и высокой частотой изменений.
Использование встроенного Kafka-коннектора для выгрузки в топик через Confluent по расписанию, а также наша собственная реализация обработки данных из Kafka, динамического партицирования, параллельной загрузки через динамические таски и инкрементальной загрузки в стейдж и DDS-слои позволили интегрировать эту "тяжелую" сущность в общую экосистему DWH, соблюдая строгие требования к актуальности.

Витрины нового уровня: dbt-core + dbt-af как ключевой элемент архитектуры

Проблемы прошлого:
Наши витрины в прежней системе создавались с большими трудностями:

Скрытая логика: Основная часть логики была спрятана в сложных схемах KNIME, которые были понятны только их авторам.
Сложные SQL-скрипты: Часть логики реализована в громоздких и неподдерживаемых SQL-скриптах.
Отсутствие переиспользования: Для создания новой витрины приходилось писать всё с нуля, часто копируя существующий код.
Недостаток документации: Документация либо отсутствовала, либо быстро устаревала.
Ручное тестирование: Проверка данных проводилась вручную, что отнимало много времени.

Наше решение: dbt-core как основа трансформаций.

Мы внедрили dbt (data build tool) для построения слоя Common Data Marts – единых и документированных витрин, которые стали важной частью нашей слоистой архитектуры:

Доменная организация: Модели разбиты по бизнес-доменам (customers, marketing, orders, products, sandbox, segmentation, tv_broadcast), что позволяет избежать монолитных скриптов и обеспечивает четкую структуру проекта.
Принцип DRY (Don't Repeat Yourself): Общая логика вынесена в макросы и базовые модели. Финальные витрины (marts_) строятся поверх них с помощью простых и понятных запросов SELECT.
SQL, документация и тесты: Код моделей написан на чистом SQL. Описания моделей и полей, а также тесты на уникальность, свежесть и согласованность значений задаются в .yml-файлах рядом с кодом. Команда dbt docs generate создает актуальный каталог данных.
Гибкость через Jinja: Шаблонизация позволяет создавать параметризуемые модели без дублирования кода.

Интеграция с Airflow через dbt-af от Toloka

Для интеграции dbt в нашу экосистему мы используем библиотеку dmp-af от команды Toloka, которая позволяет автоматически генерировать DAG'и для dbt-проекта и интегрировать их с Airflow:

Автоматическая генерация DAG'ов: dbt-af автоматически создает Airflow DAG'и на основе структуры dbt-проекта, разделяя модели по доменам и создавая отдельные DAG'и для каждого домена. Это позволяет запускать модели из разных доменов параллельно.

Преимущества интеграции:

Единая оркестрация: Витрины запускаются как часть общих Airflow DAG'ов после обновления DDS-слоя, без необходимости ручных запусков или внешних скриптов.
Мониторинг и алерты: Статус выполнения задач dbt и ошибки тестов отображаются в интерфейсе Airflow и отправляются в уведомления.
Ресурсный контроль: Задачи dbt выполняются в Docker-контейнерах с выделенными ресурсами (CPU, RAM), не влияя на другие процессы.
Текущий режим работы: На данный момент dbt работает в "онлайн-режиме", без полной интеграции в CI/CD pipeline. Это означает, что обновления кода и запуск моделей выполняются по мере необходимости, но мы планируем внедрить автоматизацию через CI/CD в будущем, как это сделано для других компонентов системы.

Отдельно хочется выделить важнейшее архитектурное свойство нашей новой связки Airflow + dbt — идемпотентность (re-runnability).
В старой системе на самописных скриптах любая ошибка при загрузке означала долгий ручной разбор полетов, написание скриптов отката и риск задублировать данные.

Теперь, если что-то пошло не так (например, сбойнула сеть или источник отдал некорректные данные), дата-инженеру достаточно просто нажать кнопку Clear task в интерфейсе Airflow. Инструмент dbt сам поймет, как безопасно пересчитать этот кусок: он "под капотом" выполнит delete + insert для инкрементальной модели за нужный день. Никаких дублей и никакого ручного вмешательства в базу. Пайплайн можно перезапускать хоть 10 раз подряд — результат всегда будет корректным. Это радикально снизило уровень стресса в команде эксплуатации и повысило доверие к данным.

Рабочая среда для аналитиков:

Чтобы аналитики могли эффективно работать с dbt, мы развернули VS Code в отдельном контейнере, где они могут писать модели, не заходя в CLI.
Аналитики просто создают и редактируют SQL-файлы моделей в привычной среде разработки, а dbt-af автоматически генерирует необходимые DAG'и на основе структуры проекта.
Это значительно упрощает работу с платформой и снижает порог входа для аналитиков.

Обучение и поддержка аналитиков:

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

Итог:

Комбинация dbt-core (для трансформаций, тестов и документации) и dbt-af от Toloka (для автоматической генерации DAG'ов и интеграции с Airflow) позволила нам создать слой Common Data Marts (витрин), который:

Понятен: Аналитики видят логику в SQL и могут участвовать в разработке с ревью.
Надежен: Автоматические тесты выявляют ошибки до продакшена.
Быстро развивается: Скорость создания новых витрин значительно выросла.
Документирован: dbt docs и будущая интеграция с DataHub (о нем далее) обеспечивают полную картину данных.
Автоматизирован: Запуск осуществляется через автоматически сгенерированные DAG'и по расписанию.
Удобен для аналитиков: Работа в VS Code в контейнере без необходимости использования CLI.

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

Что изменилось за этот год:

Когда мы начинали, наша data-платформа была настоящей головной болью. Аналитики ждали данные сутками, инженеры ночами чинили сбои, а система 1С страдала от нагрузки.
Сегодня данные обновляются каждый час, аналитики сами создают витрины в Yupiter, а процессы работают стабильно. Мы уже интегрировали DataHub для управления метаданными и готовим CI/CD для dbt, чтобы автоматизировать деплой витрин.
Мы прошли путь от хаоса к порядку, и это было непросто, но результат того стоил. Надеюсь, наш опыт вдохновит вас на перемены.

Автор статьи: