Мы живем в век данных и data-driven подхода. Есть продуктовые компании, где даже минимальные изменения в продукте обязаны пройти A/B-тест перед релизом (который из-за этого может и не состояться). С бумом данных и AI произошел и бум ETL (Extract, Transform, Load) инструментов. Сейчас, в 2025 году, выбор действительно впечатляет, даже если ограничиться только open source-решениями:

• Apache Airflow

• Kestra

• Apache NiFi

• Mage ai

• Dagster

• Prefect

• И многие другие

При этом существует множество решений — как у облачных поставщиков, так и просто проприетарных и платных. Выбор действительно огромный, но, как вы догадались, наш падет на Dagster. Но к этому надо будет еще подвести.

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

Данная статья была написана совместно с автором тренажера Курс по ETL-разработке и оркестрации на Dagster и Apache Nifi

После двух месяцев работы вы сложили для себя пазл о том, как должно в будущем выглядеть ядро вашей платформы данных — ETL-инструмент.

У компании есть несколько источников данных:

• Партнерские API, где можно получить статистику по продажам.

• Внутренняя база данных с каталогом товаров и их движением.

• Продажи собственного интернет-магазина.

• Рекламные кабинеты и их API.

• Также могут появиться другие источники, которые надо будет подключать

По тому, какие отчеты нужно готовить, вы понимаете, что понадобиться может все со всем вместе. Статистика продаж и статистика рекламы, опросы, каталог — все должно быть под рукой.

Бизнес-заказчики имеют потребность самостоятельно изучать данные, а также получать регулярные отчеты по разным информационным каналам.

С технической стороны вы хотите заложить надежный фундамент для будущего масштабирования и спектра самых разных задач (в том числе ML).

Также по опыту прошлых работ вы знаете, насколько важно иметь доступ к описанию всех компонентов вашего конвейера данных, а также автоматизировать проверку качества данных.
Ну и довольно очевидное требование — язык. Выбор здесь небольшой, вы полагаетесь на стандарт индустрии — Python.

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

Dagster

Dagster — это open source ETL/ELT (extract, transform, load/extract, load, transform) инструмент, который предназначен для создания многоступенчатых конвейеров данных от внешнего источника до отчета или дашборда. Язык разработки dagster-конвейеров — python, а значит, нам доступен весь функционал языка по подключению к источникам данных и их преобразованию.

Dagster использует декларативный подход. То есть вы говорите, что делать, а не как. Это очень удобно для аналитиков, так как позволяет сосредоточиться именно на аналитике.

Тем не менее вам доступен и императивный подход, когда вы можете указать, как именно нужно что-то сделать. Например, как отправить отчет или DELETE-запрос в REST API.

Dagster — инструмент современный, и вы можете выбрать, где вам его использовать:

• Полностью самостоятельно через Docker или Kubernetes. И полностью бесплатно.

• В официальном облаке разработчиков. Полностью (compute — на их стороне, полностью — serverless) или частично (hybrid, compute — на вашей стороне).

Отличительные фишки dagster:

• встроенные проверки качества данных;

• интеграция с dbt;

• data lineage и подробное (и кастомное) описание компонентов системы.

Поговорим подробнее про все аспекты.

Software Defined Asset

В dagster основной элемент — Software Defined Asset (SDA) или программно-определенная сущность актива. Ключевое слово здесь — определенная. То есть вы определяете некоторый актив на вашей платформе, который может быть переиспользован в дальнейшем.

Что может считаться SDA:

• отчет из рекламного кабинета;

• модель dbt;

• модель машинного обучения.

Что лучше не подводить под рамки SDA:

• рассылку отчетов;

• апдейт или удаление конкретных строк в базе данных.

Ограничения довольно условны, например, та же рассылка отчетов может быть реализована как ассет. Я руководствуюсь таким правилом: чем больше у меня в коде императивного, а не декларативного, тем меньше причин использовать SDA.Ассет нужен для того, чтобы его материализовать. То есть выполнить код из тела функции ассета. Материализовать можно руками или автоматически через Jobs и Schedules.

Ops, Jobs

А вот если нет причин использовать SDA, то тут можно применить довольно стандартный подход с объединением отдельных заданий (ops) в большую работу (job). При этом для автоматизации ассет или несколько ассетов тоже должны быть запущены через job.

Resources

