2. 请求受理与数据主体验证
这个环节看上去简单，其实是整个系统中最容易翻车的地方。为什么？因为GDPR对“验证请求者身份”的要求是“reasonable measures”（合理措施），但什么叫合理，法条没说死，不同国家的监管解释也不一样。如果验证太松，可能造成数据泄露，罚单反而更重；如果验证太严，又会影响数据主体行使权利，招来投诉。
我的经验是把验证强度分成三档：
- 低风险请求：比如“修改营销偏好”，通过注册邮箱点确认链接即可。
- 中风险请求：比如“导出我的数据副本”（访问权），需要验证邮箱 + 手机验证码或一次性口令。
- 高风险请求：比如“删除我的全部数据”或“修正我的收入/信用信息”，建议人工审核辅助，要求提供身份证明文件（如护照、身份证）的脱敏副本。
在系统实现上，要注意一个反直觉的点：GDPR要求“不对数据主体行使权利设置不合理障碍”，但同时又允许“在合理范围内收取费用”。这里建议不要一开始就上付费门槛，容易引发负面体验。先尝试自动验证，自动验证无法完成时，再走人工辅助流程，只有恶意重复请求才考虑“明显没有依据或过度请求”的豁免条款。
从工程角度，这个模块的数据模型核心是请求实体，建议包含几个关键字段：request_id、subject_id、request_type（DELETE、COPY、RECTIFY等）、verification_level、status、deadline_date。这里特别强调一下deadline_date —— GDPR规定“一个月内”响应，复杂情况下可延长两个月但要通知数据主体。所以系统里必须有一个自动计算响应截止日期的逻辑，并且支持延长后的二次通知。这个日期不是给人看的，而是驱动整个任务流转的“心跳”。我见过不少公司把到期日写死，结果一遇到法定节假日就全乱了，实际上响应期限是按自然日算的，建议区分工作日提醒与自然日截止，避免内部误判。
前端受理页面建议同时支持两种入口：一种是给终端用户填的表单，另一种是给客服人员代客提交的界面（当用户通过电话或邮件提出请求时）。别忘了，GDPR没有强制要求用户必须通过特定表单来提请求，你来电、发邮件都算有效请求。所以DSR系统最好能提供一个邮件解析入口，把用户发送到privacy邮箱的请求自动提取成工单。这个需求很常见，但很多公司第一版都漏了。
3. 数据定位与元数据盘点：最硬核的一环
请求受理之后，真正的硬仗才开始：搞清楚这位用户的个人数据到底存在哪些系统里。这一步是整个DSR系统中最耗时、也最容易遗漏的，因为它严重依赖企业数据治理的成熟度。
我的建议是：不要在DSR系统里“边做边摸索”，而是平时就把数据地图维护好。理想的元数据层至少要覆盖：
- 数据源清单：哪些库、哪些表、哪些消息队列存了个人数据；
- 字段级标识：是否包含个人数据，属于哪一类（身份信息、联系方式、生物识别、位置、行为记录等）；
- 主体关联键：这张表靠什么字段能关联到具体用户（user_id、mobile_hash、device_id等）；
- 数据生命周期：保留期限、是否归档、是否已做假名化；
- 数据血缘：这张表的上下游是什么，删除一处后会不会影响别的业务。
如果你所在的公司数据治理还比较原始，也可以从一条务实的路径起步：先做“最小盘点”，只盘点包含明确个人标识符（user_id、身份证、手机号、邮箱）的表，把它们纳入DSR扫描范围。宁可第一版范围窄一点，也要保证范围内的系统质量可控。否则一上来就追求全口径覆盖，结果盘点出几百张表，真正能跑通的没几张，法务和研发的信任瞬间就崩了。
数据定位的执行方式，业内有几种常见方案，我按实用程度排一下：
- 索引优先方案：在HBase、Elasticsearch、ClickHouse等系统里用user_id精确检索关联数据。适合OLTP类型的在线业务库。
- 离线扫描方案：用Spark或Hive定时任务，扫描Hive/Iceberg/离线数仓中的全量表。适合日志类、行为类数据。
- 规则解析方案：基于已梳理的“表-字段-主体键”映射关系，自动生成查询SQL或API调用，把盘点动作固化下来。
- 流式标记方案：在实时链路上给每条数据打上“主体可识别标记”，以支持准实时的DSR响应（这个一般公司用不上，Level很高）。
如果你有数据血缘工具（比如Atlas、DataHub或者自研），强烈建议在数据定位模块中直接调用血缘API，拿到一张主体数据影响拓扑图。这样当你要删除一个核心用户时，能看到哪些下游报表、模型特征可能受影响，避免出现“用户删了，但离线训练集里还残留着他的数据”这种尴尬。
这块投入的人力和时间成本最高。我见过一个中等规模公司，数据盘点阶段整整做了三个月，但后面DSR请求的执行时间从“几天”下降到“3小时以内”，这笔前期投资是完全值得的。
4. 执行引擎：删除、导出、更正的工程实现
数据定位完成之后，系统会生成一个“待执行任务包”。这个任务包里，每一项都对应到具体的存储系统和具体的数据对象。执行引擎要做的，就是用统一的方式把这些差异巨大的任务调度起来。
工程实现上，我推荐“插件化执行器”的架构。每种数据源类型写一个执行器插件，暴露统一的接口：
execute(task)，获取任务详情 checkStatus(taskId)，查询执行状态 rollback(taskId)，异常回滚比如MySQL执行器内部封装了分批删除、主从延迟检测；HDFS执行器内部封装了目录级清理或文件覆盖；ES执行器处理索引刷新和别名切换。上层调度中心只需要负责编排和状态机流转，不需要关心某个数据源到底怎么删、怎么查，这样扩展性和可维护性都很好。
执行优先级也值得讲究。删除和更正类任务，必须按照“在线业务库 → 消息队列/缓存 → 数据仓库 → 备份与归档”的顺序来推进。先处理了业务库，但忘了清理Kafka里的延迟消息，用户在下一个消费周期还会收到基于旧数据的推送，那合规和体验上就都打了折扣。
还有一种特别麻烦的情况——数据无法物理删除，只能逻辑删除。典型的是审计日志、财务流水、风控事件记录，这些数据受其他法律义务约束，必须保留。这种情况下系统应该自动把请求标记为“部分拒绝”，并生成一份说明文档，告知数据主体依据哪条法律规定延长保留。这是GDPR第17条第3款的典型场景，千万不要直接删，也不要无视用户的删除请求，“视而不见”是要吃罚单的。
导出（访问权）的实现也要多说几句：导出文件建议采用CSV和JSON两种格式，JSON适合程序化处理，CSV方便个人查看。同时导出的数据包要做结构分层，避免把内部系统字段直接暴露出去。真实案例是某公司导出用户数据时，把内部的crm_owner_id也带出去了，用户看到后反而引发更多投诉。正确的做法是输出前做字段级脱敏和映射，把内部id替换成有意义的标签。
关于假名化数据要不要纳入删除范围，这里给一个参考做法：如果数据经过不可逆的假名化处理，且原始标识符已删除，那么它就不再属于“可识别的个人数据”，可以不响应该数据主体的删除请求；但仍然存在争议，建议由法务给出最终判断。系统层面要支持“人工判断结果回填”的能力，也就是允许法务针对单条数据决定“执行删除”或“豁免删除”并附上依据。
5. 审计、闭环与可视化：让数据主体权利请求形成完整证明链
最后这个模块虽然不直接面对用户，但它的价值在审计和监管问询时会体现得淋漓尽致。你需要让系统证明：你在法定时限内响应用户的请求了，处理和响应的过程是合规的、有记录的。
审计方面，我们需要全链路留存三类信息：
- 请求生命周期事件：包括收到请求时间、验证完成时间、定位完成时间、执行完成时间、通知用户时间；
- 操作者行为记录：谁在什么时候看了哪些数据、批准了哪些例外；
- 执行凭证：每个数据源返回的结果集、受影响行数、执行日志、异常信息。
这三类信息合在一起，才是完整的证据链。空口无凭，监管机构看的是日志和时间戳，而不是PPT。
另外系统还要支持“重新执行”和“异常重试”机制。比如某个下游数据源当时超时了，响应动作没完成，用户那边可能已经收到了“已完成”的通知，这就比较危险。我的建议是：只有所有子任务都进入“成功”状态，主请求才能置为“已完成”；否则即便法务已审批，也要保持“人工复核中”的状态，防止半截子工程“假装成功”。这一点看似简单，但实现起来很容易被忽略，因为主请求的执行状态是编排中心统一汇总的，如果某个子任务状态漏更了，前端就永远卡在“处理中”。
可视化报表的作用主要有两块：一是给管理者看运营大盘，现在有多少待办、多少即将逾期、哪个数据源执行失败率最高；二是给法务提供“请求类型分布趋势”，辅助判断是否需要申请监管机构的指导或调整内部流程。我通常的做法是，把关键指标（请求量、按时响应率、平均执行时长、各处理类型分布）全部拉到独立的BI看板，每天定时同步，方便月底出合规报告时直接引用。
6. 实践中的几个高频问题与排查建议
数据主体权利请求系统上线后，真正的考验才开始。这里挑几个我实际运维中踩过的坑，按出现频率做一个速查表：
| 现象 | 常见原因 | 排查思路 |
|---|---|---|
| 定位查不到但实际有数据 | 主体标识不统一（业务库用user_id，日志用device_id） | 建设全局id-mapping表，统一关联后再跑全链路验证 |
| 删除成功但用户还能搜到历史内容 | ES索引未刷新、Redis未清、CDN缓存未purge | 执行器增加关联索引清理步骤，验收时用关键词实测搜索 |
| 用户删除了却仍收到营销推送 | Kafka/消息队列里还积压着旧消息 | 先暂停相关topic的生产消费，清空后再恢复，核验消费位点 |
| 执行任务报权限不足 | 大数据平台删除HDFS/Hive分区需要独立授权 | 提前为DSR引擎申请最小权限账号，走完平台审批流程 |
| 耗时操作同步等待导致超时 | 接口默认超时时间短于Spark任务执行时长 | 改异步任务，通过回调或轮询更新状态，不要追求同步返回 |
最后补一个“全链路演练”的建议。上线前找一个真实测试账号，从受理、验证、定位、执行到通知，完整跑一遍导出和删除两个场景，记录每个环节的耗时。这样才能提前发现哪些表没接入、哪些关联关系漏了、哪些执行器会卡住。别等到监管问询或用户投诉来了才去测试，那时候每多花一天都是风险。
7. 一点务实层面的体会
数据主体权利请求系统的落地，远不只是写一套CRUD。它的成败取决于数据盘点是否扎实、流程设计是否闭环、执行链路是否有审计支撑。很多公司把数据合规当成一个“合规项目”来做，上线即结束，但实际上，数据是持续增长的，新的表、新的业务域不断出现，DSR系统必须与元数据管理和数据血缘工具形成常态化联动。
从我个人的实操经验来看，最值得优先投入的永远是数据地图和数据血缘的梳理。CRUD谁都能写，执行引擎也有很多开源方案可以参考，唯独“知道自己有什么数据、数据在哪、怎么关联到用户”这件事，没有捷径可走。把这一步扎扎实实做好，后面所有数据主体权利请求的实现都只是水到渠成。如果你所在的公司刚开始做这件事，我建议别贪大求全，先跑通一条核心链路再逐步扩展，稳扎稳打比一步到位的效果要好得多。
