1. プロンプトとコンテキスト
データレイクは毎日オブジェクトストレージファイルを受信し、それらをParquetとして書き込み、ダッシュボードやモデル用のテーブルスナップショットをコミットします。チームは、転送の中断、オブジェクトの置き換え、コンテンツと一致しなくなったメタデータ、リトライ後の重複書き込みを懸念しています。単一の最終行数を比較するだけでなく、障害の境界を特定できるチェックを設計してください。
2. 面接官がテストしていること
- 転送の整合性、ファイルの破損、テーブルの一貫性、およびビジネス上の正確性を分離して捉えられるか。
- チェックサムは偶発的なバイト変化を検出するものの、セマンティックな正確性を証明したり、悪意のある書き換えを単独で阻止したりするわけではないことを説明できるか。
- 書き込み時、読み取り時、バックグラウンドのチェックを、それぞれのコストとカバレッジを含めて区別できるか。
- 隔離可能で再生可能なアラート、修復、および監査のワークフローを提示できるか。
3. 最初に明確にすべき質問
- 目的は転送エラーの防止、サイレント破損の検出、コンプライアンスの証跡作成のどれでしょうか？ 目的によってアルゴリズムや保持ポリシーが変わります。
- ファイルはイミュータブルですか？ インプレースでの置き換えが許可されている場合、オブジェクトバージョンまたはコンテンツダイジェストをテーブルスナップショットに含める必要があります。
- 許容される検出遅延と誤検知率はどのくらいですか？ リアルタイムチェックと日次のフルスキャンではコストや予算が異なります。
- 複数のフォーマット、ストア、またはクロスリージョンコピーが存在しますか？ 境界ごとに新たな検証が必要です。
4. 30秒の回答フレームワーク
「私は4つのレイヤーを使用します。アップロード時のオブジェクトチェックサム検証、読み取り時のParquetページCRC検証、スナップショットコミット時のファイルマニフェストとメタデータの検証、そしてビジネス層での行数、パーティション範囲、重要な集計値の照合です。チェックごとにアルゴリズム、ダイジェスト、オブジェクトバージョン、ジョブID、タイムスタンプを保存します。障害のあったファイルを隔離し、アップストリームソースまたは信頼できるレプリカから再構築します。リスクベースのサンプリングとフルスキャンを組み合わせ、データセットと影響範囲（ブラストレイディウス）によってアラートを段階分けします。最後に、ログにのみ障害を残すのではなく、監査可能なテーブルに結果を書き込みます。」
5. ステップバイステップの論理展開
第1に、転送を保護します。プロデューサーはアップロード前にダイジェストを計算し、ストレージサービスがそれを検証します。不一致の場合はオブジェクトが拒否され、リトライがトリガーされます。Amazon S3はシングルパートおよびマルチパートアップロードのチェックサムをサポートしており、クライアントがダウンロード時にチェックサムを要求することも可能です。マルチパートETagをオブジェクト全体のMD5として扱ってはなりません。
第2に、ファイルを保護します。ParquetはCRC32で各データページのチェックサムを計算できるため、リーダーは解凍前に破損を検出できます。ページチェックサムは破損領域を特定しますがビジネスルールを強制するものではないため、マニフェストにはパス、サイズ、フォーマットバージョン、コンテンツダイジェストも保存する必要があります。
第3に、スナップショットを保護します。コミット時に、オブジェクトバージョンまたはダイジェスト、パーティション、行数、ライタージョブIDを含むイミュータブルなファイルマニフェストを作成します。ファイルが見つからない、重複している、またはダイジェストが異なる場合はスナップショットを拒否します。そうしないと、破損したファイルが下流の読み取りに入り込んでしまいます。
第4に、ビジネスシグナルを照合します。重要なパーティションについては、行数、Null率、金額の合計、ユニークキー数を計算し、アップストリームの台帳や以前のバージョンと比較します。メトリクスが一致していてもコンテンツが同一であるとは証明されないため、照合はチェックサムを超えた独立したシグナルとなります。
第5に、パトロールと修復を行います。ホットデータは読み取り時に検証し、コールドデータはリスクに応じてサンプリングします。高価値または規制対象のデータセットに対しては完全なチェックを実行します。Amazon S3 Batch Operationsは、保存されている大量のオブジェクトに対して、フルオブジェクトまたは複合チェックサムレポートを非同期に生成できます。元のダイジェスト、検出時刻、スナップショット参照情報とともに異常を隔離し、信頼できるレプリカから再構築して、検証後にのみ再度コミットします。
6. 質の高い模範解答
「私はチェックサムをデータ品質プランの全体として扱うことはしません。アップロード層で転送ダイジェストを検証し、ParquetリーダーでページCRCを有効にし、スナップショットのコミット時にオブジェクトバージョンとライターIDを含むイミュータブルなマニフェストを保存し、ビジネス層でクリティカルなパーティションのカウント、キー、金額を照合します。すべてのチェックでアルゴリズム、ダイジェスト、時刻を記録します。読み取りまたはパトロールで障害が発生した場合、該当ファイルを隔離し、新しいスナップショットがそれを参照しないようにします。ホットデータは同期的に検証し、通常のデータはリスクベースのサンプリングでカバーし、規制対象のデータはスケジュールに基づいてフルスキャンします。修復は信頼できるレプリカから再構築し、元の障害証拠を保持します。これらのレイヤーにより、転送、ストレージ、スナップショット、ビジネスロジックの各障害を明確に区別し、それぞれのコストと盲点を明確にします。」
7. よくある間違い
- 間違い → 総行数のみを比較する → 置き換えや重複行が検出をすり抜けてしまう → オブジェクトダイジェスト、ユニークキーチェック、重要な照合を追加する。
- 間違い → マルチパートETagをファイルのMD5として扱う → アルゴリズムのセマンティクスが成立しない → 宣言されたチェックサムタイプとオブジェクトバージョンを保存する。
- 間違い → 読み取りごとに毎回完全な強力チェックを実行する → レイテンシとコストが無限に増大する → ホットデータは同期的にチェックし、コールドデータはリスクに応じてパトロールする。
- 間違い → 不良ファイルが1つあった後にパイプライン全体を再実行する → 正常と確認済みのファイルが二重に書き込まれる可能性がある → 隔離し、ジョブIDで特定して、影響を受けたファイルのみを再構築する。
- 間違い → チェックサムをビジネス上の正確性の証明として使用する → ダイジェストはバイトが変更されたか否かを証明するだけである → 独立したビジネス品質ルールを維持する。
8. フォローアップの質問
攻撃者がファイルを置き換え、そのダイジェストも更新した場合はどうなりますか？
通常のチェックサムは偶発的な破損に対処するものです。保護された署名、アクセス制御、オブジェクトバージョンロック、および監査チェーンを追加します。信頼できるダイジェストは書き込み権限から分離されたメタデータストレージに保持し、誰が新しいバージョンを承認したかを記録します。
フルスキャンに使える時間が1日に1時間しかありません。どのように割り当てますか？
データの価値、最近の変更、過去の障害、レプリケーションパスによってパーティションをスコアリングします。最もリスクの高いものを最初にスキャンし、残りは読み取り時チェック、サンプリング、ローリングウィンドウでカバーします。レイク全体が検証されたと主張するのではなく、カバレッジと未検証のウィンドウを報告します。
修復ジョブによるデータの重複をどのように防ぎますか？
元のファイルID、ターゲットスナップショット、および冪等な書き込みキーを使用します。コミット前に、マニフェストに同じコンテンツダイジェストが既に含まれているかどうかを確認し、スナップショットポインタをアトミックに更新します。リトライでは障害が発生したファイルのみを再構築し、すでに確認済みのファイルを追加することは決してありません。