プロンプトとスコープ
Iceberg v3イベントテーブルは、CDC、再計算、およびクロススナップショット監査をサポートする必要があります。チームは、追跡可能な行の同一性と、各行を最後に更新したコミットを求めています。行リネージフィールド、継承のタイミング、コミットのリトライ、equality-deleteの制限、および検証について説明してください。
面接官がテストしていること
- 書き込み時に値を勝手に生成するのではなく、
_row_idおよび_last_updated_sequence_numberの継承を理解しているかどうか。 first-row-id、next-row-id、およびマニフェストを関連付けられるかどうか。- 楽観的コミットのリトライ、同時実行ライター、および古いリーダーを適切に処理できるかどうか。
- 行リネージ、ビジネスキー、equality deletes、および物理的なクリーンアップを明確に分離して理解しているかどうか。
尋ねるべき確認の質問
- 物理的な行の同一性、ビジネスエンティティの同一性、またはその両方が必要ですか？
- すべてのリーダーがIceberg v3をサポートしていますか？また、古いエンジンのフォールバックは何ですか？
- 更新はcopy-on-write、merge-on-read、またはequality deletesのどれですか？
- スナップショットを横断した監査が必要ですか、それとも現在のテーブルバージョンのみで十分ですか？
30秒の回答フレームワーク
Iceberg v3は、テーブル行の同一性に_row_idを、最終更新コミットに_last_updated_sequence_numberを使用します。リーダーは、データファイルのfirst-row-id、行の位置、およびマニフェストのシーケンス番号からこれらを継承します。ライターはコミット前にnullフィールドを出力できるため、リトライ時はメタデータを再読み込みして新しいfirst-row-idを割り当てる必要があります。行リネージはビジネスキーではなく、equality deletesは古い行IDを保持しません。v2/v3の機能マトリックスを確立し、スナップショット、コンフリクト、およびリトライをテストします。
ステップバイステップの詳細解説
1. 同一性を分離する
ビジネスキーはレコードがどのエンティティを表しているかを示し、_row_idはこのテーブル内の行を識別します。エンティティが削除されて再度書き込まれた場合、そのビジネスキーは再出現する可能性がありますが、その行リネージは永続的なエンティティIDとして扱われるべきではありません。監査では、ビジネスキー、スナップショットID、および行IDを一緒に保持する必要があります。
2. フィールド継承の仕組みを理解する
新しい行の_row_idおよび_last_updated_sequence_numberは、データファイル内ではnullである場合があります。読み取り時、行IDはファイルのfirst-row-idと行の位置から導出され、更新シーケンスはマニフェストエントリから取得されます。これにより、ライターはコミットが成功する前にデータファイルを書き直す必要がなくなります。
row_id = data_file.first_row_id + row_position
last_updated = manifest_entry.data_sequence_number3. コミットリトライの処理
楽観的コンフリクトの発生後、テーブルのnext-row-idが変更されている可能性があります。リトライ時は現在のメタデータを再読み込みし、新しいfirst-row-idを割り当ててマニフェストリストを再構築する必要があります。最初の試行の範囲を再利用することはできません。試行内容、コンフリクトの理由、および最終的なスナップショットIDを記録します。
4. equality-deleteの境界
equality-deleteエンジンは通常、古いデータ行を読み取らずに変更を書き込むため、置換された行の元のIDを提供できません。仕様では、このような更新は古い行の削除と新しい一意な行の追加として扱われます。エンティティの同一性が重要な場合は、ビジネスキーと変更イベントを個別に保持してください。
5. 互換性と読み取り
行リネージはv3の機能であり、古いリーダーはその予約フィールドを理解できない可能性があります。アップグレードする前にエンジンマトリックスを構築し、古いリーダーがnullを参照するか、フィールドを無視するか、または失敗するかを検証します。エクスポート処理は、すべてのリーダーが行IDを導出できることに依存すべきではありません。v3対応サービスが監査フィールドをあらかじめ実体化（materialize）しておくことができます。
6. 検証、ロールバック、およびクリーンアップ
単一の書き込み、同時コミット、コンフリクトリトライ、スナップショット読み取り、削除と再書き込み、およびコンパクションをテストします。各スナップショットにおける行IDの一意性、古い範囲が再利用されていないこと、およびシーケンス番号と最終スナップショットの整合性を検証します。ロールバックは履歴IDを書き直すのではなくスナップショット参照を変更します。物理的なクリーンアップは引き続きスナップショットの有効期限切れ処理（snapshot expiration）や孤立ファイルクリーンアップ（orphan cleanup）の役割です。
模範的な高クオリティの回答
ビジネスキーとIcebergの行リネージを明確に分離します。v3では、_row_idと_last_updated_sequence_numberがテーブル行の同一性とコミット順序を提供し、読み取り時にfirst-row-id、行の位置、およびマニフェストのシーケンス番号から継承されます。ライターはコミット前にフィールドをnullのままにし、コンフリクト時のリトライでは古いマニフェストを再利用するのではなく、メタデータを再読み込みして新しい範囲を割り当てます。equality deletesは古い行IDを保証しないため、監査データにはビジネスキー、スナップショットID、変更イベントも併せて保存します。ロールアウト前に、v2/v3リーダー、コンフリクト、スナップショット読み取り、コンパクション、クリーンアップをテストし、ロールバックはスナップショット参照の切り替えのみに留めます。
よくある間違い
- 行IDをビジネスキーとして扱う → 削除と再書き込みのセマンティクスが壊れる → 両方の識別情報を保持する。
- ファイル書き込み時に永続的な行IDを割り当てる → リトライによって範囲が重複したり浪費されたりする → コミット時の継承に依存する。
- コンフリクトしたマニフェストを再利用する → 古いnext-row-idが含まれている → リトライごとに必ずメタデータを再読み込みする。
- equality deletesが行IDを保持すると仮定する → 仕様では保証されていない → ビジネスイベントでエンティティを追跡する。
- 現在のクエリのみを検証する → スナップショットや古いリーダーで依然としてリスクが残る → クロススナップショットの挙動と機能をテストする。
フォローアップ質問と回答
なぜ_row_idをビジネスキーに置き換えないのですか？
ビジネスキーは重複したり、変更されたり、テーブル間で一意でなかったりする可能性があります。行リネージはテーブル行の同一性です。この2つは異なる監査上の問いに答えるものであるため、両方を保持する必要があります。
コンフリクトのリトライによって行IDにギャップが生じる可能性はありますか？
実装によっては、未使用の範囲が存在する可能性があります。安全性のルールは、成功したスナップショットによって公開されたIDを決して再利用しないこと、および最終的なスナップショット内で行IDの一意性を保つことです。
コンパクションによって行IDは変更されますか？
正しい実装であれば、リネージの継承を通じて同一性が保持されます。同一のスナップショットセマンティクスについて、コンパクション前後の監査マッピングを検証してください。ファイルパスの確認だけでは不十分です。