Ресурсы в дагстере — это классы, содержащие методы для работы с внешним миром. Они могут как возвращать данные, так и просто заключать в себе логику работы с этим ресурсом.
Примеры ресурсов:

• Клиент к API рекламного кабинета.

• Методы для работы с телеграм-ботом.

• Чтение из внешней базы данных.

Ресурсы довольно легко пишутся самостоятельно, поэтому не стоит ждать каких-то интеграций с очередным REST API. Намного проще написать самому и под свои нужды.

IO Managers

Или Input/Output Mangers. Классы с методом для записи и чтения ассетов. Ключевое отличие от Resources состоит в том, что ресурсы — это дверь во внешний мир, а IOManagers — способ записывать данные из этого внешнего мира и дальше с ними работать. Менеджеры имеют два основных метода: запись данных и чтение данных. Такой подход позволяет выстроить ассеты в конвейер.
Пример конвейера с ресурсами и менеджерами.
Самописным ресурсом вы забираете статистику из рекламного кабинета Яндекса (назовем его yandex_asset). Для этого ассета используете ClickhouseIOManager (такой же самописный). То есть рекламная статистика записывается в ваше Clickhouse-хранилище в виде отдельной таблицы. Далее вы можете создать в дагстере ассет, который как-то эти сырые данные преобразует. В итоге вам не надо будет писать, как эти данные читать из кликхауса, надо всего лишь указать название ассета-источника. Менеджер сам предоставит данные для зависимого ассета. Мы разберем подробные примеры, когда будем разговаривать о IOManagers отдельно.
Также важно добавить, что IOManager могут добавлять метаданные о ваших ассетах в UI, что полезно для документации.

Schedules

Расписания — основа автоматизации. Плюс дагстера в том, что расписания могут задаваться полностью программно, а не просто быть cron-строчкой. Пример из опыта: при каждом тике расписания вызывается пересчет ассетов за три дня. Или за четыре. Реализуется простым циклом.

Checks

Asset Checks — это Data Quality в Dagster.
Чеки могут быть разнообразными — как шаблонными, так и кастомными, написанными для конкретного ассета. Важно, что это тесты именно на данных и они участвуют в автоматизации. То есть даже если материализация вашего ассета прошла успешно, но при этом в данных нашлись аномалии, не удовлетворяющие вашим тестам, то джоба будет помечена как failed, а вы получите уведомление, если они у вас настроены. Также важно, что все другие ассеты, зависящие от материализации этого, не будут материализованы автоматически. Таким образом в отчеты и дашборды (или ML-модели) не попадут данные плохого качества.

Data Lineage

Я уже не раз упоминал конвейер данных. Этот конвейер (или более привычный в профессиональной среде термин DAG — directed acyclic graph) не только отрисовывается в UI дагстера, но и имеет несколько прикладных применений. Выбрав часть графа (например, конкретный ассет и все зависящие от него другие ассеты), вы можете запустить их материализацию.

А в платной облачной версии можно построить еще и column level lineage. То есть буквально проследить, из чего складывается та или иная метрика в витринах данных.

Резюме

Dagster — это не просто ETL/ELT-инструмент. Это полноценная платформа данных, которая поверх вашего графа данных добавляет еще data quality и data lineage.

Декларативный подход к созданию узлов графа (ассетов) позволяет реализовать database agnostic подход. Вы можете легко заменить хранилище материализованных ассетов, просто поменяв значение в аргументе io_manager.

Код с курса

Код доступен в репозитории GitHub - Inzhenerka/dagste... @GitHub.

Для запуска вашего Dagster-сервера локально нужно установить пакеты:

pip install -r requirements.txt

И выполнить одну команду:

dagster dev -m inzhenerka_dagster

Если вы назвали модуль иначе, то вместо inzhenerka_dagster — ваше название.Но я советую после установки пакетов в системное окружение создать Dagster-проект с нуля:

dagster project scaffold --name <имя вашего пакета а папки>

Начните с этого или клонируйте общий репозиторий, запустите дагстер локально и пройдитесь по его UI.

– И все это нам нужно подключить?

– Давай начнем с того, что у нас есть, – предложил он.

– Ну что, освоился? Пойдем, у нас задача.

– Да, причем так, чтобы бизнес сам мог ковыряться.

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

