做数据报表三年，最让我后悔的五个设计选择

三年前我开始负责公司内部的 BI 和数据报表。当时觉得这事不复杂：把业务数据捞出来，算一算，画成图，老板看了点头就行。结果三年过去，回头看看最初的几个决定，真是给自己挖了不少坑。有些坑到现在还在填。

今天把五个最后悔的设计选择列出来，不是说这些方案一定错，而是我在当时的场景里用错了。如果你也在小团队里做数据报表，希望能帮你少踩几个。

一、所有指标都塞进一张大宽表

最早的时候，为了方便，我把订单、用户、商品、财务相关的字段全塞进一张宽表里。思路很简单：查询的时候一张表搞定，不用 join，速度快，报表配置也省事。

前三个月确实爽。第四个月开始出问题：

• 这张表有 300 多个字段，新同事打开直接懵。
• 任何一个上游字段改动，下游所有报表都可能受影响。
• 表体积膨胀极快，半年后跟老板说“能不能加块 SSD”，老板看我的眼神不太对。

更麻烦的是语义混乱。同一个字段在不同业务线里的定义不一样，比如“活跃用户”，A 业务看的是登录，B 业务看的是产生过行为，C 业务看的是付费。全塞一张表里，最后谁也说不清报表上那个数到底怎么算的。

后来我拆成了主题域：订单域、用户域、商品域、财务域。每个域维护自己的事实表和维度表，宽表只在最终展示层按需生成。改完之后，新同事至少能看懂表结构了，加字段也不用提心吊胆。

说到底，不要为了省事搞万能表。主题域拆分这堂课，迟早要补。

二、把 BI 工具当成 ETL 工具用

我们用的是 Metabase。一开始没有专门做 ETL，所有的清洗逻辑都写在 Metabase 的 SQL 问题里：

```sql
SELECT  
  DATE(created_at) AS dt,  
  CASE  
    WHEN source LIKE '%ios%' THEN 'iOS'  
    WHEN source LIKE '%android%' THEN 'Android'  
    ELSE 'Other'  
  END AS platform,  
  COUNT(*) AS orders  
FROM orders  
WHERE status != 'cancelled'  
GROUP BY 1, 2

类似这样的 SQL 在 Metabase 里复制了几十份。每个报表各自写清洗逻辑，今天改了一个口径，要手动把所有相关 SQL 改一遍。漏改一个，两个报表同一个指标数字对不上，开会的时候非常尴尬。

Metabase 本身没问题，问题是我让它承担了它不该承担的工作。后来我们把清洗逻辑前置到 dbt（也试过 airflow 里的 SQL 任务），BI 层只负责选已经清洗好的表。同一个口径只定义一次，改了也只要改一处，开会终于不用先道歉了。

BI 工具就做展示，别把 ETL 的活也塞给它。

三、没做版本管理，改挂过两次核心报表

有段时间我们的核心日报 SQL 直接存在 BI 工具里。某人（好吧，就是我）手滑改了一个过滤条件，把 status = 'paid' 改成了 status != 'refunded'，当天晚上老板看到的 GMV 直接翻倍。第二天一早被拉去解释，场面一度非常社死。

还有一次，新同事想优化一个慢查询，改完后没通知别人，结果依赖这个查询的三个报表全部报错，我们过了两天才发现。

从那以后，所有核心指标 SQL 全进 Git。dbt 模型、airflow DAG、superset 图表定义都用代码管理。上线走 PR，出问题能回滚。这个改造花了大概两周，但之后再也没出现过“改挂报表找不到人”的情况。

数据代码也是代码，该上 Git 就上 Git，别心疼那两周。

四、为了追求实时，把所有报表都做成准实时

老板第一次说“我想看实时数据”的时候，我立刻紧张起来，觉得不上实时就要被时代抛弃了。于是搞 Kafka + Flink，把订单、支付、用户行为都接入实时链路。折腾了一个多月，终于能在看板上看到“最近 5 分钟”的数字。

然后呢？然后发现：

• 99% 的报表 nobody 看实时版，大家还是每天上午看昨天汇总。
• 实时链路复杂度高，出一次问题排查半天。
• 实时口径和离线口径经常对不上，业务方问起来解释成本极高。

现在我的原则是：除非业务真的需要分钟级决策，否则先做 T+1。实时只给真正需要它的场景，比如风控、运营告警、库存预警。大多数经营分析报表，T+1 完全够用，且成本低得多。

不要为了炫技做实时，先问清楚业务到底需不需要。

五、指标口径全靠口头约定

最早我们没有任何指标字典。同一个“留存率”，有人按次日算，有人按 7 日算；有人算设备维度，有人算用户维度。每次开会前都要先花十分钟对齐口径，效率极低。

有次更离谱，财务和业务各拿了一张报表给老板，同一个“月活跃用户”，两个数字差了 15%。老板问怎么回事，我们现场才发现一个排除了测试账号，一个没排除。

后来我们做了一个很简单的指标字典，Excel 都行，现在用的是 Notion 表格。每个指标写明：

• 指标名称
• 业务定义（一句话说清是什么）
• 计算公式
• 数据来源
• 更新频率
• 负责人
• 常见口径差异说明

不要求多高大上，关键是所有人能达成一致。我们现在要求：任何进入核心看板的指标，必须先入库。新同事来了一看就懂，不用再拉着老员工问。

指标口径不写下来，迟早会在老板面前翻车。

三年下来，我越来越觉得小团队做数据，拼的不是工具多先进，而是“克制”。克制地建表、克制地实时、克制地炫技。把基础的事情做扎实，比上一堆中台组件有用得多。

如果你也在做类似的事，上面这五个坑可以对照看看。你踩过哪些不一样的坑，欢迎一起聊。