АНАЛИТИКА ПЛЮС
Профессиональные услуги в сфере BI

Airflow VS Prefect

21.06.2022

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

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

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

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

 

Обзор

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

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

— DAG, которые необходимо запускать вне расписания или вообще без расписания

—D AG, которые выполняются одновременно с одним и тем же временем запуска

— DAG со сложной логикой ветвления

— DAG со множеством быстрых задач

— DAG, которые основаны на обмене данными

— Параметризованные DAG

— Динамические DAG

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

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

API

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

— Документация по Airflow

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

Однако API Airflow полностью императивен и основан на классах. Кроме того, из-за ограничений, которые Airflow накладывает на то, что рабочие процессы могут и не могут делать (подробнее об этом в последующих разделах), написание DAG-файлов Airflow похоже на написание кода Airflow.

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

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

Один из способов добиться этого — использовать «функциональный API» от Perfect. В этом режиме задачи ведут себя точно так же, как функции. Вы можете вызывать их с помощью входных данных и работать с их выходами — вы даже можете преобразовать любую функцию Python в задачу с помощью одной строки кода Prefect. Это упрощает преобразование существующего кода или скриптов в полноценные рабочие процессы Prefect.

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

 

Планирование и время

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

airflow test tutorial print_date 2015–06–01

## Output

AIRFLOW_CTX_EXECUTION_DATE=2015–06–01T00:00:00+00:00

[2019–04–17 15:54:45,679] {bash_operator.py:110} INFO - Running command: date

[2019–04–17 15:54:45,685] {bash_operator.py:119} INFO - Output:

[2019–04–17 15:54:45,695] {bash_operator.py:123} INFO - Wed Apr 17 15:54:45 PDT 2019

и задаться вопросом: что означают все эти разные времена?

Airflow имеет строгую зависимость от определенного времени: execution_date. Ни один DAG не может выполняться без даты выполнения, и ни один DAG не может выполняться дважды для одной и той же даты выполнения. Есть ли у вас конкретный DAG, который нужно запустить дважды, причем оба экземпляра запускаются одновременно? Airflow этого не поддерживает; исключений нет. Airflow просто объявляет, что таких рабочих процессов не существует. Вам нужно будет создать два почти идентичных DAG, или запустить их с интервалом в миллисекунду, или использовать другие креативные хаки, чтобы это сработало.

Что еще более запутанно, execution_date Airflow интерпретирует не как время начала DAG, а как конец интервала, ограниченного временем начала DAG. Первоначально это было связано с требованиями оркестровки ETL, когда задание для данных от 2 мая должно было выполняться 3 мая. Сегодня это источник серьезной путаницы и одно из самых распространенных недоразумений, с которыми сталкиваются новые пользователи.

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

Это означает, что если вы хотите:

— Выполнять свой рабочий процесс по нерегулярному (или отсутствующему) расписанию

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

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

тогда Airflow — неправильный инструмент.

 

Prefect

В отличие от Airflow, Prefect рассматривает рабочие процессы как автономные объекты, которые могут быть запущены в любое время, с любым параллелизмом (одновременно с другими процессами) и по любой причине. Расписание — это не что иное, как заранее определенная настройка времени начала, и вы можете сделать свои расписания настолько простыми или сложными, насколько захотите. И если вы действительно хотите, чтобы ваш рабочий процесс зависел от времени, просто добавьте его в качестве параметра потока.

 

Планировщик

Планировщик Airflow является основой Airflow. Этот сервис имеет решающее значение для производительности Airflow и отвечает за:

— Регулярное чтение папки DAG каждые несколько секунд

— Проверка расписаний DAG для определения готовности DAG к запуску

— Проверка всех зависимостей задач, чтобы определить, готовы ли какие-либо задачи к запуску

— Установка окончательных состояний DAG в базе данных

И наоборот, Prefect разделяет большую часть этой логики на отдельные (необязательные) процессы:

 

Prefect Flow scheduling

