关于数据仓库的分层,彷佛你们都有一个共同的认识。但涉及到每一层该如何去建模,可能每一个人都有本身的理解。数据建模,毫无疑问是数仓建设的重中之重,而后,在实际的开发过程当中,会把大量的时间都投入到了需求开发,每每会忽略数据建模(尤为是DWS层的建模),久而久之,数据模型变的愈来愈杂乱,指标口径没法统一,形成的结果就是:虽然表不少,可是却很难取数。本文主要介绍DWS层建模的基本方法论,但愿对你有所帮助。跨域
公众号【大数据技术与数仓】首发,关注领取资料
合理的数据仓库分层一方面可以下降耦合性,提升重用性,可读性可维护性,另外一方面也能提升运算的效率,影响到数据需求迭代的速度,近而影响到产品决策的及时性。创建数据分层能够提炼公共层,避免烟囱式开发,可见一个合适且合理的数仓分层是极其重要。数据结构
当咱们在作数据需求时,会不会有这样的疑问:我直接能从DWD层很方便的取出想要的数据,为何还要画蛇添足创建DWS层的汇总表呢?那是否是意味着能够不用创建DWS层的表呢,答案是:能够的。可是这有一个前提,就是业务场景不复杂。从短时间来看能够快速知足数据需求的开发,可是长期来看,会存在以下的问题:性能
以分析的主题对象做为建模驱动,基于上层的应用和产品的指标需求,构建公共粒度的汇总指标表。以宽表化手段物理化模型,构建命名规范、口径一致的统计指标,为上层提供公共指标,创建汇总宽表。如:造成日,周,月粒度汇总明细,或者基于某一个维度,如商品类目粒度的汇总日表,统计便于下一步报表数据结构的组织。大数据
原子指标与派生指标所谓原子指标,便是业务过程的度量,就是明细事实表中的度量值。好比订单表,那么某个订单对应的订单金额就是一个原子指标,这个指标是伴随着订单的业务过程而产生的。设计
所谓派生指标,即由统计周期+修饰词+统计粒度+原子指标组合加工而成的指标对象
其中,统计周期:指的是想要统计的时间周期,好比天、周、月接口
修饰词:指的是业务的约束,一般出如今SQL的where条件中,好比订单的下单渠道等等资源
统计粒度:指的是维度组合,一般出如今SQL的group by中,好比统计商品一级类目对应的销售额,那一级类目就是统计粒度开发
关于汇总层的表建模应遵循如下的原则:数据分析
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表的时候,不少人会把全部能够聚合的维度进行cube,这样就获得了不少个派生指标,而这些派生指标放在同一张表中无疑会增长这张表的使用难度,好比在实际的取数时,每每只关心某个统计粒度的指标。实际上cube的数据尽可能放在ADS层,这样在开发数据接口或者应用层取数时都会比较方便。因此在设计DWS层时,应当遵循前文提到的一些原则,一言以蔽之,就是设计尽可能体现出公共性、使用简单而且用户很容易理解。
数仓建设是一个不断迭代的过程,数据建模一样是一个不断迭代的过程。同时,业务是不断变化的,建模人员对业务的理解也是变化的,这些也就注定了建模是一个迭代过程。虽然存在这些变化,但咱们在数据建模的时候一样要遵循必定的规范,切不可为所欲为。
因为数仓的建设是与业务息息相关的,数仓建设的方法论仅仅只是指引咱们构建数仓的一个方向,在实际的落地执行过程当中会存在各类各样的问题,且不可被这些理论所禁锢。简单一句话就是:合适就好。因此,评价模型的好坏与否,更多的是从使用者的角度出发,好比简单、易于取数、表的数量刚好。
本文主要介绍了数据仓库中DWS建设的基本思路,包括DWS层的特色、设计原则以及设计步骤,并对DWS层建设存在的一些问题进行了阐述。固然,这些只是DWS层建模的一些方法论,智者见智仁者见仁,在实际的数据建模过程当中能够参考这些方法论,但也要注意与具体的业务场景相结合,数据建模是创建在本身对业务的理解基础之上的,切不可一味地照搬,要灵活运用。另外,不要苛求创建完美的数据模型,应当追求简单、方便、易用。换句话说,建模没有对错之分,合适就好。