对于数据仓库的分层，仿佛大家都有一个独特的意识。但波及到每一层该如何去建模，可能每个人都有本人的了解。数据建模，毫无疑问是数仓建设的重中之重，而后，在理论的开发过程中，会把大量的工夫都投入到了需要开发，往往会疏忽数据建模(尤其是 DWS 层的建模)，长此以往，数据模型变的越来越芜杂，指标口径无奈对立，造成的后果就是：尽管表很多，然而却很难取数。本文次要介绍 DWS 层建模的根本方法论，心愿对你有所帮忙。
公众号【大数据技术与数仓】首发，关注支付材料
数仓为什么要分层
正当的数据仓库分层一方面可能升高耦合性，进步重用性，可读性可维护性，另一方面也能进步运算的效率，影响到数据需要迭代的速度，近而影响到产品决策的及时性。建设数据分层能够提炼公共层，防止烟囱式开发，可见一个适合且正当的数仓分层是极其重要。
通用分层设计思路
- ODS: 操作型数据(Operational Data Store)，指构造与源零碎根本保持一致的增量或者全量数据。作为 DW 数据的一个数据筹备区，同时又承当根底数据记录历史变动，之所以保留原始数据和线上原始数据保持一致，不便前期数据核查须要。
- CDM：通用数据模型，又称为数据中间层(Common Data Model)，蕴含 DWD、DWS、DIM 层。
- DWD：数据仓库明细层数据(Data Warehouse Detail)。对 ODS 层数据进行荡涤转化，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。能够联合企业的数据应用特点，基于维度建模思维，将明细事实表的某些重要属性字段做适当冗余，也即宽表化解决，构建明细宽表。
- DWS：数据仓库汇总层数据(Data Warehouse Summary)，基于指标需要，构建初步汇总事实表，个别是宽表。基于下层的利用和产品的指标需要，构建公共粒度的汇总指标表。以宽表化伎俩物理化模型，构建命名标准、口径统一的统计指标，为下层提供公共指标。
- DIM：建设统一数据分析维表，能够升高数据计算口径不对立的危险，同时能够不便进行穿插探查。以维度作为建模驱动，基于每个维度的业务含意，通过增加维度属性、关联维度等定义计算逻辑，实现属性定义的过程并建设统一的数据分析维表。
- ADS：面向利用的数据服务层(Application Data Service)。整合汇总成剖析某一个主题域的服务数据，面向应用逻辑的数据加工。该层次要存放数据产品个性化的统计指标数据，这一层的数据间接对接数据的消费者，是产品、经营等角色能够间接感知了解的一层，大多数这一层的表都能够间接在 BI 上通过图表的模式间接透出。
没有 DWS 层不行吗
当咱们在做数据需要时，会不会有这样的疑难：我间接能从 DWD 层很不便的取出想要的数据，为什么还要多此一举建设 DWS 层的汇总表呢 ？那是不是意味着能够不必建设 DWS 层的表呢，答案是： 能够的。然而这有一个前提，就是业务场景不简单。从短期来看能够疾速满足数据需要的开发，然而长期来看，会存在如下的问题：
- 对于简单的业务场景而言，会呈现很多跨域、跨事实的穿插探查，如果没有积淀出 DWS 层的指标进行统一口径的收口，那么雷同的指标会呈现不同的口径和命名，其结果就是取数变得越来越不不便，而且容易造成业务狐疑数据是否正确的难堪场面。
- 公共指标没有对立计算，当每次须要雷同的指标时，则须要从新计算一遍取数逻辑，不仅效率不高(须要关联表，计算指标)，而且会造成计算资源节约。
DWS 层设计
以剖析的主题对象作为建模驱动，基于下层的利用和产品的指标需要，构建公共粒度的汇总指标表。以宽表化伎俩物理化模型，构建命名标准、口径统一的统计指标，为下层提供公共指标，建设汇总宽表。如：造成日，周，月粒度汇总明细，或者基于某一个维度，如商品类目粒度的汇总日表，统计便于下一步报表数据结构的组织。
DWS 层的根本特点
- DWS 层是面向剖析维度进行设计的，剖析维度通常是业务常常须要的看数据的角度。
- DWS 层的表服务于数据报表和数据产品的指标需要
- ADS 层的指标数据会存在穿插探查的状况，所以 DWS 层的指标要放弃命名和口径统一，防止 ADS 层的指标数据凌乱
- DWS 是公共汇总层，提供不同维度的统计指标，指标的口径要保持一致，并且要提供具体的形容
- 以宽表的模式进行设计，比方雷同粒度的统计指标能够放在一起，防止创立太多的表
- 公共汇总层的一个表通常会对应一个派生指标
- DWS 存储派生指标(统计周期 + 修饰词 + 统计粒度 + 原子指标)，原子指标存储在 DWD 层的事实表中
原子指标与派生指标
所谓 原子指标，即是业务过程的度量，就是明细事实表中的度量值。比方订单表，那么某个订单对应的订单金额就是一个原子指标，这个指标是随同着订单的业务过程而产生的。
所谓 派生指标 ，即由 统计周期 + 修饰词 + 统计粒度 + 原子指标 组合加工而成的指标
其中，统计周期：指的是想要统计的工夫周期，比方天、周、月
修饰词 ：指的是业务的束缚， 通常呈现在 SQL 的 where 条件中，比方订单的下单渠道等等
统计粒度 ：指的是维度组合， 通常呈现在 SQL 的 group by 中，比方统计商品一级类目对应的销售额，那一级类目就是统计粒度
DWS 层的设计准则
对于汇总层的表建模应遵循以下的准则：
- 数据专用性 比方，汇总的汇集表是否与别人专用？基于某个维度的汇集是否是数据分析或者报表中常常应用的？如果满足这些状况，咱们就有必要把明细数据积淀到汇总表中。
- 不跨数据域 数据域是在较高层次上对数据进行分类汇集的形象，如交易对立划到交易域下，商品的新增、批改放到商品域下。
- 辨别统计周期 表命名上要能阐明数据的统计周期，如_1d 示意最近 1 天，_td 截止到当天，_nd 示意最近 N 天。
- 防止多个层级的数据 应该防止将不同层级的数据放在一起，比方，如果存在 7 天和 30 天的事实，咱们能够抉择用两列寄存 7 天和 30 天的事实，然而须要在列名和字段正文上阐明分明。同时咱们也能够应用两张表别离存储不同统计周期的数据加以辨别。
- 汇集是不逾越事实的 汇集是针对原始星型模型进行的汇总，为了获取和查问原始模型统一的后果，汇集的维度和度量必须与原始模型保持一致，因而汇集是不跨事实的。横向钻取 (穿插探查) 是针对多个事实基于一致性维度进行的剖析，很多时候采纳交融事实表，事后寄存横向钻取的后果，从而进步查问性能。因而交融事实表是一种导出模式而不是汇集。
DWS 层设计步骤
- 首先，确定汇集维度，即确定统计粒度，比方商品粒度
- 而后，确定统计周期，比方天
- 最初，确定汇集事实，即派生指标
CREATE TABLE IF NOT EXISTS dws_asale_trd_itm_ord_1d
(
item_id BIGINT COMMENT ‘ 商品 ID’,
item_title STRING COMMENT ‘ 商品名称 ’,
cate_id BIGINT COMMENT ‘ 商品类目 ID’,
cate_name STRING COMMENT ‘ 商品类目名称 ’,
mord_prov STRING COMMENT ‘ 收货人省份 ’,
confirm_paid_amt_sum_1d DOUBLE COMMENT ‘ 最近一天订单曾经确认收货的金额总和 ’
)
COMMENT ‘ 商品粒度交易最近一天汇总事实表 ’
PARTITIONED BY (ds STRING COMMENT ‘ 分区字段 YYYYMMDD’)
;
对于 DWS 层建设的一些问题
为什么一张 DWS 表通常只会对应一个派生指标？
在设计 DWS 表的时候，很多人会把所有能够聚合的维度进行 cube，这样就失去了很多个派生指标，而这些派生指标放在同一张表中无疑会减少这张表的应用难度，比方在理论的取数时，往往只关怀某个统计粒度的指标。实际上 cube 的数据尽量放在 ADS 层，这样在开发数据接口或者应用层取数时都会比拟不便。所以在设计 DWS 层时，该当遵循前文提到的一些准则，一言以蔽之，就是设计尽量体现出公共性、应用简略并且用户很容易了解。
怎么设计出完满的 DWS 层表？
数仓建设是一个一直迭代的过程，数据建模同样是一个一直迭代的过程。同时，业务是一直变动的，建模人员对业务的了解也是变动的，这些也就注定了建模是一个迭代过程。尽管存在这些变动，但咱们在数据建模的时候同样要遵循肯定的标准，切不可得心应手。
如何评估 DWS 层建设的好坏？
因为数仓的建设是与业务非亲非故的，数仓建设的方法论仅仅只是指引咱们构建数仓的一个方向，在理论的落地执行过程中会存在各种各样的问题，且不可被这些实践所禁锢。简略一句话就是：适合就好。所以，评估模型的好坏与否，更多的是从使用者的角度登程，比方简略、易于取数、表的数量恰好。
总结
本文次要介绍了数据仓库中 DWS 建设的基本思路，包含 DWS 层的特点、设计准则以及设计步骤，并对 DWS 层建设存在的一些问题进行了论述。当然，这些只是 DWS 层建模的一些方法论，智者见智仁者见仁，在理论的数据建模过程中能够参考这些方法论，但也要留神与具体的业务场景相结合，数据建模是建设在本人对业务的了解根底之上的，切不可一味地照搬，要灵活运用。另外，不要奢求建设完满的数据模型，该当谋求简略、不便、易用。换句话说，建模没有对错之分，适合就好。