1. 質問と背景
この質問では、データプラットフォーム、データエンジニアリング、アナリティクスエンジニアリングに関する判断力が試されます。焦点はオーケストレーションタスクが完了したかどうかだけでなく、データ自体の健全性と影響にあります。優れた回答には、ディメンション、ベースライン、オーナーシップ、アラートの重大度、そしてリカバリが含まれます。
2. 面接官が評価しているポイント
- オブザーバビリティを鮮度（freshness）、データ量（volume）、スキーマ（schema）、完全性（completeness）、分布（distribution）、一意性（uniqueness）、参照整合性（relational integrity）に分解して捉えているか。
- 単一の閾値を一律に共有するのではなく、データセットの用途、リネージ、ビジネスインパクトに応じてルールを使い分けているか。
- 観測結果にルールのバージョンと実行証跡が保持され、ブロッキングを伴う失敗、警告、不明な状態が区別されているか。
- アラートが、担当者のいない単なる通知にとどまらず、隔離（quarantine）、バックフィル、照合（reconciliation）、レビューへとつながっているか。
MentorCruiseの公開データエンジニアリング面接ガイドでは、データオブザーバビリティの意味について直接問いかけており、鮮度、データ量、スキーマドリフト、NULL値、重複、分布、リネージを挙げています。Great Expectationsでは、データ品質のユースケースとして分布、鮮度、完全性、欠損、スキーマ、一意性、データ量を文書化しており、Expectationを「データに関する検証可能なアサーション」と定義しています。
3. 回答前の明確化のための質問
- そのデータセットはレポート作成、決済処理（settlement）、レコメンデーション、機械学習のトレーニングのいずれに使われますか？レイテンシやエラーによる影響はどのようなものですか？
- ソースはバッチ、ストリーミング、ハイブリッドのいずれですか？イベント時刻と到着時刻はどのように定義されていますか？
- どの障害が公開をブロックし、どの障害が警告のみにとどまりますか？機能縮小運転（degradation）のための信頼できるスナップショット（trusted snapshot）は利用可能ですか？
- アセット、リネージ、アラートのオーナーは誰ですか？どのパーティションをバックフィルする必要があり、どのコンシューマーに通知する必要がありますか？
4. 30秒の回答フレームワーク
私ならビジネスインパクトに基づいてデータセットを階層化し、重要なアセットごとに鮮度、データ量、スキーマ、完全性、分布、リレーションのチェックを定義します。各実行ではルールのバージョン、バッチ、観測値、リネージ、オーナーを記録し、結果はブロック、警告、情報としてルーティングします。下流のリーダーは品質ステータスを参照し、必要に応じて隔離やタイムスタンプ付きの信頼できるスナップショットを利用します。修正後は、同じチェックバージョンを再実行し、入力、出力、除外レコード、消費レコードを照合した上で、レビュー時に閾値をチューニングします。
5. ステップごとの詳細解説
ステップ 1: アセットと重要度の定義
テーブル、トピック、ファイル、モデル入力に不変の識別子を与え、オーナー、コンシューマー、機密性、リネージを紐付けます。決済処理や顧客向け指標など、影響度の高いアセットを最初に対象とします。そうしなければ、チェック費用とアラート件数が制御不能なほど膨らんでしまいます。
ステップ 2: 補完的なシグナルの選択
鮮度ではビジネスタイムスタンプと到着タイムスタンプをチェックし、データ量では行数、ファイル数、バイト数をチェックし、スキーマではフィールド、データ型、互換性をチェックし、完全性では必須値、重複、外部参照をチェックし、分布では範囲、分位数、カテゴリの頻度をチェックします。単一のスコアによって障害のディメンションが隠れてしまわないよう、すべてのメトリクスについてサンプルサイズ、ウィンドウ、閾値、ルールのバージョンを保持します。
ステップ 3: チェックを行動可能かつ説明可能にする
宣言的アサーションとカスタムクエリは、コードレビューとデプロイの管理下に置きます。重要なルールには重大度、失敗時のアクション、オーナーを割り当てます。低ボリュームまたは季節性のあるアセットには、ベースラインや連続ウィンドウを使用します。結果は、パーティション、実行、上流の変更、下流への影響と紐付けられた品質台帳（quality ledger）に書き込みます。
ステップ 4: アラート、隔離、リカバリの連携
不正なデータが財務や機械学習モデルを汚染する恐れがある場合は、公開をブロックします。広範囲のブロックが不要な場合は、局所的な不整合を隔離し、タイムスタンプ付きの信頼できるスナップショットを維持します。アラートには、アセット、ディメンション、観測値、閾値、リネージ、推奨アクションを含めます。上流の修正後はビジネス時間軸でバックフィルを行い、データの欠損や重複がないことを証明するために冪等な書き込みと入出力の照合を実施します。
6. 高品質な回答例
私ならアセットをビジネスインパクト別に階層化し、重要なものについてオーナー、コンシューマー、リネージを登録します。ロードごとに到着時刻とビジネス時刻、行数またはバイト数、スキーマ、必須フィールド、重複、リレーション、主要な値の分布をチェックします。結果にはルールのバージョン、バッチ、サンプルサイズ、観測値、下流への影響を保持し、重大度によって公開をブロックするか、警告を出すか、単に記録するかを決定します。
決済テーブルで完全性チェックが失敗した場合は、バッチを隔離して公開をブロックします。独立したダッシュボードであれば、タイムスタンプ付きの以前の信頼できるスナップショットを利用できます。アラートでは、不透明な単一スコアを表示するのではなく、失敗したディメンションと原因と見られる上流の変更を明示します。修復後は、パーティションをバックフィルし、同じチェックを再実行し、入力、出力、除外レコード、消費レコードを照合し、メトリクスが回復したことを確認して初めてインシデントをクローズします。最後に、誤検知、見逃し、対応時間をもとに、閾値とカバレッジをチューニングします。
7. よくある失敗パターン
- データが新鮮で、完全で、利用可能であるかではなく、DAGが成功したかどうかだけをチェックすること。
- コンシューマー、季節性、サンプルサイズを無視して、すべてのアセットに単一の閾値を適用すること。
- ルールのバージョン、バッチ、リネージを省略し、アラートが再現不能になること。
- あらゆる障害に対してプラットフォーム全体をブロックしたり、不正なデータを自動的に下流システムへリトライしたりすること。
- 修復後にバックフィル、照合、重複書き込み防止を記録せずに履歴を上書きしてしまうこと。
8. フォローアップ質問と回答
フォローアップ 1: データ品質とデータオブザーバビリティの違いは何ですか？
品質チェックはアサーションを検証するものです。オブザーバビリティはさらに、健全性シグナルを実行コンテキスト、リネージ、オーナーシップ、影響度、アクションと結び付けます。品質は運用ループにおける1つのシグナルであり、ループ全体ではありません。
フォローアップ 2: 誤検知をどのように減らしますか？
アセットやセグメントごとの過去のベースラインを使用し、サンプルサイズを保持し、連続するウィンドウを要求し、重大度レベルを適用します。新しいルールはシャドウモードで観察し、誤検知のコストを検証しながら古いバージョンを保持します。
フォローアップ 3: すべてのチェック失敗で公開をブロックすべきですか？
影響度とリネージに基づいて判断します。決済、顧客へのコミットメント、モデルトレーニングを汚染する可能性のある障害は、関連する公開をブロックすべきです。リスクの低いコンシューマーには、警告付きの信頼できるスナップショットを読み込ませることができます。影響範囲、エスカレーションのタイムアウト、リリース条件は監査可能である必要があります。