– Слушай, мы растем быстро, но я вообще не понимаю как. У нас куча данных: продажи, поездки, реклама. Вчера пытался посмотреть, сколько самокатов сломалось за месяц – плевался.

Версия с историей

Алекс открыл дверь офиса кикшеринговой компании Rider Go. Обстановка, типичная для стартапа: пара ноутбуков на стоячих столах, ребята спорят у белой доски, кто-то забавно упал с самоката прямо в офисе, и все вокруг смеются.

Алекс огляделся. Новая работа – всегда вызов. До этого он три года занимался аналитикой в крупной розничной сети, где все было четко структурировано: данные собирались в огромный склад Snowflake, ETL обрабатывался на Airflow, а дашборды – в Tableau. Здесь же чувствовался легкий хаос.
Фаундер компании Сергей встретил Алекса радостным жестом:

Они сели за круглый стол в переговорной. На доске – кривая диаграмма продаж, какая-то таблица, каракули маркером. Сергей вздохнул:

Алекс кивнул. На этапе интервью он уже понял: культуры работы с данными здесь нет. Но в этом и был вызов – построить систему с нуля, на своих условиях.

Первый вызов

– Сергей, я, кажется, нашел инструмент. Нужно будет протестировать, но выглядит интересно.

– А как Airflow?

– Лен, привет! Помоги. У нас куча данных. Хочу инструмент для ETL. Как думаешь, с чего начать?

Фаундер ответил почти сразу:– Тогда готовь презентацию. Мне надо будет продать идею ребятам.

– Норм для разработчиков. Но у вас стартап, а не SpaceX. Хочешь месяц писать код?

– Выбирай то, что автоматизирует, а не усложняет. И обрати внимание, что твой инструмент:

1. Должен дружить с Python.

2. Масштабироваться.

3. Не быть монстром, который потребует месяц на настройку.

Первый вызов

Прошло две недели. Алекс собрал все в голове: какая платформа нужна, какие данные обрабатывать. На бумаге это выглядело логично: ETL-инструмент, который соединит все в одну систему.

Во время кофе-брейка он решил спросить совета у бывшей коллеги Лены, которая ушла в крупную IT-компанию:

Лена ответила быстро:

Алекс задумался. Вроде бы понятно, но как применить это на практике?

Выбор инструмента

Алекс начал копать. Вечерами он сидел в Slack-чатах, перечитывал блоги аналитиков и обратил внимание, что в каждом обсуждении упоминается Airflow. Он переслал ссылку Лене:

Алекс закрыл вкладку. Prefect выглядел интереснее: декларативный подход, модные фичи. Но как оказалось, за удобство надо платить: с бесплатной версией ты далеко не уйдешь.

Потом он наткнулся на Dagster. На вид – золотая середина. Поддержка Python, мощная визуализация процессов, автоматизация качества данных.
Алекс открыл чат:

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

Решение

– Если я не смогу убедить Сергея и остальных, проект просто не взлетит, – думал Алекс, сидя вечером над структурой документа.

– Звучит убедительно. Ладно, давай попробуем.

Решение

Алекс тщательно изучал возможности инструментов, разбираясь, какой из них подойдет для задач Rider Go. Просматривая сообщества аналитиков, статьи и блоги, он обратил внимание на Dagster. На первый взгляд он подходил идеально: поддержка Python, декларативный подход и возможность работы с данными на разных уровнях – от простых ETL-конвейеров до сложных процессов с проверкой качества.

Алекс задумался: внедрение Dagster – это не просто выбор инструмента, это проект, который нужно "продать" команде. Поэтому он взялся за подготовку презентации, в которой решил показать не только технические преимущества, но и бизнес-ценность.

Презентация получилась лаконичной:

• Что такое Dagster: мощный инструмент для автоматизации обработки данных.

• Почему он подходит для Rider Go: быстрое развертывание, минимальные затраты на поддержку.

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

На следующее утро Алекс показал свою работу Сергею. Тот задумчиво пролистал слайды.

Первые шаги

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

Алекс создал первый Software Defined Asset (SDA) – сущность, описывающую данные о поездках на самокатах. SDA помогал структурировать данные и облегчал их дальнейшую обработку.

Пример из практики:

• Алекс создал ассет для сбора сырых данных о поездках.

• Данные передавались в другой ассет, где уже рассчитывались ключевые метрики: средняя продолжительность поездки, количество поездок в час пик.

