如何检查事实表的粒度？添加列后如何判断其粒度是否变化？

嘿，这个问题绝对是数据仓库设计里的核心痛点——事实表的粒度就像整个模型的「地基」，搞错了后续的分析报表、指标计算全都会跑偏。我来分享下我日常工作里的实操方法：

• 先锚定业务定义：别上来就看数据，先找业务方聊清楚——这个事实表是用来记录什么最小业务单元的？比如订单事实表，是记录「每一笔订单整体」还是「每一笔订单里的单个商品行」？前者粒度是订单头，后者是订单行，这完全是两回事。
• 看主键/唯一约束：事实表的复合主键（比如order_id + product_id）通常就是粒度的直接体现——每一个唯一的主键组合对应一行，这行就是最细的业务单元。如果没有显式主键，就找能唯一确定一行的列组合，这就是隐含的粒度键。
• 核对度量值的粒度：比如同样是「销售额」，如果是订单行粒度，那每一行的销售额是单个商品的金额；如果是订单头粒度，就是整个订单的总金额。拿这个和业务预期对比，就能快速验证粒度是否正确。
• 做重复行测试：跑个简单的SQL查询就能验证：

  SELECT grain_column1, grain_column2, COUNT(*)
  FROM your_fact_table
  GROUP BY grain_column1, grain_column2
  HAVING COUNT(*) > 1;
  

  如果返回结果不为空，要么是数据重复了，要么是你认定的粒度不是真正的最细单元——得重新梳理业务逻辑。

核心就一个：新增的列是否把原来的「最小业务单元」拆得更细了？换句话说，原来能唯一确定一行的列组合，现在还能不能做到？

我通常会这么排查：

• 先明确原粒度的核心：比如原来的事实表粒度是「每个用户每天的APP访问次数」，唯一键是user_id + date，每一行代表用户某天的访问统计。
• 判断新增列的性质：
  • 如果新增的是原有粒度的属性列：比如用户的性别、日期对应的星期几，这些只是给原有行加了额外描述，user_id + date依然能唯一确定一行——粒度没变化。
  • 如果新增的是拆分原有粒度的维度列：比如加了hour（小时）列，原来的一行（用户+日期）现在可能拆成24行（用户+日期+小时），这时候粒度就从「天」变成「小时」了；再比如订单行粒度的表加了batch_no（批次号），如果同一个订单行对应多个批次，那原来的order_id + product_id就不能唯一确定行了，粒度肯定变了。
• 用SQL验证：拿原来的粒度列组合分组，看新增列是否有多个不同值：

  SELECT original_grain_col1, original_grain_col2, COUNT(DISTINCT new_column)
  FROM your_fact_table
  GROUP BY original_grain_col1, original_grain_col2
  HAVING COUNT(DISTINCT new_column) > 1;
  

  如果有结果返回，说明新增列把原来的粒度单元拆分成了更小的单元——粒度已经发生变化。
• 结合度量值验证：如果原来的度量是「日访问次数」，加了小时列后，度量变成「小时访问次数」，每一行的数值是小时级的，总和等于原来的日级数值，这也能直观说明粒度变细了。

内容的提问来源于stack exchange，提问作者Sly