Databricks 認定学習資料

テーマ切替

実運用で理解する Databricks【ストリーミング版】：ECサイト リアルタイム基盤 ​

databricks-operation-flow.md（日次バッチ版）のリアルタイム対応版です。Professional 試験で問われる Structured Streaming の運用論点を、図で理解します。 図は Mermaid 記法。VSCode プレビュー（Cmd+Shift+V）や GitHub で表示されます。 機能単体の詳細は ../04_professional-materials/07-ingestion.md（インジェスト）を参照。

想定シナリオ ​

同じ 「ECサイト A社」 が、今度はリアルタイムにやりたい：

  • 注文・クリックイベントが Kafka（/ Event Hubs / Kinesis）に絶えず流れてくる
  • ログファイルもクラウドストレージに継続到着する
  • これを秒〜分で処理し、不正検知アラート・リアルタイム売上ダッシュボード・レコメンドの特徴量を常に最新化する
  • 求められるのは exactly-once（重複も欠損もない）、遅延データへの耐性、落ちても自動復旧

💡 バッチ版との一番の違い：処理が「1回動いて終わり」ではなく、マイクロバッチが延々ループし続けること。だから「途中で落ちたら？」「同じデータを二度処理しない保証は？」が運用の主役になります。

1. リアルタイムのエンドツーエンド処理フロー ​

  • 形はメダリオンのまま。違いは各段が readStream/writeStream で繋がりっぱなしなこと。
  • ストリーム-静的結合：流れてくる注文（ストリーム）に、在庫マスタ（静的テーブル）を結合して意味づけする定番。

2. マイクロバッチ「1周」の中身（exactly-once の仕組み） ​

ストリーミングは、内部で小さなバッチ（マイクロバッチ）を繰り返しています。1周で何が起きるかを追うと、なぜ「重複しない」のかが分かります。

ここが Professional の核心

  • チェックポイント＝「どこまで読んで・処理したか」の記録。これがあるから落ちても続きから再開できる。
  • チェックポイントはクエリごとに専用。使い回すと壊れる。書き込み先を変えるときは基本作り直し。

3. ストリーミング運用の「4つのツマミ」 ​

ストリーミングクエリは、下の4つを状況に合わせて設定します。Professionalはこの組み合わせ判断を問われます。

ツマミ何を決める運用での選び方（例）
トリガー処理の起動間隔常時稼働は processingTime、コスト重視の準リアルタイムは AvailableNow（増分バッチ）、超低遅延は continuous
出力モード各バッチで何を書くか追記なら append、集計の更新は update/complete。ただし Delta シンクは append/complete のみ（update 非対応）
ウォーターマーク「何分前までの遅延を待つか」集計・結合の状態を無限に溜めないために必須。例：withWatermark("ts","10 minutes")
バックプレッシャー1バッチの取り込み量上限追いつかない時に1バッチを絞って安定化

4. なぜ foreachBatch ＋ MERGE なのか（頻出パターン） ​

「ストリームで更新（upsert / SCD）したい」時、Delta シンクは update 出力モードに非対応です。そこで foreachBatch で各マイクロバッチをバッチDataFrameとして受け取り、MERGE を実行します。

落とし穴（Professionalで問われる）

  • foreachBatch は at-least-once（同じ batchId が再実行されうる）。
  • なので MERGE に txnAppId + txnVersion（= batchId） を付けて冪等にし、再実行時の二重書き込みを防ぐ。これで実質 exactly-once。

5. 監視と障害復旧（ストリーミング特有） ​

バッチと違い動き続けるので、「止まっていないか」「遅れていないか」を継続監視します。

  • 入力レート > 処理レート が続く＝追いつけていないサイン。バックプレッシャーやクラスタ増強で対処。
  • 状態（state）が無限に増えていないかを監視。増えていればウォーターマーク不足を疑う。
  • 復旧はチェックポイントから自動。コードを変える時はチェックポイントとの互換性に注意。

6. バッチ版との違い（対比で理解する） ​

観点日次バッチ（前回の図）リアルタイム（この図）
起動Jobs が 02:00 に1回起動クエリが動き続ける（マイクロバッチのループ）
読み方read で一括／AvailableNow で増分readStream で継続
進捗管理ジョブの成功/失敗チェックポイント（offset/commit/状態）
重複防止冪等な MERGE 等exactly-once（チェックポイント）＋ foreachBatch は冪等化
遅延データバッチ境界で吸収ウォーターマークで制御
監視実行結果・所要時間入力/処理レート・バックログ・状態サイズを常時
コスト処理後クラスタ自動終了常時稼働 or AvailableNow で間欠実行して節約

Trigger.AvailableNow は「ストリーミングの仕組み（チェックポイント）を使いつつ、今ある分だけ処理して止まる」モード。バッチとストリーミングの中間で、コスト効率の良い準リアルタイム運用に多用されます。

7. まとめ：ストリーミング運用の勘所 ​

  • 入口 = readStream（Kafka）/ Auto Loader、心臓 = チェックポイント（落ちても続きから・重複なし）
  • 状態管理 = ウォーターマークで無限肥大を防ぐ
  • 更新 = Delta が update 非対応 → foreachBatch + MERGE（冪等化を忘れない）
  • 運用 = レート/バックログ/状態サイズを継続監視、復旧はチェックポイントから

関連 ​