数仓维度建模简析(ODS-DWS)

一、数仓为什么要分层？

  合理的数据仓库分层一方面能够降低耦合性，提高重用性，可读性可维护性，另一方面也能提高运算的效率，影响到数据需求迭代的速度，近而影响到产品决策的及时性。建立数据分层可以提炼公共层，避免烟囱式开发，可见一个合适且合理的数仓分层是极其重要。

二、通用分层设计思路

  ODS:操作型数据(Operational Data Store)，指结构与源系统基本保持一致的增量或者全量数据。作为DW数据的一个数据准备区，同时又承担基础数据记录历史变化，之所以保留原始数据和线上原始数据保持一致，方便后期数据核对需要。

  （1）保持数据原貌不做任何修改，起到备份数据的作用。

  （2）数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）

  （3）创建分区表，防止后续的全表扫描

  CDM：通用数据模型，又称为数据中间层(Common Data Model)，包含DWD、DWS、DIM层。

  DWD：数据仓库明细层数据(Data Warehouse Detail)。对ODS层数据进行清洗转化，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可以结合企业的数据使用特点，基于维度建模思想，将明细事实表的某些重要属性字段做适当冗余，也即宽表化处理，构建明细宽表。

  DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

  维度建模一般按照以下四个步骤：

      选择业务过程→声明粒度→确认维度→确认事实

  （1）选择业务过程

  在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。

  （2）声明粒度

  数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。

  声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

  典型的粒度声明如下：

  订单中，每个商品项作为下单事实表中的一行，粒度为每次下单；
  每周的订单次数作为一行，粒度就是每周下单；
  每月的订单次数作为一行，粒度就是每月下单；

  （3）确定维度

  维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。

  （4）确定事实

  此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。

  在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

  DWS：数据仓库汇总层数据(Data Warehouse Summary)，基于指标需求，构建初步汇总事实表，一般是宽表。基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标。

  统计各个主题对象的当天行为，服务于DWT层的主题宽表，以及一些业务明细数据，应对特殊需求（例如，购买行为，统计商品复购率）。

  统以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建主题对象的全量宽表。

  DIM：建立一致数据分析维表，可以降低数据计算口径不统一的风险，同时可以方便进行交叉探查。以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。

  ADS：面向应用的数据服务层(Application Data Service)。整合汇总成分析某一个主题域的服务数据，面向应用逻辑的数据加工。该层主要存放数据产品个性化的统计指标数据，这一层的数据直接对接数据的消费者，是产品、运营等角色可以直接感知理解的一层，大多数这一层的表都可以直接在BI上通过图表的形式直接透出。

维度表和事实表（重点）

维度表（类比名词）

  维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。

  维表的特征：
  1. 维表的范围很宽（具有多个属性、列比较多）
  2. 跟事实表相比，行数相对较小：通常< 10万条
  3. 内容相对固定：编码表

事实表（类比动词）

  事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等），例如，订单事件中的下单金额。
  每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。

  事实表的特征：
  1. 非常的大
  2. 内容相对的窄：列数较少
  3. 经常发生变化，每天会新增加很多。

  1）事务型事实表
  以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

  2）周期型快照事实表
  周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。

  3）累积型快照事实表
  累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

三、没有DWS层不行吗?

  当我们在做数据需求时，会不会有这样的疑问：我直接能从DWD层很方便的取出想要的数据，为什么还要多此一举建立DWS层的汇总表呢？那是不是意味着可以不用建立DWS层的表呢，答案是： 可以的。 但是这有一个前提，就是业务场景不复杂。从短期来看可以快速满足数据需求的开发，但是长期来看，会存在如下的问题：

  对于复杂的业务场景而言，会出现很多跨域、跨事实的交叉探查，如果没有沉淀出DWS层的指标进行统一口径的收口，那么相同的指标会出现不同的口径和命名，其后果就是取数变得越来越不方便，而且容易造成业务怀疑数据是否正确的尴尬局面。
公共指标没有统一计算，当每次需要相同的指标时，则需要重新计算一遍取数逻辑，不仅效率不高(需要关联表，计算指标)，而且会造成计算资源浪费。

四、DWS层设计

   以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表。 如：形成日，周，月粒度汇总明细，或者基于某一个维度，如商品类目粒度的汇总日表，统计便于下一步报表数据结构的组织。

五、DWS层的基本特点

  1.DWS层是面向分析维度进行设计的，分析维度通常是业务经常需要的看数据的角度；

  2.DWS层的表服务于数据报表和数据产品的指标需求；

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

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

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

  6.公共汇总层的一个表通常会对应一个派生指标；

  7.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层建设的好坏？

  由于数仓的建设是与业务息息相关的，数仓建设的方法论仅仅只是指引我们构建数仓的一个方向，在实际的落地执行过程中会存在各种各样的问题，且不可被这些理论所禁锢。简单一句话就是：合适就好。所以，评价模型的好坏与否，更多的是从使用者的角度出发，比如简单、易于取数、表的数量恰好。