✍️ 필사 모드: データエンジニアリング完全ガイド — Lakehouse・Streaming・dbt・Orchestration・Data Mesh (Season 2 Ep 8, 2025)

はじめに — 2025年のデータエンジニアへの期待値

10年前のデータエンジニアは「ETLスクリプト + Hadoop運用」だった。2025年の期待値:

• Lakehouse 設計: Iceberg/Delta/Hudi から選択・運用
• Streaming と Batch の統合: Lambda は終わり、Kappa が標準
• Modern Data Stack: dbt + Airflow/Dagster + Fivetran/Airbyte + BigQuery/Snowflake
• Data Mesh: 集中 vs 分散の組織モデル
• Data Contract: Protobuf 的なスキーマ契約
• AI/ML 連携: Feature Store、Vector DB、MLOps
• コスト管理: クラウドデータコストの統制(FinOps)

本稿は2025年のデータエンジニアの思考フレームを一本に詰め込む。

第1部 — Lakehouse: Data Lake + Data Warehouse の統合

1.1 歴史的背景

定義: オブジェクトストレージ(S3/GCS/ADLS) + テーブルフォーマット(Iceberg 等) + クエリエンジン(Spark, Trino, DuckDB) で Warehouse 級 ACID と性能を提供。

1.2 3つのテーブルフォーマット比較 (2024〜2025)

2024年の決定的事件: Databricks が Tabular(Iceberg 創業社)を買収 → Iceberg と Delta の統合方向。

2025 推奨: 新規は Iceberg。Databricks 環境なら Delta も可。

1.3 Iceberg の基本構造

Metadata (JSON):
  -> Manifest List (Avro):
     |- Manifest 1 (Avro)
     |  \- Data Files (Parquet)
     |- Manifest 2
     \- ...

• Snapshot: 特定時点の状態 (time travel)
• Partition Evolution: パーティションスキーマ変更可
• Hidden Partitioning: WHERE year=2025 で内部パーティションを自動利用

1.4 2025 のクエリエンジン

第2部 — Streaming: Kappa の勝利

2.1 Lambda vs Kappa

Lambda (2010s): Batch Layer + Speed Layer + Serving。同じロジックを2回書く保守地獄。

Kappa (2014, Jay Kreps): Streaming のみ。再処理はストリーム再開。2025年の標準。

2.2 Streaming エンジン 2025

2.3 Streaming 10の中核概念

1. Event Time vs Processing Time
2. Watermark: 「T時刻までのイベントは到着済」信号
3. Windowing: Tumbling / Sliding / Session
4. Stateful Processing
5. Exactly-Once
6. Backpressure
7. Checkpointing
8. Join: Stream-Stream / Stream-Table
9. CDC (Change Data Capture)
10. Deduplication

2.4 CDC — 現代データ統合の核

PostgreSQL/MySQL -> Debezium -> Kafka -> Flink/Spark -> Iceberg

Batch ETL を廃し、ほぼリアルタイム同期。ツール: Debezium(OSS)、Fivetran、Airbyte。

2.5 2025 リアルタイムデータ基盤の例

[Kafka] -> [Flink SQL] -> [Iceberg (bronze/silver/gold)] -> [Trino/DuckDB]
                   |
                   +-> [Materialize] (リアルタイムダッシュボード)
                   |
                   +-> [Redis] (低遅延サービング)

第3部 — Medallion Architecture: Bronze/Silver/Gold

3.1 3層構造

1. Bronze (Raw): 原本。スキーマ変動を吸収
2. Silver (Cleansed): 精製・検証・重複除去・統一スキーマ
3. Gold (Business): ドメイン集計、BI/ML 即利用

3.2 各層の責任

3.3 利点

• 再処理可 (Bronze 保全)
• 契約明確 (Silver = 標準スキーマ)
• ビジネスロジック分離 (Gold)

第4部 — dbt: Analytics Engineering の標準

4.1 dbt とは

「SQL モデリングをソフトウェアエンジニアリングのように」 — バージョン管理、テスト、ドキュメント、依存グラフ。

4.2 構成

models/
  staging/
    stg_orders.sql
    stg_customers.sql
  marts/
    orders.sql
tests/
seeds/
macros/

4.3 モデル例

