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

Данная статья переведена с английского с адаптациями в рамках курса Тренажер по разработке ETL и оркестрации данных

Почти вся разработка программного обеспечения в области данных сводится к одной деятельности: построению графов вычислений, которые потребляют и производят активы данных, такие как таблицы, файлы и обученные модели. Существующие инструменты, которые моделировали графы зависимостей, не рассматривали этот процесс целостно, ограничивая себя развертыванием и операциями. Яркий пример: сегодня наиболее часто используемый движок рабочего процесса — Airflow, и он имеет узкую направленность — планирование, упорядочивание и мониторинг развернутых вычислений.

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

Мы сравним эти две системы, рассмотрев, как они обрабатывают каждый из этапов жизненного цикла данных.

Dagster создан для решения каждой из этих стадий жизненного цикла и обеспечивает:

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

• Среда оркестровки, которая растет вместе с вами, от «однопользовательского режима» на вашем ноутбуке до многопользовательской платформы корпоративного уровня.

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

Разработка и тестирование

Наше убеждение: специалисты по работе с данными заслуживают полного цикла проектирования с быстрыми циклами разработки и сквозным тестированием. Orchestrator должен ощущаться как инструмент производительности.

Что мы слышим от пользователей Airflow:

• «Я не могу разрабатывать свои DAG локально».

• «Трудно тестировать мои DAG».

• «Я обнаруживаю слишком много ошибок в постановке и производстве».

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

Если оркестратор не был специально разработан для быстрой разработки и тестирования, то и графики, смоделированные в оркестраторе, не будут такими. Раннее обнаружение ошибок и ускорение циклов обратной связи — это огромная возможность. Как говорит Эрик Бернхардссон: «Снижение скорости итераций на порядок оказывает драматическое влияние на выполнение задач».

Функциональная обработка данных

Подход Airflow

Основная абстракция Airflow — это DAG (направленный ациклический граф), набор задач, связанных через зависимости выполнения. Airflow намеренно не знает ничего, кроме названий задач, того, какие задачи зависят друг от друга, и необработанных журналов, которые они производят. Документация Airflow ясно говорит об этом:

«Важно то, что DAG не заботится о том, что делают входящие в его состав задачи; его работа заключается в том, чтобы убедиться, что все, что они делают, происходит в нужное время, или в нужном порядке, или с правильным решением любых непредвиденных проблем». ссылка

Airflow имеет некоторую поддержку зависимостей данных в виде XCom и TaskFlow, API, представленного в Airflow 2. Но он не был разработан с учетом этого и, по сути, активно препятствует зависимостям данных. Из документации Airflow:

“Это тонкий, но очень важный момент: в общем, если двум операторам нужно обмениваться информацией, например, именем файла или небольшим объемом данных, вам следует рассмотреть возможность объединения их в одного оператора. Если этого совершенно невозможно избежать, Airflow имеет функцию для кросс-коммуникации операторов, которая называется XCom…” ссылка

Подход Dagster

Конвейеры Dagster — это графы метаданных, параметризуемых функций, называемых сплошными массивами , соединенных через постепенно типизированные зависимости данных. Чтобы определить конвейер, пользователь пишет функции vanilla python, которые определяют вычисления и структуру графа:

из конвейера импорта dagster, solid @solid def return_one() -> int:   return 1 @solid def add(x: int, y: int) -> int   return x + y @pipeline def add_two():   # строит график зависимостей   add(return_one(), return_one())

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

Конечный результат совершенно очевиден в пользовательском интерфейсе. При просмотре задачи в пользовательском интерфейсе Airflow единственная информация для наблюдателя — это имя задачи и задача, от которой она зависит.

Сравните это с Dagster, где прекрасные инструменты отображают описания, входные данные, выходные данные, требуемые ресурсы и другие метаданные.

Функциональная обработка данных Dagster дает множество преимуществ помимо самоописания, эргономичных API и более богатого пользовательского интерфейса на основе метаданных:

• Тестируемость: Функции, моделирующие входы и выходы, позволяют пользователям параметризовать выполнение и напрямую проверять результаты. Тестирование групп DAG и задач Airflow требует установки внешнего состояния, выполнения без параметров, а затем проверки внешнего состояния.

• Выполнение подмножества: Выполнение произвольных подмножеств графов для тестирования или операционных целей в Dagster просто, поскольку каждый узел может описать свои требуемые входы и конфигурацию. Напротив, Airflow не предоставляет API для выполнения подмножества DAG.

