4、数据质量问题分类体系：结构性问题、内容性问题、关系性问题、元数据问题
做数据治理这些年，我见过太多团队一上来就埋头修数据。修完一批又来一批，永远看不到头。为什么？说白了，就是没搞清楚问题到底出在哪一层。
我个人习惯，先把数据质量问题分成四大类：结构性、内容性、关系性、元数据。这就像医生看病，先分内科外科，再往下细查。分类对了，诊断才有方向。
核心观点：数据质量问题分类不是学术游戏。它是你制定清洗策略、分配治理资源、评估工具选型的底层框架。分错类，后面全白干。
4.1 结构性问题：表结构本身就不对
结构性问题，指的是数据在物理或逻辑存储结构上存在的缺陷。这类问题通常在数据接入阶段就能发现。你想想看，如果表结构都是歪的，里面的数据再干净也没用。
我在项目中遇到过最典型的例子：某业务系统导出的 CSV 文件，字段顺序三天两头变。今天 A 列是姓名，明天 A 列变成了手机号。ETL 脚本跑完，数据全对到错列上去了。这就是结构性问题。
常见的结构性问题包括：
- 字段缺失或多余：接口文档说好有 20 个字段，实际只来了 18 个。或者多出几个未定义的字段。
- 数据类型不匹配：定义的是整型，传过来的是字符串。或者日期字段传了个 "2024-02-30"。
- 字段长度超限：数据库字段定义 varchar(50)，实际数据最长到了 200 个字符。截断还是报错？都是坑。
- 主键/唯一约束冲突：同一张表里出现了两条完全相同的记录，或者主键重复。
- 分区/分表策略错误：按日期分区的表，数据写到了错误的分区。
我的建议：结构性问题最好在数据接入层就拦截掉。写一个 schema validation 脚本，每次数据进来先过一遍。不符合结构的直接 reject 并告警，别让它流到下游。
4.2 内容性问题：数据值本身有问题
内容性问题，是大家最熟悉的一类。说白了，就是字段里的值不对。这类问题最容易被发现，但也最难彻底根治。
我记得有一次做客户数据清洗，发现某个字段叫 "性别"，里面居然填了 "男/女/未知/保密/1/0/M/F/先生/女士" 十几种写法。这就是典型的内容性问题——格式不统一。
内容性问题可以细分为：
| 子类型 | 说明 | 示例 |
|---|---|---|
| 空值/缺失值 | 该有值的地方没有值 | 用户手机号字段为空 |
| 异常值/离群值 | 数值明显偏离正常范围 | 年龄字段出现 200 岁 |
| 格式错误 | 数据格式不符合规范 | 日期写成 "2024/01/01" 而非 "2024-01-01" |
| 精度/截断错误 | 数值精度丢失或四舍五入错误 | 金额字段只保留整数，丢失分 |
| 编码/字符集问题 | 乱码或字符集不统一 | 中文显示为 "????" 或 "汉å—" |
注意：内容性问题往往不是单一原因造成的。我曾经排查过一个乱码问题，源头是上游系统从 GBK 转 UTF-8 时做了两次转换。这种问题靠人工查很痛苦，建议用数据质量监控工具自动扫描。
4.3 关系性问题：数据之间的关联断了
关系性问题，关注的是数据实体之间的关联完整性。你想想看，如果订单表里引用的用户 ID 在用户表里根本不存在，那这张订单还有什么意义？
关系性问题在数据仓库和业务系统中尤其常见。我见过一个电商平台，订单明细表里有 30% 的商品 ID 在商品主表中查不到。原因是商品下架后，主表做了物理删除，但订单明细没做级联处理。
常见的关系性问题：
- 引用完整性缺失：外键引用的主键记录不存在（孤儿记录）。
- 冗余/重复记录：同一实体在系统中存在多条记录，且无法判断哪条是准确的。
- 时序/逻辑矛盾：比如订单的 "下单时间" 晚于 "发货时间"，或者 "开始日期" 大于 "结束日期"。
- 聚合/汇总不一致：明细表汇总后的金额，与汇总表对不上。
诊断技巧：关系性问题用 SQL 就能快速排查。写几个 LEFT JOIN 查 NULL，或者用 GROUP BY 查重复。我习惯在数据管道里加一个 "关系完整性检查" 步骤，每次跑数前先过一遍。
4.4 元数据问题：关于数据的数据出了问题
元数据问题，是四类问题里最隐蔽的。它不直接体现在数据值上，而是体现在对数据的描述、定义和管理信息上。说白了，就是 "数据的数据" 出了问题。
我记得有一次接手一个数据仓库项目，里面有一张表叫 "T_001"，字段名全是 F1、F2、F3。没有任何文档说明这张表是干什么的。这就是典型的元数据缺失问题。
元数据问题主要包括：
- 业务定义缺失或不一致：同一个指标，不同部门理解不同。比如 "活跃用户"，运营部定义为 "7 天内登录过"，产品部定义为 "30 天内登录过"。
- 数据血缘/溯源缺失：不知道数据从哪里来，经过哪些转换，最终用到了哪里。出了问题没法排查。
- 数据字典/模型文档缺失：没有字段级别的说明文档，新人接手完全靠猜。
- 变更记录缺失：表结构改了、ETL 逻辑改了，但没有记录。三个月后出问题，没人知道改了什么。
- 数据质量规则/度量缺失：没有定义什么是 "好数据"，什么是 "坏数据"。出了问题全靠人工拍脑袋。
我的经验：元数据治理是数据治理的基石。没有好的元数据，其他三类问题你根本查不清楚。我建议团队至少维护一份 数据字典 + 血缘图谱，工具可以用开源的 Apache Atlas 或者商业的 Informatica。
4.5 四类问题的关系与诊断优先级
这四类问题不是孤立的。它们之间有很强的关联性。举个例子：
元数据定义错了（元数据问题）→ 导致 ETL 映射写错了（结构性问题）→ 数据值被截断（内容性问题）→ 关联查询时找不到匹配记录（关系性问题）。
你看，一个元数据问题，可能引发连锁反应。所以诊断时，我建议按这个优先级来：
- 先查元数据：定义对不对？文档全不全？
- 再查结构：表结构、字段类型、约束条件是否匹配？
- 然后查关系：外键、引用、时序逻辑是否完整？
- 最后查内容：值本身是否准确、一致、合规？
避坑指南：我曾经跳过元数据和结构，直接去修内容。结果修了三个月，发现是上游接口改了字段类型，导致数据写入时被隐式转换。白白浪费了三个月的人力。记住：先诊断，后治疗；先上游，后下游。
好了，这四类问题就是数据质量诊断的 "四大门类"。你可以在实际项目中拿这个框架去套一套，看看你手头的数据问题，到底属于哪一类。分类清楚了，下一步的根因分析和修复方案，自然就有了方向。