第二步：数据采集与初步分析
好，咱们进入第二步。这一步说白了就是「把现场证据搬回来，先做个初筛」。很多团队一上来就急着建模型、跑算法，结果数据本身就有问题，后面全白干。我个人的习惯是：先花 70% 的精力把数据摸清楚，再动手分析。这一步做扎实了，后面三步才能站得住脚。
2.1 采集相关数据源
数据采集不是「能拿多少拿多少」，而是「该拿的必须拿，不该拿的别乱拿」。我在项目中遇到过好几次，业务方一股脑给了几十张表，结果一半是冗余字段，另一半是聚合后的数据——根本没法做根因分析。
你需要采集的数据源，通常包括这几类：
| 数据源类型 | 典型内容 | 采集要点 |
|---|---|---|
| 源系统日志 | ETL 执行日志、API 调用记录、数据库慢查询日志 | 保留时间戳、状态码、异常堆栈 |
| 数据仓库/湖 | ODS 层原始表、DWD 层明细表 | 避免使用聚合表，尽量拉取未清洗的原始数据 |
| 元数据 | 字段定义、数据血缘、分区信息 | 确认字段类型、空值约束、主外键关系 |
| 业务上下文 | 业务规则文档、变更记录、工单系统数据 | 重点采集问题发生时间窗口内的变更记录 |
我的小技巧： 采集时顺手做个「数据清单」，记录每张表的行数、时间范围、关键字段。这样后面探查时不用反复回去查，省很多时间。
2.2 数据探查与质量评估
数据拿回来了，别急着分析。先做一轮「体检」。我习惯用一套固定的探查清单，每次照着做，不容易漏。
探查的核心维度有四个：
- 完整性——空值率、缺失记录比例。比如某张表本该每天 100 万行，结果某天只有 80 万，这就是线索。
- 准确性——字段值是否符合业务预期。比如订单金额出现负数，或者日期字段跑到 2099 年去了。
- 一致性——同一实体在不同表中的值是否对齐。比如用户表里性别是「男/女」，但行为表里是「M/F」，这就是不一致。
- 时效性——数据延迟是否在可接受范围内。实时流数据延迟超过 5 分钟，可能就是问题源头。
重点： 质量评估不是「打分」，而是「找异常」。你不需要给每个字段打个 95 分，而是要标记出哪些字段、哪些时间段的数据「不对劲」。这些不对劲的地方，往往就是根因的入口。
举个例子。我之前处理过一个电商订单数据质量事故。探查时发现，订单表的 create_time 字段在 2024-03-15 这天，有 12% 的记录时间戳是 1970-01-01。这就是典型的「默认值污染」——程序里没处理好空值，直接塞了个 Unix 时间戳 0。你看，一个简单的探查动作，直接锁定了问题范围。
2.3 识别异常模式
探查完数据质量，接下来要回答一个问题：这些异常是孤立的，还是成片出现的？ 换句话说，有没有规律可循？
我总结了三种最常见的异常模式：
- 时间窗口型： 异常集中在某个时间段。比如每天凌晨 2 点到 3 点，数据量骤降。这通常跟定时任务、批量作业有关。
- 维度倾斜型： 异常集中在某个业务维度。比如某个省份的订单数据全部缺失，或者某个商品类目的价格字段全是乱码。
- 级联扩散型： 一个源头异常引发下游一连串问题。比如上游表字段类型变更，下游所有依赖它的表都报错。
识别异常模式，我一般用两个方法：
- 可视化扫描： 把关键指标按时间画成折线图，一眼就能看出「断崖」「尖刺」「平台期」。别小看肉眼，很多时候比算法管用。
- 交叉比对： 把异常记录跟元数据、变更日志做关联。比如发现某张表某天数据量暴跌，去查一下那天是不是有人改了 ETL 脚本——十有八九就是它。
避坑提醒： 我曾经犯过一个错——发现异常模式后，直接跳到「修复」阶段，跳过了后面的根因验证。结果修了三次都没修对，白白浪费了两周。记住，这一步只是「识别」，不是「定案」。真正的根因，要留到第三步去验证。
好了，第二步的核心就这些。说白了就是三件事：拿对数据、查清质量、找出规律。这一步做得越细，后面三步就越轻松。你想想看，如果连数据本身有没有问题都没搞清楚，后面再怎么分析，不都是空中楼阁吗？