v1 ETL 基盤の限界 execution_date の仕様が直感的ではない問題 • execution_date は実際に schedule される時間の1つ前の時間が格 納されている — “0 1,13 * * *” という schedule だと 13時に実行される Task の execution_date には 1時が入っている • レビューでひたすら指摘する必要が… Python で自由度高く Workflow を記述できる反面、全体像を把握しにくい • UI で rendering されないと Dag が理解できない — 複数の branching や join があると読むのがかなり厳しくなる — `op1 >> op2 >> op3`, `op2 >> op4 >> op5`, `op4 >> op3`, ... Airflow を利用してもらうコストが高い 基盤の安定性・利用者の開発容易性の観点から Airflow を運用しつづけるのは妥当ではないと判断