У нас на s3  такое писалось

- как ниже уже написали - файлы
- вариант записи в отдельную бд и потом одним sql сенсор в каждый витринный даг(ну или все витрины в одном даге, тут как вам удобней)
- вариант sql сенсора в бд airflow - этот варик чуть хуже отдельной таблицы/базы так как вы лочитесь на внутреннюю структуру таблиц airflow и при будущих апдейтах может что-то сломаться в пайплайнах.
- еще вариант - в часовой даг depend_on_past а в даги с витринами даг сенсор с необходимым оффсетом

Я бы проверил 23 при помощи модели DagRun https://airflow.apache.org/docs/apache-airflow/stable/_api/airflow/models/dagrun/index.html

А 24-й (если возможно их одновременное выполнение) – в сенсор. Хотя можно и без него, просто рэйзить исключение на reschedule. Такое можно сделать на кастомном сенсоре, например

Всем привет!
Подскажите, можно ли настроить так, чтобы по завершению DockerOperator airflow чистил за собой завершенные контейнеры? а то их скапливается приличное количество

можно

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

Привет всем). Использую TriggerDagRunOperator и в даге который запускаю в default_args указаны 'retries': 2, но при падении дага попыток перезапуска нет. Может я не так использую перезапуск в triggered dag?

параметр auto_remove

Да, уже нашел. Спасибо большое!

Привет!

Подскажите, пожалуйста, можно ли ограничить максимальное количество планируемых дагранов?
Я хочу, чтобы пока есть активный дагран (в состоянии running), шедулер не планировал новые даграны (они появляются в состоянии queued). По аналогии с параметром max_active_runs, но не только для дагранов в состоянии running. Версия 2.1.4

а для чего это нужно?
стало интересно какой use case

Max_active_queues

Добрый день!
Как выставлять дагран в success,  если все таски в нем skip?

сделать последнюю задачу с другим trigger_rule

Так получается, что у дагранов промежуток 10 минут, но но одновременно может исполняться только один (max_active_runs=1), иногда шедулер тормозит, даги пускаются в очередь и не исполняются, в это время уже новые даграны шедулятся, новым дагранам отдается больший приоритет, а старые просто пропускаются

Поможет ли такой оператор в таком случае

То есть таски в дагране даже не запускаются, как я понял

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

А разве можно weightrule дагу поставить, а не таске?
То, что вы описали, больше на catchup похоже