Планирование потока в Prefect — это легкая операция. Мы просто создаем новый запуск потока и переводим его в запланированное состояние. На самом деле, когда мы говорим о «планировщике» Prefect Cloud, это его исключительная ответственность. Наш планировщик никогда не участвует в какой-либо логике рабочего процесса или его выполнении.

 

Prefect Flow logic

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

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

# run your first Prefect flow from the command line

python -c «from prefect import Flow; f = Flow(’empty’); f.run()»

 

Prefect Task scheduling

Когда выполняется поток, он выполняет планирование для своих собственных задач. Это важно по нескольким причинам:

— Как источник логики рабочего процесса, поток является единственным объектом, который должен нести эту ответственность

— Это снимает огромную нагрузку с центрального планировщика

— Это позволяет потоку принимать решения об уникальных обстоятельствах, таких как динамически генерируемые задачи (например, в результате работы оператора map)

— Это позволяет Prefect передавать детали выполнения на аутсорсинг внешним системам, таким как Dask

Этот последний момент очень важен. Хотя Airflow поддерживает множество сред выполнения, включая локальные процессы, Celery, Dask и Kubernetes, он остается узким местом из-за собственного планировщика, который (с настройками по умолчанию) занимает 10 секунд для выполнения любой задачи (5 секунд, чтобы пометить ее как поставленную в очередь, и 5 секунд, чтобы отправить ее на выполнение). Независимо от того, насколько велик ваш кластер Dask, Airflow все равно будет запрашивать у него выполнение задачи только каждые 10 секунд.

Perfect, напротив, использует современные технологии. Когда вы запускаете Prefect на Dask, используется планировщик задач Dask с задержкой в миллисекунды, чтобы выполнять все задачи как можно быстрее, с максимально возможным параллелизмом, который предлагает кластер. Действительно, спецификация развертывания по умолчанию для Prefect Cloud развертывает кластеры задач в Kubernetes (это также настраивается).

Помимо производительности, это имеет большое значение для того, как проектируются потоки: Airflow поощряет «большие» задачи; Prefect поощряет небольшие модульные задачи (и все еще может обрабатывать большие задачи).

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

 

Выводы

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

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

— Централизованный характер планировщика Airflow обеспечивает единую точку отказа для системы

— Повторное использование DAG в каждом отдельном цикле может привести к серьезным несоответствиям (планировщик может запустить задачу, которая при повторной установке обнаруживает, что она даже не существует)

— Централизованное планирование обычно означает, что задачи не могут взаимодействовать друг с другом (нет разрешения зависимостей)

 

Поток данных

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

Что предлагает Airflow, так это «XCom», утилита, которая была введена для того, чтобы позволить задачам обмениваться небольшими фрагментами метаданных. Это полезная функция, если вы хотите, чтобы задача A сообщала задаче B, что большой фрейм данных был записан в известное место в облачном хранилище. Однако он стал основным источником ошибок Airflow, поскольку пользователи пытаются использовать его в качестве надлежащего механизма передачи данных.

XCom’ы используют доступ администратора для записи исполняемых файлов pickles в базу данных метаданных Airflow, что имеет последствия для безопасности. Даже в форме JSON он имеет огромные проблемы с конфиденциальностью данных. Эти данные не имеют TTL или срока действия, что создает проблемы с производительностью и стоимостью. Что наиболее важно, использование XComs создает строгие восходящие / нисходящие зависимости между задачами, о которых Airflow (и его планировщик) ничего не знают! Если пользователи не проявят дополнительной осторожности, Airflow может фактически выполнить эти задачи в неправильном порядке. Рассмотрим следующую схему:

def puller(**kwargs):

ti = kwargs['ti']

# get value_1

v1 = ti.xcom_pull(key=None, task_ids='push')

Эта задача явно зависит от действия, выполняемого задачей «push», но Airflow не может этого знать. Если пользователь явно (и избыточно) не разъясняет это Airflow, то планировщик может запускать эти задачи не по порядку. Даже если пользователь сообщит Airflow об этой связи, Airflow не сможет понять, что это связь, основанная на данных, и не будет знать, что делать, если XCom push завершится неудачей. Это один из наиболее распространенных, но тонких и трудных для отладки классов ошибок Airflow.

