2. 运营数据基础：数据采集与埋点、数据仓库与ETL、数据质量与治理
好，咱们正式开始聊数据基础。很多同学一上来就急着建模，结果数据一塌糊涂，模型跑出来全是垃圾。我见过太多这样的项目了。说白了，数据基础不牢，地动山摇。这一章，咱们就把地基打扎实。
2.1 数据采集与埋点：源头决定一切
数据采集，就是给系统装「眼睛」和「耳朵」。ATO系统里，每一笔交易、每一次状态变更、每一个报警，都是数据源。但数据不会自己跑过来，你得主动去「采」。
埋点，就是有策略地「偷看」用户和系统的行为。
我个人习惯把埋点分成三类：
- 全埋点：所有操作都记录。简单粗暴，但数据量大，存储成本高。适合探索期。
- 关键路径埋点：只记录核心业务流程。比如下单、支付、出票。效率高，但容易漏掉异常场景。
- 自定义埋点：针对特定分析需求。比如「用户点击了退票按钮后，停留了多久」。灵活，但需要开发配合。
埋点数据怎么传？常见方式有：
- HTTP请求：实时性高，但会阻塞业务。适合关键事件。
- 日志文件：异步写入，不影响性能。适合海量数据。
- 消息队列：比如Kafka。解耦、削峰。我强烈推荐这种方式。
举个实际例子。我在项目中遇到过一个问题：用户下单后，系统返回了成功，但实际出票失败。如果只埋点了「下单成功」事件，你根本发现不了问题。后来我们加了一个「出票结果」的埋点，才把问题揪出来。嗯，这里要注意：埋点一定要覆盖完整链路。
2.2 数据仓库与ETL：把脏数据变成干净资产
数据采回来了，但往往是「脏乱差」的。比如时间格式不统一、字段缺失、重复记录。这时候就需要数据仓库和ETL上场了。
数据仓库，说白了就是一个专门存「分析用数据」的地方。 它和业务数据库不一样。业务库追求的是「快」，仓库追求的是「全」和「准」。
我常用的数据仓库分层模型是这样的：
| 层级 | 名称 | 作用 | 例子 |
|---|---|---|---|
| ODS | 操作数据层 | 原封不动存原始数据 | 订单日志、埋点日志 |
| DWD | 明细数据层 | 清洗、去重、标准化 | 统一时间格式、补全字段 |
| DWS | 汇总数据层 | 按维度聚合 | 每日订单数、用户活跃数 |
| ADS | 应用数据层 | 直接给报表和模型用 | 用户画像、预测特征 |
ETL，就是数据从ODS到ADS的「搬运工」。 三个字母分别代表：
- Extract（抽取）：从各种数据源拉数据。比如从MySQL、日志文件、API接口。
- Transform（转换）：清洗、过滤、合并、计算。这是最耗时的环节。
- Load（加载）：把处理好的数据写入目标表。
我曾经接手过一个项目，ETL跑了整整8小时，每天凌晨跑，早上上班还没跑完。后来发现是SQL写得有问题，一个JOIN没加索引。优化后，20分钟搞定。你想想看，ETL的效率，直接决定了你第二天能不能看到报表。
这里给一段简单的ETL代码示例（伪代码风格）：
-- 1. 抽取：从原始日志表拉取昨天的数据
INSERT INTO dwd_order_log
SELECT
order_id,
user_id,
-- 2. 转换：统一时间格式
CAST(event_time AS TIMESTAMP) AS event_time,
-- 3. 转换：清洗异常值
CASE WHEN amount < 0 THEN 0 ELSE amount END AS amount,
status
FROM ods_order_log
WHERE dt = '2024-01-15'
AND order_id IS NOT NULL; -- 去空2.3 数据质量与治理：别让垃圾数据毁了模型
数据质量，是数据挖掘的「命门」。模型再牛，喂进去的是垃圾，出来的还是垃圾。我见过太多团队，花80%的时间调模型，却只花20%的时间管数据质量。结果呢？模型上线就崩。
数据质量，我主要看这六个维度：
- 完整性：字段有没有空值？关键字段不能为空。
- 准确性：数据对不对？比如订单金额不能是负数。
- 一致性：不同系统间的数据是否矛盾？比如CRM里用户叫「张三」，订单系统里叫「张3」。
- 及时性：数据更新是否及时？比如实时报表延迟不能超过5分钟。
- 唯一性：有没有重复数据？比如同一个订单被记录了两次。
- 规范性：数据格式是否统一？比如日期都是YYYY-MM-DD。
怎么治理？我总结了一套「三板斧」：
- 第一板斧：事前预防。在数据入库时就做校验。比如用约束、触发器、或者ETL里的检查逻辑。
- 第二板斧：事中监控。跑定时任务，检查数据质量指标。比如每天统计空值率、重复率。
- 第三板斧：事后追溯。出了问题，能快速定位到是哪个环节、哪个人、哪条数据导致的。
举个例子。有一次，我发现模型预测的退票率突然飙升。查了半天，原来是上游系统改了接口，把「退票成功」的状态码从'03'改成了'04'，但ETL里没更新。结果所有退票数据都被当成「其他状态」过滤掉了。你看，一个状态码的变更，就能让整个模型失效。
所以，数据治理不只是技术问题，更是管理问题。你需要：
- 建立数据标准文档
- 明确数据责任人
- 定期做数据质量审计
- 对变更做影响分析
好了，这一章的内容就这些。数据采集、ETL、数据治理，这三件事做好了，后面的建模才能顺风顺水。下一章，咱们聊聊「探索性数据分析」——拿到数据后，第一件事该干什么。