プロンプトとコンテキスト
本番環境のIcebergテーブルは日次で増分データを受信します。エンジニアには、隔離された書き込み、品質チェック、アトミックな公開、監査マーカー、および古いスナップショットの自動クリーンアップが必要です。ブランチ、タグ、スナップショット参照、同時コミット、保持、およびロールバックを設計してください。これは、テーブルフォーマットのメタデータとリリースガバナンスに関するdataの質問です。
面接官が評価するポイント
- ミュータブル（変更可能）なブランチとイミュータブル（不変）なタグの違いを明確に理解しているか。
- スナップショット参照、
main、および現在のスナップショットについて説明できるか。 - WAPチェック、アトミックな公開、およびコンフリクト処理を設計できるか。
- ロールバックの証拠を削除することなく、ブランチ／タグの保持を設定できるか。
- 読み取り側が一部の不完全なファイルではなく、一貫した1つのスナップショットを参照できることを証明できるか。
質問すべき確認事項
- カタログ、エンジン、およびバージョンは、ブランチ、タグ、WAPをサポートしていますか？
- 本番環境の読み取り側は常に
mainを使用しますか、それとも明示的な参照を使用しますか？ - どのようなテーブル、パーティション、およびクロス artisan/テーブル間の品質制約が必要ですか？
- 複数の書き込みブランチを同時にマージできますか、また競合はどのように解決されますか？
- 監査ポイントはどのくらいの期間保持する必要があり、孤立ファイルは誰がクリーンアップしますか？
30秒での回答
「各ジョブを隔離されたブランチに書き込み、そのスナップショットに対して品質チェックを実行します。承認後、mainをアトミックに進め、監査ポイント用の不変タグを作成します。ブランチとタグには独立した保持ルールを設定し、有効期限切れ処理では参照されておらずポリシーを満たすスナップショットのみを削除できるようにします。リリース前後にスナップショットID、行数、主要メトリクス、クエリ結果を比較し、競合は再試行または裁定します。」
詳細な回答
ステップ 1: 参照モデルの確立
Icebergはブランチとタグをスナップショット参照として保存します。ブランチは変更可能なスナップショットチェーンであり、タグは1つのスナップショットを指し、リリース、月末締め、監査に適しています。本番環境のmainには所有者が必要であり、サービスがテーブルメタデータを直接編集してはなりません。
main -> snapshot 120
audit-2026-08-01 (tag) -> snapshot 118
daily-load (branch) -> snapshot 121この図は参照を示しており、カタログのコミットチェックによって実際の更新が保護されます。
ステップ 2: Write-Audit-Publishの実装
書き込みフェーズでは、mainを変更することなく、データファイルと削除ファイルをワークブランチにコミットします。監査フェーズでは、そのブランチのスナップショットに対してスキーマ、一意性、範囲、行数、およびクロス artisan/クロス artisanチェックを実行します。承認されたスナップショットのみが本番参照を進め、実行者、バージョン、レポートが記録されます。
ステップ 3: 同時コミットの処理
オプティミスティックなカタログチェックにより、古い祖先に基づく更新は拒否されます。ジョブは最新のスナップショットを再読み込みし、変更をマージまたはリベースして、必要なチェックを再実行する必要があります。参照を上書きしてはなりません。互いに素なパーティションへの書き込みであっても、明示的なマージポリシーが必要です。
ステップ 4: 読み取りの一貫性の維持
クエリは開始時にスナップショットIDまたは参照バージョンを固定（ピン留め）します。データファイルが完全で読み取り可能になった後に、公開によってメタデータ参照が変更されます。失敗したジョブによって参照されていないファイルが残る場合がありますが、孤立ファイルのクリーンアップはコミットと安全ウィンドウを待ってから行われます。
ステップ 5: 保持および監査ポリシーの設定
タグは重要なリリーススナップショットを保持し、ブランチには最大保持期間やスナップショット数のポリシーを設定できます。有効期限処理（Expiration）は、まずmain、ブランチ、およびタグによって参照されているスナップショットを計算し、対象となる履歴のみを削除します。監査タグの保持期間は、コンプライアンスおよびロールバック期間をカバーする必要があります。
ステップ 6: ロールバックの設計
ロールバックは、mainを検証済みの古いスナップショットまたはタグに移動し、新しいメタデータコミットを記録します。問題のあるスナップショットを最初に削除しないでください。ダウンストリームのジョブとマテリアライズドビューを更新し、キャッシュが失敗したバージョンを返さないようにします。
ステップ 7: 受け入れメトリクスの定義
ブランチコミットのレイテンシ、チェック合格率、公開成功率、競合再試行回数、参照スナップショット数、有効期限切れボリューム、孤立ファイル、およびロールバック時間を追跡します。ロールアウトを拡大する前に、スナップショットID、行数、主要な集計値、ダウンストリームの結果を比較します。
模範解答
「日次ジョブは隔離されたブランチに書き込み、固定されたスナップショットに対してチェックを実行します。承認されるとアトミックにmainが進められ、不変の監査タグが作成されます。有効期限処理では、履歴や孤立ファイルをクリーンアップする前に、main、ブランチ、またはタグによってまだ参照されているすべてのスナップショットを保護します。
カタログのオプティミスティックチェックによって古いコミットは拒否されます。ジョブは参照を上書きするのではなく、最新の祖先を再読み込みして検証を再実行します。読み取り側はスナップショットを固定し、ロールバックは新しいメタデータコミットを介してmainを古いタグに向けます。受け入れ基準として、スナップショットID、行数、集計値、公開成功率、競合、およびリカバリ時間を比較します。」
よくある間違い
- ブランチを不変として扱う → 以降のコミットで移動してしまう → 監査にはタグを使用する。
mainメタデータを上書きする → 同時実行保護をバイパスしてしまう → カタログ経由でコミットする。- ロールバック前に履歴を削除する → 証拠が失われる → タグを保持し、新しいロールバックコミットを作成する。
- 期間のみで有効期限切れにする → 参照されているスナップショットが削除される → まず参照セットを計算する。
- クエリのスナップショットを固定しない → 長時間の読み取りでバージョンが混在する → 参照またはスナップショットIDを固定する。
- 孤立ファイルを即座にクリーンアップする → 未コミットのファイルが削除される可能性がある → 安全ウィンドウを待つ。
フォローアップ質問と回答
フォローアップ 1: なぜ公開にタグを使用するのですか？
ブランチは先に進みますが、タグは1つのスナップショットを固定するため、監査、月末処理、ロールバックに適しています。これらは個別のライフサイクルを持つことができます。
フォローアップ 2: 2つのブランチが同じパーティションに書き込んだ場合はどうなりますか？
古いコミットを拒否し、最新の祖先からマージするか、人手による裁定を要求します。ファイル名による上書きは絶対に行いません。
フォローアップ 3: 有効期限切れ処理でロールバックポイントが削除されることはありますか？
スナップショットがブランチまたはタグによって参照されており、保持ポリシー内にある限り削除されません。参照は有効期限処理の保護対象セットに含まれている必要があります。
フォローアップ 4: 部分的なデータの読み取りをどのように防ぎますか？
まずファイルを完全に書き込み、1つのアトミックなmainスナップショットを公開し、未公開のブランチを本番クエリから除外します。