ストリーミングデータ処理クイズ
Step 4で学んだストリーミング基礎、Kafka入門、ストリーム処理、Lambda/Kappaアーキテクチャについて理解度を確認しましょう。10問中8問以上の正解で合格です。
Q1. バッチ vs ストリーミング
ストリーミング処理がバッチ処理より適しているユースケースはどれですか?
- A: 月次売上レポートの作成
- B: リアルタイム不正検知
- C: 過去1年分のデータ分析
- D: 機械学習モデルの学習
正解と解説
正解: B
リアルタイム不正検知は低レイテンシが求められるためストリーミング処理が適しています。月次レポートや大量データ分析、モデル学習はバッチ処理が適しています。
Q2. メッセージ配信保証
決済処理に最適なメッセージ配信保証レベルはどれですか?
- A: At-most-once
- B: At-least-once
- C: Exactly-once
- D: Best-effort
正解と解説
正解: C
決済処理ではメッセージのロストも重複も許容できないため、Exactly-once保証が必要です。At-most-onceはロスト許容、At-least-onceは重複許容です。
Q3. Kafkaパーティション
Kafkaのパーティション数と並列処理の関係として正しいものはどれですか?
- A: パーティション数に関係なく無制限に並列処理できる
- B: 同一Consumer Group内の最大並列度はパーティション数と等しい
- C: パーティション数はBroker数と必ず一致する
- D: パーティション数は後から変更できない
正解と解説
正解: B
同一Consumer Group内では、1パーティションに最大1Consumerが割り当てられます。そのため、Consumer数がパーティション数を超えるとアイドル状態のConsumerが発生します。
Q4. ウィンドウ処理
「直近10分間の注文数を1分ごとに更新する」場合に最適なウィンドウの種類はどれですか?
- A: タンブリングウィンドウ(10分)
- B: スライディングウィンドウ(サイズ10分、スライド1分)
- C: セッションウィンドウ(ギャップ10分)
- D: グローバルウィンドウ
正解と解説
正解: B
スライディングウィンドウはサイズ10分、スライド1分と設定することで、1分ごとに直近10分間の集計値を更新できます。タンブリングウィンドウは重複がないため、この要件には適しません。
Q5. Consumer Group
Kafkaで同じトピックを「売上集計」と「不正検知」の2つの目的で処理したい場合、どうすべきですか?
- A: 同じConsumer Groupに2つのConsumerを配置する
- B: 2つの異なるConsumer Groupを作成する
- C: トピックを2つに分ける
- D: パーティション数を2倍にする
正解と解説
正解: B
異なるConsumer Groupは同じトピックのメッセージを独立に消費できます。各グループがそれぞれの目的で同じメッセージを処理できます。
Q6. Lambdaアーキテクチャ
Lambdaアーキテクチャの最大の課題はどれですか?
- A: リアルタイム処理ができない
- B: バッチとストリーミングで同じロジックを2回実装する必要がある
- C: データの保存ができない
- D: スケールアウトできない
正解と解説
正解: B
Lambdaアーキテクチャでは、バッチ層とスピード層で同じビジネスロジックを別々に実装・保守する必要があり、コードの重複と運用負荷が最大の課題です。
Q7. Kappaアーキテクチャ
Kappaアーキテクチャで過去データの再処理を行う方法はどれですか?
- A: バッチ処理パイプラインを別途構築する
- B: Kafkaのログを最初から再生(Replay)する
- C: データベースからデータを読み直す
- D: 再処理はKappaアーキテクチャでは不可能
正解と解説
正解: B
Kappaアーキテクチャでは、Kafkaのイベントログを保持しておき、必要に応じてオフセットをリセットしてログを再生することで再処理を実現します。
Q8. ストリーム処理の状態管理
長時間の集約処理で最も適した状態管理方式はどれですか?
- A: インメモリのみ
- B: ファイルシステムへの書き込み
- C: 外部ストア(Redis等)とチェックポイントの組み合わせ
- D: 状態を持たない設計にする
正解と解説
正解: C
長時間の集約ではインメモリだけでは障害時にデータ喪失するリスクがあります。外部ストアとチェックポイントを組み合わせることで、高速アクセスと耐障害性を両立できます。
Q9. Dead Letter Queue
ストリーム処理におけるDead Letter Queue(DLQ)の目的はどれですか?
- A: 正常に処理されたメッセージを保存する
- B: 処理に失敗したメッセージを退避し、後で調査・再処理できるようにする
- C: メッセージの順序を保証する
- D: メッセージを暗号化する
正解と解説
正解: B
DLQは処理に失敗したメッセージを別のトピックに退避する仕組みです。正常なメッセージの処理を止めることなく、問題のあるメッセージを後で調査・再処理できます。
Q10. アーキテクチャ選択
既存のバッチパイプラインを運用中で、リアルタイムダッシュボード機能を追加したい場合、最適なアプローチはどれですか?
- A: 全てをKappaアーキテクチャに作り替える
- B: 既存バッチを維持しつつストリーミング層を追加するLambdaアプローチ
- C: バッチパイプラインの実行頻度を上げる
- D: ストリーミングは導入せず、バッチの結果をキャッシュする
正解と解説
正解: B
既存のバッチパイプラインを活かしつつ、リアルタイム要件の部分だけストリーミング層を追加するLambdaアプローチが最もリスクが低く現実的です。
結果
| 正答数 | 判定 |
|---|---|
| 8-10問 | 合格 - Step 5に進みましょう |
| 6-7問 | もう一度レッスンを復習しましょう |
| 5問以下 | Step 4のレッスンを最初から再学習しましょう |
推定所要時間:30分