Чтобы автоматизировать процесс, нужно было задать расписания. Dagster предлагал программные расписания, которые позволяли запускать ассеты только тогда, когда это действительно необходимо.

Первые шаги

Преодоление сложностей

– Как круто, что не надо прописывать крон-задания! – восхитился Алекс, когда автоматизировал обновление данных каждое утро.

– Идет. Теперь я могу увидеть, где именно в данных что-то пошло не так.

– Ты пробовал готовые решения?

– Они есть, но не подходят для нашей структуры данных.

– Ну как там?

Преодоление сложностей

Однако не все шло гладко. Dagster оказался мощным, но требовательным инструментом. Для настройки некоторых процессов приходилось разбираться с кодом, который был плохо задокументирован.

На одном из этапов Алекс столкнулся с проблемой интеграции с Clickhouse. Для ее решения ему пришлось написать свой IOManager – класс, отвечающий за взаимодействие между SDA и хранилищем данных.

Лена снова пришла на помощь:

Алекс потратил несколько дней, создавая кастомный IOManager. Этот инструмент позволял записывать данные в Clickhouse и тут же использовать их для других ассетов.Также он внедрил систему Checks – проверок качества данных. Теперь, если данные были некорректны, Dagster сам останавливал процесс, чтобы избежать ошибок в итоговых отчетах.Сергей заглянул в офис:

Самым сложным оказалось убедить команду аналитиков использовать Dagster. Алекс провел для них мастер-класс, показывая, как легко работать с инструментом и какие преимущества это даст в долгосрочной перспективе.И хотя процесс внедрения еще не был завершен, Алекс понимал: он на правильном пути.

Успех

– Так просто и красиво? А я думала, тут надо будет разбираться неделями.

– Это прямо как личный ассистент для данных, – пошутил Сергей, увидев отчет о сработавшем чекере.

Успех

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

Например, отчеты для отдела маркетинга, которые раньше приходилось вручную собирать из нескольких источников, теперь формировались автоматически. Используя data lineage в Dagster, Алекс показал команде, откуда берутся цифры в итоговых таблицах и как каждый этап обработки данных влияет на результат.

Лена, глядя на визуализацию процессов в интерфейсе Dagster, сказала:

Одним из ключевых моментов стало внедрение чеков качества данных. Теперь, если в данных обнаруживались аномалии – например, внезапный скачок числа поездок в три часа ночи – Dagster останавливал процесс и отправлял уведомление в Slack.

Но настоящим прорывом стал переход от стандартных ассетов к сложным сценариям с использованием Resources и IOManagers. Алекс создал клиент для работы с рекламными API, который автоматически подключал новые кампании. А в Clickhouse теперь загружались не только данные о поездках, но и результаты экспериментов, которые можно было сразу анализировать.

Команда почувствовала изменения: задачи, которые раньше казались неподъемными, теперь быстро решались. Dagster стал не просто инструментом, а частью культуры работы с данными в Rider Go.

Финал

– А знаешь, что самое крутое? – сказал Алекс вечером за чашкой кофе.

– Я теперь понимаю, как связаны все эти штуки: данные, люди, процессы. Dagster – это просто инструмент. А настоящая работа – это построить систему, которая помогает принимать решения.

– Например, мы сразу видим, что реклама в TikTok привела к пиковому числу поездок. Теперь можно точнее планировать бюджеты. И еще: отчеты, которые раньше занимали полдня, теперь формируются за пять минут.

– Вот так мы обрабатываем данные о поездках, рекламе и продажах. Здесь все связано. А самое главное – все прозрачно, – объяснял Алекс.

– Я уже чувствую, как меньше времени трачу на рутину. Алекс, классно получилось!

– Что? – спросила Лена.

– Как это помогает бизнесу? – спросил Сергей.

Финал

Наступило утро понедельника, когда Алекс наконец представил результаты работы всей команде. Он запустил презентацию и продемонстрировал график DAG – сложный, но логичный.

Аплодисменты прозвучали неожиданно, но приятно. Лена подняла руку:

Этот проект стал важным этапом не только для Rider Go, но и для самого Алекса. Dagster оказался мощным инструментом, который он освоил, внедрил и адаптировал под нужды компании.

И хотя впереди еще было множество задач, Алекс знал: с этим проектом он точно справился. Наконец-то у него получилось выделить время, чтобы как следует поработать с документацией, и он описал начало работы с Dagster.Код доступен в репозитории GitHub - Inzhenerka/dagste... @GitHub.

