第3章 数据发现的定义与价值
先问一个问题：你手上到底有多少数据？它们在哪？长什么样？
别小看这个看似简单的问题。我见过不少团队，数据治理花了大半年，结果连自己仓库里存了哪些表都说不清楚。说白了，数据发现就是给你画一张“数据家底地图”的过程。它不是一次性动作，而是一套持续搞清楚「有什么、在哪、是什么、谁能用」的方法论。
3.1 什么是数据发现？
数据发现（Data Discovery）指的是主动扫描、识别和索引组织内各类数据资产，并提取其元数据与业务含义的技术与流程。
用大白话说：
- 扫描——遍历数据源（数据库、对象存储、消息队列等）
- 识别——判断有哪些表、字段、文件、API 端点
- 标注——打上技术标签（类型、大小、位置）和业务标签（PII、财务、日志）
- 索引——把这些信息建成可搜索的目录
我个人习惯把数据发现比作“体检”——你不光要知道身体里有多少器官，还得知道每个器官的指标正不正常。
核心目标：让数据资产从“不可知”变成“可知”，从“不可控”变成“可管”。
3.2 为什么数据发现是数据治理的第一步？
你想想看，治理的前提是看清。看不清，谈什么治理？
我踩过这个坑。曾经有一个金融客户，因为历史迁移导致数据湖里混入了上千张废弃表。安全审计时发现某些表里居然有明文信用卡号，而之前根本没人知道这些表存在。那次整改花了整整两周，就是因为连“数据清单”都没有。
数据发现在治理中的价值，我总结成四个维度：
| 维度 | 说明 | 我在项目中看到的典型问题 |
|---|---|---|
| 可见性 | 摸清资产全貌，避免盲区 | “孤岛数据”长期无人维护，却包含敏感信息 |
| 合规性 | 确定哪些数据受法规约束 | GDPR/个保法要求的数据映射，没发现就没法做 |
| 风险控制 | 识别异常数据存储位置 | 生产库被误放到开发环境，导致权限失控 |
| 成本优化 | 发现冗余/过期数据，减少存储浪费 | 某云存储桶里 60% 是三个月前的临时备份 |
避坑提醒：我曾经见过一个团队买了很贵的分类分级工具，结果因为底层数据目录是五年前的，分类全部打偏。记住，工具再好，地基——也就是数据发现——必须先打好。
3.3 数据发现的典型场景
场景不同，发现的方法也不同。我大致分成三类：
- 迁移评估：上云前需要盘点本地数据，决定移哪些、留哪些、删哪些。
- 安全审计：定期扫描云存储桶，看有没有意外公开的敏感数据。
- 数据目录建设：为后续分类分级、血缘分析、质量监控提供基础元数据。
嗯，这里要注意：场景决定了发现的范围和深度。审计场景往往需要全量扫描，而日常目录建设则可以用增量模式，减轻对业务库的性能冲击。
3.4 数据发现的四步法
我习惯用一个简单的四步模型来落地：
- 连接数据源——配置数据库、对象存储、API 等连接器
- 采集元数据——提取表结构、字段类型、行数、分区信息
- 智能采样与推断——按规则或 ML 模型推测字段内容类型（如姓名、手机号、IP）
- 注册到目录——将结果写入统一的数据目录，支持搜索与打标
你可能会问：“第三步智能采样会不会很慢？” 会的。但在生产环境，我们通常按优先级分层：核心库全量采样，边缘库只扫结构，或者设置采样比例。
3.5 数据发现的不同方法对比
实际工作中，没有一种方法包打天下。我习惯根据数据源类型和更新频率做组合：
| 方法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 静态扫描 | 批量离线分析，如迁移前盘点 | 对线上无影响，可深度采样 | 时效性差，扫描周期长 |
| 动态监控 | 实时审计，如检测新创建的敏感表 | 延迟低，能捕获临时数据 | 需要持续的资源开销 |
| 元数据爬取 | 建立数据目录，持续增量更新 | 轻量，适合云原生环境 | 无法推断数据内容含义 |
| 混合模式 | 大中型企业全场景 | 兼顾广度与深度 | 架构复杂度高 |
我的实践建议：小团队起步阶段先用「元数据爬取 + 静态扫描」组合，等安全合规要求变严之后再加上动态监控。我曾经帮一个 SaaS 公司用这套方案，三个月就把原来分散在 200 多个表的敏感数据全部摸清了。
3.6 本章小结
数据发现不是可有可无的“前置调研”。它是数据治理的基石——没有它，分类分级的对象都不存在。说白了，你想给数据上锁，首先得知道锁哪些门。
下一层我们要聊的敏感分类分级，正是建立在数据发现输出的“资产清单”之上。但记住：发现不是一步到位，它需要按照数据源类型、更新频率和业务优先级，搭配合适的方法持续跑起来。
好了，先把这章的核心记牢：「只有被发现的数据，才可能被管理。」