中小企业数据管道：轻量数仓踩过的四个坑

数据管道这件事，一开始总是很简单：把几张表同步过来，做个汇总，出个报表。

半年之后就变成一团：字段口径不一致、任务互相依赖、某天早上发现数字对不上，没人知道是哪一步出的问题。

这篇写中小团队做轻量数仓时最容易踩的四个坑。

坑一：把「同步」当成了「建模」

把业务库的表原样搬到分析库，看起来最快。但业务表是为事务设计的，字段含义会随业务变化，同一个状态值今天和半年前的意思可能已经不同。

正确的顺序是先定义口径：这个指标怎么算、排除哪些记录、以哪个时间为准。口径定了，表怎么建是后面的问题。

坑二：任务依赖靠时间硬排

常见做法是「先跑 A，等半小时再跑 B」。任务一多，等待时间就越加越长，出错也没人知道为什么。

更稳的做法是把依赖写成显式的：B 依赖 A 完成，而不是依赖「现在几点」。这样重跑和补数才可控。

坑三：没有数据质量校验

报表里的数字错了，往往是被使用者发现的，而不是被系统发现的。

最基础的校验其实不贵：行数不能为负、关键字段不能为空、今天的总量和昨天不能差出三倍。这几条能拦下大部分显性错误。

坑四：不留原始数据

有人为了省存储，只保留处理后的结果。等到发现口径错了，就没法重算。

原始层尽量保留，而且不要改写。它是对账的底本，也是唯一能回答「当时到底是什么样」的地方。

轻量方案怎么选

数据量在几十 G 以内，用一套简单的编排工具加列式存储就够，不必上完整的数据仓库体系。

选型时先看团队有没有人能维护，再看功能。没人维护的复杂方案，最后都会变成新的技术债。

文档和血缘

表格和任务能跑起来之后，第二个问题马上出现：这个字段是从哪来的。

至少要做到每个指标能追到来源表，每个任务写明输入输出。出问题时，这份记录能省掉半天排查时间。

别忘了算成本

轻量方案也要花钱：存储、计算，以及最贵的人力维护。

我习惯每月看一次成本曲线。如果某条任务的成本远高于它产出的价值，就该考虑降频或者直接下线。

另一个容易被忽视的成本是变更成本：改一次上游表结构，下游要跟着动。所以上游字段尽量少改，优先新增，不要轻易重命名或删除。

最后是留一份运行记录：每次任务跑没跑成、跑了多久。这份记录平时没人看，但一旦数字不对，它是最快的线索。

这些做法都很朴素，省下来的是反复排查的时间。

重跑的成本也不该被忽略：一次全量重算可能比一天的增量任务更贵，所以补数要尽量按分区做。

结论

数据管道的问题几乎都不是技术问题，而是口径问题和流程问题。

先把「这个数字怎么来的」讲清楚，再谈用什么工具。

本文不构成任何技术建议，具体方案请结合自身数据规模与团队情况评估。