LESSON 30分

ストーリー

田
田中VPoE
ストリーム処理、イベント駆動、CDC。リアルタイムデータパイプラインの構成要素を学んだ。最後に、これらを組み合わせてリアルタイム分析基盤を設計する
あなた
リアルタイムのダッシュボードや不正検知のような仕組みですね
あ
田
田中VPoE
そうだ。ただし「すべてをリアルタイムにする」必要はない。コストとの兼ね合いだ。日次売上レポートにリアルタイム処理は不要。一方、不正検知やリアルタイムレコメンドはミリ秒の遅延が求められる。要件に応じてバッチとストリームを使い分ける
あなた
Speed Layer（リアルタイム近似）とBatch Layer（正確な結果）のハイブリッドですね
あ
田
田中VPoE
まさにそうだ。Lambda Architectureの考え方だが、現代ではKappa Architecture的にストリーム処理を中心に据えつつ、正確性が必要な部分はバッチで補完するアプローチが多い

リアルタイム分析のアーキテクチャ

全体構成

リアルタイム分析基盤:

ソースシステム           ストリーム処理        サービング層
┌──────────────┐    ┌──────────────┐    ┌──────────────────┐
│ アプリDB (CDC) │───→│ Apache Kafka │───→│ OLAP エンジン      │
│ イベントログ    │───→│              │    │ (ClickHouse,      │
│ IoTセンサー    │───→│              │    │  Apache Druid,    │
└──────────────┘    └──────┬───────┘    │  Pinot)           │
                           │            └────────┬─────────┘
                    ┌──────┴───────┐             │
                    │ Flink / KS   │      ┌──────┴─────────┐
                    │ (リアルタイム   │      │ ダッシュボード    │
                    │  集計・変換)   │      │ アラート         │
                    └──────────────┘      │ API             │
                                          └────────────────┘

リアルタイムOLAPエンジン

主要エンジン比較

観点ClickHouseApache DruidApache PinotBigQuery
開発元Yandex → ClickHouse IncApacheLinkedIn → ApacheGoogle
クエリレイテンシミリ秒〜秒ミリ秒〜秒ミリ秒〜秒秒〜分
リアルタイム取り込み対応対応（ストリーム）対応（ストリーム）Streaming API
SQL互換ほぼ完全SQL互換SQL互換完全
スケーラビリティ水平・垂直水平水平自動
運用の複雑さ中高高低（マネージド）
コスト低〜中中中使用量による
適用場面ログ分析、時系列、アドホックリアルタイムBIユーザー向け分析汎用分析

リアルタイム分析のユースケース

パターン別の設計

ユースケースレイテンシ要件アーキテクチャツール構成
リアルタイムダッシュボード秒〜分CDC → Kafka → DWHDebezium + Kafka + BigQuery Streaming
不正検知ミリ秒Event → Kafka → Flink → AlertKafka + Flink + ルールエンジン
リアルタイムレコメンドミリ秒Event → Kafka → Feature Store → MLKafka + Redis + ML serving
運用メトリクス秒Metrics → Kafka → OLAPKafka + ClickHouse + Grafana
A/Bテスト結果分〜時間Event → Kafka → 集計 → BIKafka + Flink + Looker

リアルタイムダッシュボードの実装パターン

パターン1: マテリアライズドビュー

  Kafka → Flink → 集計テーブル（マテリアライズドビュー）→ BI

  メリット: クエリが高速（事前計算済み）
  デメリット: 集計パターンが固定される

パターン2: OLAPエンジン

  Kafka → ClickHouse / Druid → BI

  メリット: アドホッククエリが可能
  デメリット: 運用の複雑さ

パターン3: DWH Streaming Insert

  Kafka → BigQuery Streaming API → BI

  メリット: 既存のBIツールをそのまま利用
  デメリット: Streaming Insertのコスト

バッチとストリームの統合

Speed Layer + Batch Layer の統合

統合アーキテクチャ:

                 ┌─────────────────────────────┐
                 │    ストリーム処理              │
  データソース ──→│    (ニアリアルタイム近似値)      │──→ リアルタイムビュー
      │          └─────────────────────────────┘        │
      │                                                  │
      │          ┌─────────────────────────────┐        ├──→ 統合ビュー
      └─────────→│    バッチ処理                 │        │    (最新の正確な値を
                 │    (日次・正確な値)            │──→ バッチビュー  優先的に使用)
                 └─────────────────────────────┘

  dbtでの実装例:
    WITH realtime AS (
      SELECT * FROM streaming_mart WHERE batch_date > CURRENT_DATE()
    ),
    batch AS (
      SELECT * FROM batch_mart WHERE batch_date <= CURRENT_DATE()
    )
    SELECT * FROM batch
    UNION ALL
    SELECT * FROM realtime

レイテンシ vs コストのトレードオフ

レイテンシ要件推奨アプローチ相対コスト
日次（翌朝）バッチ（dbt + Airflow）低
時間次マイクロバッチ（Spark Streaming）中
分次CDC + Kafka + DWH Streaming中〜高
秒次Flink + OLAP Engine高
ミリ秒Flink + Redis/専用DB非常に高

「リアルタイム分析は『できるからやる』ではなく『ビジネスが求めるからやる』だ。日次レポートで十分な指標をリアルタイム化しても、コストだけが増える。レイテンシ要件を明確にしてから設計すること」 — 田中VPoE

まとめ

ポイント内容
リアルタイムOLAPClickHouse、Druid、Pinotでミリ秒〜秒のクエリ応答
ユースケース不正検知はミリ秒、ダッシュボードは秒〜分、レポートは日次
バッチとストリームの統合Speed Layer + Batch Layerで近似値と正確な値を組み合わせる
コスト意識レイテンシ要件を明確にし、過剰なリアルタイム化を避ける

チェックリスト

  • リアルタイムOLAPエンジンの特性を比較できる
  • ユースケースに応じたレイテンシ要件の設定方法を理解した
  • バッチとストリームの統合アーキテクチャを設計できる
  • レイテンシ vs コストのトレードオフを説明できる

次のステップへ

次は「演習：ストリーム処理パイプラインを設計しよう」です。Step 3で学んだストリーム処理、CDC、リアルタイム分析の知識を使い、実践的なパイプラインを設計します。

推定読了時間: 30分