Scheduling & Triggers の To Keep in Mind を読む。

以下を読む。

Scheduling & Triggers — Airflow Documentation

以下超訳（カッコ内は自分の感想）

DAG Run は start_date から始まるよ。これは日付をしないときの話かな。（trigger とは関係なさそう。）
schedule_interval に基づき、連続した DAG Runs は作成されるよ。（そりゃそうだろうね。）
再実行をするために状態の初期化をするときに覚えていたほうがいい重要なことは、DAG Runの状態も、その実行を triggerするタスクを見に行くかどうかを決定する。（今はなんの依存もないタスクであってもtrigger_dags で実行されないからとりあえずいいか。）

ここでタスクをアンブロックすることができる方法がある。（おや、ブロックされているの？）

UIから…（すみません、まだUIとかのレベルではないのでスキップしします）
airflow clear -h はたくさんのオプションがあって次のものを指定できる。日付の範囲、task_id の正規表現、upstream, downstream の関連（！）、ターゲットタスクのインスタンスの失敗や成功。（インスタンスというのは実行かな？　失敗しても、idempotent 的には、永遠に失敗だから、状態をクリアしないと再実行されないのかな…って、そんな感じのメッセージは現在のところ見てないのでこのあたりは関係なさそう。ところで　upstream やdownstream の状態を削除できるのは、luigi ではできなかったことなので、でかい気がするなー。）
UIを通してタスクを成功とマークすることができる。これは主に誤った失敗（すなわち成功している話）の修正や例えばairflow外から修正するためのものである。
CLIのサブコマンド airflow backfill には --mark_success というフラグがあり、日付を指定するのと同様に DAG のsubsection をしているすることを許可する。（ちなみに、--mark_success オプションは上の意味と同じで、実行せずに成功とマークする機能）

で結論。trigger_dag が上手くいかない手がかりは得られなかった。

UI を見る

UI は本当に見れているのか。

airflow webserver -p 8080

みたいな感じで起動。scheduler などとは直接通信をせず、sqlite の中身をみて現状を確認する様子。よって、scheduler が動いていなくてもWebの画面は正常に表示されるし、 trigger_dag のサブコマンドを実行すると、しっかり web 上のステータスもrunningに追加・変更されるので、まるで scheduler が動いているかののような錯覚を覚えるが、 scheduler は webサーバを起動しても特に動くわけではないし、running のステータスも、実は嘘で、running の状態になるように設定されましたくらいの意味。

重要な設定

Google グループ

くそっ、早く気がつくべきだった。

airflow.cfg に下記を設定

[core]
load_examples = False

デバッグコードを埋め込む

以前からあるエラーメッセージ

nakano-tomofumi.hatenablog.com

の原因が何であるかわからない。すなわち、dag_stats.dag_id と dag_run.dag_id は空である、とのことであるが、これは一体どうなっているのか。

調べていくと、jobs.py の関数 process_file が怪しいことがわかった。

そして、実行されるべきDAG の入ったリスト dags は空であることが判明した。また、何故空なのか、調べると、ターゲットのDAGが、is_paused となっていることが分かった。

つづく。

nakano-tomofumi.hatenablog.com