先说一个挺丢人的数字
2021 年我在一家做跨境电商 SaaS 的公司，数据团队四个人，要服务大概三百个内部用户。那年我们干了一件现在想起来挺蠢的事：把已经用了两年的 Tableau 换掉，迁到 Power BI，八个月后又迁到 Metabase。十四个月，三套 BI，平台的月活从 180 掉到 96。最讽刺的是日均查询量其实是涨的，因为涨的全是我们自己写的临时导出 SQL，业务同学基本不来了。
复盘文档我写了 27 页，后来压缩成一句话贴在了工位上：大部分公司的 BI 问题，跟 BI 工具一点关系都没有。
这不是一句鸡汤。后面我会把这句话拆成三块：谁写 SQL、延迟预算、口径治理。这三件事没定下来，你换什么工具都是白换。
那些功能对比表，我看过不下几十份，基本都是废的
网上流行的 BI 选型对比表，套路是把"支持多少种图表""能不能拖拽""有没有 AI 问答"列成一张大表打勾打叉。这类表最大的问题是，它假设所有公司处在同一个约束条件下，而实际上约束条件才是决定性的。
第一个约束是谁来写 SQL，这是最硬的一条。你要是团队里没有两三个 SQL 写得很溜的人，Superset 做出来的看板会很难看，而且改一个筛选项就要动 dataset，业务方自己根本搞不定。Metabase 的 question 模式对非技术用户友好得多，但它的 Model 层在 0.46 版本之前基本是残的，稍微复杂点的逻辑还是得下沉到数据库视图。Power BI 更麻烦，DAX 是另一个物种，会 SQL 完全不等于会 DAX——我们有个写了六年 SQL 的分析师，第一次写 CALCULATE 的时候调了两个下午，最后发现是筛选上下文没理清。
第二个约束是延迟预算。如果你要的是 3 秒内出图的看板，那你需要的是预聚合表或者列存引擎，而不是换个 BI 前端。这一点我后面单独用一节讲，因为有太多人搞反了因果。
第三个约束是治理成熟度。这个不是技术问题，是组织问题，但它的杀伤力比前两个加起来都大。
42 秒到 1.8 秒，BI 工具一行代码没改
我们有一张看板叫"分渠道分国家的日订单趋势 + 同比"，源表是订单明细，2.3 亿行。原方案是 MySQL 5.7 单实例，一个 group by 加两个 join，还要算去年同期。8 核 32G 的机器，平均查询 42 秒，月末跑批的时候偶尔直接超时。
后来做了三件事，注意，BI 前端我们一行代码都没改：
- 建了一张日粒度的聚合表，按
dt + channel + country + 币种聚合，行数从 2.3 亿降到 380 万； - 同比不走 join 了，改成窗口函数
lag(...) over (order by dt)，直接在聚合表上跑； - 查询引擎换成 ClickHouse，单副本，还是 8C32G，数据压缩后大概 2.1 GB。
结果：同样的看板渲染时间 1.8 秒，P95 是 2.6 秒。后来因为组织调整，前端从 Tableau 换成 Metabase 又换成 Superset，这个数基本没变，在 1.7 到 2.1 秒之间波动。所以每次有人跟我说"这个 BI 工具太慢了想换一个"，我第一句话都是问：你的聚合表建了吗？分区裁剪写对了吗？
顺便说个参数坑：Power BI Pro 的数据集每天只能刷新 8 次，想刷 48 次得升到 PPU（每人每月 20 美元，Pro 是 10 美元）。我们当时有十几个看板依赖同一个数据集，早中晚各要刷新一次，8 次根本不够用，最后是拆成多个数据集绕过去的，维护成本直接翻倍。
GMV 到底扣不扣退款，我们吵了三次会
这个故事比较典型。我们的 GMV 在三个地方有三个数：财务用的是扣退款后的净额，增长团队用的是支付成功口径不扣退款，运营看的是已发货口径。三个数大概差 12%。最尴尬的一次是周会上，CEO 拿着手机上的看板截图问"为什么这个数跟昨天财务发的邮件不一样"，会议室里安静了大概五秒，然后所有人一起看向我。
解决方案不复杂，但很烦：把指标定义从 SQL 里抽出来，做成有 owner 的代码资产。
- 建了一个 metrics 目录，每个指标一个 YAML 文件，字段包括 name、owner、口径描述、SQL 表达式、可用维度、时间粒度、依赖的上游表；
- 全部进 Git，改口径必须提 PR，PR 模板里强制填"影响哪些看板、需要通知谁"；
- dbt 跑的时候生成一张 metrics 元数据表，BI 层直接读这张表做指标说明，鼠标悬停能看到"该指标由 XXX 于 2023-08-14 修改"这种信息。
这件事花了我们大概三周，其中一整周都在吵架——不是技术吵架，是业务吵架，增长的人坚持不扣退款，财务的人坚持扣。最后定下来两个指标都保留，但必须叫不同的名字（gmv_gross 和 gmv_net），默认看板上只放 net。
指标数量上，一开始列出来 180 多个，去重合并之后剩 63 个，真正常用的不到 20 个。剩下那 43 个现在还在，但我知道它们只是还没到被删的时候。
报表数量过了 150 张以后，熵增是不可逆的
具体表现是这样的：同一个业务问题对应 4 张表；有两张表名字一模一样但数据不同，因为有人复制粘贴之后忘了改 where 条件；没人知道某张表是谁建的；有人离职，他留下的 30 张表没人敢删，就一直挂着。
我们的做法是每季度做一次访问量盘点。连续 90 天零访问、且没有邮件订阅调度的表直接下线，提前一周发邮件通知，抄送直属领导。一般没人反对。最多的一次我们下线了 214 张表，占当时总量的 61%，下完之后平台加载速度肉眼可见地快了，因为元数据少了，首页渲染从 4 秒多降到 1 秒出头。
有个小技巧：Metabase 的 query_execution 表和 Superset 的 logs 表都能直接查访问记录，写个定时任务每周跑一次就够了。别去买那些"数据资产盘点"的商业产品，我试过两家，报价六位数起，功能还没有自己写 200 行 SQL 好用。
我的选型决策表，跟网上那些不太一样
按约束走，不对着功能清单选：
- 分析师 ≤ 3 人、业务用户 ≤ 50 人、没有专职数据工程：Metabase 开源自建。PostgreSQL 存元数据，Docker Compose 十分钟起一套，别折腾 Superset。
- 分析师 SQL 强、已经有 Trino 或 Presto、想要完全可控：Superset。但要准备好自己写 Helm chart，并且接受它的 UI 确实不太好看。
- 业务方深度依赖 Excel、公司已经在用 Microsoft 365：Power BI，生态打通这一点别的工具真比不了。注意上面说的刷新次数限制。
- 预算充足、对可视化有强迫症、老板要看大屏：Tableau。我们当年签的时候 Creator 席位大概 70 美元一个月，现在涨了不止一点，具体多少我不敢给数，反正不便宜。
- 国内要厂商驻场、要私有化、要有人接电话：帆软 FineBI 或者观远。按年报价，几万到几十万不等，主要看并发用户数和是否私有化部署。
- 单表超过 5 亿行、有多维聚合场景：别在前端工具上纠结了，ClickHouse 或者 StarRocks 当查询引擎，前面套 Superset 或者 Metabase 都行，甚至直接 Grafana 都可以。
最后说一句可能得罪人的：不要相信"自助式分析"这四个字。我们三百个用户里，真正会自己拖维度做分析的不到 20 个。剩下 280 个要的是一张不会变来变去的表，加一个每天早上八点准时到邮箱的订阅。这事儿想明白了，选型就没那么难了。
现在我的团队维护 137 张报表。上周有个运营同学来找我，说想要个新看板。我先问了他三个问题：现在哪张表不能满足你？你每周看几次？如果这张表下周消失了你会不会有感觉？他想了两分钟说，好像用现有的那张就行。
这个流程挺得罪人的，但比一年后删两百张表省事。