大数据：我们建了数据中台，然后发现没人信上面的数

去年公司上线数据中台，汇报那天大屏很漂亮：GMV、活跃、留存，曲线一条条往上走，领导点头。散会后运营总监和财务总监在门口吵了起来——因为大屏上那个“本月营收”，和财务自己报表里的数字差了三百万。

两个人各拿一份“正确”的数据，站在同一个走廊里，谁也说服不了谁。后来查了两天，原因简单得可笑：运营算的是下单金额，财务算的是到账金额，中间还有一批退款和一笔跨期确认，两边口径从来没对齐过。

那一刻我才明白，大数据最难的部分，从来不是“大”。

一、数据能跑通，不代表能信

我们前期花了最多力气的事，是让数据流跑起来：埋点上报、Kafka 入湖、离线清洗、实时链路、指标计算，每一环都有监控，每一环都不报错。从工程角度看，这套东西是健康的。

但它只是“把数算出来了”，没有回答“这个数对不对”。

同一个指标，不同人写不同的 SQL，跑出来的数不一样，而且每个 SQL 单看都合理。问题不在 SQL，在大家心里的定义不一样：新客算不算退款用户？活跃算不算只打开没操作？“本月”按自然月还是按财务月？

工程能保证管道不漏，保证不了管道里流的是不是同一个东西。

二、指标不是算出来的，是“定义”出来的

后来我们做了一件很朴素的事：把核心指标的定义写下来，写成人和代码都能读的形式。

# 指标不是一行 SQL，是一份契约：定义、口径、负责人
metric = {
    "name": "月营收",
    "definition": "当月已到账且未退款的订单金额之和",
    "exclude": ["未支付", "已退款", "跨期调整"],
    "owner": "finance",
    "sql": "SELECT sum(paid_amount) FROM orders WHERE ...",
}

看起来只是加了几个字段，但它改变了一件事：指标从“某个人写的 SQL”变成了“一个有主人的约定”。财务说口径不对，找的是这份定义，不是找写 SQL 的人吵架；新来的分析师要复用，读的是定义，不是猜。

我们后来把这件事做成了规矩：每个上大屏的指标，必须有定义、有负责人、有一组校验用例。没有这三样，不许上线。

三、校验用例，比监控更有用

监控能告诉你“任务失败了”，告诉不了你“数算错了”。任务成功跑完、算出个离谱的数，监控一声不吭。

真正救命的是这种断言：

assert 0 <= monthly_revenue <= 1e9          # 量级不对，先报警
assert abs(monthly_revenue - last_month) / last_month < 0.5   # 环比突变 50% 要人工确认
assert daily_active >= paying_users         # 逻辑关系，付费用户不可能多于活跃

这几行的价值，比一整面监控墙都高。因为它们校验的不是“程序有没有崩”，是“结果符不符合业务常识”。

我们在一次上游字段变更后靠第二行拦下过一次事故：任务全绿，指标环比掉了 60%，断言报警，人去看，发现是某个埋点字段改名了没人通知。要是没这行，这个错数会安安静静地在大屏上挂一个月。

四、大屏很好看，但决策不看大屏

最扎心的一课是：中台建完半年，用得最多的还是那几个做报表的人。业务决策时，大家还是打开自己的 Excel，或者直接在群里问“这个数对不对”。

因为数据平台给的是“数”，业务要的是“能不能据此做决定”。这两者之间隔着一层信任：用户得先相信这个数，才会用它。而信任不是靠大屏的配色建立的，是靠一次一次“我拿它做的决定，事后证明是对的”。

我们后来砍掉了一半指标，只留那些有明确负责人、有校验、有人真的在用的。指标少了，反而用的人多了——因为大家终于开始相信上面那几个数。