写点什么

如何优雅的设计 DWS 层?

用户头像
云祁
关注
发布于: 15 小时前
如何优雅的设计DWS层?

对于数仓的分层,大家最耳熟能详的就是基于 OneData 方法论的三层数仓划分,分别是:数据引入层(ODS,Operational Data Store)、数据公共层(CDM,Common Dimenions Model)和数据应用层(ADS,Application Data Store)。​


当然,涉及到每一层具体该怎么建模,可能大家都有自己的理解。数据建模无疑是重中之重,如果我们把指标比作树上的果实,那么模型就好比是大树的躯干,想让果实结得好,必须让树干变得粗壮。​


我们先来回想下,构建数据中台的初衷是什么:


  • 没有可以复用的数据,

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


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

常见的数仓分层设计思路

下图是数仓分层的逻辑架构图,大家不妨回忆一下数据模型的分层设计:​



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

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

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

  • 明细数据层(DWD,Data Warehouse Detail):以业务过程作为建模驱动,基于每个具体的业务过程特点,构建最细粒度的明细事实表。可将某些重要属性字段做适当冗余,也即宽表化处理。

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

  • 数据应用层(ADS,Application Data Store):存放数据产品个性化的统计指标数据,根据 CDM 层与 ODS 层加工生成。

DWS 层很重要?

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


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


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


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

应该遵循的设计原则

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


因此,我们可以以最终交易成功的商品、类目、买家等角度对最近一天的数据进行汇总。数据聚集的注意事项如下:​


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

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


此外,进行 DWS 层设计时还需遵循数据公用性原则。数据公用性需要考虑汇总的聚集是否可以提供给第三方使用。我们可以思考基于某个维度的聚集是否经常用于数据分析中,如果答案是肯定的,就有必要把明细数据经过汇总沉淀到聚集表中。​


简单的说就是:


  • 主题

  • 宽表

  • 轻度汇总

图解 DWS 层设计流程

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


这里严格按照:业务过程→声明粒度→确认维度→确认事实 完成建模,过程如下:​



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


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



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


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

思考:如何设计出完美的 DWS 层?

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


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


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


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

发布于: 15 小时前阅读数: 9
用户头像

云祁

关注

公众号:云祁QI 2020.06.23 加入

我是「云祁」,一枚热爱技术、会写诗的大数据开发猿,专注数据中台和 Hadoop / Spark / Flink 等大数据技术,欢迎一起交流学习。生命不是要超越别人,而是要超越自己!加油 (ง •_•)ง

评论

发布
暂无评论
如何优雅的设计DWS层?