select distinct count(fact_login.user_id) from fact_login

left join dim_date on date.date_key = fact_login.login_date

group by dim_date.date_key

从衍生指标这里，就能发现问题了。你会发现，group by 后的结果，是按照每天进行去重的。

最终的结果，只能是统计每天范围内的累积登录人数。用户的期望是，统计某个时间区间内的累积登录人数，这个需求维度模型产生的指标没法满足。如果事实表的真实数据如下：

基于维度模型，系统可以生成这样的汇总表：

但系统无法生成如下汇总表：

需求只能搞定一般，这可怎么交差？

四、粒度是搞清问题的关键

刚开始，我很疑惑，想了各种办法也没办法解决。后来才意识到，问题根源其实是粒度。

让我们回归到真实场景里：登录成功，这个事件发生在一瞬间。常见的时间计量单位有年、月、天、小时、分钟、秒、毫秒、微秒等等。而系统记录某个操作，常见的记录粒度是秒。

比如， 2021 年 6 月 27 号 14 : 00 : 00，小明登录了系统。如果按照秒去统计登录人数，则完全不用考虑去重，因为小明在这个粒度的计量单位里，只能登录一次。但秒级别的统计粒度，太细了。

业务方希望从更加宏观的角度去统计和分析，例子里面，是以天为单位去统计。

那这个时候，统计就要升粒度了，并且，要去重。此时，系统也是可以按照天的粒度进行去重统计的。那问题又是啥呢？再看看实际需求时，统计的时间区间是不固定的。

即，业务方可能今天想统计 1 号到 2 号的登录人数，明天想统计 3 号到 5 号的登录人数。这个时候，就没法玩了，为什么呢？

粒度不固定：1-2号，间隔时间是1天，3-5号，间隔时间则是2天。维度建模中，声明粒度就是要把粒度的大小定下来。

不管是什么维度，都要提前把粒度定下来，这样才能实现累计去重。

从技术实现的角度来看，如果查询的粒度，是一个变量，而不是一个固定值，没法提前计算，只能临时用明细表算，这就叫做即系查询。

所以，这个需求中，维度建模只能解决前面部分的需求：按照天去重统计每天登录人数。而变化区间的去重统计，只能即席查询了。

五、最后，说点学习经验

维度建模工具箱这本书，一再强调粒度的重要性，大概率就是因为粒度这玩意，太抽象，不好理解。

当初，我就在这上面理解出了差错，陷在维度建模的漩涡里。

本人愚笨，看书好久，都没明白粒度的真正含义，被真实业务需求痛扁一顿后，我才体会到粒度的真正含义。

作为一个新人，接触到新的方法或者工具，我们是兴奋的。

与此同时，我们也要谨防 “捡到锤子，看什么都像钉子”，没有能解决所有问题的方法和工具，特定场景，选用特定的工具。死磕核心概念，结合实际场景去理解，搞懂了，很多问题就通了~