• Зависимости данных: Без зависимостей данных специалист Airflow должен указать зависимости дважды: сначала явно на уровне выполнения, создав DAG; затем неявно, вручную написав код, который извлекает результаты вычислений вышестоящего уровня. Зависимости данных Dagster устраняют целый класс ошибок: несоответствия между зависимостями выполнения и неявными зависимостями данных в коде.

• Встроенный маршалинг: Обработка данных должна масштабироваться по процессам, что требует маршалинга вывода одного узла во ввод другого. Dagster предоставляет встроенные компоненты и подключаемый пользователем API для маршалинга данных между файловыми системами, хранилищами объектов, хранилищами данных и другими системами хранения.

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

Разделение ввода-вывода и вычислений

Подход Airflow

Группы DAG Airflow обычно состоят из таких операторов, как SparkSubmitOperator, KubernetesPodOperatorили PostgresOperator. Обратите внимание, что все они относятся к конкретным развернутым инфраструктурным технологиям.

Успешное выполнение требует полного развертывания пользовательской инфраструктуры, будь то разработка, конвейер CI/CD или производство. Связывание инфраструктуры является ключевой причиной, по которой группы DAG Airflow сопротивляются выполнению в нескольких средах, что препятствует быстрому, гибкому рабочему процессу разработки и тестирования.

Подход Dagster

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

@solid def filter_over_50(люди: DataFrame) -> DataFrame:   return people.filter(люди['возраст'] > 50)

В приведенном выше примере практик пишет функции, которые принимают и выводят фреймы данных напрямую. Ввод-вывод — в данном случае сохранение фрейма данных — управляется ресурсом. У конвейеров есть режимы, такие как «test» и «prod», которые предоставляют различные ресурсы во время выполнения. В этом примере ресурс режима «test» может сохранять фрейм данных в файловой системе, а ресурс режима «prod» может сохранять фрейм данных в хранилище объектов, таком как s3, при этом сохраняя постоянную бизнес-логику.

• Гибкое выполнение: Dagster предоставляет возможность контролировать выполнение из разных сред — ноутбука, конвейера CI/CD, производства и т. д. — сохраняя при этом постоянную бизнес-логику.

• Чистый, интуитивно понятный API: Специалисты, работающие с Python (например, специалисты по обработке данных, использующие Spark или Pandas), могут писать и подключать чистые функции Python для создания конвейеров.

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

Легкое, не привязанное к графику, нерегламентированное исполнение

Подход Airflow

Airflow DAGs связывают структуру графа и политику планирования (например, запускать это в 3 часа утра ежедневно). Эта связь означает, что DAG не может работать по двум разным расписаниям (например, ежедневное задание и еженедельное свертывание). На более глубоком уровне DAG не является автономным артефактом, независимым от расписания.

С точки зрения инфраструктуры Airflow требует длительного процесса планировщика для регистрации и итерации DAG локально, что делает опыт медленным и неоптимальным. Локальная разработка не является нормативной и, когда она выполняется, требует тяжеловесной инфраструктуры.

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

Конкретным следствием этих концептуальных и инфраструктурных проблем является отсутствие чистого, легкого API Python для выполнения DAG или подмножеств DAG без запущенного процесса планировщика.

Подход Dagster

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

Структура графа и расписания также являются разъединенными концепциями; расписания и датчики определяются независимо от конвейера.

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

• Быстрый запуск: Dagster имеет чрезвычайно быстрый и простой процесс запуска. Определите конвейер с несколькими строками ванильного кода, а затем загрузите его в графическую среду для проверки и выполнения или вызовите его с помощью API Python.

• Облегченные API-интерфейсы Python Execution: конвейеры Dagster могут выполняться полностью в памяти, без необходимости использования базы данных или процесса планировщика.

• Облегченная графическая среда разработки: Dagit, наш веб-инструмент, не требует инфраструктуры и может использоваться как локальная среда разработки, например IDE для DAG.

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

• Pipelines as Documentation: Отсутствие требований к инфраструктуре и веб-пользовательский интерфейс, разработанный для локальной разработки, делают pipelines артефактами документации, богатыми метаданными. Как практикующий специалист, я могу быть уверен, что вы можете использовать git cloneрепозиторий и мгновенно просматривать эти pipelines в богатом пользовательском интерфейсе.

