题干与适用场景
用户要求删除个人数据，但系统同时保留运营数据、分析数据和灾备副本。部分数据已被聚合，部分下游由第三方托管。请说明请求认证、影响面发现、删除传播、备份处理、异常恢复和对外反馈。
题目考察数据血缘、异步工作流、幂等性、保留策略和证据链。法律适用范围需要由隐私与法务确认，工程方案不能自行扩大或缩小例外。
面试官考察点
面试官会看你是否把“删除请求已接收”“活跃系统已删除”“备份已超出使用范围”和“所有豁免有记录”分别定义。欧盟委员会、EDPB 和 ICO 都强调删除权存在例外，且备份不能被继续使用；工程上必须能说明范围和完成状态。
高质量回答会先建立数据目录和用户标识映射，再用版本化删除事件驱动各存储完成删除或隔离，最后用独立查询验证。只执行一条 SQL DELETE 无法覆盖湖仓、缓存、索引、快照和第三方副本。
回答前需要澄清的问题
- 请求者如何完成账号级认证，代理请求和误删如何防止？
- 哪些字段属于个人数据，哪些聚合结果已不可重新识别？
- 是否存在法律保留、财务留档或争议处理例外？
- 数据目录是否记录每个下游、快照、备份和第三方处理者？
- 对外承诺是立即删除、在期限内完成，还是先让数据“超出使用范围”？
30 秒回答框架
“我先认证请求并生成不可变的 deletion case，再通过数据目录解析用户标识和所有处理系统。工作流发布带版本和幂等键的删除事件，各下游回报状态；活跃数据删除后，备份按保留计划隔离并禁止恢复使用。法律保留和不可逆匿名化单独记录。最终用抽样查询、墓碑清单、下游确认和审计日志证明完成范围，失败任务可安全重试。”
分步骤深入解答
第一步：建立数据目录与删除范围
为用户维护统一的 subject key 映射，例如账号 ID、租户 ID、事件中的 pseudonymous ID 和第三方映射。数据目录记录来源、处理目的、保留期限、下游表、文件、索引、缓存、快照、备份和处理者。
先冻结新增处理，避免删除期间继续产生同一主体的数据。对每个资产定义动作：物理删除、字段清除、不可逆匿名化、阻断访问或法律保留，并记录依据。
第二步：创建幂等删除工作流
请求服务完成身份确认后生成 caseId、subjectId、策略版本和唯一 requestKey。通过事务性 outbox 发布删除事件，消费者以 caseId + assetId 做幂等。
{
"type": "SubjectErasureRequested",
"caseId": "erase_20260729_001",
"subjectId": "user_123",
"policyVersion": "2026-07",
"requestKey": "user_123:20260729:001"
}每个消费者先写状态再执行可重试动作，或使用带幂等约束的顺序；不能因为重复事件而误删新账号或把成功状态覆盖成失败。
第三步：处理不同存储层
OLTP 先删除或打不可恢复的 tombstone；事件总线保留最小必要的处理记录，阻止旧事件重新物化主体数据。数据湖和数仓要更新分区、表、SCD、物化视图和快照；不可变文件可用删除清单、重写任务或支持删除语义的表格式处理。
搜索索引、缓存、反向 ETL 和第三方处理者需要独立确认，不把“主库已删”当成全局完成。聚合结果只有在无法合理重新识别且策略允许时才可保留，否则要重算或扣除该主体贡献。
第四步：处理备份与法律保留
先判断例外：法律义务、诉讼保全、公共利益研究等可能要求保留，但必须由授权策略决定并记录范围、期限和复核人。对没有例外的备份，不能继续用于恢复生产或分析；如果无法即时覆写，应隔离、加密、禁止读取，并在轮换时删除。
对外状态要写清活跃系统、备份和第三方副本的时间表，不声称“一键完成”已经抹除所有历史介质。
第五步：验证、观测和对账
为每个资产保存状态、attempt、最后错误、删除证明摘要和完成时间。独立验证器根据目录生成查询：活跃表无主体记录、索引无命中、快照不再服务旧数据、下游确认已消费事件、备份处于 beyond-use 状态。
指标至少包括待处理 case 数、各资产延迟、重试率、永久失败数、豁免数量、第三方确认率和验证抽样失败率。完成通知应引用范围与例外，而不是只返回一个布尔值。
高质量示范回答
“我会先把删除请求变成可审计的 case。认证成功后生成 subject key、策略版本和唯一 request key，从数据目录展开 OLTP、事件流、湖仓、数仓、BI、索引、缓存、备份和处理者。事务性 outbox 发布带 caseId 的删除事件，每个资产以 caseId+assetId 幂等处理并回报状态。
活跃数据、物化视图和索引分别删除或重算；聚合数据只有在不可合理重新识别且政策允许时保留。备份不能继续用于恢复或分析，无法立即覆写就隔离到 beyond-use 状态并按轮换计划清除。法律保留单独审批、限时和复核。最后用目录驱动的独立查询、下游确认和审计摘要证明范围，失败任务可重试而不会误删新数据。”
常见错误
- 只删 OLTP → 湖仓、索引、快照和第三方仍可能保留数据 → 从目录展开所有资产并逐项回执。
- 把删除事件当成一次性脚本 → 中途失败后无法恢复或证明完成 → 使用幂等 case、状态机和重试。
- 把聚合都视为匿名 → 组合维度可能重新识别主体 → 做可识别性评估或重算。
- 直接删除备份文件 → 破坏灾备、审计或法律保留 → 隔离、禁止使用并按策略轮换。
- 对外承诺立即彻底删除 → 技术介质和例外可能不支持该承诺 → 说明活跃系统、备份和例外时间表。
- 用业务日志记录完整个人数据 → 删除后日志成为隐藏副本 → 日志只保留 case、资产、结果和最小错误摘要。
追问及应对
追问一：删除请求到达时，如何防止误删同名用户？
要求已登录会话、二次确认或等价身份验证，并使用内部不可变 subject ID，不以邮箱或显示名作为删除键。高风险租户可增加人工审批和通知。
追问二：事件已经进入不可变日志怎么办？
日志本身不应继续被业务读取；为事件建立删除或屏蔽清单，在重放和下游物化时过滤主体。若日志含个人字段，应按存储能力重写、加密隔离或按轮换期限销毁。
追问三：聚合报表能否永远保留？
不能仅凭“聚合”下结论。评估小分组、稀疏维度和外部数据组合后的重新识别风险；无法合理识别且政策允许时才保留，否则重算、扣除或删除。
追问四：怎样证明备份中的数据已删除？
记录备份代次、保留期限、隔离状态、读取控制和轮换时间，并在轮换后做抽样验证。无法即时覆写时，证明其已 beyond use，比声称物理字节立即消失更准确。