プロンプトとスコープ
Apache Icebergテーブルがユーザーレコードを保存しており、GDPRによる消去や頻繁な修正をサポートする必要があります。チームはv2からv3へのアップグレードを計画しており、deletion vectorsの導入を検討しています。3つの行レベル削除フォーマット間のトレードオフと、古いリーダー、並行ライター、ロールバック、およびコンパクションを安全に保つ方法を説明してください。
この質問は、単なる機能フラグの切り替えではなく、テーブルフォーマットの読み取り/書き込みプロトコルをテストするものです。Iceberg仕様では、deletion vector (DV) は参照される1つのデータファイルに対する位置ビットマップとして定義されており、そのスコープ、メタデータ、およびメンテナンスの責務はequality deleteファイルやposition deleteファイルとは異なります。
面接官が評価するポイント
- 値ベース、ファイル位置ベース、およびビットマップ削除の違いを区別できているか。
- deletion vectorsがIceberg v3の機能であり、v2で新たにサポートされるものではないことを理解しているか。
- スナップショット読み取りにおけるファイルパス、パーティション、およびシーケンス番号の条件を説明できるか。
- データファイルごとに最大1つのDVであることや、古いposition deletesのマージを考慮しているか。
- フォーマットの選択を、読み取り増幅、書き込み増幅、削除密度、互換性、およびメンテナンスバジェットと関連付けて説明できるか。
- 可観測性、ロールバック訓練、および古いリーダーのための安全な移行パスを設計できるか。
最初に確認すべき明確化事項
以下を確認します：
- テーブルはIceberg v2かv3か、また各リーダーおよびライターのどのバージョンがデプロイされているか？
- 削除リクエストにはビジネスキー値が含まれているか、それともすでにデータファイルと行位置が特定されているか？
- 削除密度、更新頻度、クエリレイテンシの目標値、およびコンパクションのバジェットはどの程度か？
- 読み取り専用のv2エンジンはまだ存在するか、またタイムトラベルやスナップショットロールバックは必要か？
- 削除はダウンストリームのCDCストリームに供給される必要があるか、それともカレントスナップショットでの不可視化で十分か？
詳細が不明な場合は、大半のリーダーがv3をサポートしており、少数のv2リーダーが残存しており、コミットの成功によってコミットされたスナップショット内で削除が可視化される必要があると仮定します。
30秒の回答フレームワーク
セマンティクスに基づいて選択します。equality deletesは列値に一致し、position deletesはファイルと行位置を特定してv2互換性を提供でき、v3テーブルは1つのデータファイルに対する頻繁なposition deletesをdeletion vectorに統合できます。リーダーは、ビットマップのみを見るのではなく、参照されるファイル、パーティション、およびシーケンス番号のスコープを検証する必要があります。
ライターは、1つのスナップショット内でデータファイルあたり最大1つのDVを維持し、既存のposition deletesをそこにマージする必要があります。コミットにはIcebergスナップショットの並行性チェックを使用します。v2リーダーはDVを解釈できないため、書き込みを有効にする前にケーパビリティマトリクス、デュアルリード比較、およびロールバック計画を構築します。受け入れテストでは、削除の可視性、古いスナップショット、競合、コンパクション、およびパフォーマンスを対象とします。
ステップごとの詳細解説
1. 各フォーマットのセマンティクスを定義する
equality deleteは、id = 5などの1つ以上の列値によって、該当する任意のデータファイル内の行に一致します。position deleteは、ファイルパスと0ベースの行位置を特定します。deletion vectorは、参照される1つのデータファイルの位置ビットマップを保存し、ビットがセットされていることはその行が削除されたことを意味します。
これらは単なる圧縮レベルの違いではありません。equality deletesはキーベースのイベントに適していますが、スキャン中に述語の一致処理が必要です。position deletesは高精度でv2互換性がありますが、多数のファイルが蓄積される可能性があります。DVは、1つのデータファイルに対する多数の位置を、直接アドレス指定可能な単一のバイナリオブジェクトに統合します。
2. バージョンとリーダーケーパビリティを処理する
Icebergはv1の後に行レベル削除を導入し、deletion vectorsはv3で追加されました。v3テーブルは新しいposition deleteファイルを追加してはなりませんが、アップグレードされたv2テーブルの既存のposition deletesは有効なままであり、DVが作成される際にマージされる必要があります。
したがって、カタログのアップグレードだけでは不十分です。すべてのリーダーがv3メタデータ、deletion-vector-v1 Puffin blob、および削除マニフェストを解析できるかどうかを棚卸しします。サポートされていないリーダーには、互換性のあるスナップショットまたは完了したマイグレーションが必要です。新しく書き込まれたDVを暗黙のうちに無視することを期待してはなりません。
3. スナップショット読み取りスコープを遵守する
リーダーがデータファイルにDVを適用するのは、データファイルのパスがreferenced_data_fileと等しく、データファイルのシーケンス番号がDVのシーケンス番号以下であり、パーティション仕様および値が一致する場合のみです。パスのみを照合すると、書き換えられたファイルに削除が適用されるリスクがあり、シーケンス番号を無視すると順序セマンティクスが崩れます。
削除メタデータには、包含するファイル、blobオフセット、および長さも記録されます。リーダーは、オブジェクトストレージの見慣れた名前を持つファイルを信頼するのではなく、スナップショットメタデータを通じてblobを特定する必要があります。
4. ライターのマージと並行コミットを設計する
スナップショットでは、1つのデータファイルに対して最大1つのDVが許可されます。削除を追加する際、ライターは現在の削除状態を読み取り、新しい位置を古いDVおよびposition-deleteファイルとマージして、代替となるDVを書き込みます。データファイルが削除された場合、該当するDVエントリを削除マニフェストから削除する必要があります。
コミットには依然としてIcebergスナップショットの楽観的並行制御が使用されます。競合によるリトライでは、現在のメタデータと削除マニフェストを再読み込みする必要があり、最初の試行で生成されたビットマップを再利用することはできません。リトライ回数、競合の原因、および最終的なスナップショットIDを記録します。
5. 読み取りと書き込みの増幅のバランスをとる
まばらで分散した削除の場合、equality deletesは元のファイルを特定する手間を省けますが、スキャン時の照合処理が増加します。少数のファイルに集中した頻繁な削除の場合、DVはposition-deleteファイルの管理とマージの負荷を削減できます。広範囲にわたる削除や、すでに書き換え時期にあるファイルの場合、データを書き換えて削除ファイルをクリーンアップする方が低コストである可能性があります。
DVが常に高速であると主張してはなりません。さまざまな削除密度において、スキャンされたバイト数、削除ファイル数、ビットマップサイズ、マニフェスト読み取り時間、コンパクションCPU、およびエンドツーエンドのレイテンシを比較します。
6. メンテナンス、ロールバック、およびコンプライアンス証拠を計画する
メンテナンスでは、古い削除ファイルをマージし、削除密度の高いデータファイルを書き換え、安全な時間枠内で参照されていないblobを削除する必要があります。タイムトラベルの保持ルールを遵守しなければ、履歴スナップショットが読み取れなくなります。GDPRについては、対象の行が現在の有効なスナップショットおよびダウンストリームのコピーに存在しないことを証明します。
ロールバック訓練では、DVコミット後のロールバック、そのPuffinファイルの継続的な可用性、古いposition deletesの適用、および新しいスナップショットでの削除保証をカバーする必要があります。個人データをログに含めることなく、リクエストID、コミットされたスナップショットID、および検証結果を監査記録に保持します。
7. 互換性と可観測性のゲートを確立する
リリース前に、v2リーダー、v3リーダー、バッチジョブ、ストリーミングリーダー、およびメンテナンスツールのマトリクスを構築します。それぞれについてequality、position、およびDVの動作をテストします。DV適用エラー、不一致のデータファイル、削除マニフェストの肥大化、競合リトライ、古いスナップショットのエラー、およびコンパクションのバックログを追跡します。
ロールアウト中は、同じスナップショット上で古いリーダーと新しいリーダーの結果を比較します（行数、キーセット、サンプリングされた値など）。古いリーダーがv3の削除を解釈できない場合は、影響範囲を拡大するのではなく、DVの書き込みを停止するか、互換フォーマットに切り替えます。
質の高い模範回答
削除セマンティクスとリーダーマトリクスから始めます。キーベースの削除にはequality deletesを使用します。リクエストがすでにデータファイルと行位置を特定しており、v2互換性が必要な場合は、position deletesが適切です。テーブルがv3になり、削除が1つのデータファイルに集中している場合は、その位置をdeletion vectorに統合します。DVはファイルごとのビットマップであり、スナップショット内でそのデータファイルに対して最大1つのDVが存在し、新しいDVを作成する際は既存のposition deletesをマージする必要があります。
リーダーはファイルパスのみに依存することはできません。referenced_data_file、パーティション仕様および値、そしてデータファイルのシーケンス番号がDVのシーケンス番号以下であることを検証する必要があり、blobオフセットと長さは削除マニフェストから取得する必要があります。ライターはスナップショットの楽観的並行制御を使用し、競合時には現在のメタデータを再読み込みし、古いビットマップでリトライしてはなりません。
移行前に、すべてのリーダーでv3、Puffin、およびDVのサポートを検証し、DV書き込みに対するキルスイッチを維持します。受け入れテストは、カレントスナップショットの可視性、タイムトラベル、並行削除、ロールバック、コンパクション、古いリーダーとの比較、およびコンプライアンス証拠を網羅します。パフォーマンス面では、スキャンバイト数、マニフェスト時間、DVサイズ、コンパクションCPU、およびエンドツーエンドのレイテンシを比較します。削除密度が高い場合は、DVを蓄積し続けるよりもデータファイルを書き換える方が有利な場合があります。
よくある間違い
- DVを単なる圧縮されたequality deleteとして扱い、照合セマンティクスを無視すること。
- Iceberg v2がdeletion vectorsを書き込めると主張すること。
- パーティションやシーケンス番号のチェックを行わず、ファイルパスのみでDVを適用すること。
- 1つのデータファイルに対して複数のDVを保持したり、古いposition deletesのマージに失敗したりすること。
- すべてのリーダーやメンテナンスツールをテストせずにカタログをアップグレードすること。
- 読み取りと書き込みの増幅を比較せずに、単一のコンパクション実行を万能の解決策とすること。
- 保持されているタイムトラベルスナップショットを破壊するような方法で削除マニフェストをクリーンアップすること。
- 個人データをログに出力して、それを削除の証拠と呼ぶこと。
フォローアップの質問と回答
フォローアップ1：v2リーダーにDVを無視させないのはなぜですか？
削除メタデータを無視すると、すでに削除された行が返される可能性があり、サイレントな正当性障害（silent correctness failure）が発生します。まずケーパビリティマトリクスと結果比較を完了し、その上でマイグレーション、互換書き込み、またはDV書き込みの一時停止を選択します。
フォローアップ2：削除が増え続けるファイルはいつ書き換えるべきですか？
削除密度、ビットマップサイズ、スキャンCPU、クエリレイテンシ、およびコンパクションバジェットを使用してしきい値を設定します。それを超えた場合は、データファイルを書き換え、新しいスナップショットで該当するDVを削除し、タイムトラベルの保持ポリシーを検証します。
フォローアップ3：競合リトライ時に最も見落としやすいものは何ですか？
最新の削除マニフェストとデータシーケンス番号の再読み込みです。すべてのリトライは現在のテーブルメタデータに対してマージを行う必要があり、競合と最終的なスナップショットIDを記録する必要があります。
フォローアップ4：規制要件を満たす削除をどのように証明しますか？
リクエストのスコープ、コミットされたスナップショットID、カレントスナップショットのクエリ結果、ダウンストリームコピーのチェック、およびメンテナンスステータスを保持します。タイムトラベルの保持期間を明示的に示し、個人データをログから排除します。
フォローアップ5：equality deleteが適しているのはどのような場合ですか？
イベントにビジネスキーのみが含まれている場合、ファイルが頻繁に書き換えられる場合、または1つの述語で多数のファイルをカバーする必要がある場合、equality deletesの方が直接的です。ただし、スキャン時の照合コストを測定し、書き換えポリシーを定義しておく必要があります。