Из-за этих проектных решений мы постоянно слышим следующее от пользователей, которые перешли с Airflow на Dagster: Разработка и тестирование DAG Airflow — это сложно, медленно, а иногда и невозможно. Напротив, разработка и тестирование в Dagster не просто возможны, но и увлекательны и быстры. Практики счастливее, а системы, которые они производят, более надежны, устойчивы и поддаются изменениям.

Развертывание и выполнение

Наше убеждение: Orchestrator должен быть надежной многопользовательской платформой, предоставляющей командам независимый и надежный цикл развертывания.

Что мы слышим от пользователей Airflow:

• «Каждый может уничтожить оркестратора».

• «Централизованный планировщик задач продолжает вызывать проблемы масштабирования».

• «Я не могу самостоятельно и надежно развернуть свои DAG».

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

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

Изоляция процесса

Подход Airflow

Архитектура Airflow включает в себя множество компонентов, в том числе:

• Централизованный планировщик, отвечающий за планирование запусков и задач.

• Веб-сервер.

• Набор рабочих для обработки задач.

Планировщики и рабочие процессы загружают и обрабатывают все DAG с частым интервалом (по умолчанию одна минута). Все определяемые пользователем DAG и все компоненты Airflow сосуществуют в одном процессе Python. Это имеет ряд недостатков:

• Dependency Hell: Все зависимости Airflow (почти 100 пакетов на чистой установке) и все зависимости DAG должны сосуществовать в одной среде Python. Разные команды могут захотеть использовать разные пакеты, версии пакетов или версии Python, что невозможно при типичном использовании Airflow. Это также усложняет процесс обновления Airflow и операторов Airflow.

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

• Монолитное развертывание: все команды в экземпляре Airflow должны развертываться монолитно. Это также приводит к проблемам надежности, поскольку процессы Airflow могут оценивать эти файлы во время неатомарного обновления (например, операция git или команда rsync). Продвинутые пользователи часто вынуждены приостанавливать процессы планировщика, обновлять код, а затем возобновлять планирование. Цикл пауза-развертывание-возобновление сложен в реализации и усложняет процессы развертывания.

Команды должны выбирать между управлением (1) одним, хрупким, трудно масштабируемым экземпляром Airflow, (2) управлением несколькими экземплярами Airflow или (3) специальной структуризацией всех DAG для вывода из процесса бизнес-логики и инфраструктуры, специфичных для команды.

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

Другой вариант — использование нескольких экземпляров. Команда платформы данных может централизованно управлять ими или делегировать операционную нагрузку командам заинтересованных сторон. Любой подход влечет за собой существенную централизованную или распределенную операционную нагрузку соответственно. Это также означает регрессию в некодированные зависимости между командами, что было основной причиной добавления оркестратора в первую очередь.

Подход Dagster

В Dagster системные процессы и пользовательские процессы четко разделены. Наши системные процессы — веб-сервер, демон — не загружают написанный пользователем код в память. Конвейеры, ресурсы и другие определения сгруппированы в репозитории и доступны через API.

Преимущества

• Изолированные зависимости: Различные команды (например, специалисты по науке о данных, специалисты по инжинирингу данных) часто используют разные версии пакетов Python. Изолированные зависимости позволяют избежать технических проблем, таких как раздутые размеры образов Docker, неразрешимые конфликты и несоответствия версий. Команды могут даже использовать разные версии Python! Это также изолирует пользовательские зависимости от зависимостей компонентов системы Dagster.

• Надежность: Изоляция процесса означает более надежную систему. Если команда выдвигает ошибку, которая приводит к сбою или замедляет строительство трубопровода, общесистемные операции не пострадают.

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

Гибкое, распределенное планирование задач

Подход Airflow

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

Подход Dagster

Длительный процесс Dagster, демон, отвечает за планирование запусков, а не задач. Это позволяет использовать многоуровневый подход, при котором запуски Dagster обычно управляются в эфемерных, одноцелевых вычислительных ресурсах (например, процессах, заданиях Kubernetes), отвечающих за планирование задач. Те, в свою очередь, могут выбирать собственную политику планирования задач.

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

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

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

• Горизонтальная масштабируемость: каждый вычислительный процесс, специфичный для запуска, выполняется независимо. Запускается горизонтально, масштабируется.

• Облачные технологии: Эфемерные вычислительные ресурсы используют преимущества полностью эластичных вычислений в публичных облаках.

Гибкое планирование запусков на основе событий

Подход Airflow

Датчики моделей Airflow (например, запускаются каждый раз при обновлении этого контейнера s3) отдельно от временных графиков (например, запускаются ежедневно в 4 утра).

