データアーキテクチャパターン

ストーリー

田

田中VPoE

データ戦略が決まったら、次はそれを実現するアーキテクチャを選ぶ必要がある。データ処理にはいくつかの代表的なアーキテクチャパターンがある

あなた

Lambda Architectureは聞いたことがあります。バッチとストリームを組み合わせるやつですよね

あ

田

田中VPoE

そうだ。ただし、Lambda Architectureには課題もある。バッチとストリームで同じロジックを二重実装する必要があるからだ。それを解決するためにKappa Architectureが生まれた。さらに最近ではData Mesh、Medallion Architectureといった新しいパターンも登場している

あなた

用途に応じて使い分けが必要なんですね

あ

田

田中VPoE

その通り。万能なアーキテクチャは存在しない。組織のデータ成熟度、チームのスキル、ビジネス要件に応じて最適なパターンを選ぶ判断力が必要だ

Lambda Architecture

概要

バッチ処理とストリーム処理を組み合わせ、正確性とリアルタイム性を両立するアーキテクチャ。

Lambda Architecture:

                   ┌──────────────────────────┐
                   │      Batch Layer          │
                   │  (全データの再処理)         │
データソース ──────→│  Spark / Hive             │──→ Batch View
      │            └──────────────────────────┘        │
      │                                                 │
      │            ┌──────────────────────────┐        ├──→ Serving Layer
      │            │      Speed Layer          │        │    (クエリ応答)
      └───────────→│  (リアルタイム処理)         │──→ Real-time View
                   │  Kafka Streams / Flink    │
                   └──────────────────────────┘

メリットとデメリット

観点	メリット	デメリット
正確性	バッチ層で全データを再処理し正確な結果を保証	バッチとストリームのロジック二重実装
リアルタイム性	スピード層でリアルタイム近似結果を提供	運用が複雑（2つのパイプライン管理）
耐障害性	バッチ層がマスターとして機能し、障害から回復可能	デバッグが困難

Kappa Architecture

概要

ストリーム処理のみで構成し、Lambda Architectureの複雑さを解消するアーキテクチャ。

Kappa Architecture:

                   ┌──────────────────────────┐
                   │     イベントログ            │
データソース ──────→│  (Kafka等の永続キュー)       │
                   └────────────┬─────────────┘
                                │
                   ┌────────────┴─────────────┐
                   │     Stream Processing     │
                   │  (Flink / Kafka Streams)  │
                   └────────────┬─────────────┘
                                │
                   ┌────────────┴─────────────┐
                   │     Serving Layer         │
                   │  (クエリ応答)              │
                   └──────────────────────────┘

Lambda vs Kappa

観点	Lambda	Kappa
処理方式	バッチ + ストリーム	ストリームのみ
ロジックの重複	あり（二重実装）	なし（単一ロジック）
運用の複雑さ	高い	低い
過去データの再処理	バッチ層で容易	ログの再生で実現（設計が必要）
適用場面	正確性が最重要（金融等）	リアルタイム性が重要、ロジックが頻繁に変わる場面

ETL vs ELT

パラダイムシフト

観点	ETL（Extract-Transform-Load）	ELT（Extract-Load-Transform）
変換タイミング	ロード前にステージングで変換	ロード後にDWH内で変換
変換場所	専用のETLサーバー	DWHのコンピュートリソース
スケーラビリティ	ETLサーバーがボトルネック	DWHのスケーラビリティを活用
柔軟性	スキーマ変更に弱い	生データが残るため柔軟
代表的ツール	Informatica, Talend	dbt, Spark SQL
現在のトレンド	レガシーシステムで多い	モダンデータスタックの主流

ETL:
  [ソース] → Extract → Transform → Load → [DWH]
                         ↑
                    ステージングで変換
                    (スキーマが固定)

ELT:
  [ソース] → Extract → Load → [DWH] → Transform → [データマート]
                                         ↑
                                    DWH内で変換
                                    (dbt等で柔軟に)

「ELTの最大のメリットは、生データが残ることだ。ビジネス要件が変わっても、生データから新しいモデルを作り直せる。ETLでは変換済みデータしか残らないため、やり直しができない」 — 田中VPoE

データパイプラインのパターン

バッチ vs ストリーム vs マイクロバッチ

パターン	処理頻度	レイテンシ	適用場面
バッチ	日次/時間次	分〜時間	日次レポート、月次集計
マイクロバッチ	数秒〜数分	秒〜分	ニアリアルタイム分析、Spark Streaming
ストリーム	イベント単位	ミリ秒〜秒	リアルタイムアラート、不正検知

選択基準

要件	推奨パターン
レイテンシ要件が「翌日」で十分	バッチ
数分以内のデータ反映が必要	マイクロバッチ
秒以内のリアルタイム処理が必要	ストリーム
コスト最適化を重視	バッチ（オフピーク時間帯に実行）
データ量が極めて大きい	バッチ or マイクロバッチ

まとめ

ポイント	内容
Lambda Architecture	バッチとストリームの二重構成で正確性とリアルタイム性を両立
Kappa Architecture	ストリーム処理のみで構成し、ロジックの二重実装を排除
ETL vs ELT	モダンデータスタックではELT（ロード後に変換）が主流
パイプラインパターン	バッチ・マイクロバッチ・ストリームをレイテンシ要件で使い分ける

チェックリスト

Lambda ArchitectureとKappa Architectureの違いを説明できる
ETLとELTの違いとトレンドを理解した
バッチ/マイクロバッチ/ストリームの使い分け基準を説明できる
自組織のデータ処理要件に最適なアーキテクチャを選定できる

次のステップへ

次は「Data Meshの考え方」を学びます。中央集権的なデータチームに依存せず、各ドメインチームがデータの所有権を持つ分散型アーキテクチャを理解しましょう。

推定読了時間: 30分