プロンプトとコンテキスト
レイクハウスジョブがオブジェクトストレージからParquetを読み取ります。クロスリージョンレプリケーション後に少数のファイルが破損しますが、現在のパイプラインはファイル全体をリトライするだけです。ページレベルのCRC計画を設計してください：チェック対象バイトの定義、圧縮境界の説明、リーダー互換性の維持、不良ページの分離、および受け入れメトリクスの選定を行います。これは、列指向ファイルの整合性に関するdataの質問です。
面接官が評価するポイント
- ページCRCとファイルレベルのチェックを区別し、フィールドがオプショナルであることを理解しているか。
- チェックサムのスコープと圧縮境界を正確に述べているか。
- 古いリーダーがCRCフィールドを無視する場合のロールアウトを設計できるか。
- サイレントな部分読み取りを防ぎ、分離、レプリケーションリカバリ、および再書き込みを明確に区別しているか。
- 正確性、特定時間、およびCPU/I/Oオーバーヘッドを測定しているか。
尋ねるべき確認事項
- 対象のライターおよびリーダーのバージョンはページCRCの書き込みと検証を行っていますか？
- 破損はオブジェクトストレージ、レプリケーション、またはローカルキャッシュのどこで発生していますか？
- 圧縮、暗号化、またはページインデックスは有効化されており、リーダーはcolumn chunkを特定できますか？
- すべての行を復元する必要がありますか、それともアップストリームデータからパーティションを再構築できますか？
- リトライによって同じ破損したオブジェクトバージョンがキャッシュされ続ける可能性はありますか？
30秒の回答
「まず、Parquetフォーマットと正確なリーダーバージョンに対するページCRCのサポートを確認し、ファイルバージョン、row group、column chunk、ページタイプ、およびオブジェクトバージョンを記録します。検証の失敗時は、行をスキップするのではなくオブジェクトを隔離（quarantine）すべきであり、リカバリでは一致するレプリカを試すかアップストリームから再書き込みを行います。古いリーダーはCRCを無視する可能性があるため、読み取りは可能ですが整合性検証は保証されません。データページ、ディクショナリページ、ヘッダー、レプリケーションの末尾に破損を注入し、検出率、特定時間、リトライコスト、および結果の一致度を比較します。」
深掘り回答
ステップ 1: フォーマット境界を確立する
Parquetページヘッダーには、データページやディクショナリページなどのページタイプに対するオプショナルの32ビットCRCフィールドが含まれています。ライターがそれを設定し、リーダーがそれを検証することを確認します。ライター側のみの設定変更ではダウンストリームの読み取りは安全になりません。
write page bytes -> compute CRC32 -> persist header and payload
read page -> read header -> verify payload CRC -> decodeリトライ時に同じバイトを読み取ったことを証明できるよう、オブジェクトバージョン、row group、column chunk、およびページ序数を診断情報に含めます。
ステップ 2: 圧縮とチェックサムの順序を確定する
フォーマット仕様と実装によって、CRCがカバーする正確なバイトが定義されます。ライター/リーダーのバージョンマトリックスを維持し、デコードされた論理値に対してチェックサムを勝手に作成してはなりません。解凍エラーとCRC不一致は異なる障害クラスであり、個別のメトリクスが必要です。
ステップ 3: 破損を安全に分離する
失敗時にはファイル読み取りを失敗させ、URI、バージョン、ページ位置、およびエラータイプを付与してオブジェクトを隔離キューに入れます。ページをサイレントに省略してはなりません。利用可能な場合は一致するレプリカを読み取ります。すべてのコピーが失敗した場合は、同じバイトを永久にリトライするのではなく、パーティションを再書き込みするかアップストリームデータをリプレイします。
ステップ 4: 古いリーダーを処理する
古いリーダーはCRCフィールドを無視して行を返す可能性があるため、デコードが成功しても整合性は証明されません。ロールアウト中はリーダー機能マトリックスを維持します。厳格なリーダーで重要なワークロードを検証し、古いリーダーは整合性検証が欠如しているものとしてラベル付けし、サンプリングされたサイドカーチェックによって移行前に差異を検出できます。
ステップ 5: CRCを暗号化およびページインデックスと関連付ける
暗号化の認証、圧縮、およびCRCの順序は、対象の実装に従う必要があります。CRCは認証タグではなく、ページインデックスはペイロードバイトを検証しません。デコードやプルーニングを行う前にフォーマットで要求される整合性チェックを完了し、診断のためにcolumn-chunk座標を保持します。
ステップ 6: 破損注入テストを構築する
データページの1バイトを反転させ、その後ディクショナリページ、ページヘッダー、ファイルの末尾、および複製されたオブジェクトバージョンを個別に破損させます。圧縮ページ、NULLが多いページ、空のページ、および大きなページを網羅します。厳格なリーダーの位置特定を検証し、古いリーダーの挙動を記録します。
ステップ 7: 再現可能な受け入れ基準を定義する
同じオブジェクトバージョン、並行性、およびコールドキャッシュの条件下で、CRCのオンとオフをCPU、読み取りバイト数、p95、検出率、特定時間について比較します。無傷の入力に対する結果は完全に一致する必要があり、注入された破損は失敗して隔離に入る必要があります。チェックサム障害、繰り返されるリトライ、およびリカバリ成功率についてアラートを設定します。
模範回答
「私はまずParquetフォーマットと対象リーダーの実装から始め、ページCRCがオプショナルであること、どのページタイプがそれを保持するか、およびカバーされる正確なバイト範囲を確認します。読み取り処理は解凍およびデコードの前にCRCを検証します。解凍エラーとチェックサムエラーは別々のメトリクスです。不良ページはファイルを失敗させて隔離し、リカバリは別のレプリカから同じオブジェクトバージョンを使用するか、アップストリームから再書き込みを行います。ページをスキップしたり、不良オブジェクトを際限なくリトライしたりしてはなりません。
古いリーダーはCRCを無視する可能性があるため、機能マトリックスを公開し、重要なジョブを厳格なリーダーに移行します。ビット反転、ページヘッダー、ディクショナリページ、およびレプリケーション切り捨てテストにより、ロールアウトを拡大する前に検出、特定、CPU、読み取りバイト数、リカバリ率、および結果のハッシュを測定します。」
よくある間違い
- CRCを認証として扱う → CRCは偶発的な破損を検出するものであり、改ざんは検出できません → 必要に応じて認証付き暗号化または署名を追加します。
- ライターのみを変更する → ダウンストリームのリーダーがフィールドを無視する可能性があります → バージョンマトリックスをテストします。
- 不良ページをスキップする → サイレントに行が欠落します → 失敗させて隔離します。
- 1つのオブジェクトを永久にリトライする → コストを増大させます → バージョンを固定し、リトライを制限します。
- ファイル全体の破損のみをテストする → ページやヘッダーの境界を見逃します → 多層的な破損を注入します。
- デコードエラーとチェックサムエラーを混同する → リカバリを不明瞭にします → メトリクスとランブックを分離します。
フォローアップの質問と回答
フォローアップ 1: CRCは悪意のある改ざんを防ぎますか？
いいえ。CRCは偶発的な破損を検出します。耐改ざん性のためには、認証付き暗号化、署名、または信頼できるストレージの検証を使用してください。
フォローアップ 2: 古いリーダーは互換性を損ないますか？
通常、フォーマットのデコード機能は維持されますが、CRCが検証されたと主張することはできません。重要なジョブには厳格なリーダーを使用する必要があります。
フォローアップ 3: 不良ページのみを再読み込みできますか？
レンジリードまたは一致するレプリカを試行しますが、完全な結果を検証してください。検証済みのコピーが存在しない場合は、アップストリームデータを再書き込みまたはリプレイします。
フォローアップ 4: なぜオブジェクトバージョンを記録するのですか？
リトライ中にオブジェクトが上書きされる可能性があります。バージョン識別子によって、エラーとリカバリアクションが1つのバイトシーケンスに関連付けられます。
フォローアップ 5: オーバーヘッドをどのように制御しますか？
現実的なページサイズと並行性でCPU、スループット、およびp95をベンチマークし、全面展開の前にリスクの高いパーティションでカナリアリリースを実施します。