← データエンジニアリング 一覧

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：べき等性と再実行・SQL変換とdbt　|　関連：データガバナンスとカタログ

要点（BLUF）

• オーケストレーションは、多数のタスク（取り込み→変換→集計→配信）の依存関係を管理し、正しい順序で・スケジュール通りに・失敗したら再実行する仕組み。Airflow/Dagster/Prefectが代表。
• パイプラインをDAG（有向非巡回グラフ）で表す。辺が依存（「BはAの後」）、循環は許されない（無限ループになるため）。実行順はトポロジカルソートで決まる。
• 価値は依存解決・スケジューリング・再実行・監視の一元化。各タスクが冪等（→ べき等性と再実行）なら、失敗時に安心して再実行できる。

概念 ── パイプラインをDAGで表す

「抽出が終わってから整形、整形が両方終わってから結合、結合の後にレポート」。この依存を絵にするとDAGになります。

flowchart LR
    EX["extract"] --> SU["stg_users"]
    EX --> SO["stg_orders"]
    SU --> JM["join_mart"]
    SO --> JM
    JM --> RP["report"]

オーケストレータは、この図を読んで「依存を満たす順序」を自動で決め、独立なタスク（stg_usersとstg_orders）は並列に走らせます。dbtのref()によるDAG（→ SQL変換とdbt）や、Sparkの実行DAG（→ Sparkの基礎）と同じ構造です。

仕組み ── トポロジカルソートで実行順を出す

依存を満たす順序は、入次数0（依存なし）のタスクから順に取り出すトポロジカルソートで求まります。

# 各タスク -> 依存（先に終えるべき）タスク
deps = {"extract":[], "stg_users":["extract"], "stg_orders":["extract"],
        "join_mart":["stg_users","stg_orders"], "report":["join_mart"]}
order = topo_sort(deps)   # 入次数0から順に取り出す

実行結果（実機・純Pythonで再現）:

実行順（依存を満たす順序）:
  extract -> stg_orders -> stg_users -> join_mart -> report

extractが最初、reportが最後。stg_users/stg_ordersは順不同（並列可能）。依存が循環していると順序が定義できないため、検出してエラーにします。

循環依存の検出 -> 循環依存を検出

設計の勘所 ── オーケストレータが担うもの

• 冪等性が前提：再実行・バックフィルは「同じ日付分を作り直す」操作。各タスクが冪等（→ べき等性と再実行）でないと、再実行で二重計上する。
• タスクは小さく・独立に：1タスク1責務にすると、失敗箇所だけ再実行でき、並列度も上がる。

なぜそうするか ── 依存と失敗を一元管理する

なぜcronでスクリプトを並べないのか。依存と失敗の管理が破綻するからです。cronは「9時にA、9時15分にB」と時刻でごまかすしかなく、Aが長引けばBが未完成データを読む。タスクが増えるほど時刻調整は地獄になります。オーケストレータは時刻でなく依存で順序を保証し、失敗を検知してそこから再実行し、全体の状態を可視化する。「いつ動かすか」でなく「何の後に動かすか」で組むことが、壊れにくいパイプラインの条件です。

⚠️ よくある落とし穴

• cronの時刻ずらしで依存を表現 → 上流が遅れると下流が未完成データを処理。依存（DAG）で表す。
• タスクが非冪等 → 再実行・バックフィルで二重。冪等に作る（→ べき等性と再実行）。
• 1タスクに何でも詰める → 失敗時に全部やり直し。小さく分割。
• DAGに循環を作る → スケジュールが回らない。設計時に検出。

対応ラボ

data-engineering-study/labs/07_streaming_orchestration.py（PYTHONIOENCODING=utf-8 で実行・トポロジカルソートと循環検出を確認済み）。

関連

• 再実行の安全性の土台は べき等性と再実行、変換DAGは SQL変換とdbt
• 実行DAGの親戚はSparkの Sparkの基礎
• 実行履歴・リネージはガバナンスへ繋がる データガバナンスとカタログ

← 第7章 ストリーミングとオーケストレーション 目次