ETLとELTパイプライン

抽出・変換・ロードという三段

データパイプラインの骨格は昔から三工程です。抽出（Extract） は業務DB・イベントログ・SaaSのAPI・ファイルなど源泉から生データを取り出す。変換（Transform） は型変換・クレンジング・結合・集約・重複排除でビジネスが使える形に整える。ロード（Load） は結果を分析先（データウェアハウス、データレイク）へ書き込む。

問題は変換をどの順序で、どの計算基盤で行うかです。これがETLとELTを分ける唯一の本質的な差であり、残りは全てそこから派生します。分析基盤の議論なので、ここで扱うのは1行1行のトランザクション処理ではなく、数億〜数十億行を一括で作り替えるバッチ処理の設計だと押さえてください。

ETLからELTへ：なぜ順序が入れ替わったのか

古典的なETLは、抽出したデータを専用の変換エンジン（かつては高価なETL製品や中間サーバー）で加工してからウェアハウスへロードします。ウェアハウスの計算資源が希少で高価だった時代、DWHには「整形済みの最終形」だけを入れ、重い変換は外で済ませるのが合理でした。

ELTはこの順序を反転させ、生データをまず分析基盤へロードし、変換は基盤内のSQL（や分散処理エンジン）で行う。移行を後押ししたのは技術的な地殻変動です。

決定的だったのはクラウドDWH（BigQuery、Snowflake、Redshift系）のストレージと計算の分離です。ストレージが安価になり生データを丸ごと保持できるようになった。さらに計算は必要な時だけ弾力的にスケールするため、「巨大な変換を基盤内でSQLとして走らせる」コストが現実的になった。結果、変換ロジックが変わっても再抽出せず、保持済みの生データを作り直すだけで済むというELTの利点が効いてきます。抽出と変換が疎結合になり、変換はバージョン管理されたSQLとして育てられる（この規律はソフトウェア工学そのもので、/programming/ の設計原則が生きます）。

オーケストレーションと依存管理：本体はDAG

パイプラインの真の姿は、順番に並んだ手順ではなくタスク間の依存関係を表すDAG（有向非巡回グラフ）です。「注文テーブルの取り込みが終わってから、日次売上の集計を走らせ、その後にダッシュボード用マートを作る」——この先行・後続の関係を宣言し、実行を司るのがオーケストレーター（Airflow、Dagster、Prefect等）です。

オーケストレーターの役割は四つに集約されます。

• 順序と並列の制御：依存が無いタスクは並列に、あるタスクは先行完了を待って実行する。
• 再試行：一時障害で落ちたタスクをバックオフ付きで再実行する。
• 待機（センサー）：上流ファイルの到着や先行パーティションの充足など、外部条件が満たされるまで待つ。
• 可視化と履歴：どのタスクがどの区間で成功／失敗したかを追跡する。

extract_orders ─┐
                ├─► build_daily_sales ─► build_sales_mart ─► refresh_dashboard
extract_users ──┘

ここで初心者と実務者を分ける論点があります。時刻で駆動するな、データの準備完了で駆動せよ。「毎日9時に集計」ではなく「対象日のパーティションが揃ったら集計」で動かす。上流が遅延しても、時刻トリガーは空や欠損のデータを平然と処理してしまうが、データ駆動なら揃うまで待つ。分散システムでは上流の遅延・欠損・再送は日常なので（/devops/ の非同期処理と同じ前提）、依存はデータの存在で表すのが安定運用の分かれ目です。

冪等性：再実行が安全であること

バッチパイプラインで最重要の性質が冪等性（idempotency）です。定義は「同じ入力に対し、タスクを何回実行しても最終結果が同じに収束する」。なぜ死活的かというと、オーケストレーターの再試行も、後述のバックフィルも、障害復旧も、すべてタスクの再実行だからです。再実行が結果を二重化するようでは、パイプラインは触れば壊れる代物になります。

非冪等な典型は**追記（append/INSERT）**です。同じ区間を二度走らせれば行が二重に積まれます。冪等にする定石は「追記ではなく、区間を丸ごと置換する」ことです。

