Планирование тысяч задач с помощью Airflow

Question

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

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

Другой вариант - это иметь только несколько параллельных долгосрочных задач, а затем реализовать собственный планировщик в этих задачах. Мы можем добавить пользовательский код в PythonOperator, который будет запрашивать базу данных и решать, какой API вызывать дальше.

Возможно, Airflow не очень подходит для такого случая использования, и было бы проще и лучше внедрить такую ​​систему за пределами Airflow? Кто-нибудь имеет опыт работы с тысячами задач в Airflow и может пролить свет на плюсы и минусы приведенного выше варианта использования?

Answer 1

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

Не уверен если вы планируете запускать Airflow, но если загрузка через GCP и загрузка занимает не более 9 минут, вы можете использовать следующее:

task (PythonOperator) -> pubsub -> cloud function (to retrieve) -> pubsub -> function (to save result to backend).

Последняя функция может не потребоваться, но мы (повторно) используйте обобщенный c и простой «bigquery streamer».

Наконец, вы запрашиваете в последующей задаче AF (PythonSensor) количество результатов в бэкэнде и сравниваете с количеством опубликованных запросов.

Мы делаем это достаточно эффективно для вызовов 100K API сторонней системе, которую мы размещаем на GCP, поскольку мы максимизируем параллелизм. Приятной особенностью GCF является то, что вы можете настроить архитектуру для использования и параллелизма вместо предоставления виртуальной машины или контейнера для выполнения задач.