GDPR 数据流程：PII 重新识别从每小时轮询转向事件驱动

这是大型企业数据团队经常遇到的场景：分析团队提出委托，需要在符合 GDPR 审批要求的前提下，通过受控映射把数据湖中的哈希个人 ID 恢复为原始 ID，供指定的下游业务使用。

我接手并重构了这条受控重新识别流程。原方案能够完成任务，但它有两个非常实际的问题：慢，而且贵。

问题

为了满足个人数据保护要求，数据湖中的个人 ID 默认经过哈希处理。用户可以用稳定标识跨表关联数据，但不能看到原始 ID；少数经过审批的场景需要通过单独保存的映射表恢复原始 ID。本文把这个动作称为“受控重新识别”。

分析团队先取得审批，再把待处理文件上传到约定位置。Airflow 每小时扫描一次这些位置；发现文件后，流程检查该请求是否已有批准，然后在一套专用 EMR 集群上启动 Spark 任务。

这条链路还依赖一套常驻的 EMR 集群和 Amazon Aurora 数据库。处理完成后，用户需要手动下载结果，再上传到最终系统。

请求获批
→ 上传文件
→ 等待 Airflow 每小时扫描
→ 检索批准记录
→ 常驻 EMR 上运行 Spark
→ 用户下载结果
→ 用户再上传到目标系统

一次请求的典型端到端时间约为两小时。其中一部分来自轮询和批处理，另一部分来自结果生成后的人工交接。这是“慢”。

与此同时，一个低频、间歇性的工作负载，却长期支付常驻 EMR 和 Aurora 的费用。这是“贵”。

根因分析

1. AWS 搬迁延续了本地数据湖的思维惯性。

平台从本地服务器迁到 AWS 后，架构仍然默认围绕常驻服务器展开。团队没有根据任务性质区分长期服务与偶发任务，而是统一采用带服务器的方案：用常驻 Aurora 保存流程状态，并让 EMR 集群长期 standby，等待偶尔到达的文件。云平台提供了按事件启动、按使用付费的能力，但工作负载仍按本地数据中心的方式运行。

2. 收到需求后，团队从现有方案出发，而不是从需求出发。

真实需求是：“一个获批文件到达后，立即检查授权、处理文件并交付结果。”原方案却先看团队已经拥有什么——Airflow、EMR 和关系型数据库——再把需求套进这些组件。因此，一个天然由文件到达触发的流程，被实现成 Airflow 定时轮询；一个短时计算任务，被实现成等待任务的常驻集群。

两个根因共同造成了结果：架构跟随已有工具，而没有跟随任务的触发方式、运行频率和生命周期。

改造思路

1. 用 push 替代 pull，缩短时延。

原方案由 Airflow 定时检查“文件是否已经到达”，本质是 pull。轮询间隔天然变成了等待时间。我把触发方向反过来：文件一到达 S3，就由事件主动 push 给处理流程。任务不再等待下一次扫描，而是在数据到达时立即开始。

2. 用 serverless 消除低用量业务的固定开支。

这个业务模型很简单：请求频率低，每次处理时间短，因此真正由用量产生的费用本来就很低。原方案的大部分成本来自常驻 Aurora 和 standby EMR 集群等固定开支。改用 Lambda、Step Functions、DynamoDB 和 EMR Serverless 后，没有请求时几乎没有运行资源；其中大部分低频调用基本落在 AWS 免费额度内。

解决方案

我把流程的起点改成文件到达事件：

S3 Object Created Event
→ Lambda 启动 Step Functions
→ Lambda 在 DynamoDB 中检查既有批准
→ EMR Serverless 执行获批的重新识别
→ Lambda 把结果发送到批准的目标系统
→ 每个阶段向负责人发送状态

S3 Event 消除了等待下一次扫描的时间。Step Functions 把状态转换和失败节点显式化。DynamoDB 替代了只服务于狭窄查询模式的常驻关系型数据库。EMR Serverless 替代专用集群，只在处理文件时产生计算资源。最后一个 Lambda 将结果直接交付到获批的 SFTP 等目标位置。

每个关键节点都会通知负责人：发现文件、批准通过或拒绝、处理完成、下游交付成功或失败。速度提高没有削弱治理；相反，控制路径变得更清楚。

小提示：给每一步发送 receipt email。 我在 serverless 流程的每个关键状态转换中，通过 Amazon SNS 向 stakeholder 发送回执邮件。用户不需要猜测文件是否被发现、是否通过审批、处理到了哪里，或是否已经送达下游；发生问题时，最后一封成功回执也能直接指出故障落在哪两个步骤之间。这是一个实现成本很低、但明显改善用户体验和排障效率的设计。

结果

典型时延从约 两小时降到 5–10 分钟。这是实际运行中的典型范围，不是由专门监控系统支撑的正式 SLA。

根据大账单中可以识别出的相关 AWS 资源费用，这条流程的基础设施成本降低约 90%。这个比例只针对该流程的可识别资源，并非 AWS 总账单降低 90%。

除了速度与账单，流程本身也发生了这些变化：

• 不再等待每小时轮询；
• 不再保留常驻 EMR 集群；
• 不再为狭窄查询模式保留常驻 Aurora；
• 不再需要人工搬运结果；
• 批准检查和各阶段通知都被显式记录；
• 只有真正发生获批请求时才产生主要运行成本。

核心改变是让资源生命周期与一次获批请求的生命周期一致：低频文件不再由常驻系统等待，而是由事件触发一条有明确状态、权限和通知的处理链路。