LabHub

ブログ

データオーケストレーション 2025 完全ガイド: dbt・SQLMesh・Dagster・Airflow・Prefect、データ契約、CI/CD (2025)

2026-04-15 · 15 分で読めます · #data-orchestration#dbt#sqlmesh#dagster#airflow#prefect#data-contracts#data-observability#deep-dive#series

한국어English日本語中文

Season 5 Ep 4 — Ep 3 が「誰が速くクエリするか」だったとすれば、Ep 4 は「誰がパイプラインを治めるか」。2025年のデータオーケストレーションは、エンジニアリング原則（CI/CD・テスト・契約）がデータに移植されている最中だ。

Prologue — 「データパイプラインもソフトウェアだ」

2010年代のデータエンジニアリングは「SQL スクリプト + cron」だった。2025年は違う:

この変化は Analytics Engineer という新しい職種を生み、dbt がその中心に立った。しかし 2025年は dbt だけではない — SQLMesh・Dagster が実質的な代替として、Airflow・Prefect は依然として汎用オーケストレーションの王座を守っている。

第1章 · オーケストレーションツールの分類

1.1 2つの軸

1.2 主要ツール

ツール主な役割哲学
dbt Core / CloudSQL 変換Analytics Engineer の標準
SQLMeshSQL 変換バージョン・増分・状態
DagsterオーケストレーションAsset-centric
Airflow 2/3オーケストレーションTask DAG、汎用
Prefect 3オーケストレーションPythonic、動的
Temporalワークフロー信頼性・ステートマシン
Mage, Kestraオーケストレーション新世代

第2章 · dbt — Analytics Engineer の標準

2.1 アイデンティティ

2.2 コア概念

2.3 依存関係の管理

-- models/fact_orders.sql
SELECT *
FROM {{ ref('stg_orders') }}
JOIN {{ ref('dim_customers') }} USING (customer_id)

2.4 2024–2025 の動向

2.5 限界

2.6 使いどころ

第3章 · SQLMesh — 「dbt の代替か補完か」

3.1 アイデンティティ

3.2 コアとなる差別化点

3.3 哲学

「dbt の生産性 + データウェアハウスの厳格さ + DevOps のセーフティネット」

3.4 例 — 増分モデル

MODEL (
  name core.fact_orders,
  kind INCREMENTAL_BY_TIME_RANGE (
    time_column order_date,
  ),
);

SELECT *
FROM raw.orders
WHERE order_date BETWEEN @start_date AND @end_date;

→ SQLMesh が増分処理・バックフィル・キャッシュを自動管理する。

3.5 限界

3.6 使いどころ

第4章 · Dagster — 「Asset-centric の革命」

4.1 アイデンティティ

4.2 コアとなる違い

from dagster import asset

@asset
def orders(raw_data):
    return transform(raw_data)

@asset
def customer_lifetime_value(orders, customers):
    return compute_clv(orders, customers)

4.3 強み

4.4 2024–2025 の動向

4.5 限界

4.6 使いどころ

第5章 · Airflow — 「依然として最も広く使われている」

5.1 アイデンティティ

5.2 Airflow 2.x

5.3 Airflow 3.0 (2024–2025)

5.4 マネージドの選択肢

5.5 強み

5.6 限界

第6章 · Prefect — 「Pythonic なオーケストレーション」

6.1 アイデンティティ

6.2 Prefect 2.x → 3.0

6.3 強み

6.4 限界

6.5 使いどころ

第7章 · Temporal — 「ワークフローエンジンの別系譜」

7.1 アイデンティティ

7.2 Airflow との違い

7.3 使いどころ

第8章 · データ契約（Data Contracts）

8.1 何なのか

8.2 構成

8.3 ツール

8.4 例 (dbt Contract)

models:
  - name: dim_customers
    config:
      contract:
        enforced: true
    columns:
      - name: customer_id
        data_type: bigint
        constraints: [{type: primary_key}, {type: not_null}]
      - name: email
        data_type: varchar
        constraints: [{type: not_null}]

