事实表粒度：粒度的定义、为什么粒度是核心、粒度对查询性能的影响

好，咱们直接进入正题。事实表设计里，我敢说，粒度是决定成败的第一道关卡。很多新手甚至老手，在这个问题上栽过跟头。我自己就见过一个项目，因为粒度没定好，上线后报表跑不出来，最后整个ETL重做，那叫一个惨痛。

说白了，粒度就是事实表中一行数据所代表的事件的详细程度。你想想看，一行数据是代表一次「用户点击」，还是代表一次「用户会话」，还是代表一天的「页面汇总」？这就是粒度。

粒度的定义：一行数据到底代表什么？

我习惯用一个简单的公式来理解：

嗯，这里要注意。粒度不是凭空想出来的，它必须和业务过程一一对应。我记得有一次，业务方说「我要看每天的销售额」，结果他们给的源数据是「每笔订单的总金额」。如果我把粒度定为「每天」，那订单里的商品明细就全丢了。这就是粒度没对齐。

所以，定义粒度时，我建议你问自己三个问题：

1. 业务事件是什么？（下单？支付？退款？）
2. 这个事件的最小单位是什么？（一次点击？一个商品行？一张发票？）
3. 这个单位在源系统中是如何记录的？（有没有唯一标识？）

这三个问题答清楚了，粒度也就定了。

为什么粒度是核心？

你可能会问：「粒度不就是个定义吗，有那么重要？」

太重要了。我直接说结论：粒度决定了事实表的灵活性和可加性。

咱们来看一个对比：

特性	细粒度（原子粒度）	粗粒度（汇总粒度）
灵活性	高。可以按任意维度下钻、上卷	低。只能按预聚合的维度查询
可加性	强。所有度量值都可以跨维度累加	弱。部分度量可能不可加（如去重计数）
存储成本	高。数据量大	低。数据量小
查询性能	直接查询慢，但可以通过聚合表加速	直接查询快，但无法回答细粒度问题

你看，粒度越细，你能回答的问题就越多。比如，你存的是「每次点击」的粒度，那你可以算「点击率」「转化路径」「用户行为序列」。但如果你只存了「每天汇总」，那这些分析就全做不了。

我曾经在一个电商项目中，业务方一开始说「只要每天的总销售额就行」。我坚持做了订单行级别的粒度。结果三个月后，他们要做「每个商品在每次促销活动中的实时销量」，如果没有原子粒度，这个需求根本接不住。

粒度对查询性能的影响

好，咱们聊聊性能。很多人担心细粒度会导致查询变慢。这个担心没错，但要看你怎么用。

直接查一张百亿行的事实表，确实慢。但这不是粒度的问题，是查询设计的问题。我见过太多人，上来就SELECT * FROM fact_sales WHERE ...，那能不慢吗？

正确的做法是：

1. 利用维度表的过滤能力。先通过维度表缩小范围，再关联事实表。
2. 建立聚合表（Aggregate Table）。把常用的查询维度提前汇总好。
3. 使用分区和索引。按日期分区是最基本的操作。

举个例子，假设你有一个订单行粒度的事实表：

-- 错误的查询：直接扫全表
SELECT product_id, SUM(amount)
FROM fact_sales
WHERE order_date BETWEEN '2024-01-01' AND '2024-01-31'
GROUP BY product_id;

-- 正确的做法：先通过维度表过滤
SELECT p.product_id, SUM(s.amount)
FROM fact_sales s
JOIN dim_product p ON s.product_id = p.product_id
WHERE p.category = '电子产品'
  AND s.order_date BETWEEN '2024-01-01' AND '2024-01-31'
GROUP BY p.product_id;

你看，第二个查询利用了维度表的过滤能力，数据量一下子就降下来了。

另外，我建议你为常用的查询粒度建立聚合表。比如：

• 原子粒度：订单行（每天几亿行）
• 日聚合：按天+商品+渠道汇总（每天几百万行）
• 月聚合：按月+品类汇总（每月几万行）

查询时，根据用户的请求粒度，自动路由到最合适的表。这就是多维分析中的聚合导航。

粒度的选择：一张图说清楚

下面这张图，是我在培训时经常画的。它展示了粒度在整个事实表设计中的核心位置：

从这张图你可以看到，粒度一旦确定，就决定了事实表的类型（事务、周期快照、累积快照），也决定了后续的查询灵活性和性能表现。所以，我每次设计事实表，第一件事就是和业务方反复确认粒度，直到双方都明确「一行数据到底代表什么」。

总结一下

粒度不是技术细节，它是业务语义在数据模型中的映射。选对了，后面的聚合、查询、扩展都顺风顺水。选错了，那就是给自己挖坑。

我个人习惯，在项目初期花30%的时间在粒度讨论上。这个时间花得值。因为一旦事实表上线，再想改粒度，那代价就太大了。