プロンプトとユースケース
データセットに値が存在するからといって、データが新鮮であるとは限りません。回答では、ビジネス上の可用性期限を測定可能な指標へと変換し、取り込み、転送、処理、または公開のどこで遅延が発生しているかを特定する必要があります。
面接官が評価するポイント
- イベント発生、データ到達、処理完了、クエリ可能（提供）の各時刻が明確に区別されているか。
- データセット、パーティション、ビジネス用途ごとに適切なSLOが設定されているか。
- リネージ、実行状態、品質、鮮度のエビデンスが保持されているか。
- ジョブの成功と利用可能なデータが明確に区別されているか。
- アラートの抑制、エスカレーション、バックフィル、リプレイのパスが存在するか。
- 鮮度の違反がダウンストリームのユーザー影響と関連付けられているか。
回答前の確認事項
- ビジネス上の期限、更新頻度、タイムゾーンは何か？
- 鮮度の測定は、イベント作成、データ到達、クエリ可能のどこから開始するか？
- クリティカルパス上にあるパーティション、フィールド、レポートはどれか？
- 許容される遅延、データの欠落、バックフィル期間はどの程度か？
- アップストリーム側からイベント時刻、バッチID、リトライメタデータを提供できるか？
- SLO違反が発生した場合、レポートを停止するか、データステータスラベルを表示するか、そのまま続行するか？
30秒の回答フレームワーク
「ビジネスの期限に基づいてクエリ可能な鮮度を定義し、イベント時刻、到達時刻、提供時刻を個別に記録します。クリティカルな各データセットについてパーティション単位の鮮度SLIを計算し、リネージ、実行状態、行数、品質アサーションを組み合わせて遅延箇所を特定します。アラートは警告と違反を区別し、ジョブの成功によってデータの欠落が見落とされないようにします。リカバリにはリトライ、バックフィル、リプレイ、ダウンストリームでのラベリングを活用し、ユーザー影響とSLOバジェットに基づいて継続的な改善を行います。」
ステップごとの詳細解説
ステップ 1: 時間セマンティクスを定義する。 ジョブの終了時間のみに依存するのではなく、イベント時刻とクエリ可能時刻を明示し、遅延到着イベント、タイムゾーン、夏時間を処理します。
ステップ 2: SLIとSLOを定義する。 例えば、期限までにクエリ可能となったパーティションの割合を測定し、クリティカルなレポートと探索的データで異なるターゲットを設定します。
ステップ 3: 実行エビデンスを収集する。 実行メタデータ、入力・出力パーティション、リネージ、行数、Nullチェック、データセットのバージョンに紐づく品質アサーションを保存します。
ステップ 4: 遅延箇所を特定する。 エンドツーエンドの遅延を取り込み、転送、キューイング、計算、公開に分解し、アップストリームのデータ未達とダウンストリームの障害を区別します。
ステップ 5: アラートを設計する。 警告には残り時間と傾向を使用し、違反には実際の影響度を使用します。データセットとパーティションごとに重複を排除し、サイレンス、エスカレーション、担当者を割り当てます。
ステップ 6: リカバリとリプレイを行う。 べき等性のあるバッチ、チェックポイント、範囲を限定したバックフィルを使用し、影響を受けたパーティションを再実行して、データのステータスと更新時刻を公開します。
ステップ 7: システムを改善する。 エラーバジェットの消費量、根本原因の割合、誤アラートを追跡し、スケジューリング、キャパシティ、パーティショニング、またはプロダクトのコミットメントを変更します。
質の高い模範解答
「収益レポートには現地時間08:00というビジネス期限があります。私は日次パーティションが08:15までにクエリ可能であることを鮮度の定義とし、イベント発生から到達までの遅延を個別に測定します。監視機構は実行メタデータから入力・出力パーティション、リネージ、行数、品質アサーションを読み取ります。ジョブ自体が成功してもパーティションが欠落していれば、それは鮮度のリスクとなります。08:00前には残り時間に基づいて警告を出し、08:15以降はレポートの影響度に応じてエスカレーションします。リカバリはバッチIDを用いてべき等にバックフィルを行い、レポートステータスにラベルを付与します。振り返りでは、バジェットの消費を取り込み、転送、計算の原因ごとに分解して分析します。」
よくあるミス
- ジョブの成功のみを監視する → パーティションの欠落が見逃される → クエリ可能なパーティションとビジネス期限を確認する。
- 処理終了時刻のみを使用する → 遅延到着イベントの解釈を誤る → イベント時刻、到達時刻、提供時刻を保持する。
- すべてのデータセットに単一のしきい値を設定する → 優先順位が失われる → 用途とクリティカルパスに応じて階層化する。
- 担当者やエスカレーションなしでアラートを発行する → 誰も対応しない → 期限ウィンドウ、担当者、リカバリアクションを紐付ける。
- バックフィル中に上書きする → 重複やバージョンが不明瞭になる → べき等なバッチ、範囲、バージョンを記録する。
フォローアップの質問と回答
フォローアップ 1: アップストリームにイベント時刻がない場合はどうしますか？
到達時刻を明確に制約のある一時的な指標として使用し、アップストリーム側にイベント時刻とバッチメタデータの追加を要求します。
フォローアップ 2: 遅延データが現状ユーザーに影響を与えていない場合はどうしますか？
技術的なSLIとユーザーへの影響を併せて追跡し、ビジネス上のコミットメントに照らし合わせてバジェット消費を判断します。
フォローアップ 3: アラートストームをどのように防ぎますか？
リネージを通じて根本原因を集約し、警告ウィンドウ、重複排除、サイレンス、エスカレーションを適用します。
フォローアップ 4: バックフィル中、ダウンストリーム側は何をすべきですか？
データステータスと更新時刻を公開し、クリティカルなレポートを固定またはラベル付けして、不完全な結果が最終データとして扱われないようにします。
フォローアップ 5: SLOがビジネスニーズを反映しているかをどのように検証しますか？
レポートの利用者にヒアリングを行い、違反事例を意思決定の遅延や顧客への影響と比較して、定期的に許容ウィンドウを再調整します。
フォローアップ 6: 遅延データによって過去のパーティションが変更された場合はどうしますか？
バックフィル期間とバージョンのセマンティクスを定義し、再計算の範囲を記録して、ダウンストリームのキャッシュや増分モデルに通知します。
フォローアップ 7: 最も重要な改善点は何ですか？
ダッシュボードを増やす前に、クリティカルなユーザーパス上で最もバジェットを消費している根本原因を修正することです。