什么是数据管道？阶段、类型和一个统计实例

每一个统计数字都走过一条管道：采集、校验、清洗、补充、存储、查询。本文逐个讲六个阶段以及它们怎么出问题，比较批处理和流处理，并估算一条事件管道：重试、迟到的移动事件和丢失的脚本先后让看板失真，直到四条简单的监控把它们抓出来。

什么是数据管道？

数据管道（Data Pipeline）是把数据从产生的地方搬到使用的地方、并在途中加工的一组自动化步骤。在数据分析里，管道接收网站、App 和服务端发来的原始事件，校验并清洗，补充信息（渠道、设备、地区），存储起来，再变成看板、告警和导出背后的那些表。

看板上的数看起来不对时，原因几乎总在管道的某一段：某个事件没到、重复了、一批数据晚到、某个属性改了名。弄清各个阶段，是排查统计问题最快的办法。

数据管道的各个阶段

要监控管道本身：采集坏了，看起来就像流量下跌。

批处理和流处理

大多数分析产品是混合的：事件以流的方式进来，供实时视图使用；批处理任务再生成每日汇总、补上迟到的数据。这就是「今天」的数字隔夜会小幅变化的原因。

ETL 和 ELT

两种经典模式的区别在于在哪里做转换：

• ETL（抽取、转换、加载）： 先清洗整理，再装进数仓。存储更小更整齐，重新处理历史数据较难。
• ELT（抽取、加载、转换）： 先把原始数据装进去，再在数仓里用 SQL 转换。保留了原始数据，口径变了可以重建表。现代云数仓常用这种方式。

计算示例：估算并检查一条事件管道

某 SaaS 产品每天从网页和 App 发送约 12 万个事件（示例数字）。

数据量。 原始 JSON 事件每条约 0.8 KB，一天 96 MB，一个月约 2.9 GB，一年约 35 GB（未压缩）。JSON 事件数据用 gzip 通常能压缩 8–12 倍，一年的导出也就几 GB。这个规模的网站，数据量很少是问题，正确性才是。

重复。 网络断了，移动 SDK 会重试。有一周 0.6% 的购买事件到了两次。没有去重键，收入就多算了 0.6%。每个购买事件带上订单号、按订单号去重，重复就消失了。

迟到数据。 1.8% 的 App 事件迟到了一小时以上（离线设备恢复联网后同步）。凌晨 00:30 跑一次、之后不再处理的每日任务，就把昨天少算了这么多。几小时后把前一天的汇总再跑一次，问题就解决了。

新鲜度和数据量检查。 团队给管道本身加了几条监控：

这些正是数据可观测性工具自动做的事：新鲜度、数据量、结构、分布和血缘。

数据管道的实践要点

1. 先定义事件再采集。 埋点方案和数据字典能挡住大部分结构问题。
2. 每一步都可以安全重跑。 同一天的任务重跑一次，结果应该一样，而不是翻倍。
3. 业务事件带唯一编号（订单号、发票号），并按它去重。
4. 时间戳用 UTC 存，查询时再换成报表时区。
5. 原始数据保留一段明确的时间，这样能重建派生表。
6. 注意基数。 有几百万个不同取值的属性（带会话 ID 的完整网址、自由文本）会撑大存储、拖慢查询。
7. 监控管道本身，不只监控业务指标。 流量下跌和采集坏了，在看板上看起来一模一样。
8. 尽早把个人数据挡在外面。 在采集时就去掉邮箱和令牌，后面再清就难多了。

TapCub 的数据管道

• 采集： 网页脚本、移动和小程序 SDK、服务端事件，也可以导入服务器日志。
• 接入： 采集服务校验每个请求。拒收发生在存储之前，数据质量页按原因和日期列出：域名不符、排除规则、月度额度、限流、请求格式错误和机器人。
• 处理： 机器人识别、渠道和 UTM 解析、会话、身份合并。
• 存储： 事件表和每日用户汇总。默认保留期：事件 365 日，自动采集 90 天，用户档案和同意记录各 730 天。
• 使用： 报表、SQL 查询、监控，以及 gzip 压缩的 JSONL 原始数据导出（每个任务最多 365 日，文件保留 48 小时），可以装进你自己的数仓。

购买事件要带上订单号，这样重试不会多出一笔订单。

另见：湖仓一体和数仓、数据血缘。

参考资料

• Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly, chapters 10–11.
• Google Cloud. What is a data pipeline?
• Reis, J. and Housley, M. (2022). Fundamentals of Data Engineering. O'Reilly.