• 阅读: 535 回复: 0
    大数据技术与数仓

    数据仓库汇总层(DWS)建模方法与步骤

    楼主 发表于 2021-10-25 15:22:58

    关于数据仓库的分层,似乎大家都有一个共同的认识。但涉及到每一层该如何去建模,可能每个人都有自己的理解。

    数据建模,毫无疑问是数仓建设的重中之重,然后,在实际的开发过程中,会把大量的时间都投入到了需求开发,往往会忽略数据建模,尤其是DWS层的建模。长此以往,数据模型变的越来越杂乱,指标口径无法统一,造成的结果就是:虽然表很多,但是却很难取数。

    本文主要介绍DWS层建模的基本方法论,希望对你有所帮助。

    1、数仓为什么要分层?

    合理的数据仓库分层一方面能够降低耦合性,提高重用性,可读性可维护性,另一方面也能提高运算的效率,影响到数据需求迭代的速度,进而影响到产品决策的及时性。

    建立数据分层可以提炼公共层,避免烟囱式开发,可见一个合适且合理的数仓分层是极其重要。

    2、通用分层设计思路

    • 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上通过图表的形式直接透出。

    3、没有DWS层不行吗?

    当我们在做数据需求时,会不会有这样的疑问:我直接能从DWD层很方便的取出想要的数据,为什么还要多此一举建立DWS层的汇总表呢?那是不是意味着可以不用建立DWS层的表呢,答案是:可以的。

    但是这有一个前提,就是业务场景不复杂。从短期来看可以快速满足数据需求的开发,但是长期来看,会存在如下的问题:

    • 对于复杂的业务场景而言,会出现很多跨域、跨事实的交叉探查,如果没有沉淀出DWS层的指标进行统一口径的收口,那么相同的指标会出现不同的口径和命名,其后果就是取数变得越来越不方便,而且容易造成业务怀疑数据是否正确的尴尬局面。

    • 公共指标没有统一计算,当每次需要相同的指标时,则需要重新计算一遍取数逻辑,不仅效率不高(需要关联表,计算指标),而且会造成计算资源浪费。

    4、DWS层设计

    以分析的主题对象作为建模驱动,基于上层的应用和产品的指标需求,构建公共粒度的汇总指标表。

    以宽表化手段物理化模型,构建命名规范、口径一致的统计指标,为上层提供公共指标,建立汇总宽表。

    如:形成日,周,月粒度汇总明细,或者基于某一个维度,如商品类目粒度的汇总日表,统计便于下一步报表数据结构的组织。

    5、DWS层的基本特点

    • DWS层是面向分析维度进行设计的,分析维度通常是业务经常需要的看数据的角度。

    • DWS层的表服务于数据报表和数据产品的指标需求。

    • ADS层的指标数据会存在交叉探查的情况,所以DWS层的指标要保持命名和口径一致,避免ADS层的指标数据混乱。

    • DWS是公共汇总层,提供不同维度的统计指标,指标的口径要保持一致,并且要提供详细的描述。

    • 以宽表的形式进行设计,比如相同粒度的统计指标可以放在一起,避免创建太多的表。

    • 公共汇总层的一个表通常会对应一个派生指标。

    • DWS存储派生指标(统计周期+修饰词+统计粒度+原子指标),原子指标存储在DWD层的事实表中。

    原子指标与派生指标:

    所谓原子指标,即是业务过程的度量,就是明细事实表中的度量值。比如订单表,那么某个订单对应的订单金额就是一个原子指标,这个指标是伴随着订单的业务过程而产生的。

    所谓派生指标,即由统计周期+修饰词+统计粒度+原子指标组合加工而成的指标。

    其中,统计周期:指的是想要统计的时间周期,比如天、周、月。

    修饰词:指的是业务的约束,通常出现在SQL的where条件中,比如订单的下单渠道等等。

    统计粒度:指的是维度组合,通常出现在SQL的group by中,比如统计商品一级类目对应的销售额,那一级类目就是统计粒度。

    6、DWS层的设计原则

    关于汇总层的表建模应遵循以下的原则:

    • 数据公用性比如,汇总的聚集表能否与他人公用?基于某个维度的聚集是否是数据分析或者报表中经常使用的?如果满足这些情况,我们就有必要把明细数据沉淀到汇总表中。

    • 不跨数据域数据域是在较高层次上对数据进行分类聚集的抽象,如交易统一划到交易域下,商品的新增、修改放到商品域下。

    • 区分统计周期表命名上要能说明数据的统计周期,如_1d 表示最近1天,_td 截止到当天,_nd 表示最近N天。

    • 避免多个层级的数据应该避免将不同层级的数据放在一起,比如,如果存在7天和30天的事实,我们可以选择用两列存放7天和30天的事实,但是需要在列名和字段注释上说明清楚。同时我们也可以使用两张表分别存储不同统计周期的数据加以区分。

    • 聚集是不跨越事实的聚集是针对原始星型模型进行的汇总,为了获取和查询原始模型一致的结果,聚集的维度和度量必须与原始模型保持一致,因此聚集是不跨事实的。横向钻取(交叉探查)是针对多个事实基于一致性维度进行的分析,很多时候采用融合事实表,预先存放横向钻取的结果,从而提高查询性能。因此融合事实表是一种导出模式而不是聚集。

    7、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层建设的一些问题:

    7、为什么一张DWS表通常只会对应一个派生指标?

    在设计DWS表的时候,很多人会把所有可以聚合的维度进行cube,这样就得到了很多个派生指标,而这些派生指标放在同一张表中无疑会增加这张表的使用难度,比如在实际的取数时,往往只关心某个统计粒度的指标。

    实际上cube的数据尽量放在ADS层,这样在开发数据接口或者应用层取数时都会比较方便。所以在设计DWS层时,应当遵循前文提到的一些原则,一言以蔽之,就是设计尽量体现出公共性、使用简单并且用户很容易理解。

    8、怎么设计出完美的DWS层表?

    数仓建设是一个不断迭代的过程,数据建模同样是一个不断迭代的过程。同时,业务是不断变化的,建模人员对业务的理解也是变化的,这些也就注定了建模是一个迭代过程。

    虽然存在这些变化,但我们在数据建模的时候同样要遵循一定的规范,切不可随心所欲。

    9、如何评价DWS层建设的好坏?

    由于数仓的建设是与业务息息相关的,数仓建设的方法论仅仅只是指引我们构建数仓的一个方向,在实际的落地执行过程中会存在各种各样的问题,且不可被这些理论所禁锢。

    简单一句话就是:合适就好。所以,评价模型的好坏与否,更多的是从使用者的角度出发,比如简单、易于取数、表的数量恰好。

    10、总结

    本文主要介绍了数据仓库中DWS建设的基本思路,包括DWS层的特点、设计原则以及设计步骤,并对DWS层建设存在的一些问题进行了阐述。

    当然,这些只是DWS层建模的一些方法论,智者见智仁者见仁,在实际的数据建模过程中可以参考这些方法论,但也要注意与具体的业务场景相结合,数据建模是建立在自己对业务的理解基础之上的,切不可一味地照搬,要灵活运用。

    另外,不要苛求建立完美的数据模型,应当追求简单、方便、易用。

     

    换句话说,建模没有对错之分,合适就好。

    本文内容转载自“数据学堂”(ID:data_school)

热门文章

数据中台系列(一):你的企业真的需要「数据中台」吗?

辨析BI、数据仓库、数据湖和数据中台内涵及差异点(建议收藏)

数据中台案例 | 数字化为零售行业创造新可能

数据中台案例 | 一呼百应:激活 670 万企业用户数据,赋能智慧供应链

最新文章

人民日报《大小单双上岸技巧赢钱规律》百度热议

人民日报《大小单双上岸技巧赢钱规律》百度热议

「央视新闻」快三彩平台邀请码「手机搜狐网」

数据仓库研发规范

  • 未登录

    回复楼主

    登录后可回复
    /1000