如何优雅地设计DWS层？ | StartDT Tech Lab 17

写在前面

这是奇点云技术专栏「StartDT Tech Lab」的第17期。在这里，我们聚焦数据技术，分享方法论与实战…滑到文末，可以看到我们的往期内容。

如有希望我们分享讨论的话题，欢迎在文末留言哦！

本篇由奇点云资深数据开发工程师「云祁」带来：

作者：云祁

阅读时间：约9分钟

大家好，云祁又来了！今天聊一个老生常谈的话题，如何设计DWS层？

对于数仓的分层，想必大家都不陌生。基于OneData方法论的三层数仓划分：数据引入层（ODS，Operational Data Store）、数据公共层（CDM，Common Dimension Model）和数据应用层（ADS，Application Data Store）早就深入人心。

当然啦，涉及到每一层具体该怎么开发、建模，可能大家都有自己的理解。

但好在大家对数据建模重要性的认识都是一致的，如果我们把指标比作树上的果实，那么模型就好比是大树的躯干，想让果实结得好，必须让树干变得粗壮。

我们先来回想下，构建数据中台的初衷是什么——我们通常会遇到这些问题：

· 缺少可以复用的数据；

· 大家不得不使用原始数据进行清洗、加工和计算指标；

· 大量重复代码的开发对资源的消耗。

问题的根源就在于数据模型的无法复用，以及数据开发都是烟囱式的。所以要解决这个问题，就要搞清楚健壮的数据模型该如何设计。

1. 常见的数仓分层设计思路

下图是数仓分层的逻辑架构图，我们回忆一下数据模型的分层设计：

图源：云祁

1.1

数据引入层

数据引入层（ODS，Operational Data Store），又称数据基础层。我们将原始数据几乎无处理地存放在数据仓库系统中，结构上与源系统基本保持一致，是数据仓库的数据准备区。这一层的主要职责是将基础数据同步、存储。

1.2

数据公共层

在数据公共层（CDM，Common Dimension Model），存放明细事实数据、维表数据及公共指标汇总数据。

其中，明细事实数据、维表数据一般根据ODS层数据加工生成。公共指标汇总数据一般根据维表数据和明细事实数据加工生成。CDM层又细分为维度层（DIM）、明细数据层（DWD）和汇总数据层（DWS），采用维度模型方法作为理论基础，可以定义维度模型主键与事实模型中外键关系，减少数据冗余，也提高明细数据表的易用性。在汇总数据层同样可以关联复用统计粒度中的维度，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

1）维度层（DIM，Dimension）

以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。为了避免在维度模型中冗余关联维度的属性，基于雪花模型构建维度表。

2）明细数据层（DWD，Data Warehouse Detail）

以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可将某些重要属性字段做适当冗余，也即宽表化处理。

3）汇总数据层（DWS，Data Warehouse Summary）

以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。

1.3

数据应用层

数据应用层（ADS，Application Data Store）存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。

2. 为什么DWS层很重要？

通常，大家都会有这样的疑问：明明可以直接从DWD层取数，为什么要多此一举建立DWS的汇总逻辑表呢？

其实，如果业务场景不复杂，那样做是没有问题的。可一旦面对复杂的业务场景，那这种做法无疑是混乱的根源所在。前面提到的烟囱式开发、计算资源的浪费等等情况，正是这样产生的。

举个例子，我们需要的是从数据明细层中做一个初步的汇总，抽象出来一些通用的维度：时间、用户ID、IP等，并根据这些维度做一些统计，比如用户每个时间段在不同登录IP购买的商品数等。

这里做一层轻度的汇总会让计算更加高效，在此基础上如果计算仅7天、30天、90天的行为的话会快很多。我们希望80%的业务都能通过DWS层计算，而不是ODS或者DWD层。

3. DWS层设计原则

3.1

聚集原则

聚集是指针对原始明细粒度的数据进行汇总。DWS汇总数据层是面向分析对象的主题聚集建模，以零售的场景为例，我们最终的分析目标为：最近一天某个类目（例如，厨具）商品在各省的销售总额、该类目销售额Top10的商品名称、各省用户购买力分布。

因此，我们可以从最终交易成功的商品、类目、买家等角度对最近一天的数据进行汇总。

数据聚集的注意事项如下：

1）聚集是不跨越事实的。聚集是针对原始星形模型进行的汇总。为获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨越事实的，所以原子指标只能基于一张事实表定义，但是支持原子指标组合为衍生原子指标。

2）聚集会带来查询性能的提升，但聚集也会增加ETL维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。

3.2

数据公用性原则

进行DWS层设计时还需遵循数据公用性原则。

数据公用性需要考虑汇总的聚集是否可以提供给第三方使用。我们可以思考基于某个维度的聚集是否经常用于数据分析中，如果答案是肯定的，就有必要把明细数据经过汇总沉淀到聚集表中，简单来说就是：

· 主题

· 宽表

· 轻度汇总

4. DWS层设计流程

以电商零售的场景为例，我们已经基于ODS层的订单表、用户表、商品表、优惠券表等，经过ETL完成了DWD层的建模，一般是采用星型模型。

这里严格按照「业务过程→声明粒度→确认维度→确认事实」完成建模，过程如下：

图源：知乎

接下来，便是到了DWS层设计的环节。按照我们上面的设计思路，通过从维度表去看事实表，便可得出每天的宽表。

这样既可以统计各个主题对象的当天行为，服务于ADS层的主题宽表以及一些业务的明细数据，也可以应对一些特殊的需求，例如了解购买行为、统计商品复购率等。

图源：知乎

通过外键获取相关的度量值，我们整合多个DWD的明细事实表度量值来构成新表。

在这里，我们还是要遵循上文提到的设计原则，在设计上尽量体现出公共性、使用简单，且要让用户容易理解。

5. 什么是“完美”的DWS层？

在数据中台实际实施落地的过程中，团队不仅要建设公共数据层，形成数据中台，也承担着新需求的压力。

往往我们要先满足需求（活下去），再研发公共数据层（构建美好未来）。在满足业务需求的过程中，再根据需求不断对模型进行迭代和优化，随着时间的推移，越来越多的业务需求可以通过DWS层的数据完成。

这一过程中，完善度是很好的考核标准，主要看DWS层汇总的数据能满足多少的查询需求。如果汇总数据无法满足需求，使用数据的人就必须用明细的数据，甚至是ODS层的原始数据。

DWS/ADS层的完善度越高，说明数据的上层建设越完善，而从使用者的角度来说，查询快、取数易、用得爽，那才是硬道理。