課題とスコープ
運用中のレイクでIcebergテーブルを使用しており、1.10.1から1.10.2への移行を進めています。テーブルにはequality delete、v2 delete、並行ライターが含まれており、リリースにはセキュリティ修正が含まれています。アップグレード、検証、ロールバック、およびクリーンアップを設計してください。
Apache Icebergの記録によると、1.10.2は2026年5月18日にリリースされ、equality deleteのスキーマ順序付け、コミット後のスナップショット読み込み、安全でないファイルクリーンアップ、並行フォーマットアップグレード、および依存関係の脆弱性に関する修正が含まれています。この面接では、リリースノートをデータの正確性の証拠へと落とし込む能力がテストされます。
面接官が評価するポイント
- テーブル仕様、エンジン実装、Catalog、FileIO、およびランタイム依存関係の分離。
- Equality delete、position delete、delete vector、およびスナップショット可視性の説明。
- シャドウ検証、並行書き込みテスト、クリーンアップ保護、およびロールバックウィンドウの設計。
- 依存関係アップグレードの通過が過去のクエリの正確性の証明にはならないことの認識。
- 監査可能なメトリクス、停止ライン（ストップライン）、およびアップグレード後のクリーンアップゲートの定義。
確認すべき質問
- どのエンジン、Catalog、オブジェクトストア、Icebergランタイムがデプロイされていますか？ライターは複数の言語で構成されていますか？
- 適用されるフォーマットバージョン、削除ファイルタイプ、パーティショニング、スナップショット保持期間、コミットレートはどのようなものですか？
- これはクライアントの依存関係の置き換えのみですか、それともライター、リーダー、Catalogサービスも変更されますか？
- 一時停止できないストリーミングライターやダウンストリームクエリはどれですか？
バージョンと互換性マトリクス
実際の依存関係ツリーとデプロイ済みバージョンを固定します。リーダー、ライター、Catalog、FileIO、オブジェクトストレージ、クリーンアップジョブ向けのマトリクスを構築します。1.10.2の修正は、古いエンジンが新しいメタデータを理解できることを証明するものではありません。公式の互換性ガイダンスに加えてリプレイテストを使用してください。読み取り専用リーダー、オフラインライター、オンラインライター、クリーンアップの各段階に分けてロールアウトします。
カナリア環境で、本番環境のスナップショット、削除ファイル、並行コミットをコピーします。スナップショットID、マニフェスト数、削除ファイル数、各コンポーネントが読み取ったテーブルフォーマットバージョンを記録します。「読み取れる」ことを証拠として扱うのではなく、未知の互換性はブロッカーとしてマークします。
削除セマンティクスと正確性の検証
重複する等価キー、複数の行バージョン、position delete、delete vector、並行更新を含むゴールデンデータセットを作成します。同じスナップショット、タイムトラベルクエリ、増分スキャンで、アップグレード前後のリーダーを比較します。行数、プライマリキーセット、集計、スキーマ順序をチェックし、フィルタリングされた行と一致しなかった削除を記録します。
現在のテーブルのみを検証してはいけません。不適切な削除はコンパクション後に表面化する可能性があります。元のマニフェスト、削除ファイル、スナップショットログを保持し、独立したSQLまたは小規模で厳密な実装とクロスチェックします。障害発生時はスナップショットを保持し、即座に期限切れにしないでください。
並行コミットとスナップショット保護
アップグレード中に、追加（append）、上書き（overwrite）、行レベル削除、コンパクションのテストを実行します。コミットの競合、Catalogのタイムアウト、一時的なオブジェクトストアの503エラーを注入します。失敗したトランザクションがアクティブなスナップショットによって参照されているファイルをクリーンアップできないこと、および成功したコミットが一貫した1つのスナップショットを公開することを確認します。フォーマットアップグレードと並行するv2 deleteに対して、専用の停止ラインを設定します。
クリーンアップは、保持設定、アクティブなクエリ、ブランチやタグの参照、コミット時刻から候補を算出します。候補は遅延キューに入り、2回目の確認後にのみ削除されます。ロールバック中は、読み取り可能な履歴を維持できるように不可逆的なクリーンアップを禁止します。
デプロイ、ロールバック、ガバナンス
読み取り専用サービス、低負荷ライター、その後にすべてのジョブという順でバッチリリースします。各バッチで、エラー、スナップショットコミットのレイテンシ、クエリ結果の差異、削除漏れ（delete misses）、オブジェクトストアの404、クリーンアップ候補、リソースコストを記録します。ロールバックでは、互換性のあるクライアントに切り替えつつ、新バージョンで作成されたスナップショットをレビュー用に保持します。メタデータを削除することはロールバックではありません。
ビルド成果物内の推移的依存関係を固定してスキャンします。1.10.2でテストフィクスチャやランタイム成果物が削除または変更された場合は、本番環境の前にビルドマトリクスでパッケージング、クラスパス、ライセンスを検証します。手動での例外は有効期限付きで記録します。
障害訓練とリリースゲート
Equality deleteのスキーマ順序変更、並行フォーマットアップグレード、スナップショット読み込み失敗、クリーンアップ時の503受信、古いリーダーによる新しいスナップショットの読み込み、オブジェクトストアの遅延、リカバリ時の重複コミットについて訓練を実施します。ゲートの基準には、説明のつかない結果差異がゼロであること、削除漏れが許容範囲内であること、アクティブなスナップショットのファイルがクリーンアップされていないこと、ロールバック後も履歴が読み取り可能であること、依存関係スキャンに合格していることが含まれます。
順序のみが異なる場合は、順序が未指定であったかどうかを判断します。プライマリキーセットや削除の可視性が異なる場合は、展開を直ちに停止します。保持期間および観察期間の経過後、クリーンアップを段階的に再開します。ディスク容量の逼迫は、証拠の保持を省略する理由にはなりません。
フォローアップの質問と回答例
最新の行数のみを比較するのでは不十分な理由は何ですか？
タイムトラベル、増分読み取り、削除ファイルの適用、過去のクリーンアップが見逃されるためです。ゴールデンデータセット上で、複数のスナップショット、プライマリキーセット、集計、および削除漏れを比較してください。
ロールバックが安全であることをどのように証明しますか？
アップグレード前後のスナップショットを保持し、不可逆的なクリーンアップを停止し、古いリーダーが保持ウィンドウ内を読み取れることを確認し、コミットの競合やオブジェクトストアの障害後のリカバリをリハーサルします。
依存関係のセキュリティ修正はデータ検証にどのように関わりますか？
推移的依存関係を固定して成果物をスキャンし、クラスパス、ライセンス、リーダー/ライターのマトリクステストを実行します。セキュリティスキャンがクリーンであっても、削除セマンティクスの証明にはなりません。