3、数据采集与清洗：数据采集的常见方式（API、日志、数据库）、数据清洗规则、缺失值处理策略
好，咱们进入第三章。这一章讲的是数据采集与清洗。说实话，这是整个监控数据分析里最枯燥、但也是最关键的一环。你想想看，如果源头数据就是脏的、乱的，后面再漂亮的图表、再复杂的模型，都是白搭。我见过太多审计项目，结论被质疑，最后追根溯源，都是数据采集阶段埋的雷。
3.1 数据采集的常见方式
数据怎么来？无非三种路子：API、日志、数据库。每种方式都有它的脾气，咱们一个一个说。
3.1.1 通过API采集
API，说白了就是系统之间互相喊话。监控系统暴露一个接口，你去调它，它把数据吐给你。这是目前最主流的方式，尤其是云原生环境。
常见场景：
- 调用Prometheus的HTTP API获取指标数据
- 调用云厂商（阿里云、AWS）的监控API拉取资源使用率
- 调用业务系统的RESTful接口获取交易流水
我个人习惯，写API采集脚本时，一定要加重试机制和限流。为什么呢？我在项目中遇到过，有一次半夜批量调一个第三方API，对方没做限流保护，直接把人家服务打挂了。第二天运维大哥找我喝茶，那场面...嗯，你懂的。
核心要点：API采集一定要处理好鉴权、频率限制、超时重试。别偷懒，这三个缺一不可。
3.1.2 通过日志采集
日志采集，这是审计的老本行。系统每时每刻都在吐日志，里面藏着大量行为数据。常用的工具有Filebeat、Logstash、Fluentd这些。
常见做法：
- 应用日志 -> Filebeat -> Kafka -> Logstash -> ES
- 或者直接用Syslog集中转发
这里有个坑，我曾经踩过。有一次审计一个金融系统的操作日志，发现日志时间戳全是UTC，而业务系统用的是北京时间。差了8个小时，导致审计结论里有一批交易的时间线对不上。后来我定了个规矩：所有日志采集，第一件事就是统一时区，要么全部转成UTC+8，要么全部用Unix时间戳。
避坑指南：日志采集最怕两件事——丢日志和日志格式不统一。建议在采集端做一次格式校验，不符合规范的直接告警，别等到分析时才发现。
3.1.3 通过数据库采集
直接从数据库拉数据，这是最传统的方式。适合那些已经落库的结构化数据，比如财务系统的流水表、ERP的库存表。
常用手段：
- 直连数据库执行SQL查询
- 通过CDC（Change Data Capture）工具，比如Debezium、Canal，实时同步变更数据
- 定时导出CSV或Parquet文件，再加载到分析平台
你想想看，直接连数据库风险很大。我建议，千万不要用业务账号直连生产库。我在项目中遇到过，有人用root账号去拉数据，结果一个慢查询把整个库拖垮了。正确的做法是：申请一个只读的从库账号，或者用数据仓库的镜像表。
| 采集方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| API | 实时性好，标准化程度高 | 依赖接口稳定性，有频率限制 | 云监控、微服务指标 |
| 日志 | 信息量大，覆盖全面 | 解析复杂，存储成本高 | 操作审计、异常追踪 |
| 数据库 | 数据结构清晰，查询灵活 | 对源库有压力，权限管理复杂 | 财务数据、业务流水 |
3.2 数据清洗规则
数据采回来了，但别高兴太早。原始数据就像刚挖出来的矿石，里面全是杂质。清洗，就是把这些杂质筛掉。
我总结了几条铁律：
- 去重：同一个监控指标，因为网络重传或者采集脚本bug，可能被记录了多次。必须按时间戳+唯一标识去重。
- 格式统一：比如日期格式，有的系统用"2024-01-15"，有的用"2024/01/15"，还有用"20240115"的。统一成一种格式，不然后面聚合分析会疯掉。
- 异常值过滤：比如CPU使用率超过100%的，或者内存使用量为负数的，这种明显是采集错误，直接剔除。
- 字段映射：不同系统对同一个概念的命名可能不同。比如A系统叫"user_id"，B系统叫"uid"，清洗时要映射成统一字段名。
小技巧：清洗规则不要一次性写死。我习惯先跑一个样本数据，把清洗逻辑写成脚本，反复调几轮，确认没问题了再全量跑。否则，一个错误的清洗规则可能把好数据也洗没了。
3.3 缺失值处理策略
缺失值，这是审计数据里最头疼的问题。为什么会有缺失？原因很多：采集节点挂了、网络闪断、业务系统升级期间没记录...总之，你永远拿不到100%完整的数据。
那怎么办？我的策略分三种情况：
3.3.1 直接删除
如果缺失比例很小（比如低于1%），而且缺失是随机的，不影响整体统计，那就直接删掉。简单粗暴，但有效。不过要注意，删除前最好记录一下删了多少条，审计底稿里要能说清楚。
3.3.2 填充
如果缺失比例较高，或者缺失的数据很重要，那就得填充。常用的填充方法：
- 均值/中位数填充：适合数值型指标，比如CPU使用率。用前后一段时间的平均值填进去。
- 前向填充：用上一个有效值填充下一个缺失值。适合变化缓慢的指标，比如磁盘容量。
- 插值法：用线性插值或样条插值，适合时间序列数据。
我曾经在一个审计项目里，发现某系统的交易量数据有连续3个小时的缺失。如果用均值填充，会掩盖那段时间的真实情况。后来我查了上下游系统的日志，发现是采集脚本挂了，但业务其实正常运行。最后我用了上下游系统的数据做交叉验证，把缺失值补上了。所以，填充不是机械地套公式，要结合业务逻辑。
3.3.3 标记为特殊值
有些缺失值本身就有信息量。比如某个监控指标突然不报了，可能意味着系统挂了。这种情况下，我会把缺失值标记为-1或者NULL，在分析时单独处理。这样，缺失本身就成了一个审计线索。
总结一下：缺失值处理没有银弹。我的原则是——能追溯原因的就追溯，追溯不了的就用合理方法填充，实在不行就标记出来，但一定要在审计结论里说明缺失情况，别藏着掖着。
嗯，这一章的内容就这些。数据采集和清洗，说白了就是「磨刀不误砍柴工」。你花80%的精力把数据搞干净了，后面20%的分析工作就会非常顺畅。下一章，咱们聊聊数据建模和指标设计，那才是真正出审计结论的地方。