課題とコンテキスト
5分ごとの注文金額および注文数のメトリクスを計算します。オフラインクライアント、リトライ、マルチリージョン配信によりイベントが遅延して到着することがあり、同一の注文が複数回送信される可能性もあります。ビジネス要件として、1分以内に初期値を提供し、24時間以内にレポート用の補正データを利用可能にする必要があります。
イベント時間（event time）と処理時間（processing time）を区別し、ウィンドウが結果を出力（emit）するタイミングを定義した上で、遅延イベントの送信先やコンシューマーが補正データを識別する方法を示してください。
面接官が見ているポイント
時間のセマンティクス
優れた回答では、イベントのタイムスタンプ、処理時間、ウィンドウ境界、タイムゾーンを定義した上で、ウォーターマークが「そのウィンドウのデータの大部分が到着した」という推定値であることを説明します。
結果のライフサイクル
早期結果、定刻（on-time）結果、遅延による補正データ、カットオフを超過したデータを明確に分離します。1回の出力が自動的に永続的な真実となるわけではありません。
状態とコスト
状態保持（state retention）、許容遅延（allowed lateness）、再計算の範囲、ホットキー、チェックポイントについて議論します。無制限に待機すると、状態保持量とコストが無制限に膨らみます。
可観測性（オブザーバビリティ）
ウォーターマークのラグ、遅延分布、補正比率、ドロップされたイベント数、重複率、結果の鮮度を追跡します。
確認すべき明確化のための質問
- メトリクスはイベント時間と到着時間のどちらでグループ化されますか？
- 初回結果において許容される誤差はどの程度で、最終カットオフはいつですか？
- 遅延イベントによって、すでに公開済みのレポートを修正する必要がありますか？
- 重複排除のために、すべてのイベントに安定した event_id が含まれていますか？
- キーごとのピークレートおよび最大状態予算はどのくらいですか？
- カットオフを超えたイベントは破棄、隔離、またはオフラインでの再計算の対象とすべきですか？
30秒で答えるフレームワーク
「イベント時間ウィンドウを採用し、event_id とイベントタイムスタンプを必須とします。ストリームプロセッサはウォーターマークを使用して初期結果を出力し、補正のために有界な許容遅延期間を設けます。補正は同一のウィンドウキーとリビジョン番号を使用します。カットオフを超えたイベントは、履歴をサイレントに書き換えるのではなく隔離およびバッチ再計算へ送ります。ウォーターマークのラグ、遅延パーセンタイル、補正率、破棄数、状態サイズを監視します。」
ステップ別の詳細解説
ステップ 1: ウィンドウと時間を定義する
UTC イベント時間と、[10:00, 10:05) のような固定ウィンドウを使用します。処理時間は運用上のアラートや早期トリガーに使用し、ビジネスロジックのグループ化には使用しません。キーにはテナント、製品、またはリージョンを含めます。
ステップ 2: ウォーターマークを進める
各パーティションは観測されたイベントタイムスタンプに基づいて進み、グローバルポリシーは安全な下限値を取ります。アイドル状態のパーティションを検出します。サイレントなパーティションによってパイプライン全体が停滞してはなりません。
ステップ 3: トリガーと累積
処理時間トリガーで近似値を出力し、ウォーターマークがウィンドウの終了位置を通過した時点で定刻（on-time）結果を出力します。累積（accumulating）または破棄（discarding）ペインを選択し、各出力に window_end、revision、および is_final を含めます。
ステップ 4: 遅延および重複イベントを処理する
許容遅延の範囲内で、event_id によって重複排除を行い、状態を更新して新しいリビジョンを出力します。リプレイによって金額が二重加算されてはなりません。ビジネス上のカットオフまで状態を保持し、その後クリーンアップします。
ステップ 5: 遅延データのフォールバックを定義する
許容遅延を超えたイベントは、理由と元のペイロードとともに隔離領域に書き込みます。バッチジョブが過去24時間分を再計算し、冪等なアップサート（upsert）またはより高いリビジョンを補正ストアに適用します。
ステップ 6: テストとパブリッシュ
制御されたタイムスタンプを使用して、順序の入れ替わり、重複、アイドルパーティション、再起動時の復元、境界での遅延をテストします。コンシューマーは (metric, window_end, revision) の重複を排除し、レポートには最終リビジョンまたはカットオフ承認済みリビジョンを使用します。
高品質な回答例
「まず、イベント時間、ウィンドウ、カットオフを明示的な契約として定義します。すべてのイベントには、安定した eventid、eventtime、および schema_version が付与されます。プロセッサはテナントとメトリクスごとに5分単位でウィンドウ化します。パーティションごとのウォーターマークはアイドルパーティションを考慮し、グローバルウォーターマークはウィンドウ完了の保守的な推定値とします。
システムは早期リビジョンを即座に出力し、ウォーターマークが終了位置を通過した後に定刻リビジョンを出力し、30分間は遅延イベントを受け入れます。各出力にはウィンドウ境界、リビジョン、および完了フラグ（final flag）が含まれるため、ダウンストリームへの書き込みは冪等になります。30分を超えて遅延したイベントは隔離領域に入り、24時間の再計算ジョブがより高いリビジョンを生成します。レポートのカットオフ後は、イベントの監査は行いますが、ビジネス台帳をサイレントに書き直すことはしません。
ウォーターマークのラグ、p50/p95/p99の遅延、補正率および破棄率、重複、状態バイト数、再計算のバックログ、最終結果の遅延を監視します。キャパシティはアクティブなウィンドウ数×ウィンドウあたりの状態量となり、チェックポイントと状態のTTLによって制限されます。」
よくある間違い
- イベント時間を処理時間に置き換える → オフラインイベントが誤ったウィンドウに入る → event_time を維持し、処理時間は運用目的のみに限定する。
- ウォーターマークを絶対的な真実として扱う → 遅延イベントがサイレントに消失する → 推定値として定義し、許容遅延と隔離領域を設定する。
- 単一の不変結果のみを出力する → 補正が伝播できなくなる → 冪等な更新のためにリビジョンと完了フラグを使用する。
- 無制限に待機する → 状態とコストが無制限になる → ビジネスカットオフを設定し、それ以降はオフラインで再計算する。
- ペイロードのみで重複排除する → リトライの順序によって二重カウントが発生する → 安定した event_id と永続的な重複排除状態を使用する。
- アイドルパーティションを無視する → ウォーターマークが停滞し、アラートが誤報を出す → アイドルパーティションを検出し、一時的に下限値の計算から除外する。
- 順序通りの入力のみをテストする → 本番環境で境界エラーが発生する → 順序の入れ替わり、重複、遅延データ、再起動、リカバリを注入してテストする。
フォローアップの質問と回答
フォローアップ 1: ウォーターマークが停滞する原因は何ですか？
パーティションが無音である、切断されている、または進行状況を極めて保守的に見積もっている可能性があります。アイドリングタイムアウト、パーティションのハートビート、ウォーターマークラグのアラートを組み合わせて、無音状態と障害を区別します。
フォローアップ 2: 許容遅延（allowed lateness）はどのように決定しますか？
過去の遅延データ、ビジネスのカットオフ、状態予算に基づいて決定します。p99の遅延見積もりから開始し、リプレイによって検証します。期間を長く設定すれば自動的に正確になるわけではなく、状態保持量と補正コストが増加します。
フォローアップ 3: 補正の嵐（correction storm）をどのように防ぎますか？
遅延イベントをマイクロバッチ化し、ウィンドウあたりの補正回数を制限し、ダウンストリームでは最新リビジョンのみを保持します。スパイク発生時には、非重要メトリクスをバッチ補正へとダウングレードします。
フォローアップ 4: カットオフを超えたイベントを破棄してもよいですか？
決してサイレントに破棄してはなりません。隔離データと監査ログを記録し、ビジネスへの影響を測定します。会計やコンプライアンスの要件により、再計算や手動対応が必要になる場合があります。
フォローアップ 5: 再起動後に結果が過去の状態に戻ってしまうのを防ぐにはどうすればよいですか？
ウィンドウの状態、重複排除の状態、ウォーターマークをチェックポイントに保存します。単調増加するリビジョンを使用し、ダウンストリームで古いリビジョンを拒否し、ログをリプレイして、復旧後に整合性チェックを実行します。
出典 1: Apache Beam Programming Guide
Beam は、遅延データが新しいペインを生成する方法を含め、ウォーターマーク、トリガー、許容遅延、累積モードを定義しています。
出典 2: Apache Kafka Streams Core Concepts
Kafka Streams は、順序不同レコードの猶予期間（grace period）およびウィンドウ終了＋猶予期間経過後の破棄セマンティクスを文書化しています。
出典 3: Dataford streaming interview question
公開されている面接課題では、このシナリオにおける詳細な検証項目として、ウォーターマーク、遅延イベントのルーティング、再計算、および監視が扱われています。