4、数据发现与定位：数据地图、血缘分析、元数据管理、跨系统数据关联
数据删除请求来了，第一件事是什么？
不是直接去删库跑路，而是先搞清楚——数据到底在哪。
我见过太多团队，一上来就写SQL DELETE，结果删完才发现，还有三个副本、两个备份、一个归档库没处理。嗯，那场面，挺尴尬的。
所以今天咱们聊聊数据发现与定位。说白了，就是给你的数据做一次「人口普查」。
4.1 数据地图：你的数据资产导航仪
数据地图是什么？我习惯把它理解成「数据界的百度地图」。
它告诉你：某个用户的数据，分布在哪些数据库、哪些表、哪些字段里。甚至能精确到某个分区、某个文件。
核心价值：数据地图让「数据在哪」这个问题，从「靠人脑记」变成「查地图」。
我在项目中遇到过一家电商公司，他们的用户数据散落在12个系统里。每次处理删除请求，运维小哥都要手动翻一遍所有数据库。后来我们搭了数据地图，把每个系统的表结构、数据量、更新频率都标出来。你猜怎么着？原来有3个系统根本不需要存用户数据，之前是历史遗留问题。
数据地图通常包含这些信息：
- 数据源信息：数据库类型、连接地址、版本
- 表结构：字段名、类型、是否可空、默认值
- 数据量级：行数、存储空间、增长趋势
- 数据分类：个人数据、敏感数据、业务数据
- 数据生命周期：创建时间、最后访问时间、归档策略
我的小技巧：数据地图别只做静态的。我建议加上「数据热度」标签——哪些表经常被查询，哪些表半年没人碰。这对删除请求的优先级判断很有帮助。
4.2 血缘分析：数据从哪里来，到哪里去
数据地图告诉你「数据在哪」，血缘分析告诉你「数据怎么来的」。
举个例子：用户A的邮箱地址，最初是从注册表单录入的，然后经过ETL流入数据仓库，再被同步到CRM系统，最后被报表系统引用。这一整条链路，就是数据的血缘关系。
为什么要关心这个？
因为删除数据不是终点。你删了源表，但下游系统可能还缓存着。你删了主库，但备份任务可能又把数据拉回来了。
注意：血缘分析最容易踩的坑是「只做正向血缘，不做反向血缘」。正向血缘告诉你数据从哪来，反向血缘告诉你数据去了哪。处理删除请求时，反向血缘更重要。
我曾经处理过一个案例：某金融公司要删除一批用户的交易记录。我们通过血缘分析发现，这些数据不仅存在于交易库，还被复制到了风控系统、反洗钱系统、以及一个用于监管报送的归档库。如果只删交易库，风控系统会报错，监管报送会出问题。嗯，这就是血缘分析的价值。
血缘分析的实现方式：
- 解析SQL：从ETL脚本、存储过程中提取数据流向
- 日志分析：从数据库审计日志中追踪数据访问
- 元数据采集：从数据集成工具（如DataX、Kettle）中获取映射关系
- 手动标注：对于无法自动解析的场景，人工补充
4.3 元数据管理：数据的「身份证」
元数据，就是关于数据的数据。
听起来有点绕？说白了，就是给每个数据字段办一张「身份证」。上面写着：这个字段叫什么名字、什么类型、谁创建的、什么时候更新的、有哪些约束条件。
我个人的习惯是，把元数据管理分成三层：
| 层级 | 内容 | 对删除请求的作用 |
|---|---|---|
| 技术元数据 | 表结构、字段类型、索引、分区 | 确定删除操作的SQL怎么写 |
| 业务元数据 | 字段含义、数据来源、业务规则 | 判断这个字段是否属于个人数据 |
| 管理元数据 | 数据所有者、审批流程、变更记录 | 确定删除请求需要谁审批 |
你想想看，如果没有元数据管理，你看到一个字段叫 user_extra_1，你敢删吗？说不定里面存的是用户的身份证号。有了元数据，你就能知道：哦，这个字段是「用户备用手机号」，属于个人敏感数据，需要走特殊删除流程。
避坑指南：我曾经接手过一个项目，元数据管理做得很好，但没人维护。半年后，元数据和实际数据对不上了。所以记住：元数据管理不是一次性工程，需要持续更新。我建议每次数据变更都触发元数据同步。
4.4 跨系统数据关联：打通数据孤岛
这是最难的一环，也是最有价值的一环。
现实情况是，一个用户的数据可能分散在十几个系统里。CRM系统用手机号作为用户标识，订单系统用用户ID，客服系统用邮箱。这些系统之间，数据是怎么关联的？
我处理过一个典型的跨系统删除案例：
用户要求删除所有个人数据。我们通过数据地图发现，数据分布在：
- 用户中心（主键：user_id）
- 订单系统（主键：order_id，外键：user_id）
- 客服系统（主键：ticket_id，关联字段：phone）
- 营销系统（主键：campaign_id，关联字段：email）
问题来了：客服系统和营销系统没有user_id，只有手机号和邮箱。怎么关联？
我们做了两件事：
- 建立用户统一标识：把所有系统的用户标识映射到一个全局ID上
- 记录关联关系：在数据地图中标注每个系统的关联字段和关联方式
核心思路：跨系统数据关联，本质上是解决「同一个用户在不同系统中的身份映射」问题。没有统一的用户ID，就通过手机号、邮箱、身份证号等唯一标识来关联。
这里有个技术细节：关联关系怎么存储？
我建议用一张关联映射表：
CREATE TABLE user_id_mapping (
global_user_id VARCHAR(64) COMMENT '全局用户ID',
system_code VARCHAR(32) COMMENT '系统编码',
local_user_id VARCHAR(128) COMMENT '本地用户ID',
id_type VARCHAR(32) COMMENT '标识类型：user_id/phone/email/id_card',
created_at DATETIME,
updated_at DATETIME,
PRIMARY KEY (global_user_id, system_code)
);有了这张表，处理删除请求时，就能通过任意一个标识找到所有关联数据。
注意：跨系统关联最容易出问题的是「数据一致性」。比如用户改了手机号，但客服系统没同步。这时候你通过旧手机号去关联，可能漏掉数据。我建议定期做数据对账，确保关联关系的准确性。
4.5 实操建议：从零搭建数据发现体系
如果你现在要从零开始，我建议分三步走：
- 先盘点，再工具化：别一上来就上数据地图工具。先手工盘点所有系统，搞清楚数据分布。我见过太多团队，工具买了一大堆，结果连自己有多少个数据库都说不清楚。
- 从核心系统开始：别想着一步到位。先搞定用户中心、订单系统这些核心系统，再逐步扩展到边缘系统。处理删除请求时，80%的数据都在核心系统里。
- 建立持续更新机制：数据发现不是一次性的。我建议每个月做一次全量扫描，每周做一次增量更新。新系统上线时，必须纳入数据发现体系。
我的经验：数据发现做得好不好，有个简单的检验标准——当业务方问「这个用户的数据在哪些系统里」时，你能不能5分钟内给出答案。如果能，说明你的数据发现体系及格了。
好了，数据发现与定位就聊到这里。下一章咱们聊聊删除策略的制定——知道了数据在哪，接下来就是怎么删的问题了。