プロンプトとスコープ
バッチジョブが90日分の注文ディメンションをバックフィルしたものの、後にその変換ロジックが誤っていたことが判明しました。実行中もストリーミングの書き込みは継続していました。不正なスナップショットを特定し、影響を受けるクエリを再現し、修正を分離し、コミット競合を処理し、保持ポリシーを設定する方法を設計してください。コアとなるスキルはテーブルフォーマットのバージョニング、リネージ、および復元可能なオペレーションであるため、これはデータエンジニアリングに属する課題です。
面接官が評価するポイント
回答では、スナップショットが単なるファイルコピーではなくメタデータポインタであること、またタイムトラベルが保持設定に依存していることを説明する必要があります。並行コミット、ロールバックの影響、ダウンストリームの読み取り整合性、スナップショットの有効期限切れ、および孤立ファイルのクリーンアップを網羅してください。単に「昨日の状態に復元する」と答えるだけでは、安全性を実証したことにはなりません。
最初に確認すべき明確化のための質問
- どのカタログ、エンジン、コミットロックが使用されており、スナップショットIDはどのように監査されていますか？
- 影響を受けたパーティション、スナップショット、およびダウンストリームテーブルはどれですか？
- 不正なバックフィル中にストリーミングジョブによるコミットは発生しましたか？また、それらを一時停止したりスナップショットから再再生したりすることは可能ですか？
- ビジネス側は、テーブル全体のロールバック、パーティションの再書き込み、あるいは検証用の代替テーブルのいずれを求めていますか？
- スナップショットとデータファイルはどのくらいの期間保持されますか？また、クリーンアップによって復元の証拠が削除される可能性はありますか？
30秒回答フレームワーク
「まず、テーブル履歴とジョブログからバックフィルのコミットを特定し、タイムトラベルクエリを使用してそのスナップショットを親と比較し、影響を受けるパーティションを特定します。正しい入力を分離して検証を再実行し、後続の有効なコミットを保持する必要がない場合にのみロールバックを選択し、それ以外はパーティションの再書き込みまたは修復スナップショットを選択します。ポインタを変更する前に並行コミットとリーダーを確認し、変更後にダウンストリームテーブルを再構築します。復元ウィンドウが閉じるまでスナップショットの失効と孤立ファイルのクリーンアップを遅延させ、スナップショット、ファイル、およびデータ品質のメトリクスを監視します。」
ステップごとのソリューション
テーブル履歴、スナップショット一覧、コミットサマリーを読み取ります。スナップショットID、コミット時刻、実行ID、パーティション範囲、入力バージョンを記録します。並行コミットがインターリーブする可能性があるため、実時間（ウォールクロック時間）だけでターゲットを推測しないでください。メタデータとデータファイルにおいて不正なスナップショットをその親と比較し、ジョブログ、品質アラート、パーティション統計情報を使用して影響範囲を特定します。
タイムトラベルクエリを使用して、不正な書き込みの前後で同じビジネスメトリクスを再現します。スナップショットは一貫した読み取りビューを提供しますが、無限の履歴を保持するわけではありません。失効前にクエリを完了するか、必要に応じて検証サンプルとメタデータ参照をエクスポートしてください。
ストリーミングの書き込みがまだアクティブである場合は、競合するパーティションを一時停止するか、分離されたブランチまたは一時テーブルを作成します。適切なスナップショット時点の正しい入力を読み取り、変換ロジックを修正し、親スナップショットが期待されるバージョンのままであることを確認した後にのみ修復のコミットを実行します。競合が発生した場合は、有効な書き込みを強制上書きするのではなく、最新のスナップショットを再読み込みして再計算します。
テーブル全体のロールバックが適切なのは、ロールバック時点以降の有効なコミットを保持する必要がなく、かつリーダーが一時的なリグレッションを許容する場合に限られます。多くの場合、影響を受けるパーティションを再書き込みするか、修復済みテーブルを公開してダウンストリームの参照先を切り替えます。メタデータポインタを移動しても、すでに他のテーブルにマテリアライズされたデータは修復されません。
修復後、一意性、カウント、金額、レイテンシ、ビジネス照合のチェックを再実行します。不正なスナップショット、修復スナップショット、および未加工イベント（raw events）を比較します。修復バージョンからダウンストリームテーブルを再計算し、実行の再現性を保つために新しいスナップショットとコードバージョンを記録します。
保持期間は、バックフィル、レビュー、ダウンストリームの再計算、および監査の期限をカバーしている必要があります。スナップショットの有効期限が早すぎると、タイムトラベルが失敗する可能性があります。保持されているスナップショットから参照されなくなったファイルのみを、リーダーがそれらを必要としていないことを確認した後に削除する必要があります。孤立ファイルのクリーンアップによって、未コミットまたは並行ジョブによってまだ参照されているファイルを削除してはなりません。
スナップショットの経過時間、コミット競合、ロールバック数、孤立ファイル数、有効期限切れエラー、パーティション品質、ダウンストリーム再計算の遅延、および照合の差異を監視します。スナップショットID、実行ID、コードバージョン、入力パーティションを監査テーブルに書き込み、結果をそのコミットまで遡れるようにします。
模範的な高品質の回答
「テーブル履歴、スナップショットID、実行IDを保持し、バックフィルのコミットを特定した上で、その親と子の間でタイムトラベルクエリを使用して影響を受けるパーティションを絞り込みます。ストリーミング書き込みが継続している場合は、競合範囲を一時停止するか修復内容を隔離されたテーブルに書き込み、コミット時に親スナップショットを検証し、競合時は強制上書きせずに再読み込みします。
後続の有効なコミットを保持する必要がない場合は、メタデータポインタをロールバックできますが、それ以外の場合はパーティションを再書き込みして修復スナップショットを公開します。ロールバックを行ってもダウンストリームのマテリアライズドテーブルは修復されないため、修復バージョンからそれらを再計算し、品質チェックと照合チェックを再実行します。スナップショットの失効と孤立ファイルのクリーンアップは監査ウィンドウを過ぎるまで待機させ、すべてのスナップショット、コードバージョン、入力範囲を記録します。」
よくある間違い
- タイムスタンプからスナップショットを推測する → 並行コミットがインターリーブする可能性があるため、履歴、親子関係、実行IDを使用する。
- スナップショットをファイルバックアップとして扱う → ロールバックによってダウンストリームテーブルが修正されない可能性があるため、メタデータポインタと派生データのインベントリを作成する。
- 最新のスナップショットを強制上書きする → 有効な並行書き込みが失われるため、親を確認して競合をリトライする。
- 古いスナップショットを即座にクリーンアップする → タイムトラベルと監査の証拠が消滅するため、復旧ウィンドウを維持する。
- サンプル行のみを検証する → 集計エラーが残るため、パーティション、メトリクス、一意性、照合をチェックする。
- メインテーブルのみをロールバックする → ダウンストリームの結果が不正なままになるため、修復バージョンから派生テーブルを再計算する。
- 孤立ファイルのクリーンアップを無害と見なす → 並行ジョブがまだファイルを参照している可能性があるため、コミットとリーダーの状態を確認してクリーンアップする。
- コードと入力のバージョンを省略する → 修復を再現できなくなるため、監査データ内でスナップショット、実行、バージョンを紐付ける。
フォローアップの質問と回答
フォローアップ1：テーブルのロールバックがパーティションの再書き込みよりも適しているのはどのような場合ですか？
ロールバック時点以降の有効なコミットを保持する必要がなく、リーダーが一時的なリグレッションを許容できる場合のみです。それ以外の場合は、パーティションを再書き込みするか、修復済みテーブルを公開します。
フォローアップ2：タイムトラベルが失敗することがあるのはなぜですか？
対象のスナップショットが失効しているか、そのファイルが削除されている可能性があるためです。保持期間は調査と再計算をカバーしている必要があり、クリーンアップ状況を監視する必要があります。
フォローアップ3：新しいストリーミングデータの上書きを避けるにはどうすればよいですか？
修復を影響を受けるパーティションに限定し、競合するライターを一時停止するか作業を隔離し、親スナップショットを検証し、競合後は最新バージョンから再計算します。
フォローアップ4：ロールバックによってダウンストリームのイベントも取り消されますか？
いいえ。テーブルのメタデータポインタが変更されるだけです。送信されたイベント、マテリアライズドテーブル、外部への影響については、別途補償処理または再計算が必要です。
フォローアップ5：スナップショットとフルバックアップの違いは何ですか？
スナップショットは通常、ファイルセットのメタデータビューであり、ファイルの保持状態に依存します。フルバックアップには、ストレージ間コピー、カタログ状態、およびリカバリ手順も必要です。
フォローアップ6：バックフィルの修復が正しいことをどのように証明しますか？
入力スナップショットとコードバージョンを固定し、パーティションを再実行し、未加工イベントとビジネスメトリクスを比較し、一意性と金額をチェックして照合を行い、レビュー用に修復スナップショットを保持します。
フォローアップ7：なぜコミットの競合が問題になるのですか？
Icebergのコミットは親スナップショットから更新されます。競合を無視して書き込みを強制すると、別のジョブによる有効なコミットが破棄される可能性があります。競合が発生した場合は、再読み込み、再計算、または人間による判断をトリガーする必要があります。