非冪等：INSERT INTO sales SELECT ... WHERE date = '2026-06-20'
        → 再実行するたび同じ行が重複して積み上がる

冪等：  対象パーティション date='2026-06-20' を削除してから書く
        （partition overwrite）
        あるいは主キーで MERGE（UPSERT）して一意性を保つ
        → 何度実行しても最終状態は 1 通りに収束

実装の柱は二つ。パーティション単位の上書き（対象日のパーティションを消してから作り直す＝その区間の出力は毎回同じ）と、キーによる MERGE/UPSERT（主キーで突き合わせ、既存は更新・新規は挿入し重複を作らない）。どちらも「出力は入力の決定的な関数」という状態に持ち込むための手段です。ここが担保されて初めて、次のバックフィルが道具として使えます。

バックフィル：過去を作り直す

**バックフィル（backfill）**は、過去のデータ区間を遡って作り直す運用です。新しいマートを追加して過去1年分を埋める、変換ロジックのバグを直して影響区間を再生成する、欠損期間を補う——いずれも「過去の複数区間を、今のロジックで再実行する」ことに帰着します。

バックフィルが安全に回るための前提は二つです。第一に冪等性——各区間の再実行が重複や破壊を起こさないこと。第二に区間の独立性（パーティション設計）——日付などで区切られ、ある区間の再生成が他区間に波及しないこと。この二つが揃うと、バックフィルは単に「対象区間の集合に対し、同じ冪等タスクを並列に流す」作業になります。

バックフィル対象：2026-06-01 〜 2026-06-30（30区間）
  各区間は独立 → 並列実行可
  各区間は冪等 → 途中で失敗しても、その区間だけ再実行すれば復旧
  → 全体の再生成が「安全に・部分的に・繰り返し」可能

データ品質：契約と検証

生データは必ず汚れます。欠損・型崩れ・重複・遅延到着・意味のずれ。ELTでは生を先に積むぶん、変換の各段でデータ品質（data quality）を検証する関門を設けるのが要です。検証は大きく二層に分けて考えます。

• スキーマ・契約（contract）：列・型・NULL可否・値域・一意性・参照整合性が期待どおりか。源泉側の破壊的変更（列削除・型変更）を下流に波及させないための境界です。
• 統計・意味（volume/semantics）：行数が普段の範囲か、重複率・NULL率が急変していないか、日次の合計が桁違いになっていないか。壊れた成功（エラーは出ないが値が異常）を捕まえる層です。

実務では品質チェックをパイプラインの一タスクとして DAG に組み込み、期待を満たさなければ下流を止める（fail fast）か、疑わしいデータを隔離（quarantine）します。遅延到着（late-arriving data）——イベント時刻は昨日なのに今日届くデータ——には特に注意が要り、締め切り後に来た分を後から取り込めるよう、対象区間を冪等に再計算できる設計（＝前節の置換／MERGE）が前提になります。ここでも冪等性が効いてくる。

まとめ

• ETLとELTの唯一本質的な差は変換の順序と実行場所。ETLは外部エンジンで変換してからロード、ELTは生を先にロードして基盤内SQLで変換する。
• ELT移行の核心はクラウドDWHのストレージと計算の分離。生データを安価に保持でき、ロジック変更時も再抽出せず再変換だけで済む。
• パイプラインの本体は手順ではなくDAGによる依存管理。オーケストレーターが順序・並列・再試行・センサー待機を司り、時刻でなくデータの準備完了で駆動するのが安定運用の鍵。
• 本番の要は冪等性。同じ入力なら何度実行しても結果が一意に収束するよう、追記でなくパーティション置換／MERGEで書く。処理時刻など実行依存の値を出力に混ぜない。
• バックフィルは過去区間の再実行であり、冪等性と区間独立性が揃えば「安全に・部分的に・並列に」作り直せる。
• データ品質は契約（スキーマ・値域・一意性）と統計（行数・NULL率・合計）の二層で DAG に組み込み、遅延到着は冪等な再計算で吸収する。