Датчик в Airflow — это задача, которая опрашивает и может работать вечно. Но он существует в DAG, который требует расписания на основе времени (например, ежедневного). Моделирование частоты обновления состояния, от которого зависит датчик, с помощью каденции окружающего DAG неудобно. Например, что происходит, когда ежедневный запуск ждет контейнер s3, который обновляется дважды в день время от времени?

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

Датчики Airflow также занимают «слот» в рабочем пуле. Когда работает слишком много датчиков, датчики могут заполнить все слоты задач и помешать прогрессу во всех запусках. Airflow 2.0 представил экспериментальную функцию смягчения — интеллектуальные датчики — для консолидации датчиков в другом процессе. Однако для этого требуется развернуть выделенный специализированный процесс, который добавляет операционные накладные расходы.

Подход Dagster

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

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

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

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

• Гибкость: Расписания Dagster настраиваются за пределами выражений cron. Например, пользователи могут исключить праздники, характерные для определенной страны.

• Отказоустойчивость: Модель на основе согласования упрощает для пользователей написание отказоустойчивых графиков и датчиков. Демон также вызывает весь пользовательский код вне процесса, поэтому пользователи не могут остановить процесс демона.

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

Контролировать и наблюдать

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

Что мы слышим от пользователей Airflow:

• «Я не знаю, какие вычисления производятся внутри моих DAG».

• «DAG трудно отлаживать быстро».

• «Я понятия не имею, откуда берутся мои данные».

• «Пользовательский интерфейс показывает свой возраст».

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

Orchestrator — это естественный центр тяжести для мониторинга и реагирования на все эти неизбежные ошибки. Он вызывает каждый инструмент, и эти инструменты производят каждый актив данных на предприятии. Практики проводят много времени в этом инструменте.

Пользователи заслуживают красивых, хорошо продуманных инструментов, которые позволяют им легко переходить к ошибкам, проверять прогоны и находить созданные активы. Использование инструмента должно быть увлекательным.

Структурированный журнал событий и система записей

Подход Airflow

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

Отсутствие структурной, неизменяемой записи действий имеет и другие последствия. Истории Airflow нельзя полностью доверять, поскольку многие операционные задачи уничтожают историю. Например, повторная попытка запуска для определенной даты требует удаления предыдущего запуска, связанного с этой датой. Он также не сохраняет исторические структуры DAG, поэтому запуски не воспроизводятся.

Подход Dagster

Основой возможностей мониторинга и наблюдения Dagster является его структурированный журнал событий. Он служит неизменяемой записью для вычислений в Dagster. Журнал управляет реактивными пользовательскими интерфейсами Dagit, создает наш каталог активов и обеспечивает такие возможности пользовательского интерфейса, как хорошо отформатированные трассировки стека и рендеринг markdown непосредственно в средстве просмотра выполнения.

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

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

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

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

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

• Воспроизводимая история: Любую историческую структуру прогона или графика можно воспроизвести, независимо от того, что именно изменилось в системе.

Осведомленность об активах и потоках данных

Подход Airflow

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

Подход Dagster

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

Дагстер считает, что оркестратор должен быть осведомлен об активах. В конце концов, создание активов данных — это то, для чего существуют эти системы.

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

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

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

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

• Ориентированная на активы навигация: Заинтересованные стороны могут индексировать оркестратор по имени актива для рабочих процессов. Им не нужно знать имя конвейера, чтобы получить соответствующую информацию. Названия и структуры конвейеров становятся деталями реализации, как и должно быть.

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

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

• Активы как интерфейс между командами: Мы считаем, что интерфейс между командами должен быть продуктами данных, а не конвейерами. Формальное моделирование датчиков и активов предоставляет мощный инструмент для соединения команд: датчики на основе активов.

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

Заключение

Dagster может служить альтернативой или заменой Airflow (и другим традиционным движкам рабочих процессов), поскольку он выполняет основную функцию планирования, правильного упорядочивания и мониторинга вычислений. Но он выходит за рамки традиционного определения оркестратора, переосмысливая весь сквозной процесс создания и запуска приложений данных. Мы рассматриваем Dagster как:

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

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

• Инструмент наблюдения, предоставляющий потребительские инструменты, поддерживающие операции самообслуживания, быструю отладку и отслеживание активов.

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

Данная статья переведена с английского с адаптациями в рамках курса Тренажер по разработке ETL и оркестрации данных

Спасибо за чтение!