クイズの説明
Step 3「ストリーム処理とリアルタイム分析を設計しよう」の理解度を確認します。ストリーム処理、イベント駆動アーキテクチャ、CDC、リアルタイム分析について問います。
合格ライン: 80%（5問中4問正解）
問題
Q1. ウィンドウ処理
ユーザーのWebサイトセッションを分析したい場合、最も適切なウィンドウ種類はどれですか？
- A. タンブリングウィンドウ（5分固定） — 5分ごとの固定区間で集計
- B. スライディングウィンドウ（5分幅、1分スライド） — 重複する区間で移動平均を計算
- C. セッションウィンドウ（ギャップ30分） — ユーザーの非活動期間でセッションを区切る
- D. グローバルウィンドウ — すべてのイベントを1つのウィンドウで処理
答えを見る
正解: C
ユーザーセッションの分析にはセッションウィンドウが最適です。セッションウィンドウは、イベント間のギャップ（非活動期間）に基づいて動的にウィンドウを定義します。30分間操作がなければセッション終了とみなすことで、ユーザーの実際の利用パターンに合った区間でメトリクス（セッション時間、ページビュー数等）を集計できます。タンブリング（A）やスライディング（B）は固定区間のため、1つのセッションが複数のウィンドウに分割されてしまいます。
Q2. 配信保証
売上データのストリーム処理において、データの重複も欠落も許容できない場合、最適な配信保証セマンティクスはどれですか？
- A. At-most-once — 最大1回配信、データロスの可能性あり
- B. At-least-once — 最低1回配信、重複の可能性あり
- C. Exactly-once — 正確に1回配信
- D. At-least-once + べき等処理 — 最低1回配信し、重複は処理側で排除
答えを見る
正解: D
売上データでは欠落も重複も許容できません。理論的にはExactly-once（C）が理想ですが、分散システムでの完全なExactly-onceは実装が複雑でパフォーマンスコストが高い場合があります。実務では「At-least-once + べき等処理」（D）が最も現実的なアプローチです。At-least-onceでデータロスを防ぎ、消費者側でUPSERT（INSERT ON CONFLICT UPDATE）やトランザクションIDによる重複排除を行うことで、結果的にExactly-onceと同等の効果を低コストで実現できます。
Q3. CDC方式
PostgreSQLからデータウェアハウスへのニアリアルタイムデータ同期に最も適したCDC方式はどれですか？
- A. タイムスタンプベースCDC — updated_at列で変更を検出
- B. トリガーベースCDC — DBトリガーで変更を記録
- C. ログベースCDC（WAL） — トランザクションログを読み取り変更を検出
- D. 差分比較 — 前回スナップショットとの差分を計算
答えを見る
正解: C
ログベースCDC（WAL: Write-Ahead Log）は、PostgreSQLのトランザクションログを直接読み取るため、ソースDBへの負荷が最小限で、DELETE操作も検出できます。Debezium等のツールがWALの論理デコーディングを使って変更イベントをKafkaにストリーミングします。タイムスタンプベース（A）はDELETEが検出できず、updated_at列がないテーブルには使えません。トリガーベース（B）はソースDBに負荷がかかり、差分比較（D）は大量のSELECTが必要で高負荷です。
Q4. リアルタイム分析
以下の要件に対して最もコスト効率の高いアーキテクチャはどれですか？
日次の売上レポートを毎朝9時に経営層に提供する。レポートの対象は前日までの確定した売上データ。リアルタイム性は不要。
- A. CDC → Kafka → Flink → ClickHouse → Grafana
- B. CDC → Kafka → BigQuery Streaming Insert → Looker
- C. 日次バッチ（Airflow + dbt） → BigQuery → Looker
- D. CDC → Kafka → Flink → BigQuery → Looker
答えを見る
正解: C
日次レポートでリアルタイム性が不要な場合、最もコスト効率が高いのは日次バッチ処理です。Airflowで朝8時にdbtジョブを実行し、BigQueryでGoldテーブルを更新、Lookerでダッシュボードを提供すれば十分です。A（Flink + ClickHouse）、B（Streaming Insert）、D（Flink + BigQuery）はいずれもストリーム処理のインフラコストと運用コストが発生しますが、「前日までの確定データ」であればバッチで十分です。「リアルタイム化できるからする」のではなく「ビジネス要件に合った最小限のアーキテクチャ」を選択することが重要です。
Q5. イベント駆動アーキテクチャ
Apache Kafkaにおいて、同じTopicのメッセージを複数のコンシューマが独立して消費する場合、正しい設定はどれですか？
- A. 全コンシューマを同じConsumer Groupに所属させる
- B. 各コンシューマを異なるConsumer Groupに所属させる
- C. コンシューマごとに別のTopicを作成する
- D. Partitionの数をコンシューマ数と同じにする
答えを見る
正解: B
KafkaのConsumer Groupは、同じグループ内のコンシューマでメッセージを分散処理します（各パーティションは1つのコンシューマにのみ割り当て）。一方、異なるConsumer Groupに所属するコンシューマは、同じメッセージを独立して受信できます。例えば、「分析パイプライン」と「アラートサービス」が同じorderイベントを消費する場合、それぞれ別のConsumer Groupにすることで、両方が全メッセージを独立して処理できます。A（同じGroup）だとメッセージが分散され、各コンシューマは一部のメッセージしか受信できません。
結果
合格（4問以上正解）
Step 3の内容をよく理解しています。ストリーム処理、イベント駆動アーキテクチャ、CDC、リアルタイム分析の設計知識を身につけました。次のStep 4「データ品質とガバナンスを確立しよう」に進みましょう。
不合格（3問以下正解）
Step 3の内容を復習しましょう。特に以下のポイントを重点的に確認してください：
- ウィンドウ処理 — タンブリング、スライディング、セッションの使い分け
- 配信保証 — Exactly-once vs At-least-once + べき等処理
- CDC — ログベースCDCの仕組みとメリット
- コスト意識 — リアルタイム化すべきかどうかの判断基準
推定所要時間: 30分