オーケストレーションと運用

データの処理は「取り込みが終わったら変換、変換が終わったらテストとダッシュボードの更新」のようにつながっています。オーケストレーターは、この依存関係とスケジュールを管理し、失敗したら再実行し、通知を出す道具です。Airflow・Dagster・Prefect などがあり、クラウドの管理サービスもあります。

DAG（有向非巡回グラフ）は、処理（タスク）を矢印でつないだ図で、「戻る矢印がない」ので必ず終わりがあります。Airflow では Python で DAG を書き、各タスクの再試行の回数・間隔・タイムアウトを設定します。Dagster は「どのテーブル（アセット）がどのテーブルから作られるか」を中心に書くので、データの依存関係とそのまま対応します。

オーケストレーターの中で重い処理をしないのも大事です。実際の計算は DWH や Spark にさせ、オーケストレーターは「指示して、結果を待つ」役に徹します。

バックフィルは、過去の期間をさかのぼって処理し直すことです。ロジックを直したとき、新しいパイプラインを過去分まで埋めるとき、障害で抜けた日を埋めるときに使います。うまくやるコツは次のとおりです。

• タスクを「対象の期間（Airflow ではデータの期間・論理日付）」を受け取る形にし、実行した日時（今日）を処理の中で使わない。こうすれば過去の日付を渡すだけで再現できます。
• 各期間の処理を冪等にしておく（何度流しても同じ結果）。
• 同時に流す数を絞る。一気に100日分流すと、DWH の料金や業務 DB への負荷が跳ね上がります。

流す前に、何日分を、どの順で、何並列で、いくらかかりそうかを見積もり、下流の利用者に「この期間の数字が変わる」と知らせます。終わったら、作り直す前と後で件数と主な指標を比べます。

再試行してよいのは、処理が冪等なときだけです。冪等でない処理を自動で再試行すると、重複が増えます。また、データの中身の問題（テストの失敗）は再試行しても直らないので、再試行せずにすぐ知らせます。

「毎朝 6時に変換を流す」だけだと、上流の取り込みが遅れた日に、昨日のデータのまま、あるいは途中までのデータで集計してしまいます。

DAG は大きすぎても細かすぎても運用しにくくなります。「一緒に失敗して、一緒にやり直すもの」を1つの DAG にまとめるのが目安です。

パイプラインは毎日どこかで失敗します。失敗したときに誰が・何を見て・どう判断するかを決めておくと、毎朝の対応が短くなります。

毎朝の「失敗の確認と再実行」に時間を取られているなら、それは仕組みで減らすべき作業です。失敗の種類と回数を記録して、多いものから直します。