Airflowのschedule整理
airflowのスケジューラーはDagの実行を、期間で捉える。
execution_date ~ start_date を1つの期間として、実行する。
考え方としては、スケジューラーで実行する = 前回の実行 ~ 今回の実行までの期間を対象として、Dagが動く。
なので
- 期間の終わりであるstart_dateが、実際のDagの実行時間
- 期間の始まりであるexecution_dateが、前回のDagの実行時間
となる。
Dagにデフォルト引数で渡すstart_dateは、グローバルに設定される最初の実行時間である。
スケジューラーは、有効になったDagのmin(start_date)で実行期間を決める。
schedule_intervalが期間の長さになるため、start_date + schedule_intervalをstart_dateにして、初回の実行インスタンスが作成される。
引数のstart_dateの取り扱いはFAQに書いてあったので、最初理解するのに時間かかった。
初回だけ引数のstart_dateがexecution_dateと同等の扱いになっているんだなあ、という感じ。(名前が同じなのでややこしい)
次回以降の実行も、同様にexecution_date + execution_date + schedule_interval で実行される。
airflowのUI上は、start_dateが実行時刻のためschedule実行の場合はexecution_date + schedule_intervalがstart_dateと同等になっている。
manual triggerで実行する場合、スケジューラーで動かす(schedule trigger)とはまた概念が変わる。
この記事にあるとおり、点をイメージすると分かりやすかった。
マニュアルで実行する場合、execution_dateとstart_dateはほぼ同等である。
なぜなら、期間のインスタンスを作らずにその場で即時実行するから、と理解している。
schedule_interval=Noneで指定すると、スケジューラーはそのDagを拾わない。
手動実行する場合は、NoneでDagを作るのが適していそう。
↑の記事で指摘されているとおり、schedule triggerとmanual triggerがUI上混ざるため、一見時系列がおかしく見える場合があるので注意。
schedule_intervalにcronを指定したと仮定して、具体例を書いておく
現在時刻
- 2021/12/1 13:30:00
dagのargs
- start_date: 2021/12/1 14:00:00
- schedule_interval: 30 * * * *
- 毎時間30分に起動
である場合、以下のように期間が決まる
- execution_date: 2021/12/1 14:30:00
- start_date: 2021/12/1 15:30:00