原子指标的确定

       当我们逐渐清晰报表上指标的计算口径，明确了从事实明细表生成指标的计算逻辑，那么会发现这些指标其实是由业务过程，统计粒度，业务限定和一定的统计方式派生出来的。通过整理各个指标的派生方式，让我们引发这样的思考，是否存在一类最细粒度的指标，而所有指标都是由上述过程派生计算出来的，这就是原子指标引入的原因。

       由上面讨论分析，派生指标=统计粒度+业务限定+统计方式+业务过程，当我们确定了统计粒度和业务限定等维度字段，那么原子指标就是由业务过程+统计方式唯一确定了。比如说用户每日浏览书籍商品数这样一个指标，它的原子指标计算规则就是”select count(1) from default.dwd_goods_1d ”，业务限定就是商品大类书籍，统计粒度就是每天和user_id（更准确来讲前者成为统计周期）。这样，我们就可以对每一个业务过程梳理出原子指标和业务限定。

最细粒度DWS层的引入

       我们已经明确了ads层的维度和指标，也可以很清晰地整理出dwd明细层 （一般来说，每一个业务过程对应一张dwd明细事实表），那么唯一不明确同时又是数仓设计重中之重的dws汇总层就是关键所在。在原子指标梳理的过程中，我们发现这样一类最细粒度的指标是存在的，那么我们在此基础上，将dwd明细表按照一定的维度组合进行轻度汇总，是不是就可以用这张汇总表向上产出所有ads层报表呢，答案是肯定的。而这样一张dws轻度汇总表的优势不仅在于ads层计算的复用性，而且相比较dwd明细表来说，较大地节省了存储资源和计算资源。

       设计这样一张最细粒度dws层思路是很清晰的，在梳理每个指标派生过程中，由业务限定，统计粒度和统计方式中的字段等组成了计算派生指标的必要字段，也应该包含在dws表中。如果对业务过程下每一个派生指标做这样的归纳，那么我们就得到了这样一张基于该业务过程的dws汇总表。

       比如这样一个浏览域指标，APP首页每日浏览uv，所需的维度组合就是(user_id, page_num)，所需度量字段就是次数pv。最后，将浏览业务过程所有维度组合合并作为浏览dws表的汇总粒度，度量字段作为dws表的汇总指标。

       我们都知道，汇总的粒度越细，维度组合的基数越大，如果没有将dwd明细表的数据量汇总到一个预期范围内，这个工作的实际作用就不佳。所以我们有必要分析维度组合之间的关系，这里主要列出两种维度关系：

a. 父子维度：例如城市与省份，商品细分和商品分类，那么包含子维度的组合将父维度扩充进来也不会提高基数值。

b. 互斥维度组合： 业务分析中经常分析这几个维度（A,B,C），或者另外几个维度（D,E,F），而很少跨组合进行统计分析，那么将它们合并既没有业务分析价值，也可能带来基数值的膨胀，这种情况建设两张dws表更合理。不过这种情况一般很少，更常见的是（A,B,C）和（A,B,D）这样的关系。

       这里引入一个偏序概念，如果维度组合是维度组合的子集，即，则构成一个偏序关系。而如果，则构成了一个偏序链，而有限元素的偏序链必然存在一个极大元属于该集合。在梳理指标派生过程中，产生多个维度组合{}，我们按照偏序关系整理出n条偏序链，最后找到n个极大的维度组合，然后再根据上述两个原则进行合并或者拆分。

       所以应该根据业务分析本身和表基数缩减两方面进行考量，当然我们也有必要经常收集业务查询的sql来统计查询频繁的维度组合，不过这一般是OLAP引擎所要考虑的，我们这部分的工作是基于已知的ads报表对维度组合进行分析。

       关于dws最细粒度汇总表设计的讨论基本完成，下面内容是确定dws汇总表的业务范围。对于主题域下只有一个业务过程来讲，那么业务范围既是业务过程本身也是主题域范围；而对于包含多个业务过程的主题域来说，比如互动域，我们需要关联多张dws业务过程汇总表得到ads层，这样做显然比较耗时，那么把这些业务过程合成一张主题域下dws汇总表就是有必要的。当然，这里我们建议将业务过程相似的进行合并，不相似的合并在一起会引来业务上的歧义，例如关注商家行为不具有商品维度，和收藏、评论行为放在一起就会带来业务上的不合理。不过除此之外也没有别的缺点了，更多时候放在一起更方便我们的计算和分析。关于dws表汇总指标来说，每一个业务过程对应一个汇总指标，所以最后dws表包含了收藏pv，点赞pv等等。另外要注意一点的是，我们不建议dws表的业务范围跨主题域，这是对产出时效因素考量的，一般同一个主题域的dwd表产出时间比较接近。