随着越来越多公司把报表和分析系统迁移到云数据平台，很多团队都会遇到一个阶段性问题：BI 工具本身开始变慢，甚至变成性能瓶颈。
最开始，这类系统在数据量不大的时候运行很顺畅。但当数据规模、业务复杂度、报表数量一起上涨后，问题就会慢慢暴露出来，比如：
-
仪表盘加载越来越慢
-
查询动不动几十秒
-
一个字段改错就可能影响整条报表链路
东南亚电商平台 Carousell 最近的一次架构升级，正好给了行业一个比较典型的参考案例。
云 BI 架构为什么越来越容易变慢？
现在很多 BI 工具都支持直接在报表层写逻辑，这在早期开发阶段确实很方便。
但问题也很明显：
计算压力会从数据仓库转移到 BI 层。
在 Carousell 的场景里，分析团队发现：
探索型分析经常直接连接超大数据集，有时甚至达到数百 TB。
而且很多 JOIN 操作是在 BI 层实时算的，而不是提前在数据仓库处理好。
结果就是：
-
查询链路越来越复杂
-
BI 工具开始承担计算引擎角色
-
查询延迟明显上升
内部监控数据显示：
P98 查询延迟一度超过 40 秒。
这个数字已经会直接影响业务会议体验。
更隐蔽的问题：治理风险
性能问题其实只是表象。
更大的风险来自：
开发人员可以直接把改动推到生产模型。
听起来效率很高，但问题是：
-
没有严格测试
-
依赖关系不清晰
-
一个字段错误可能让整个 Dashboard 崩掉
这种情况在快速增长阶段非常常见。
Carousell 的解决思路：把计算和展示彻底拆开
Carousell 没有继续在原有 BI 环境里做优化，而是直接换思路。
第一层变化：计算前移到数据仓库
他们把重计算逻辑迁移到 BigQuery 管道：
-
大型 JOIN 在数据库完成
-
BI 层只负责指标定义 + 展示
这样做以后，查询路径明显缩短。
第二层变化：拆成两个 BI 环境
这是最关键的一步。
生产 BI 环境
专门用于：
-
高管看板
-
周报
-
预聚合数据集
查询只跑优化好的表。
探索 BI 环境
继续开放给分析师：
-
测试新指标
-
分析细粒度数据
-
做实验查询
但不会影响生产报表性能。
为什么这种架构越来越常见？
现在很多数据团队都在做类似事情，只不过层级不同：
-
数据仓库层做隔离
-
Sandbox 项目隔离
-
或 BI 层直接双实例
核心思想其实就一句话：
生产报表和探索分析不要混在一起。
治理自动化：CI + 规则检查
Carousell 还在 BI 发布流程里加了自动检查机制：
比如：
-
SQL 语法检查
-
元数据完整性校验
-
JOIN 来源限制
-
文档强制规范
如果检查不通过，代码不能进生产。
这一点对未来对话式 BI（自然语言查数据）其实非常重要，因为 AI 依赖结构化元数据。
性能提升效果
改造完成后：
P98 查询时间
👉 从 40 秒
👉 降到 10 秒以内
业务层最大的变化其实不是速度，而是：
会议不再围绕“系统是不是坏了”，
而是直接讨论数据结果。
工程团队也不用天天救火。
这次案例给行业的真正启示
真正关键的一点不是用什么 BI 工具。
而是：
BI 层不应该承担重计算任务。
随着数据量持续增长：
把
展示层
转换层
实验层
拆开，是几乎必然趋势。
如果你正在扩展数据分析系统
可以先想清楚三个问题：
-
哪些逻辑必须在仓库算
-
哪些指标可以 BI 层算
-
是否需要探索隔离环境
很多时候，架构边界比工具选型更重要。