-- models/marts/orders.sql
{{ config(materialized='table', partition_by={'field': 'order_date', 'data_type': 'date'}) }}

with orders as (
    select * from {{ ref('stg_orders') }}
),
customers as (
    select * from {{ ref('stg_customers') }}
)
select
    o.order_id,
    o.order_date,
    c.country,
    o.amount
from orders o
join customers c using (customer_id)
where o.status = 'completed'

{{ ref('stg_orders') }} により dbt が依存グラフを自動構築。

4.4 テストとドキュメント

# schema.yml
models:
  - name: orders
    description: "完了した注文 (Gold)"
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: amount
        tests:
          - dbt_utils.expression_is_true:
              expression: ">= 0"

dbt test
dbt docs generate && dbt docs serve

4.5 2025 dbt エコシステム

• dbt Core / dbt Cloud
• dbt-osmosis: メタデータ伝播
• Elementary: データ品質
• SQLMesh: dbt 代替
• Dagster + dbt: オーケストレーション統合

第5部 — Orchestration: Airflow vs Dagster vs Prefect vs Temporal

5.1 2025 比較

5.2 Dagster の哲学: Data-aware Orchestration

Airflow は Task を管理。Dagster は Asset (データ成果物)を管理。

from dagster import asset

@asset
def raw_orders():
    return fetch_from_postgres("orders")

@asset
def cleaned_orders(raw_orders):
    return raw_orders.dropna()

@asset
def revenue_by_day(cleaned_orders):
    return cleaned_orders.groupby("date").sum()

依存・スキーマ・型が明示的。実行グラフ = Asset グラフ。

5.3 Airflow 2.x の改善

• TaskFlow API (Pythonic)
• Dynamic Task Mapping
• Dataset Triggering (Dagster に触発)
• Airflow 3.0 (2025): データ中心の刷新

第6部 — Data Mesh: 組織のデータアーキテクチャ

6.1 背景

集中データチームの限界: ドメイン知識不足、ボトルネック、優先順位衝突。

6.2 Data Mesh 4原則 (Zhamak Dehghani, 2019)

1. Domain Ownership: データはドメインチームが所有
2. Data as a Product: データセット = プロダクト
3. Self-serve Platform: 中央はプラットフォーム提供
4. Federated Governance: 中央ルール + ドメイン実行

6.3 現場の考察

成功条件: 500名以上、明確なドメイン境界、成熟したプラットフォーム組織。

失敗条件: 100名未満(過剰)、ドメインチーム能力不足、中央プラットフォーム不在。

2025 現実: 理想論から実用調整へ。Hub-and-Spoke や部分 Mesh が一般的。

第7部 — Data Contract: チーム間インタフェース

7.1 なぜ必要か

問題: フロントエンドが user.full_name を user.name にリネーム → パイプライン100本破損 → 追跡不能。

7.2 定義

スキーマ + 意味論 + SLA の公式約束。Protobuf や JSON Schema 形式。

# user_contract.yml
name: user_events
version: 1.2.0
owner: user-platform-team
schema:
  event_id: string
  user_id: string
  event_type: enum [signup, login, logout, purchase]
  timestamp: timestamp
  properties: map
sla:
  freshness: under 5 minutes
  availability: 99.9%
  breaking_change_notice: 30 days
consumers:
  - analytics-team
  - ml-team
  - finance-team

7.3 ツール (2024〜2025)

• Protobuf + Buf: エンジニアリング寄り
• Great Expectations: データ品質検証
• dbt Contracts (1.5+)
• DataHub: メタデータカタログ
• Apache Atlas: Hadoop エコシステム

7.4 Contract-first パイプライン

Producer Team                         Consumer Team
  |                                        |
  |- スキーマ変更を Buf に Commit -> Review
  |                                        |
  |- CI: 後方互換チェック                   |
  |                                        |
  |- Producer デプロイ                      |
  |                                        |
  \- イベント送信 ---- Kafka ---------> Consumer 更新

第8部 — Data Quality: 信頼の基盤

8.1 品質6次元

1. Accuracy 正確性
2. Completeness 完全性
3. Consistency 一貫性
4. Timeliness 適時性
5. Uniqueness 一意性
6. Validity 有効性

8.2 Data Observability 5 Pillars (Monte Carlo)

