BI报表中的汇总层设计：理解事实表与维度表的聚合.docxVIP

BI报表中的汇总层设计：理解事实表与维度表的聚合

为什么你的报表总是慢半拍？

说实话，很多刚入行做数据开发或者分析师的朋友，都有过这样的崩溃时刻：业务方丢过来一堆Excel，让你算“同比增速”、“占比”、“累计差值”，你吭哧吭哧写了一堆SQL，跑出来的结果要么不对，要么慢得像蜗牛。

这时候，你大概率犯了一个错误：试图在应用层或报表层做聚合，而不是在数据模型层设计好汇总逻辑。

今天我们就聊聊BI报表里那个最基础、却也是最容易被忽视的环节——事实表与维度表的聚合设计。别觉得这是老生常谈，很多看似简单的“汇总”需求，背后藏着的坑比你想象的多得多。

事实表与维度表：不是简单的Join

在谈聚合之前，我得先纠正一个常见的认知偏差。很多人觉得，事实表和维度表就是两张表连起来查嘛，LEFTJOIN搞定了。

没错，JOIN是手段，但聚合的核心在于理解“粒度”。

事实表的粒度，决定了你能算出什么。如果你的事实表里存的是“订单明细行”，那你直接SUM销售额，没问题。但如果你想算“客户维度的复购率”，你就需要明白，这个指标的计算分母是“去重后的客户数”，而分子是“购买次数大于1的客户数”。

这里就涉及到一个关键概念：不同粒度的事实表需要不同的聚合路径。

举个例子，假设你有一张销售事实表（粒度：行），一张库存事实表（粒度：天）。如果你直接把它们JOIN起来做加权平均，会出现严重的数据膨胀问题。因为一个