该如何涉及数仓的DWS层

关于数据仓库的分层，彷佛你们都有一个共同的认识。但涉及到每一层该如何去建模，可能每一个人都有本身的理解。数据建模，毫无疑问是数仓建设的重中之重，而后，在实际的开发过程当中，会把大量的时间都投入到了需求开发，每每会忽略数据建模(尤为是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层建模的一些方法论，智者见智仁者见仁，在实际的数据建模过程当中能够参考这些方法论，但也要注意与具体的业务场景相结合，数据建模是创建在本身对业务的理解基础之上的，切不可一味地照搬，要灵活运用。另外，不要苛求创建完美的数据模型，应当追求简单、方便、易用。换句话说，建模没有对错之分，合适就好。