8.5 運用

第9章 · データパイプラインの CI/CD

9.1 Git・ブランチ戦略

9.2 CI のステージ

  1. Lint（sqlfluff, dbt lint）
  2. コンパイル（dbt compile, SQLMesh plan）
  3. ユニットテスト（モデル単位のサンプル）
  4. 契約の検証
  5. Staging 環境で部分実行
  6. 統計 diff（Datafold など）

9.3 環境の分離

9.4 デプロイ戦略

9.5 オブザーバビリティの統合

第10章 · オブザーバビリティ（Observability）とアラート

10.1 5つの柱（Monte Carlo）

10.2 ツールの地形

10.3 アラートの設計

10.4 SLO

第11章 · 実際のスタック構成5種

11.1 Startup（小規模）

11.2 Scale-up

11.3 Data-heavy SaaS

11.4 Enterprise

11.5 韓国の金融・公共

第12章 · 韓国企業の実務 Tips

12.1 採用・組織

12.2 ツール導入の順序

  1. dbt + スケジュール（シンプルに）
  2. テスト・ドキュメントの拡充
  3. オーケストレーション（Airflow/Dagster）
  4. オブザーバビリティ（Monte Carlo/Metaplane）
  5. 契約（dbt Contracts/Soda）

12.3 言語・ロケール

12.4 セキュリティ・監査

第13章 · アンチパターン10選

13.1 「cron + SQL」のまま

Git・テスト・ドキュメントの不在 → 事故が頻発。

13.2 テストのない dbt

モデル数百個 → 回帰が爆増。

13.3 増分ロジックを手作業で

dbt で手作業の増分 → 保守が悪夢に。SQLMesh の検討を。

13.4 Airflow DAG のモノリシック化

1つの DAG に100個のタスク → 障害が伝播。

13.5 Dagster・Prefect・Airflow の同時運用

1社に3つはオーバーエンジニアリング。

13.6 契約なしで消費者が多数

1つの変更が5チームを壊す。

13.7 オブザーバビリティを後回し

事故をユーザーが先に発見する。

13.8 CI なしで Prod へ直接デプロイ

PR レビューの省略 → 言い訳のできないミス。

13.9 環境分離がない

Dev から Prod のデータを書き換える事故。

13.10 自動生成ドキュメントだけを信じる

自動ドキュメントは構造しか見せない。ビジネスの説明は人がやる。

第14章 · チェックリスト — データパイプライン成熟度の12項目

第15章 · 次回予告 — Season 5 Ep 5:「Semantic Layer・Metrics Store・Reverse ETL」

パイプラインがデータを作るなら、Semantic Layer は語る。Ep 5 はデータをビジネス言語につなぐ軸。

「データの意味を一度だけ定義する」という約束の 2025年版。

次回の記事で会おう。

まとめ: 2025年のデータオーケストレーションは「パイプラインもソフトウェア」という原則が完成する段階。dbt が変換の標準となり、SQLMesh が増分・バージョンで補完し、Dagster が asset-centric なオーケストレーションとして登場した。Airflow は 3.0 の大改編で再飛躍し、Prefect 3.0 は Pythonic な代替。データ契約とオブザーバビリティがエンジニアリング品質を押し上げ、CI/CD + SLO + オンコールがデータチームの日常になった。スタックは規模・文脈によって変わるが、コア原則は「Git・テスト・契約・オブザーバビリティ・ロールバック」という5つの言葉に要約される。次回はこのすべての上に乗る「ビジネス言語で語る層」。

原文を読む: https://www.youngju.dev/blog/culture/2026-04-15-data-orchestration-2025-complete-guide-dbt-sqlmesh-dagster-airflow-prefect-data-contracts-deep-dive-guide-2025.ja

コメント

まだコメントはありません。

ログインするとコメントできます