К сожалению, частым результатом для новичков Airflow является то, что они уничтожают свою базу метаданных из-за чрезмерного использования XCom. Были случаи, когда кто-то создавал скромный (10 ГБ) фрейм данных и использовал XComs для передачи его через различные задачи. Если имеется 10 задач, то каждый отдельный запуск этого DAG записывает 100 ГБ постоянных данных в базу данных метаданных Airflow.

 

Prefect

В основе Prefect — поток данных. Задачи могут получать входные данные и возвращать выходные данные, и Prefect управляет этой зависимостью прозрачным способом. Кроме того, Prefect почти никогда не записывает эти данные в свою базу данных; вместо этого хранение результатов (только при необходимости) управляется безопасными «обработчиками результатов», которые пользователи могут легко настроить. Это дает много преимуществ:

— Пользователи могут писать код, используя знакомые шаблоны Python

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

— Шаблоны в стиле Airflow без зависимостей по-прежнему поддерживаются (а иногда и поощряются!); просто потому, что Prefect допускает поток данных, это не значит, что вы должны его использовать!

— Поскольку задачи могут напрямую обмениваться данными, Prefect может поддерживать более сложную логику ветвления, более богатые состояния задач и обеспечивать более строгий контракт между Задачами и Исполнителями в потоке (например, задача не может изменять состояния своих нижестоящих задач в базе данных).

 

Параметризованные рабочие процессы (Parametrized Workflows)

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

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

 

Prefect

Perfect предлагает удобную абстракцию для таких ситуаций: Parameter. Параметры в Prefect — это особый тип задачи, значение которой может быть (необязательно) переопределено во время выполнения. Например, локально мы могли бы иметь:

from prefect import task, Parameter, Flow

@task

def return_param(p):

return p

with Flow(»parameter-example») as flow:

p = Parameter( «p», default=42)

result = return_param(p)

flow.run() # uses the value 42

flow.run(p=99) # uses the value 99

При запуске в развертывании с Prefect Cloud значения параметров могут быть предоставлены с помощью простых вызовов GraphQL или с помощью Python-клиента Prefect.

Это дает много преимуществ:

— Гораздо более прозрачная цепочка данных на случай, если что-то пойдет не так

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

— Позволяет настраивать рабочие процессы, реагирующие на события, и рабочий процесс может следовать различным ветвям в зависимости от типа или содержимого события

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

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

 

Динамические рабочие процессы (Dynamic Workflows)

В дополнение к параметризованным рабочим процессам часто бывает так, что в рамках рабочего процесса существует некоторая задача, которую необходимо повторить неизвестное количество раз. Например, представьте себе установку, в которой задача A запрашивает в базе данных список всех новых клиентов. Отсюда каждый идентификатор клиента должен быть передан в задачу, которая каким-то образом «обрабатывает» этот идентификатор. В рамках Airflow есть только один вариант: реализовать нижестоящую задачу B, которая принимает список идентификаторов и перебирает их для выполнения некоторого действия. У этой реализации есть серьезные недостатки:

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

— Если выполнение какой-либо отдельной записи завершается неудачей, вся задача завершается неудачей

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

Поскольку это такой распространенный шаблон, Perfect превращает его в функцию «Task mapping». Сопоставление (map) задач относится к способности динамически создавать новые копии задачи во время выполнения на основе выходных данных вышестоящей задачи. Сопоставление особенно эффективно, потому что вы можете сравнить сопоставленные задачи, легко создавая динамические параллельные конвейеры. Уменьшить или собрать результаты этих конвейеров так же просто, как передать сопоставленную задачу в качестве входных данных для не сопоставленной задачи. Рассмотрим этот простой пример, в котором был создан список, где дважды сопоставляется каждый элемент, чтобы добавить единицу к его значению, а затем выполняется reduce, беря сумму результата:

from prefect import task, Flow

@task

def create_list():

return [1, 1, 2, 3]

@task

def add_one(x):

return x + 1

@task

def get_sum(x):

return sum(x)

with Flow( «simple-map») as f:

plus_one = add_one.map(create_list)

