プロンプトと適用範囲
この設問では、単一の DELETE ではなく、ライフサイクルの設計と証明がテストされます。未加工オブジェクト、テーブルファイル、派生結果、キャッシュ、特徴量、エクスポート、ログ、スナップショット、バックアップを通じてサブジェクト識別子を追跡します。システムが完了を正当に主張できるタイミングを定義してください。
このプロンプトは法的な義務を決定するものではありません。プライバシー担当者および法務担当者が保持義務、例外、期限を定義し、エンジニアリングがそれらを実行可能なスコープ、状態、および証跡へと落とし込むことを述べてください。
面接官が評価している点
- コピー、派生値、ログ、スナップショット、キャッシュ、バックアップを網羅するデータインベントリとリネージ。
- 取り込みやリプレイによってデータが再導入されない、冪等で再試行可能、かつ一時停止可能なリクエスト。
- 論理的な不可視化、物理的な消去、スナップショットの失効、バックアップの有効期限の明確な境界。
- テナントおよび機密データの保護を伴う、削除中のクエリおよびトレーニングの分離。
- 1つの成功を示すブール値ではなく、すべてのスコープが処理されたことを証明する証拠。
推奨される回答の構成
サブジェクトキー、リクエスト状態、および完了契約を定義します。ドメインとリネージをマッピングします。安定した erasure_id を割り当て、そのサブジェクトの取り込みとリプレイをブロックし、各ドメインを削除または再構築した上で、独立したチェックと保持期間のクリーンアップを実行します。入力バージョン、カウント、失敗、カーソルを永続化し、重複した影響を与えることなくリカバリが再開できるようにします。
ディープダイブ：リクエストから証明まで
最初にスコープとアイデンティティを定義する
アカウント、デバイス、注文、および外部識別子を不変のサブジェクトキーにマッピングします。未加工オブジェクト、Icebergの行、集計、特徴量、インデックス、エクスポート、キャッシュ、ログ、バックアップをリストアップします。不明なデータや追跡されていないデータは、明示的なリスク項目となります。
消去と取り込みを排他的にする
消去サービスは erasure_id とサブジェクト状態を登録します。取り込み、リプレイ、および派生ジョブは、書き込み前に削除マーカーを確認します。トゥームストーンまたはサブジェクトパーティションのバリアが古いイベントをブロックし、バージョンまたはリースによって、消去後に古いスナップショットがコミットされるのを防ぎます。
論理的削除と物理的クリーンアップを分離する
Icebergのequality deleteやposition deleteは、古いファイル、スナップショット、孤立ファイルが存在するままでも、読み取りから行を隠すことができます。コンパクション、スナップショットの失効、孤立ファイルのクリーンアップを保持期間内にスケジュールします。インベントリに基づいて未加工オブジェクトを削除します。バックアップについては、制御された復元ルールと有効期限に基づく削除タスクを記録します。
派生データは入力の削除だけでは解決できない
追跡可能な集計はサブジェクト単位で再計算します。遡って追跡できない集計については、サブジェクトレベルの中間状態を保持するか、パーティションを再構築します。特徴量、キャッシュ、エクスポートのオーナーはそれぞれのバージョンをクリーンアップする必要があります。消去中は公開を一時停止し、サニタイズされた入力から再構築します。
証拠をもって完了を定義する
ドメインごとに、スキャン範囲、一致件数、削除バージョン、物理クリーンアップジョブ、失敗、および検証時間を記録します。独立したクエリ、エクスポート、およびリプレイのパスから対象のサブジェクトが返されないことを確認する必要があります。証拠の欠落は成功ではなく、部分的な完了を意味します。
回答例
「まずプライバシー担当者とサブジェクトキー、保持の例外、期限を確認します。消去サービスは冪等な erasure_id を作成し、取り込みとリプレイをブロックし、各ドメインの作業項目を書き込みます。未加工オブジェクトはインベントリから削除されます。Icebergにはまずequality deleteが適用され、その後にコンパクションとスナップショットの失効が実行されます。集計と特徴量はサブジェクトごとに再構築され、キャッシュとエクスポートのオーナーはそれぞれのバージョンをクリーンアップします。バックアップは制御された復元のみを許可し、リリース前にトゥームストーンをリプレイします。各ステップでバージョン、カウント、失敗が記録されます。すべてのドメインで一致がゼロになり、未解決の失敗がなくなった場合のみ、リクエストは完了状態に移行します。」
よくある失敗パターンと対策
- プライマリテーブルのみを削除する → 未加工、派生、キャッシュ、エクスポート、ログ、バックアップの各コピーを列挙します。
- 削除ファイルの作成を物理的消去と呼ぶ → スナップショット、古いファイル、コンパクション、孤立ファイルのクリーンアップについて説明します。
- 同時書き込みを無視する → バリア、トゥームストーン、バージョンチェック、リプレイゲートを追加します。
- 1つの成功フラグを使用する → ドメインごとのスコープ、カウント、バージョン、独立したチェックを永続化します。
- 即座のバックアップ書き換えを約束する → 保持期間、アクセス制御、有効期限によるクリーンアップ、承認された例外を明記します。
評価基準とセルフチェック
優れた回答には、安定したアイデンティティ、完全なリネージ、冪等なステートマシン、書き込みおよびリプレイのバリア、論理的/物理的境界、派生データの再構築、バックアップの取り扱い、障害復旧、ドメインごとの証跡、ゼロ一致の検証、テナント分離、監査ログの最小化が含まれます。
自問してみてください：すべてのコピーのオーナーを把握していますか？古いイベントが再混入する可能性はありませんか？どのデータが隠蔽され、どのデータが消去されていますか？リプレイはどのようにトゥームストーンを消費しますか？障害からどのように再開しますか？どのような証拠によって完了状態が更新されますか？
フォローアップと発展課題
Icebergテーブルが大きすぎて即座のファイル書き換えができない場合はどうしますか？
読み取りから即座にサブジェクトが除外されるよう行レベルの削除を書き込み、その後、削除の密度と保持期限に応じてコンパクションをスケジュールします。その間、スナップショットやエクスポートへのアクセスを制限し、物理クリーンアップの時間を状態として保持します。
削除と新しいイベントが同時に到着した場合はどうなりますか？
サブジェクトバリアまたは単調増加バージョンを使用して、消去が完了するまで新しいイベントを拒否または隔離します。リプレイはトゥームストーンを確認する必要があり、リリース後は明示的に新しく許可されたイベントのみが通過できます。
派生メトリクスがユーザーまで遡って追跡できない場合はどうしますか？
そのドメインを証明不可能としてマークし、公開を一時停止した上で、サブジェクトレベルの中間状態の保持、パーティションの再構築、または承認された代替手段を選択します。リネージの証拠がない限り、削除完了を主張してはなりません。
監査証跡からの個人データの漏洩をどのように防ぎますか？
名前、メールアドレス、イベント内容ではなく、不可逆なサブジェクト参照、リクエストID、スコープ、カウントを保存します。監査ログへのアクセスは個別に保護し、その保持期間をプライバシーポリシーに合わせます。