1. Freshness: 最終更新
2. Volume: 行数の期待範囲
3. Schema: カラム/型変化
4. Distribution: 値分布の変化
5. Lineage: 由来と流通

8.3 2025 ツール

• Great Expectations (OSS)
• Soda (SQL ベース)
• Monte Carlo (ML 異常検知)
• Bigeye (自動 SLA)
• Elementary (dbt 統合)

第9部 — Modern Data Stack 2025

9.1 標準構成

[Sources]
  |- OLTP DBs
  |- SaaS APIs
  \- Event Streams
[Ingestion]
  |- Fivetran / Airbyte
  \- Debezium (CDC)
[Warehouse/Lakehouse]
  |- Snowflake / BigQuery / Databricks
  \- Iceberg on S3 + Trino
[Transformation]
  \- dbt (または SQLMesh)
[Orchestration]
  \- Dagster / Airflow
[Serving]
  |- BI: Looker, Metabase, Hex
  |- ML: Feature Store (Feast)
  \- Reverse ETL: Census, Hightouch
[Observability]
  |- Monte Carlo / Elementary
  \- DataHub

9.2 新トレンド

• Semantic Layer: dbt Semantic Layer、Cube、MetricFlow
• Reverse ETL: Warehouse から CRM/広告へ
• Zero-copy Cloning
• Open Table Format の収束 (Iceberg 中心)
• AI 支援データエンジニアリング

第10部 — データエンジニア6ヶ月ロードマップ

• 月1: SQL + Warehouse (PostgreSQL 高度、dbt 基本)
• 月2: Orchestration (Airflow または Dagster)
• 月3: Lakehouse (Iceberg/Delta、Trino/DuckDB、Parquet チューニング)
• 月4: Streaming (Kafka、Flink/Spark Streaming、CDC)
• 月5: 品質・観測性 (Great Expectations/Soda、DataHub、Data Contract)
• 月6: 運用 + ML (FinOps、Feature Store、Semantic Layer)

第11部 — 12項目チェックリスト

1. Lakehouse 3フォーマットの差
2. Lambda vs Kappa
3. Event Time vs Processing Time + Watermark
4. Medallion 各層の責任
5. dbt ref() と依存グラフ
6. CDC パイプライン構成
7. Dagster Asset vs Airflow Task
8. Data Mesh 4原則
9. Data Contract の定義と必要性
10. 品質6次元
11. Observability 5 Pillars
12. Semantic Layer の目的

第12部 — アンチパターン10

1. Bronze を省いて Silver へ直行
2. Lambda に固執
3. dbt なしの SQL 乱立
4. Contract なしのチーム間データ共有
5. パーティション設計なしの Parquet
6. UPSERT を毎時 Batch (compaction が必要)
7. Airflow DAG にビジネスロジック (dbt/Flink へ)
8. 観測性を後回し
9. 再試行戦略なし (冪等性必須)
10. コスト監視なし

おわりに — データエンジニアリングは「契約の工学」

ソフトウェアエンジニアリングが「関数とインタフェースの工学」なら、データエンジニアリングは**「スキーマと契約の工学」**だ。

2025年の本質は変わらない:

• 信頼できるデータを必要な時に必要な形で届ける
• 意思決定・ML・プロダクトが依存できる基盤になる

しかしツールは毎年変わる。Lakehouse、Streaming、dbt、Dagster、Data Contract — 2020年には無かった。2030年にはまた違うものが出る。

不変の原理:

• データの歴史性 (Bronze 保全)
• スキーマ進化 (Contract)
• 処理の冪等性 (安全な再試行)
• 観測性 (問題検知)

これさえ守れば、ツールは必要に応じて差し替えればよい。

次回予告 — 「Observability 完全ガイド: Metric・Log・Trace・OpenTelemetry・eBPF・SLO」

Season 2 Ep 9 は現代システムの神経系、Observability:

• Metric/Log/Trace 3軸 + Profile 4軸 (Pyroscope)
• OpenTelemetry の真価
• eBPF とカーネルレベル観測
• SLO/SLI/Error Budget の実戦設計
• Grafana Stack vs Elastic Stack vs Datadog
• コスト統制 (ログ爆発の抑制)

「観測できないものは運用できない」、次回に続く。