从爬取到挖掘：数据管线与指标设计

本文基于模型知识整理。

一句话定义

数据管线是「原始层 → 清洗层 → 分析层」的分层加工链路；指标设计则从业务问题出发反向定义要采集什么字段——先有问题，再有数据。

为什么重要

多数失败的分析项目死在起点：抓了一堆「觉得有用」的数据，最后回答不了任何具体问题。分层管线保证原始数据可回溯（采集 bug 可重算），反向设计保证每一列字段都服务于某个待答问题。

前置知识

kp-011（清洗与落库的基础）。

核心概念

• 三层管线：raw（原样落盘，只追加不改）→ clean（清洗规整，可重跑）→ marts（面向问题的聚合表）。
• 指标：业务问题的可计算翻译（如「竞品价格压力」= 自家 SKU 价格 ÷ 同类目竞品中位价）。
• 反向设计：问题 → 指标 → 所需字段 → 采集目标与频率。
• 数据契约：clean 层的 schema 与字段语义固定，上下游按契约开发。

原理与机制

反向设计的推导链（示例：「我的定价值不值得再降？」）：

业务问题: 现价相对竞品是否有价格劣势?
  → 指标:   价格指数 = SKU现价 / 同类目竞品价格中位数 (逐日)
  → 字段:   sku_id, price, crawled_at, category, 竞品SKU清单
  → 采集:   竞品列表页+详情页, 每日一次, 保留历史(时序分析, 见 kp-027)
  → 判定:   价格指数 > 1.15 连续3天 → 触发价格复盘

分层的纪律（对应 kp-011 的「采集与清洗分离」）：

raw/    只追加, 原始HTML或接口响应按日期归档 —— 任何上层错误都可从这里重算
clean/  由 raw 派生, 脚本可重跑, schema 契约化
marts/  由 clean 聚合(日均价/周均/排名), 直接喂给报表与模型

实例或案例

某品类调研先抓了 30 个字段（销量、评论数、店铺名、详情页全部参数……），两周后汇报时真正用到的只有 6 个字段，而关键缺失的是「上架时间」——没做反向设计，抓的全是顺手可得而非问题所需。教训：先写「我要回答什么问题、用什么指标」，再开 DevTools。

常见误区

• 误区一：先抓后想。 采集成本最低的错觉导致数据堆山，分析时才发现缺关键字段；反向设计把「缺字段」消灭在设计阶段。
• 误区二：无 raw 层，直接边抓边清洗落库。 清洗规则写错或想加字段时无源可回溯，只能重新采集整个站点。
• 误区三：指标不可复算。 指标必须由 clean 层数据确定性推导（同一输入必得同一输出），否则报告数字无法审计。

自测题

1. 三层管线各自的读写纪律？

答：raw 只追加不改；clean 从 raw 派生、可整体重跑；marts 从 clean 聚合、直接服务分析。

1. 反向设计的推导顺序？

答：业务问题 → 指标定义 → 所需字段 → 采集对象与频率。

1. 为什么 raw 层禁止修改？

答：它是唯一的真值来源；清洗逻辑随时可能改错，只有原样留档才能无限次重算。

与其他知识点的关系

kp-025 是 clean 层的质量纪律；kp-027/028/029 是 marts 层的消费方；kp-033 把管线分层写进项目工作流。

延伸阅读

本库 kp-011、kp-033；《数据仓库》维度建模思想的入门章节（事实表/长表设计）。