23、数据采集与清洗：埋点、日志、ETL、数据质量检查
数据采集与清洗，说白了就是电商分析的「地基工程」。
我见过太多团队，模型建得花里胡哨，结果一查底层数据全是脏的。那分析出来的东西，你敢信吗？
这一章，咱们就把埋点、日志、ETL、数据质量检查这四块硬骨头啃下来。嗯，都是我在实战中踩过坑的地方。
23.1 埋点：数据采集的「第一公里」
埋点是什么？就是在用户操作的每个关键节点上，装一个「摄像头」。用户点了哪里、停留了多久、加购了什么商品，都得记录下来。
埋点的三种主流方式：
- 代码埋点： 最传统，也最灵活。前端工程师在按钮点击、页面跳转时手动写一段上报代码。我习惯用这种方式做核心转化路径的监控，比如「加入购物车」按钮。
- 全埋点（无埋点）： 自动采集所有用户交互事件。优点是省事，缺点是数据量爆炸，而且很多无用数据。我在项目中遇到过，全埋点一天能产生几个T的日志，但真正有用的不到10%。
- 可视化埋点： 通过后台圈选页面元素，自动生成埋点代码。适合运营同学快速配置，但灵活性差，动态加载的内容容易漏采。
核心原则： 埋点不是越多越好。每个埋点都要问自己三个问题——这个数据能指导什么决策？不采集会损失什么？采集成本是否可控？
23.2 日志：从「原始记录」到「结构化数据」
日志是埋点产生的原始文件。常见的格式有JSON、CSV、或者自定义的文本格式。
举个例子，一个典型的电商浏览日志长这样：
{
"event": "page_view",
"user_id": "u_123456",
"page_id": "p_detail_789",
"sku": "SKU_A001",
"timestamp": 1712345678,
"device": "iPhone 15",
"duration": 45.2
}你看，这里面有用户ID、商品SKU、停留时长。这些字段直接决定了后续你能做什么分析。
日志处理的三个关键点：
- 时间对齐： 客户端时间和服务器时间经常不一致。我建议统一使用服务器时间戳，避免跨天数据错乱。
- 去重： 网络抖动可能导致同一条日志上报多次。需要根据「用户ID + 事件ID + 时间戳」做唯一性校验。
- 字段补齐： 有些字段可能为空，比如未登录用户的user_id。需要设置默认值或标记为「unknown」。
我的小技巧： 日志文件命名最好带上日期和分区号，比如 log_2024-04-01_part_001.json。这样后续ETL处理时，按日期分区读取，效率高很多。
23.3 ETL：数据加工的「流水线」
ETL 就是 Extract（抽取）、Transform（转换）、Load（加载）。说白了，就是把原始日志变成能直接分析的数据表。
我画了一张图，帮你理解整个流程：
你看，数据质量检查不是最后才做的，而是贯穿整个ETL流程。每个环节结束后，都必须跑一遍检查脚本。
ETL 中常见的转换操作：
| 操作类型 | 说明 | 示例 |
|---|---|---|
| 字段映射 | 将原始字段名转为标准字段名 | sku_id → product_sku |
| 数据类型转换 | 统一字段的数据类型 | 字符串时间 → 时间戳 |
| 缺失值处理 | 填充或删除空值 | 用户ID为空 → 标记为 -1 |
| 异常值过滤 | 剔除明显不合理的数据 | 订单金额 < 0 的记录删除 |
| 数据聚合 | 按维度汇总 | 按小时聚合页面PV |
注意： 我曾经遇到过一个问题——ETL脚本跑完，发现订单金额字段全是0。查了半天，原来是上游系统改了字段类型，从整数变成了浮点数，ETL脚本没适配。所以，每次上游系统发版，都要重新验证ETL逻辑。
23.4 数据质量检查：守住最后一道防线
数据质量检查，说白了就是「找茬」。你得主动去发现数据里的问题，而不是等分析时才发现。
我常用的五个检查维度：
- 完整性： 关键字段是否有空值？比如订单表中的「用户ID」不能为空。
- 准确性： 数据值是否在合理范围内？比如订单金额不能为负数，商品单价不能超过10万。
- 一致性： 不同数据源之间的数据是否对得上？比如订单系统的「支付金额」和支付网关的「交易金额」应该一致。
- 及时性： 数据是否在预期时间内到达？比如实时报表要求延迟不超过5分钟。
- 唯一性： 是否存在重复记录？比如同一个订单ID出现了两次。
举个例子，我写过一个简单的质量检查脚本：
-- 检查订单表的完整性
SELECT
COUNT(*) AS total_records,
SUM(CASE WHEN user_id IS NULL THEN 1 ELSE 0 END) AS missing_user_id,
SUM(CASE WHEN order_amount IS NULL THEN 1 ELSE 0 END) AS missing_amount,
SUM(CASE WHEN order_amount < 0 THEN 1 ELSE 0 END) AS negative_amount
FROM dwd_order_detail
WHERE dt = '2024-04-01';这个脚本跑完，如果发现 missing_user_id 大于0，就得立刻去查埋点日志，看看是不是前端漏传了用户ID。
我的习惯： 每天凌晨ETL跑完后，自动触发质量检查。如果检查不通过，直接发告警到钉钉群。这样早上到公司，第一件事就是看告警，而不是等业务方来投诉数据不对。
23.5 避坑指南：我踩过的三个坑
- 坑一：埋点代码上线后，忘了验证。 我曾经有一次，埋点代码上线了，但前端工程师把事件名写错了。结果一周后才发现，那一周的数据全部作废。现在我的流程是：埋点上线的同时，必须写一个自动化验证脚本，模拟用户操作，检查数据是否正常上报。
- 坑二：ETL脚本只处理了正常数据。 有一次，用户手机型号字段里出现了「iPhone 15 Pro Max (A3106)」这种带括号的字符串。ETL脚本没处理，导致后续分析时分组乱了。现在我会在ETL里加一层「字段标准化」，把所有特殊字符都处理掉。
- 坑三：数据质量检查只检查了「有没有」，没检查「对不对」。 比如订单金额字段不为空，但值却是0。这种逻辑错误，光靠空值检查是发现不了的。我后来加了一层「业务规则校验」，比如「订单金额必须大于0且小于10万」。
数据采集与清洗，听起来枯燥，但它是整个分析链条的基石。你想想看，如果地基没打好，上面盖再高的楼，你敢住吗？
嗯，这一章的内容就到这里。记住一句话：垃圾数据进，垃圾分析出。 把采集和清洗做好，后面的分析才能事半功倍。