📚 课程目录第3章数据源探查与评估

数据源探查与评估：摸清家底再动手

说实话，我见过太多团队一上来就写校验规则，结果写到一半发现数据源连都连不上，或者数据量级完全超出预期。嗯，这就像盖楼不看地基——迟早要出事。

数据源探查，说白了就是先搞清楚你要处理的数据到底长什么样。我个人习惯把这个阶段叫做「摸家底」。你连家里有什么都不知道，怎么定规矩？

核心原则：探查不是一次性动作，而是贯穿数据治理全周期的持续行为。但第一次探查，决定了你后续所有规则设计的基调。

3.1 数据源类型识别：别被表象骗了

数据源类型，远不止「数据库」和「文件」这么简单。我在项目中遇到过好几次，业务方说「就是个 MySQL」，结果连上去发现是阿里云 RDS 的只读副本，权限连 information_schema 都查不全。

你需要从三个维度去识别：

存储形态：关系型（MySQL、PostgreSQL、Oracle）、非关系型（MongoDB、Redis、Elasticsearch）、文件型（CSV、Parquet、Avro）、消息队列（Kafka、Pulsar）
接入方式：JDBC/ODBC 直连、API 接口、文件传输（SFTP、S3）、流式订阅
权限模型：库级权限、表级权限、行级权限（RLS）、字段脱敏策略

为什么这么细？因为不同的类型，探查策略完全不同。比如：

MySQL 可以直接 SELECT COUNT(*)，但 Hive 跑 count 就是全表扫描，量级大时会卡死整个集群
Kafka 没有「表结构」，你需要通过消息样本反推 schema
CSV 文件看着简单，但编码问题、分隔符转义、空行处理，坑多得很

我的小技巧：准备一个「数据源类型检查清单」，每次接入新数据源时逐项确认。我曾经因为漏掉「是否支持事务」这个选项，导致校验规则在写入时频繁死锁——那次教训挺深刻的。

3.2 数据量级评估：别让校验跑死

量级评估，直接决定了你的校验策略是「全量扫描」还是「抽样探查」。你想想看，一张 10 亿行的表，你上来就跑全量唯一性校验，DBA 不找你喝茶才怪。

我一般分三步走：

元数据预估：通过 information_schema 或 SHOW TABLE STATUS 获取行数估算（注意，InnoDB 的行数估算误差可能达到 30%-50%）
快速采样：用 SELECT COUNT(*) FROM (SELECT 1 FROM table LIMIT 10000) t 这种技巧，先确认表是否真的可读
分区探查：如果表有分区，按分区粒度统计，避免一次压垮数据库

这里有个常见的误区——很多人只看总行数，忽略了字段的基数（cardinality）。比如一张 1 亿行的表，某个字段只有 3 个不同的值，那这个字段的分布探查成本就很低。反过来，一个 UUID 字段，1 亿行几乎全是唯一值，探查成本就很高。

注意：在生产库上跑 COUNT(*) 要格外小心。我曾经在白天对一张 5 亿行的订单表跑 count，直接导致主库 CPU 飙到 95%，业务方差点报警。从那以后，我坚持只在只读副本或凌晨窗口做量级评估。

3.3 数据分布探查：找到异常的前哨

数据分布探查，是数据质量规则设计的「情报收集」阶段。没有分布信息，你定的阈值就是拍脑袋。

我通常关注以下几个分布特征：

探查维度	具体指标	常见发现
数值分布	最小值、最大值、均值、中位数、标准差、分位数（P25/P50/P75/P99）	发现离群值、数据倾斜、精度异常
类别分布	唯一值数量、TOP N 频率、低频值占比	发现脏数据（如「其他」占比过高）、枚举值溢出
空值分布	空值率、空值模式（是否集中在某段时间）	发现字段是否真的「可选」，还是业务逻辑缺陷
时间分布	按天/小时聚合的记录数、时间跨度、时间戳异常（如未来时间）	发现数据延迟、历史数据回溯、时间戳乱填
长度分布	字段长度最小值、最大值、平均长度、超长记录占比	发现截断风险、SQL 注入痕迹、不规范输入

举个例子。我在做某电商平台的用户地址字段探查时，发现「省份」字段有 37 个不同的值——中国只有 34 个省级行政区。多出来的 3 个是什么？「北京市市辖区」「上海」「unknow」。这就是典型的脏数据，直接催生了后续的「枚举值白名单校验规则」。

探查脚本示例（MySQL）：

-- 数值分布探查
SELECT 
  MIN(amount) AS min_val,
  MAX(amount) AS max_val,
  AVG(amount) AS avg_val,
  STDDEV(amount) AS std_val,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY amount) AS median
FROM orders;

-- 类别分布探查
SELECT 
  province,
  COUNT(*) AS cnt,
  ROUND(COUNT(*) / SUM(COUNT(*)) OVER() * 100, 2) AS pct
FROM users
GROUP BY province
ORDER BY cnt DESC
LIMIT 20;

3.4 数据血缘初探：知道数据从哪来

数据血缘，听起来高大上，其实核心就一句话：这张表的这个字段，是从哪张表的哪个字段来的？经过了什么转换？

初探阶段，不需要搞完整的血缘图谱，那太费劲了。我建议先做三件事：

字段映射梳理：找到源表和目标表之间的直接对应关系。比如 ods.orders.user_id → dwd.order_detail.uid
转换逻辑记录：字段是否经过了聚合、截断、类型转换、默认值填充？这些转换往往是数据质量问题的根源
依赖关系标注：哪些表是上游？哪些表是下游？有没有循环依赖？

我记得有一次，业务方反馈报表里的「成交金额」总是对不上。我顺着血缘一查，发现数据流经过了 7 层 ETL，中间有 3 层做了不同的四舍五入策略——有的向上取整，有的四舍五入，有的直接截断。你说这能对得上吗？

初探阶段，工具不重要。Excel 都能画，关键是先把「谁依赖谁」的关系理清楚。后面我们会专门讲如何用工具做自动化血缘解析，但那是后话了。

3.5 本章知识体系总览

下面这张图，是我自己梳理的数据源探查与评估的整体流程。你可以把它当作一个检查清单，每次接入新数据源时对照执行。

这张图的核心逻辑是：先接入，再探查，最后输出报告。四个探查维度不是串行的，你可以并行推进。我个人习惯是先做量级评估和类型识别，因为这两个决定了探查工具和策略的选择。分布探查和血缘初探可以同步进行，但血缘初探往往需要更多业务沟通，所以我会把它放在最后。

一个血的教训：我曾经跳过探查阶段，直接基于业务文档写校验规则。结果上线第一天，规则就误报了 3 万条「异常数据」——后来发现是源系统的一个字段在两周前改了枚举值，但文档没更新。从那以后，我坚持「不探查，不定规则」。

好了，这一章的内容就到这里。数据源探查是数据质量治理的「地基工程」，花多少时间都不为过。你想想看，如果连数据源的基本情况都没摸清，后面写的规则再漂亮，也是空中楼阁。