题干与适用场景
某公司把用户数据存放在 PostgreSQL、搜索索引、缓存、只追加事件日志、Iceberg 数据湖、数据仓库、第三方处理方和每日备份中。请设计一套执行已批准删除权请求的管道。它需要解析该用户的身份别名，处理局部失败，防止旧事件重放或备份恢复让数据重新出现，并产出可靠的完成证据。
假设隐私或法务服务已经验证申请人身份、批准请求、划定范围、记录适用例外，并给出策略截止时间。数据平台负责执行这项决定。这道题不要求工程师解释法律。
策略边界要写清楚。GDPR 第 17 条规定删除权，同时列出了成立条件与例外，因此已批准请求需要明确范围。第 19 条在适用情形下涉及通知接收方。在线系统、备份和版本化数据表也有不同删除状态：备份数据可能在等待覆盖期间保持不可使用，已从 Iceberg 当前快照删除的行仍可能位于旧快照引用的文件中。工作流需要表达这些状态，不能把它们压缩成一次数据库响应。
高质量方案会把删除视为一条持久、受策略约束的数据工作流：从已核验的主体身份出发，依据数据资产目录和血缘生成带版本的目标清单，对每个目标执行幂等任务，阻断数据复活，并在所有必需目标通过验证后才宣告完成。
面试官考察点
第一，候选人能否先定义执行契约。关闭账号、业务删除事件、限制访问和批准后的删除请求语义不同。删除服务需要明确批准范围、生效分界点、策略截止时间、例外和证据要求，不能自行补写这些决定。
第二，候选人能否在真实数据模型中找全一个人。电子邮箱通常不够。同一个人可能对应账号 ID、租户内 ID、设备 ID、支付客户 ID、客服系统身份，以及账号合并前后的历史标识。好答案会加入受控的身份解析步骤，也会处理同时属于多个主体的共享记录。
第三，候选人能否针对异构存储选择动作。行存数据库可以硬删除或字段脱敏；搜索和缓存需要失效；不可变对象文件可能需要重写；数据湖删除会生成新快照，而旧快照仍可能引用原文件；聚合数据需要匿名化判断和重算策略；备份与外部处理方又有各自的完成语义。
第四，工作流能否扛住重试与故障。同步请求同时调用所有系统，很容易超时并留下含义不明的局部状态。面试官希望听到持久状态、幂等目标任务、有限重试、明确负责人、截止时间，以及对可重试故障、已批准保留、例外和永久能力缺口的区分。
最后，候选人能否证明数据持续保持删除。编排任务显示绿色只能说明调用结束。方案还要检查目标中是否仍存在数据、历史版本是否可访问、重放链路是否会重建、备份恢复是否会复活、新增数据资产是否遗漏，以及下游是否给出确认。系统还要保留足够且最小化的控制证据来阻止复活，同时不能让审计库变成被删除个人数据的新副本。
回答前需要澄清的问题
- 批准内容究竟是什么？ 涉及哪个主体、司法辖区、数据用途、时间范围和产品？有哪些合法保留例外？谁对最终策略决定负责？
- 主体键是什么？ 是否存在稳定的内部主体 ID？需要解析哪些历史别名、合并账号、租户 ID、设备 ID 和外部处理方 ID？
- 哪些记录由多人共享？ 订单、对话、组织记录、风控证据或财务交易可能关联多人，也可能有批准的保留要求。怎样删除本人的字段，又不破坏他人的记录？
- 数据资产目录是否完整？ 每个存储是否声明负责人、主体定位方式、删除动作、血缘、保留行为、验证器和恢复流程？如何发现未登记资产？
- 哪些存储可变？ 事件日志和对象文件能否安全重写？逻辑删除后，还有哪些数据湖快照和仓库历史版本可查询？
- 备份怎样才算完成？ 能否选择性重写备份，是否必须等待自然过期，还是可以先置于不可使用状态？旧备份恢复后如何在服务接流量前重新执行删除？
- 分界点后还会不会进新数据？ 关闭账号是否阻止新活动？延迟事件、CDC 重试、导入任务或重建账号会不会继续使用旧标识？
- 数据发给过哪些处理方？ 是否有 API、工单或合同约定的确认通道？它们的目标任务达到终态前需要什么证据？
- 截止与升级规则是什么？ 哪些故障需要通知负责人，请求何时算超期，谁有权批准记录明确的例外？
- 验证怎样避免泄露？ 探针能否只返回计数、快照 ID 和加盐证据，不把个人值复制进日志？
30 秒回答框架
“我会用持久工作流执行已批准的删除请求。同步扇出遇到一个目标超时就会留下含义不明的局部状态。受控身份服务先把主体解析成不透明的内部和外部标识；带版本的数据目录和血缘图再生成目标清单。每个适配器幂等执行硬删除、文件重写、限制使用或处理方通知。最小化抑制记录负责拦截旧事件与备份恢复造成的数据复活。完成条件包括目标级不存在性检查、快照和备份保留证据、处理方确认及重放测试。后来发现的新资产需要重新打开请求。”
分步骤深入解答
第一步：把策略决定与管道执行分开
身份验证和范围审批完成后，生成不可变的请求信封。它应包含请求 ID、不透明主体引用、获批的产品与用途范围、分界点、截止时间、策略版本、例外引用和授权决定。原始身份证明和自由文本法务意见不要进入编排台账。
使用明确状态，例如已接收、已授权、已规划、执行中、验证中、已完成、部分完成、已拒绝和已超期。状态迁移只追加并记录责任主体。只有批准目标清单中的每一项都达到允许的终态，请求才能结束：已删除、在指定过期日前不可使用、处理方已确认，或存在记录完整的例外。
这条边界能避免两个危险捷径：工程团队不能自行断言所有聚合都已经匿名，法务服务也不能因为工作流已经入队就标记请求完成。双方分别提供自己负责的决定和证据。
第二步：一次解析身份，并安全保留历史关系
先把已验证的人映射到稳定主体键，再通过受限身份图扩展标识。候选边包括当前与历史账号 ID、合并前账号 ID、租户内 ID、设备标识、支付客户 ID、CRM 联系人以及第三方处理方引用。
身份图要记录生效时间和来源。被复用的邮箱或手机号不能作为跨时间证明两个账号属于同一个人的依据。共享对象还需要字段级规则：删除一名参与者时，不能删掉另一人的订单或消息；同时，本人的直接标识可能需要移除或替换。
为本次请求冻结一个身份版本。后来发现别名时，追加关系并重新生成受影响目标。任务载荷只保存最小化、受访问控制的定位符。普通日志使用请求 ID、目标 ID、计数和版本，不记录姓名或原始邮箱。
第三步：依据资产目录和血缘生成目标清单
每项可能持有主体数据的资产都应登记删除契约：
- 负责人和升级通道；
- 主体定位符及身份命名空间；
- 数据用途和保留类别；
- 上下游血缘；
- 硬删除、字段脱敏、文件重写、密钥销毁、限制访问或通知处理方等动作；
- 快照、历史查询和备份的预期行为；
- 幂等键和重试语义；
- 验证查询或探针；
- 证据格式及终态规则。
规划器把获批范围、冻结身份集合、数据目录和血缘图连接起来，生成带版本的清单。执行前可以审阅该清单。预计匹配数为零的目标也要列出，因为明确的零比无法解释的缺项更安全。
目录覆盖率需要独立控制。扫描云存储账号、仓库、主题、桶、模式、索引和处理方登记表，寻找未注册资产；再把运行时访问日志与血缘事件同目录比对。新增下游若包含范围内数据，应为所有未结请求生成目标任务，并按策略重新打开已完成请求。
第四步：用持久、幂等的工作流执行
使用支持至少一次投递的队列或工作流引擎。请求状态机按目标和身份命名空间调度任务。适配器的幂等键由请求、目标、主体定位版本和动作版本共同构成。已经完成的任务再次执行时返回同一份终态证据，不产生第二次含义不明的变更。
逐目标持久化状态：待处理、执行中、可重试失败、受阻、已删除、限制使用至过期、处理方待确认、例外和验证失败。瞬时错误采用有上限的指数退避；尝试耗尽后进入死信或受阻状态；同时暴露给负责人和截止时间监控。某个目标故障时，已成功删除的目标不回滚。
编排器不应跨全部存储持有分布式事务。它更像一条只向批准终态收敛的 Saga。若发生过度脱敏，需要在单独授权下从受保护真源纠正，不能把“补偿”理解为恢复所有已经删除的数据。
第五步：按存储类别选择删除动作
事务数据库。 用稳定主体键和映射别名定位记录。只属于该主体的行可以硬删除；共享或获准保留的记录则移除获批字段，或用不具识别性的值替换主体关联。按外键顺序执行，同时验证主表与二级表。
搜索、缓存、特征与向量索引。 删除文档和嵌入、失效缓存键，并处理异步索引刷新。源表删除不代表旧搜索文档或特征向量已经消失。验证器必须检查对外服务面和源存储。
事件日志与原始对象存储。 若能安全重写，就重写受影响分区并排除该主体。若源在保留窗口内不可变，则登记删除墓碑或抑制令牌，所有物化、重放、导出和引导链路都必须读取它。原始源仍要按照获批的限制或过期方案处理；墓碑本身不能证明已经物理删除。
数据湖表。 视情况应用等值删除、位置删除或重写受影响文件，并记录提交与快照 ID。当前快照查询为零时，旧快照仍可能引用文件。Apache Iceberg 明确说明，数据文件要等到没有保留快照引用后才会删除，因此在宣告对应物理删除阶段完成前，还要跟踪快照过期与孤儿文件清理。
数据仓库与物化视图。 删除带主体键的行，必要时重建受影响分区，刷新物化视图，并枚举克隆、导出和历史查询版本。具体保留期属于部署配置，不能当成所有平台统一常数。例如 BigQuery 文档说明其时间旅行窗口可配置，之后还有故障保护期；目标清单应读取实际平台策略，并记录旧版本何时变得不可访问。
第三方处理方。 通过对方支持的通道发送范围明确的请求，携带稳定幂等引用，并保存确认和完成状态。GDPR 第 19 条在适用场景涉及通知接收方。如果合同提供机器确认或工单终态，发出一封邮件不能作为完成证据。
第六步：明确处理聚合、模型和匿名化
先判断结果是否仍能识别或单独定位该主体。假名化数据仍能通过密钥或令牌关联，不能因为删掉邮箱列就称为匿名。真正匿名的聚合可以不进入删除目标，但这个判断需要隐私负责人批准。
对于带键或小群组聚合，从允许保留的源记录重建受影响分区。只有可逆指标且保留了可靠贡献信息时，简单相减才安全。分位数、草图、训练后的嵌入和许多模型产物无法靠减一行修正，需要重算、重新训练策略或明确批准的匿名化决定。
模型处理取决于威胁和产品契约。先删除主体级特征、样本、检索文档、缓存和评估用例。若模型本身在批准范围内，再执行获批的重训或模型遗忘策略。删除管道记录策略决定及证据，不能承诺删掉一条训练数据就自动抹除既有模型中的影响。
第七步：防止并发、重放与恢复造成复活
维护最小化抑制登记表，以不透明主体令牌和请求分界点作为键。采集与物化链路在把旧事件写回在线或分析存储前查询它。该登记表专门用于识别被删主体，访问和保留控制应比普通日志更严格。
让删除与并发写入有明确顺序。条件允许时按主体键分区执行；否则记录源水位，等所有写入方越过分界点后再做一次收尾扫描。对请求后真正发生、且获得授权的新活动单独决策。旧事件重放必须抑制；用户合法创建新账号时，可以生成新的主体世代，不必变成永久全局封禁。
所有恢复手册都要规定：恢复服务可读或向下游发数前，先重新应用删除台账和抑制集合，并用恢复演练验证。ICO 指引允许某些情形下备份数据留到覆盖时，但要求其不可使用。工程含义是限制访问、恢复时重放删除、记录过期时间，并禁止备份数据用于日常处理。
第八步：用独立证据验证完成
执行变更的适配器可以输出执行证据，但应由独立验证器决定是否完成。每个目标至少记录：
- 目标及模式版本；
- 身份定位版本；
- 动作、尝试和完成时间；
- 受影响的行、文档、对象或文件数量；
- 当前服务面的不存在性探针；
- 保留快照或备份状态及预计过期时间；
- 处理方确认引用；
- 验证器版本与结果。
探针只使用计数和不透明键，不把已删除的值复制进证据库。抽样检查可以补充确定性验证，但不能取代对本次请求的确定性检查。
端到端测试应覆盖：同一请求提交两次；每个目标在变更成功但确认前被中断；重放旧事件；隔离恢复旧备份；身份合并与拆分；重建账号；新增未登记下游表；一个处理方离线；共享记录与明确例外。必需目标没有验证器或状态未知时，完成判定必须失败关闭。
第九步：用可度量义务运营系统
监控请求相对策略截止时间的完成耗时、超期与部分完成数量、目标成功率和重试率、清单覆盖率、未知资产、处理方确认延迟、快照及备份过期积压、重放复活事故和恢复后删除重应用成功率。
告警要针对工作流状态，不能只盯任务异常。请求可能一直等待处理方确认或快照过期，期间没有任何运行错误，却已经超期。每个受阻目标都要有负责人和升级通道；定期复核例外使用情况和异常的零匹配目标。
成本也要说明。编排开销大致随目标数量增长，物理工作量取决于匹配记录和受影响文件或分区的字节数。文件重写与快照维护可以合批，但不能丢失逐请求可追踪性；每个请求仍要指出哪一个共享维护任务提供了它的证据。
高质量示范回答
“我只接收已经授权的请求信封，其中包含请求 ID、不透明主体引用、获批范围、分界点、截止时间、策略版本和例外引用。受限身份服务把主体扩展为带版本的内部、历史、租户、设备和处理方 ID，不会把邮箱当作跨时间的唯一主键。
随后，我根据数据目录和血缘图生成带版本的目标清单。每个目标声明负责人、定位方式、动作、保留行为、验证器和证据契约。目录覆盖在线数据库、索引、缓存、原始事件、对象存储、数据湖和仓库表、物化产物、导出、备份与处理方。基础设施发现和运行时血缘会把真实资产同目录比对，未知存储会阻止完成，或重新打开受影响请求。
执行层是一套异步状态机，采用至少一次投递和逐目标幂等任务。重试键由请求、目标、身份版本和动作版本组成。行存数据库硬删除主体独有行，对共享或获准保留记录只移除批准字段。在线索引、缓存、特征库和向量库在删除后接受独立查询。不可变原始日志登记抑制记录，并按批准的限制或过期计划处理；所有重放链路都必须查询抑制记录。
对 Iceberg，我会执行行删除或重写文件，记录提交与快照，再跟踪旧快照过期，因为当前查询为零不等于底层文件已经移除。仓库的克隆、物化视图、导出与历史版本也要用相同思路处理。带键或小群组聚合从允许数据重建；只有隐私负责人确认真正匿名的聚合才可保留。
备份有明确终态。不能选择性重写时，请求会记录‘限制使用直至过期’及计划覆盖日期。恢复环境在重新应用删除台账和抑制表前不能接流量。第三方处理方使用幂等任务，收到所需终态确认前保持待处理。
为解决并发，我会记录源水位，并在写入方越过分界点后做收尾扫描。延迟到达和重放的旧事件被抑制。策略允许新活动时，新账号获得新的主体世代，避免把重放保护变成永久封禁。
独立验证器逐一检查对外服务面、当前表状态、保留快照、备份状态和处理方证据。全部目标达到允许终态后，请求才能完成。我会测试重复投递、变更后确认前崩溃、目标离线、旧事件重放、隔离恢复、账号重建、身份合并、共享记录和新发现资产。
运营指标包括截止时间达标率、部分完成与超期数量、目录覆盖率、未知目标、数据复活、快照和备份过期积压、处理方延迟及恢复后删除重应用成功率。这样既能形成持久证据链，也能避免把个人值写进普通日志，并让数据管道专注执行而不越权决定法律范围。”
常见错误
- 只删除主账号表 → 索引、分析表、导出和处理方仍有副本 → 依据血缘生成目标清单，并验证所有必需的服务面和存储面。
- 把邮箱当成统一主体键 → 邮箱会变化、可能被复用，也找不到合并账号和外部身份 → 通过带来源与时间的身份图解析已验证主体。
- 在请求接口里同步调用全部系统 → 一次超时就留下状态不明的局部结果，重试也不安全 → 使用持久的逐目标任务、明确状态、幂等键和负责人升级。
- 把软删除当成删除完成 → 特权查询、导出、重放或恢复仍可读取数据 → 仅把软删除作为已批准的限制阶段，并继续跟踪最终动作或过期。
- 当前 Iceberg 查询为零就宣告完成 → 保留快照可能仍引用旧文件 → 记录快照状态，等待批准的过期和清理阶段结束。
- 默认所有聚合都是匿名数据 → 小群组、连接键和假名仍可能识别或单独定位个人 → 取得明确匿名化决定，并在需要时重建派生产物。
- 忽略重放与恢复 → 回填或备份恢复会把数据重新写回全部系统 → 维护最小化抑制登记，并在恢复数据可用前重新应用删除台账。
- 把原始身份值写入审计证据 → 审计轨迹成为被删数据的新副本 → 只保存不透明引用、计数、版本、状态迁移和受限证据。
- 把“已向处理方发送请求”当成完成 → 送达并不能证明对方已经执行 → 按契约追踪确认、终态、截止时间和升级。
- 让变更任务自己证明成功 → 成功调用可能漏掉旧索引、快照或静默空操作 → 运行独立目标探针以及端到端重放、恢复测试。
追问及应对
追问一：删除请求影响聚合表时怎么办？
先对每项输出分类。若隐私负责人确认它已经真正匿名，可以保留；假名化、带键或小群组输出仍应进入处理范围。从允许保留的源记录重建受影响分区。只有可逆聚合且贡献信息可靠时才能简单相减；分位数、草图和许多学习产物需要重算或单独批准的策略。
追问二：怎样阻止 Kafka 重放重新生成被删记录？
在派生系统宣告完成前先写入持久抑制记录。所有消费者、回填、物化和引导链路检查不透明主体令牌与事件分界点。记录源水位，等当前写入方越过分界点后做收尾扫描。把分界点前事件重放进隔离环境，证明任何目标都没有重新可读。
追问三：恢复旧备份时会发生什么？
先恢复到隔离环境。在开放流量或向下游发数前，应用从备份创建后到本次恢复前记录的所有相关删除请求，刷新抑制登记并运行目标验证器。记录恢复服务已应用到删除台账的最高位置。等待计划覆盖的备份保持访问受限，不能用于日常处理。
追问四：必需数据存储临近截止时间仍不可用怎么办？
请求保持部分完成或超期状态，已成功目标的结果继续保留，对不可用目标进行幂等重试。在策略截止时间前升级给目标负责人和隐私运营负责人。只有经过授权的例外才能改变目标所需终态；编排器绝不能把重试耗尽转换成静默成功。
追问五：删除后如何支持重新注册账号？
把历史重放保护和未来获准活动分开。重建账号使用新的主体世代和内部 ID。抑制登记继续拒绝旧标识以及分界点之前的事件，策略控制则决定是否可以采集新数据。身份解析不能让新世代意外重新关联旧派生记录。
追问六：加密擦除能否代替物理删除？
只有经过验证的存储设计才可以。如果全部相关副本都使用主体独有密钥加密，销毁密钥可以令数据不可访问。共享密钥、明文索引、日志、缓存、导出、备份或残留密钥副本都会破坏这个结论。应把密钥销毁视为一个带清单和验证器的目标动作，不能当成通用捷径。
追问七：怎样知道数据目录没有漏项？
持续把已登记资产同云资源清单、仓库元数据、主题与桶列表、处理方登记以及运行时血缘或访问事件比对。新资产处理主体数据前必须登记删除契约。未知资产触发覆盖告警，并阻止或重新打开受影响请求。定期恢复与重放演练还能发现静态血缘常常遗漏的路径。