plus_two = add_one.map(plus_one)

result = get_sum(plus_two)
f.run()

Сопоставление задач дает много преимуществ:

— Шаблон сопоставления очень легко указать в вашем потоке

— Каждая задача является отдельным экземпляром, что означает, что она может быть повторена / предупреждена для каждого отдельного и независимо от всех остальных

— Каждое выполнение вашего потока может порождать разное количество задач (здесь мы жестко задали размер списка, но он мог быть любым или даже динамическим!)

 

Версионированные рабочие процессы (Versioned Workflows)

Важной особенностью любой системы, основанной на коде, является возможность изменения версии вашего кода.

Напомним, что в Airflow DAG обнаруживаются центральным планировщиком путем проверки обозначающей папки «DAG» и выполнения файлов Python, содержащихся внутри, для поиска определений DAG. Это означает, что если вы обновите код для данного DAG, Airflow загрузит новый DAG и продолжит работу вслепую, не осознавая, что было внесено изменение. Если ваши определения DAG меняются или регулярно обновляются, это приводит к нескольким проблемам:

— Возможность повторного просмотра или даже запуска ваших старых DAG требует от вас сохранения старого кода и имен как отдельных объектов в вашей экосистеме Airflow

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

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

В Prefect Cloud версионированные рабочие процессы это базовая концепция. Любой рабочий процесс может стать частью «группы версий» для легкого отслеживания и ведения вашей истории. Как всегда, есть разумные настройки:

— Управление версиями происходит автоматически при развертывании потока в проекте, который уже содержит поток с тем же именем

— Когда поток версионируется, он получает увеличенный номер версии, и все предыдущие версии автоматически архивируются (что отключает автоматическое планирование).

Оба эти параметра можно настроить, если у вас более сложные требования к управлению версиями. Например, вы можете указать, что любой поток является версией любого другого потока, независимо от имени или проекта. Вы можете переопределить автоматическое продвижение версии для разархивирования и включить старые версии (например, для A/B-тестирования). Или же вы можете использовать управление версиями просто для ведения истории вашего рабочего процесса, не загрязняя ваш пользовательский интерфейс.

 

Локальное тестирование

Поскольку и Airflow, и Prefect написаны на Python, можно выполнить модульное тестирование вашей индивидуальной логики задачи / оператора, используя стандартные шаблоны Python. Например, в Airflow вы можете импортировать DagBag, извлечь свой отдельный DAG и сделать различные утверждения о его структуре или задачах, содержащихся в нем. Аналогичным образом, в Prefect вы можете легко импортировать и проверять свой поток. Кроме того, как в Airflow, так и в Perfect вы можете модульно тестировать каждую отдельную задачу почти так же, как вы бы проводили модульное тестирование любого другого класса Python.

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

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

— Понятие «State» задачи в Airflow — это просто строка, описывающая состояние; это усложняет тестирование прохождения данных или того, какие типы исключений возникают, и требует запросов к базе данных для определения

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

Например, чтобы убедиться, что ваша логика запуска работает для отдельной задачи, вы можете передать все состояния вышестоящей задачи через аргумент ключевого слова task_states; поскольку Prefect возвращает полностью обновленные состояния объектов (которые включают в себя такую информацию, как данные, исключения и время повторения), вы можете легко создавать утверждения на основе характера возвращаемого состояния для интересующей задачи.

Интерфейс

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

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

Пользовательский интерфейс Prefect поддерживает:

— Дашборды для обзора системы

— Планирование новых параметризованных запусков

— Оперативное обновление состояний задач и выполнения

— Обновление состояний вручную

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

— Полный интерактивный GraphQL API

— Глобальный поиск

— Управление агентами

— Проекты по организации потоков

— Управление командой и выполнениями

— Генерация токена API

— Глобальные ограничения параллелизма

— Часовые пояса (это для вас, пользователи Airflow!)

…и еще немного

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

 

Выводы

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

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

x

Этот сайт использует файлы cookies, чтобы облегчить вам пользование нашим веб-сайтом.

Продолжая использовать этот веб-сайт, вы даете согласие на использование файлов cookies.