Для запуска вашего Dagster-сервера локально нужно установить пакеты:

pip install -r requirements.txt

И выполнить одну команду:

dagster dev -m inzhenerka_dagster

Если вы назвали модуль иначе, то вместо inzhenerka_dagster — ваше название. Но я советую после установки пакетов в системное окружение создать Dagster-проект с нуля:

dagster project scaffold --name <имя вашего пакета а папки>

Начните с этого или клонируйте общий репозиторий, запустите дагстер локально и пройдитесь по его UI.

Без воды

С ростом данных и AI популярность ETL инструментов также возросла. В 2024 году существует множество open source-решений, таких как:

• Apache Airflow

• Kestra

• Apache NiFi

• Mage ai

• Dagster

• Prefect

Кроме того, доступны решения от облачных поставщиков и платные инструменты. Мы выбрали Dagster.

Требования

• Источники данных: партнерские API, внутренняя база данных, интернет-магазин, рекламные кабинеты.

• Потребность в объединении данных для отчетности.

• Бизнес-заказчики требуют самостоятельного анализа данных и регулярных отчетов.

С технической стороны необходим надежный фундамент для масштабирования и ML-задач.

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

Вы выбрали Dagster для своей платформы данных, потому что он соответствует требованиям и его еще не было в вашем резюме.

Презентация

1. Dagster — это open source ETL/ELT-инструмент для создания конвейеров данных с использованием Python.

2. Dagster использует декларативный подход, что позволяет аналитикам сосредоточиться на анализе.

3. Также доступен императивный подход для задания конкретных действий.

4. Dagster можно использовать: локально через Docker или Kubernetes. В официальном облаке разработчиков, с сервером или без.

5. Особенности Dagster: встроенные проверки качества данных. Интеграция с dbt. Data lineage и описание компонентов системы.

6. Основной элемент Dagster — Software Defined Asset (SDA), который можно переиспользовать.

7. Примеры SDA: отчеты, модели dbt, модели машинного обучения.

8. Не рекомендуется использовать SDA для рассылки отчетов или изменений в базе данных.

9. Чем больше императивных действий в коде, тем меньше причин использовать SDA.

10. Ассет материализуется, чтобы выполнить код функции. Это можно сделать вручную или через Jobs и Schedules.

11. Если SDA не нужно, можно использовать стандартный подход с объединением заданий (ops) в работу (job).

12. Ресурсы в Dagster — это классы для работы с внешними ресурсами (API, базы данных и т. д.).

13. Примеры ресурсов: API клиентов, методы работы с телеграм-ботами, чтение из баз данных.

14. Ресурсы легко пишутся самостоятельно под специфические нужды.

15. IOManagers — классы для записи и чтения ассетов. Они управляют данными в конвейере.

16. Пример: статистика из рекламного кабинета записывается в Clickhouse с использованием IOManager.

17. IOManagers могут добавлять метаданные об ассетах в UI для документации.

18. Расписания в Dagster задаются программно, что дает гибкость в автоматизации.

19. Asset Checks — это проверки качества данных в Dagster. Если данные не проходят тесты, джоба считается неудачной.

20. Data lineage в Dagster позволяет проследить, как данные проходят через систему. В UI можно увидеть зависимости между ассетами.

21. В платной версии можно отслеживать lineage на уровне колонок.

Резюме

1. Dagster — это не только ETL/ELT-инструмент, но и платформа для работы с данными, включая data quality и data lineage.

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

3. Код доступен в репозитории: GitHub - Inzhenerka/dagste... @GitHub.

Для запуска Dagster локально установите пакеты:

pip install -r requirements.txt

Запустите:

dagster dev -m <название вашего модуля>

Для создания проекта с нуля используйте:

dagster project scaffold --name <имя пакета>

Заключение

Dagster — это не просто инструмент, а новый взгляд на построение конвейеров данных. Он меняет сам подход к ETL, предлагая декларативную архитектуру, data lineage и встроенные механизмы контроля качества. Но главное — он адаптируется под реальный бизнес, позволяя быстро и гибко выстраивать процессы.

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

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

Данная статья была написана совместно с автором тренажера Курс по ETL-разработке и оркестрации на Dagster и Apache Nifi