設問とコンテキスト
この質問は、「データをどのくらいの期間保持すべきか」という問いを、実行可能で説明責任を果たせ、かつ復旧可能なデータライフサイクルシステムへと落とし込めるかを評価するものです。バージョン、スナップショット、レプリカ、バックアップ、およびダウンストリームへのエクスポートは、単一の削除セマンティクスを共有していません。また、Apache Iceberg のスナップショット有効期限切れ（snapshot expiration）処理では、保持対象のスナップショットからファイルが参照されていないことを確認する必要があります。ポリシーのソース、優先順位、エグゼキューター、依存関係の検出、削除の証跡、および障害復旧を網羅してください。保持期間は特定の法律や契約に依存するため、システムは法的判断を代替するのではなく、法的なレビューをサポートするものであるべきです。
面接官が評価しているポイント
- ビジネス上の保持、法的ホールド（legal hold）、削除リクエスト、バックアップウィンドウ、技術的クリーンアップを明確に区別できているか。
- 単一の TTL をハードコードするのではなく、バージョン管理され、スコープが定義され、承認され、例外に対応したポリシーを設計できるか。
- スナップショット、レプリカ、キャッシュ、エクスポート、ダウンストリームテーブル、孤立ファイルに潜む隠れた参照を処理できるか。
- ドライラン、可観測性のある実行、削除の証跡、リトライ、ロールバック境界、監査証跡を提供できるか。
最初に確認すべき明確化のための質問
データ分類、対象者またはテナントのスコープ、ビジネス目的、リージョン、契約、法的な根拠を確認します。ポリシーはテーブル、カラム、レコード、オブジェクト、イベントのどれに適用されますか？法的ホールドが削除リクエストと競合した場合、誰がそれを承認および解除しますか？レイクハウスのスナップショット、トピック、オブジェクトストレージ、バックアップ、検索インデックスには、どのようなコピーとリカバリパスが存在しますか？システムは物理的削除を証明する必要がありますか、それともバックアップが自然に失効する間、オンラインのクエリサーフェスから削除されたことを証明すれば十分ですか？障害発生時、実行は一時停止、リトライ、メタデータのロールバックのいずれを行うことが許容されますか？
30秒の回答フレームワーク
ポリシーをソース、バージョン、スコープ、優先順位、有効性を用いてモデル化し、通常の保持、法的ホールド、削除リクエスト、バックアップ例外を分離します。コンパイラがカタログエンティティをスナップショット、トピック、オブジェクト、インデックス、バックアップのエグゼキューターにマッピングし、まずは影響と競合を示すドライランを生成します。実行時は依存関係グラフと参照チェックを使用して、スナップショットやリカバリに必要なファイルが削除されないようにし、バッチ単位でコミットして全ステップを記録します。生成される証跡は、スコープ、実行時刻、障害、残存するバックアップウィンドウを網羅します。不確実性がある場合は、計画を黙ってスキップするのではなく一時停止してレビューに回します。
ステップごとの詳細解説
1. ポリシーのソースと優先順位のモデル化
ポリシーには、対象スコープ、データラベル、処理目的、保持期間、開始イベント、リージョン、ソース、バージョン、承認者、例外を含める必要があります。削除リクエスト、法的ホールド、契約期間、バックアップの自然失効を個別の制約として表現し、競合とエスカレーションのパスを文書化します。レコードが保持されている理由をシステムが説明できるように、すべての計算に使用された入力スナップショットを永続化します。
2. エンティティと参照カタログの構築
カタログは、テーブル、パーティション、スナップショット、オブジェクト、トピック、インデックス、エクスポート、バックアップを所有者およびリネージと紐付けます。レイクハウスの場合、保持されたスナップショット、ブランチ、タグによって参照されているファイルを特定します。非同期パイプラインの場合、削除イベントがダウンストリームのコンシューマーに到達したかを記録します。参照関係が確定できない場合は、推測で処理せずにデータを保持してワークアイテムを作成します。
3. 実行可能プランのコンパイル
コンパイラは、各エンティティに対して失効時刻、アクション、事前条件チェック、承認要件、ロールバック境界を作成します。アクションには、新規書き込みのブロック、クエリからのデータ非表示、スナップショットの失効、孤立ファイルの削除、ダウンストリームへの削除イベントの発行、バックアップウィンドウの待機などが含まれます。リトライによって副作用が重複しないよう、プランのバージョンと冪等性キーを含めます。ドライランでは競合、推定オブジェクト数、リスクを報告します。
4. バッチ実行とガードレールの設計
テナント、リージョン、テーブル、またはパーティションごとに実行を分割し、バッチあたりの並行性と削除量を制限します。物理的削除の前に、アクティブなスナップショット、リカバリジョブ、法的ホールド、最近の書き込みを再確認します。高リスクなアクションには二重承認または短い凍結ウィンドウを設けます。ストレージやカタログサービスに過剰な負荷をかけないよう、一時停止、再開、指数バックオフをサポートします。すべてのバッチについて、プランのバージョン、入力ダイジェスト、結果、エラー分類を記録します。
5. 検証可能な削除証跡の生成
証跡は単なる「ジョブ成功」ログにとどまりません。ポリシーのバージョン、対象エンティティ、開始・終了時刻、処理済みおよび失敗カウント、参照チェック、ダウンストリームの確認応答、バックアップの失効、検証不可能な境界をリストアップします。スナップショットの失効、ファイルの削除、インデックスのクリーンアップは個別に記録します。バックアップを直ちに物理削除できない場合は、オンラインサーフェスが削除されたこと、バックアップがいつ失効するか、その境界を誰が承認したかを明記します。
6. 障害、リカバリ、継続的監査の処理
メタデータの変更と物理削除を段階的にコミットし、リカバリに必要なスナップショットまたは論理削除（soft-delete）ウィンドウを保持します。ポリシーに誤りがある場合は、以降のバッチを停止し、影響を受けるエンティティをマークして代償プランを実行します。物理的に削除されたデータは不可逆であるため、復元可能であるかのように装ってはならず、許可されたレプリカまたはアップストリームからの再構築によってリカバリします。失効バックログ、削除のブロック、ダウンストリームの確認応答の遅延、バックアップの残存、ポリシーの競合を監視し、ポリシーソースと権限を定期的に見直します。
模範的な高品質の回答
データラベル、目的、対象スコープ、開始イベント、保持期間、リージョン、ソース、バージョン、承認者、例外をモデル化し、通常の保持、法的ホールド、削除リクエスト、バックアップウィンドウ間の競合を定義します。カタログはテーブル、パーティション、レイクハウススナップショット、トピック、インデックス、エクスポート、バックアップを紐付け、不明な参照は保護されたままにします。コンパイラはバージョン管理された冪等なプランを作成し、テナントやパーティションごとにバッチ処理する前にドライランを実行します。削除前にはアクティブなスナップショット、リカバリジョブ、法的ホールド、最近の書き込みを再確認し、すべての結果を記録します。証跡には、スコープ、ポリシーバージョン、削除とダウンストリームの確認応答、失敗、バックアップ失効を記載し、オンラインでの非表示と物理削除を明確に区別します。異常が発生した場合は、後続のバッチを一時停止して代償処理または承認を求めます。継続的な監査により、バックログ、ブロックされた削除、残存データ、権限を追跡します。
よくある間違い
- すべてのストレージシステムを TTL 付きの単一のキーバリューストアとして扱う。
- 最終失効日のみを保持し、目的、ソース、バージョン、承認、競合のコンテキストを失う。
- 削除前にスナップショット、ブランチ、バックアップ、インデックス、ダウンストリームのコピーを無視する。
- スコープや障害境界を示さずに、ジョブの成功ログのみを削除の証明と呼ぶ。
- ドライラン、一時停止、バッチ処理、冪等性、人間の承認によるガードレールを省略する。
- 物理削除が直ちに元に戻せると主張したり、バックアップの自然失効を無視したりする。
- システム設定を法的なアドバイスであるかのように提示し、法律や契約の根拠を失う。
フォローアップの質問と回答
法的ホールドと削除リクエストが競合した場合はどうしますか？
これらを個別の制約としてモデル化し、法的なポリシーで確認された優先順位を適用して、承認者、理由、開始時刻、解除時刻を記録します。システムは削除を凍結したりオンラインアクセスを制限したりすることはできますが、法的な例外を勝手に作り出してはなりません。
スナップショットの失効によって参照されているファイルが削除されないことをどのように証明しますか？
実行前にアクティブなスナップショット、ブランチ、タグ、リカバリジョブの参照を読み取り、保持対象外のスナップショットおよびファイルのみを処理します。投入後に再度スキャンを実行してチェック結果を記録します。不明な参照は保護されたまま維持され、ワークアイテムとして起票されます。
バックアップを直ちに削除できない場合はどうしますか？
オンラインからの削除、バックアップの利用不可、物理メディアの失効を個別の状態として表現します。バックアップの保持期間、暗号化キーの破棄または自然失効の計画、アクセス制限を記録します。証跡には、物理的にまだ削除されていないデータの境界と責任者を明記する必要があります。
誤って削除が発生した場合はどうなりますか？
ポリシーと以降のバッチを停止し、プランのバージョンと監査証跡を凍結した上で、影響を受けたエンティティを評価します。許可されたスナップショット、バックアップ、またはアップストリームからの再構築によってリカバリを行い、修正されたポリシーを適用して、是正措置、承認、通知を記録します。