プロンプトとスコープ
これは、データプラットフォームおよびアナリティクスエンジニアリングにおける典型的な設計課題です。目標は、単にいくつかのチェック項目を列挙するのではなく、「信頼性の高いデータ」を測定可能な次元に分解し、それらをコンシューマーの用途や修復プロセスと結びつけることです。
面接官が評価している点
- 鮮度（freshness）、完全性（completeness）、妥当性（validity）、正確性（accuracy）、一貫性（consistency）、一意性（uniqueness）を明確に区別できているか。
- 単一のグローバルなしきい値ではなく、各データプロダクトやコンシューマーに応じた目標値が設定されているか。
- 検知、重要度に応じたアラート通知、ダウンストリームのブロッキング、復旧手順が一体として設計されているか。
- アラートが実行可能なものとなるよう、品質のエビデンス、バージョン、リネージが保持されているか。
最初に確認すべき明確化の質問
バッチ処理かストリーミング入力か、イベント時刻と到着時刻の区別、顧客・財務・機械学習モデルが使用するテーブルやフィールド、許容される遅延、遅延パーティションやタイムゾーン、そしてインシデント発生時にコンシューマー側をブロックするのか、デグレード（縮退運用）させるのか、それとも最後に信頼されたスナップショットを表示するのかを確認します。
30秒での回答構成
コンシューマーの用途に応じてデータコントラクトを定義し、データセットごとに鮮度、ボリューム、完全性、妥当性のチェックを設定します。パイプラインは品質テストの結果とリネージを保存し、警告やブロッキングを伴う障害を担当者へルーティングし、ダウンストリームのジョブが品質ステータスを読み取れるようにします。リリースがブロックされた場合、コンシューマーにはタイムスタンプ付きの信頼できるスナップショットを提供し、復旧時はバックフィル、再計算、データ整合性突合（レコンシリエーション）を行ってインシデントをクローズします。
詳細な回答
1. 品質の次元を用途と結びつける
鮮度は使用可能な最新データがいつ生成されたかを問い、完全性は必要なフィールドやパーティションが届いているかを確認し、ボリュームは期待される行数やバイト数を検証し、妥当性はフォーマットや範囲をチェックし、一貫性はテーブル間の関連性を確認し、一意性は重複を検証します。しきい値は、財務決済、運用ダッシュボード、オフラインでのモデル学習など、用途ごとに異ならせる必要があります。
2. 実行可能なSLAおよびSLOの定義
ビジネス上のデッドライン、最大遅延時間、許容される欠損率、ブロッキング条件、オーナー、エスカレーション時間をデータセットごとに記録します。「データは到着したがバリデーションに失敗した」ケースと「アップストリームが新しいデータを生成しなかった」ケースは分けて追跡します。遅延データには期限付きのバックフィルウィンドウを設定し、期限が切れたパーティションは無限に待機するのではなく「利用不可」とマークします。
3. バージョン管理されたエビデンスの保存
ルールのバージョン、バッチまたはパーティション、観測値、しきい値、実行時刻、入力と出力のリネージ、および結果を永続化します。Expectationsやその他の宣言的システムを使用してチェックを定義し、クエリ可能な品質台帳（クオリティレジャー）によって障害の監査を可能にします。設定変更によってリグレッションが隠蔽されないよう、新しいしきい値は過去のベースラインに照らして評価します。
4. アラート、ブロッキング、デグラデーションの設計
影響度と深刻度に基づいて、データオーナー、プラットフォームのオンコール担当、ビジネスコンシューマーへアラートをルーティングします。回復可能な欠落パーティションは遅延中とマークしつつ信頼できるスナップショットを引き続き提供可能にし、財務やモデルを汚染する恐れのある障害は公開をブロックします。コンシューマーが独断でバイパスできないよう、すべてのブロッキングにはエスカレーション、承認、解除の条件が必要です。
5. バックフィルと整合性突合によるサイクルの完結
アップストリームの修正後、パーティションまたはビジネス時刻単位でバックフィルを行い、同一の変換ロジックとルールバージョンを再実行し、二重書き込みを防ぐために修復バッチを記録します。入力行数、出力行数、拒否されたレコード、遅延レコード、およびダウンストリームでの消費状況を突合します。メトリクスがベースラインに復帰した後にのみインシデントをクローズし、事後レビューでルール、しきい値、またはオーナーシップを調整します。
優れた回答例
私ならコンシューマーごとにコントラクトを定義します。財務決済テーブルは日次のデッドラインから1時間以内に必要な完全性のしきい値を満たして到着する必要がありますが、探索的ダッシュボードはより大きな遅延を許容できます。各データセットには、鮮度、パーティション数、必須フィールド、範囲、テーブル間クロスチェックを設定し、すべての結果にルールのバージョン、観測値、バッチ、リネージ、オーナーを記録します。鮮度のタイムアウトはまず警告を発しますが、財務データに関する完全性の失敗は公開をブロックし、タイムスタンプ付きの信頼できるスナップショットを提供します。アップストリームの修正後は、ビジネス時間単位でバックフィルし、同じ変換とチェックを再利用し、入力、出力、拒否データ、コンシューマーのカウントを突合し、メトリクスが回復した時点で初めてインシデントをクローズします。
よくある間違い
- データが新鮮で、完全で、妥当であるかを確認せず、ジョブの成功のみを監視すること。
- コンシューマーやデッドラインが異なるデータセットに対して、単一のグローバルなしきい値を適用すること。
- バッチ、ルールバージョン、リネージとの紐付けを行わず、品質結果をログにのみ出力すること。
- 単一のデータセットやパーティションに限定された障害のために、すべてのダウンストリームコンシューマーをブロックすること。
- バックフィルバッチの記録、整合性突合、重複排除の保護を行わずに、修復中に履歴データを上書きすること。
- コンシューマーに対してどの次元が利用不可であるかを伝えない、単一の集約スコアのみを報告すること。
フォローアップ質問
アップストリームのジョブは成功したが、新しいデータが到着しない場合はどうしますか？
到着時刻とビジネス時刻を個別に確認し、最後に信頼されたパーティションと期待される更新頻度を比較します。ジョブの成功は実行されたことを証明するだけであり、SLAの遵守を証明するものではありません。タイムアウトが発生した場合は品質インシデントを作成すべきです。
品質ルールにおける誤検知（False Positive）にはどう対処しますか？
観測値、しきい値、ルールのバージョンを保持し、強制適用する前にシャドウモードでベースラインを観測します。段階的しきい値や異常比率を活用し、コンシューマーへの影響を記録し、アラートをサイレントに無効化するのではなく変更履歴をレビューします。
すべての障害がすべてのダウンストリームシステムをブロックすべきですか？
リネージと用途に基づいて対応範囲を限定します。財務決済やモデルを汚染する可能性のある障害は関連する公開をブロックすべきですが、独立した探索的データセットであれば警告付きで前回のバージョンを使用できます。範囲と解除条件の双方が監査可能でなければなりません。
復旧作業で行が失われなかったことをどのように証明しますか？
バッチ、パーティション、入力および出力のカウント、拒否データ、遅延レコード、ダウンストリームの消費状況を突合し、主キーのセットをサンプリングします。修復バッチは再実行可能かつ追跡可能でなければならず、再実行しても同じ結果が得られる（冪等性がある）必要があります。