言いたいこと
subdag使うなら注意点多いよ
Cloud ComposerとかAstronomerもオススメしないと言っているよ
subdagとは
複数のタスクをDAGとして切り出して、別のDAGから使える機能です。
公式ドキュメントでいうと、ここらへんに説明があります。
いいじゃん
Airlfowサービス提供者いわく「やめとけ」らしいです
- Cloud Composerいわく「SubDagOperator の使用はおすすめしません」
- Astonomerいわく「Astronomer highly recommends staying away from SubDags」
（Airflowを使っているWePayさんも「We have shied away from using some of Airflow’s more exotic features, such as backfill, subdags」と言っています）
なんで悪いのか
いろいろ面倒な点があるっぽいです。各々の問題は対処出来るかもしれませんが…
Executorの問題
（Executor全般についてはAstronomerさんの記事がわかりやすいです）
SubDagOperatorではExecutorを指定する事が出来ます。
が、SequentialExecutor以外（CeleryExecutorやLocalExecutor）を使うのは危険らしく、公式ドキュメントには
「it is possible to specify an executor for the SubDAG. It is common to use the SequentialExecutor if you want to run the SubDAG in-process and effectively limit its parallelism to one. Using LocalExecutor can be problematic as it may over-subscribe your worker, running multiple tasks in a single slot」
とあったり、CeleryExecutorで問題が生じるらしいです。
が、SequentialExecutorだと並列して実行出来ない…
SubDag「Operator」が単一障害点
subdagを使うとSubDagOperator自体のタスクインスタンスも作られます。
Composerはこの点を問題視しており、「SubDag タスクを実行しているワーカーが終了すると、SubDag 内のすべてのタスクが失敗し、ワークフローの信頼性が低下します」と説明しています。
実際、(1)SubDagOperatorを実行、(2)workerに入ってSubDagOperatorのタスクのプロセスを殺すと、下図のように
- subdag中のタスクインスタンスは成功
- SubDagOperatorタスクインスタンスは失敗した状態になります。
- SubDagOperatorのdownstreamのタスクがupstream_failedで未実行
プール
（この部分は自信ないです…）
SubDagOperatorのソースコードに「 Airflow pool is not honored by SubDagOperator」とあるように、subdag+プールの挙動は怪しいです。
例えば、下図はsubdag中でたくさんタスク実行した時のプール状況ですが、Slotsよりも多くのタスクインスタンスが実行(Used Slots)されています。
ソースコード眺めた感じ、
- SubDagOperatorはBackfillJobでタスクインスタンスをキック
- 普通のDAGはSchedulerJobでタスクインスタンスをキック
- タスクインスタンスがプールが実行出来るかのチェックは、SchedulerJobでやっており、BackfillJob中ではやっていない？
のが原因ぽいです。
補足
この話は2019年10月の時点（Airflow1.10.2以前）の話ですが、少しずつ良くなっていくようです。
例えば、1.10.2ではSubDagOperatorは単にsubdagを実行するだけですが、masterのコードではsubdagが無ければ作り、すでにあればその終了を待ちます。
＝SubDagOperator自体のリトライ時にsubdag内がリトライされず、SubDagOperatorが単一障害点であることの問題が起きにくい