プロンプトとコンテキスト
あるイベントレイクでは、毎日数十億行が追加され、継続的なユーザー削除リクエストが発生しています。チームは、削除ごとにデータファイルを書き直すことを避けるため、Iceberg v3のdeletion vectorを採用したいと考えています。これらがposition deleteやequality deleteとどのように異なるかを説明し、スナップショットの一貫性、リーダーの互換性、および最終的な物理クリーンアップを設計してください。
面接官が評価するポイント
- deletion vectorが論理的な行位置マーカーであり、オブジェクトストレージのバイトを即座に消去するものではないことの理解。
- 書き込み増幅、読み取りコスト、適用範囲の観点からの3つの削除表現の比較。
- アトミックなスナップショットコミット、並行マージ、旧リーダー向けフォールバック、およびコンパクションの設計。
- プライバシーの証跡とクエリの正当性、バックアップ、レプリケーションの保持期間との整合性。
明確化のための質問
- すべてのライター、カタログ、クエリエンジン、SDKがIceberg v3とdeletion vectorをサポートしていますか？
- 削除対象は安定した位置、ビジネスキー、またはファイル全体の一致のいずれによって特定されますか？
- 論理削除はいつまで維持可能で、オブジェクトバージョン、バックアップ、レプリカはいつ期限切れになりますか？
- エンジンは削除ファイルをどのようにロードし、そのキャッシュキーにスナップショットIDが含まれていますか？
- コンパクションがストリーミング書き込み、スナップショットの期限切れ、またはプライバシー削除と競合する可能性はありますか？
30秒の回答
deletion vectorをスナップショット内の論理層として扱います。各データファイルは削除された行位置をマークする1つのベクターを参照でき、読み取り時にそれらの行をフィルタリングし、物理ファイルは後で制御されたコンパクションによって書き換えられます。position deleteも位置を特定しますが、一般に個別の削除ファイルを使用します。equality deleteは列値に一致させるため柔軟ですが、より多くのデータをスキャンする可能性があります。v3のサポートを確認し、アトミックなスナップショットコミットを使用し、旧リーダー向けの互換性パスを提供し、コンパクション、期限切れ、バックアップ、レプリカを単一の削除SLAに整合させます。
深掘り回答
ステップ1: 削除セマンティクスの定義
deletion vectorは、データファイルに関連付けられ、削除された位置をマークするビットマップまたは同等の構造です。論理スナップショットから行を隠蔽しますが、オブジェクトストレージのバイトが消去されたことを証明するものではないため、プライバシー削除には書き換え、期限切れ、バックアップのガバナンスも必要です。
ステップ2: 3つの表現の比較
position deleteはファイルの位置を指定し、すでにファイルと行を把握しているライターに適しています。equality deleteは列値に一致し、CDCやビジネスキーによる削除に適していますが、リーダーはより多くのファイルをスキャンする可能性があります。deletion vectorはデータファイルごとに行位置マークを集約し、多数の小さな削除ファイルを減らしつつ、フィルタリングとベクターのメンテナンスコストを読み取りパスに移行します。
ステップ3: スナップショット境界の確立
ベクター参照はIcebergスナップショットとともにアトミックにコミットされ、データファイルのパス、ベクターの場所、サイズ、チェックサム、フォーマットバージョンを記録します。ジェネレーターは固定された入力スナップショットを読み取り、既存のベクターをインプレースで変更することはありません。並行競合が発生した場合、別の削除を上書きするのではなく、最新のスナップショットからマージします。
ステップ4: 読み取りパスの設計
プランナーはマニフェストとスナップショットメタデータを読み取り、該当するベクターをロードします。ベクターが存在しない、破損している、またはサポートされていない場合、安全な動作はスナップショットを拒絶するか信頼できる削除表現にフォールバックすることです。エラーを「削除なし」として処理すると行が漏洩します。キャッシュキーにはテーブル、データファイル、スナップショットID、ベクターバージョンが含まれます。
ステップ5: コンパクションとクリーンアップの計画
ベクターの密度、ランダム読み取り増幅、または削除率が測定されたしきい値を超えた場合、残存行を新しいデータファイルに書き換え、新しいスナップショットで古いファイルとベクターを削除します。オブジェクトストレージのライフサイクル、バックアップ、レプリカ、スナップショットの期限切れは、同じ削除SLAを満たす必要があります。カタログのポインタを削除するだけでは物理的な消去の証跡にはなりません。
ステップ6: 旧リーダーの移行
各エンジンのフォーマットバージョン、削除ファイルのサポート、キャッシュ動作を棚卸しします。古いリーダーは、position deleteまたはequality deleteで表現された互換スナップショットを一時的に消費するか、マテリアライズドビューを使用できます。ベクターを解釈できないリーダーに対して、ベクターを含むスナップショットを公開してはなりません。
ステップ7: 正当性とコンプライアンスの検証
並行削除や重複削除、削除後の更新、スナップショットのロールバック、破損したベクター、中断されたコンパクションをテストします。スナップショットごとに最適化の有無で結果ハッシュを比較し、削除された行が見えないことをサンプリングし、データファイル、バックアップ、レプリカの最終保持期間を記録します。
模範解答
まず、すべてのリーダーがIceberg v3とdeletion vectorを解析できることを確認します。削除トランザクションはベースラインスナップショットを固定し、データファイルごとに行位置ベクターを構築し、新しいスナップショットで参照をアトミックにコミットします。競合が発生した場合は、最新のスナップショットを再読み込みしてマージします。読み取り側はスナップショットIDごとにベクターをロードします。欠落または未サポートのベクターがある場合は公開を停止するか、信頼できる削除ファイルにフォールバックし、空のベクターとして処理することは決してありません。密度が測定されたしきい値を超えると、コンパクションによって残存行が書き換えられ、古いファイル、スナップショット、バックアップ、レプリカは単一の削除SLAのもとで期限切れになります。受け入れ基準は並行削除、破損ベクター、ロールバック、中断からの回復を網羅し、結果ハッシュを比較して物理クリーンアップの証跡を生成します。
よくある間違い
- deletion vectorをオブジェクトストレージからの即時消去として扱うこと。
- バージョンおよびスナップショット管理を行わずに、既存のベクターをインプレースで上書きすること。
- v2のみに対応したリーダーにベクターを含むスナップショットを消費させ、それを無視してくれることを期待すること。
- カタログポインタを削除しただけで、コンプライアンスを満たす削除が完了したと宣言すること。
- 並行スナップショットを確認せずにコンパクションを実行し、書き込みや削除を失うこと。
フォローアップの質問と回答
フォローアップ1: なぜ常にequality deleteを使用しないのですか？
ビジネスキーによる削除は適切に表現できますが、読み取り時に多くのファイルを照合する必要が生じる可能性があります。物理的な位置がわかっており、削除が頻繁に行われる場合、ベクターによって削除ファイルのオーバーヘッドを削減できます。選択する前にリーダーのサポート状況とクエリコストを測定してください。
フォローアップ2: 破損したベクターがフィルタリングされていないデータを返すことはありますか？
いいえ。それでは削除された行が公開されてしまいます。チェックサムとバージョンを検証し、スナップショットを拒絶するか信頼できる表現にフォールバックし、修復のためにアラートを発報します。
フォローアップ3: ベクターは更新（update）とどのように相互作用しますか？
更新では通常、新しいデータファイルを書き込み、古い行に削除マークを付けます。新しいファイルと削除参照を1つのスナップショットでコミットし、リーダーが古い行または新しい行のいずれか一方のみを参照し、両方が同時に参照されないようにします。
フォローアップ4: コンパクションのしきい値はどのように設定しますか？
代表的なワークロードのもとで、削除率、ベクターサイズ、ランダム読み取り増幅、スキャンレイテンシ、ストレージコストを測定します。ファイル数だけでしきい値を決めてはなりません。
フォローアップ5: プライバシー削除をどのように証明しますか？
行レベルの不可視性チェック、期限切れスナップショットの記録、書き換えられたファイルのマニフェスト、オブジェクトバージョンの削除結果、バックアップおよびレプリカの保持期間、一致ゼロのサンプリングスキャンを提供します。