数仓建模分层详解

数仓各层详解

---

前言

了解数仓各层有什么功能，是面试中考察的重点，其实这本来也是每个做数仓的都必须清楚的事情。
得了解各层是如何划分的，或者说各层是依据什么来划分的

一、数据引入层（ODS）

ODS（Operational Data Store）层存放您从业务系统获取的最原始的数据，是其他上层数据的源数据。业务数据系统中的数据通常为非常细节的数据，经过长时间累积，且访问频率很高，是面向应用的数据。
为了满足历史数据分析需求，您可以在ODS层表中添加时间维度作为分区字段。实际应用中，您可以选择采用增量、全量存储或拉链存储的方式。

二、明细粒度事实层(DWD)

明细粒度事实层DWD（Data Warehouse Detail）以业务过程驱动建模，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。您可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。

公共汇总粒度事实层（DWS）和明细粒度事实层（DWD）的事实表作为数据仓库维度建模的核心，需紧绕业务过程来设计。通过获取描述业务过程的度量来描述业务过程，包括引用的维度和与业务过程有关的度量。度量通常为数值型数据，作为事实逻辑表的依据。事实逻辑表的描述信息是事实属性，事实属性中的外键字段通过对应维度进行关联。

事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度，一种是所表示的具体业务含义。

作为度量业务过程的事实，通常为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型：

• 可加性事实是指可以按照与事实表关联的任意维度进行汇总。
• 半可加性事实只能按照特定维度汇总，不能对所有维度汇总。例如库存可以按照地点和商品进行汇总，而按时间维度把一年中每个月的库存累加则毫无意义。
• 完全不可加性，例如比率型事实。对于不可加性的事实，可分解为可加的组件来实现聚集。
  事实表相对维表通常更加细长，行增加速度也更快。维度属性可以存储到事实表中，这种存储到事实表中的维度列称为维度退化，可加快查询速度。与其他存储在维表中的维度一样，维度退化可以用来进行事实表的过滤查询、实现聚合操作等。

明细粒度事实层（DWD）通常分为三种：事务事实表、周期快照事实表和累积快照事实表，详情请参见数仓建设指南。

• 事务事实表用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为原子事实表。
• 周期快照事实表以具有规律性的、可预见的时间间隔记录事实。
• 累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。当累积快照事实表随着生命周期不断变化时，记录也会随着过程的变化而被修改。

明细粒度事实表设计原则

明细粒度事实表设计原则如下所示：

• 通常，一个明细粒度事实表仅和一个维度关联。
• 尽可能包含所有与业务过程相关的事实 。
• 只选择与业务过程相关的事实。
• 分解不可加性事实为可加的组件。
• 在选择维度和事实之前必须先声明粒度。
• 在同一个事实表中不能有多种不同粒度的事实。
• 事实的单位要保持一致。
• 谨慎处理Null值。
• 使用退化维度提高事实表的易用性。

明细粒度事实表整体设计流程

在一致性度量中已定义好了交易业务过程及其度量。明细事实表注意针对业务过程进行模型设计。明细事实表的设计可以分为四个步骤：选择业务过程、确定粒度、选择维度、确定事实（度量）。粒度主要是在维度未展开的情况下记录业务活动的语义描述。在您建设明细事实表时，需要选择基于现有的表进行明细层数据的开发，清楚所建表记录存储的是什么粒度的数据。

明细粒度事实层（DWD）规范

通常您需要遵照的命名规范为：dwd_{业务板块/pub}{数据域缩写}{业务过程缩写}[_{自定义表命名标签缩写}] _{单分区增量全量标识}，pub表示数据包括多个业务板块的数据。单分区增量全量标识通常为：i表示增量，f表示全量。例如： dwd_asale_trd_ordcrt_trip_di（A电商公司航旅机票订单下单事实表，日刷新增量）及dwd_asale_itm_item_df（A电商商品快照事实表，日刷新全量）。
Eg:
交易商品信息事实表：dwd_asale_trd_itm_di
交易会员信息事实表：dwd_asale_trd_mbr_di
交易订单信息事实表：dwd_asale_trd_ord_di

公共汇总粒度事实层（DWS）

公共汇总粒度事实层DWS（Data Warehouse Summary）以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求构建公共粒度的汇总指标事实表。公共汇总层的一个表至少会对应一个派生指标。

公共汇总事实表设计原则

聚集是指针对原始明细粒度的数据进行汇总。DWS公共汇总层是面向分析对象的主题聚集建模。在本教程中，最终的分析目标为：最近一天某个类目（例如：厨具）商品在各省的销售总额、该类目Top10销售额商品名称、各省用户购买力分布。因此，我们可以以最终交易成功的商品、类目、买家等角度对最近一天的数据进行汇总。数据聚集的注意事项如下：

• 聚集是不跨越事实的。聚集是针对原始星形模型进行的汇总。为获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨越事实的。
• 聚集会带来查询性能的提升，但聚集也会增加ETL维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。

进行DWS层设计时还需遵循以下原则

• 数据公用性：需考虑汇总的聚集是否可以提供给第三方使用。您可以思考，基于某个维度的聚集是否经常用于数据分析中。如果答案是肯定的，就有必要把明细数据经过汇总沉淀到聚集表中。
• 不跨数据域：数据域是在较高层次上对数据进行分类聚集的抽象。数据域通常以业务过程进行分类，如交易统一划到交易域下， 商品的新增、修改放到商品域下。

区分统计周期：在表的命名上要能说明数据的统计周期，如_1d 表示最近1天， td 表示截至当天，nd 表示最近N天。

公共汇总事实表（DWS）规范

公共汇总事实表命名规范：dws_{业务板块缩写/pub}{数据域缩写}{数据粒度缩写}[{自定义表命名标签缩写}]{统计时间周期范围缩写}。
关于统计实际周期范围缩写，缺省情况下，离线计算应该包括最近一天（_1d）,最近N天（_nd）和历史截至当天（_td）三个表。如果出现_nd的表字段过多需要拆分时，只允许以一个统计周期单元作为原子拆分。即一个统计周期拆分一个表，例如最近7天（_1w）拆分一个表。不允许拆分出来的一个表存储多个统计周期。
对于小时表[无论是天刷新还是小时刷新]，都用_hh来表示。
对于分钟表[无论是天刷新还是小时刷新]，都用_mm来表示。
Eg:
dws_asale_trd_byr_subpay_1d （A电商公司买家粒度交易分阶段付款一日汇总事实表）
dws_asale_trd_byr_subpay_td（A电商公司买家粒度分阶段付款截至当日汇总表）
dws_asale_trd_byr_cod_nd（A电商公司买家粒度货到付款交易汇总事实表）
dws_asale_itm_slr_td（A电商公司卖家粒度商品截至当日存量汇总表）
dws_asale_itm_slr_hh（A电商公司卖家粒度商品小时汇总表）—维度为小时
dws_asale_itm_slr_mm（A电商公司卖家粒度商品分钟汇总表）—维度为分钟

公共维度汇总层（DIM）

公共维度汇总层DIM（Dimension）基于维度建模理念，建立整个企业的一致性维度。

公共维度汇总层（DIM）主要由维度表（维表）构成。维度是逻辑概念，是衡量和观察业务的角度。维表是根据维度及其属性将数据平台上构建的物理化的表，采用宽表设计的原则。因此，公共维度汇总层（DIM）首先需要定义维度。

定义维度

在划分数据域、构建总线矩阵时，需要结合对业务过程的分析定义维度。本教程以A电商公司的营销业务板块为例，在交易数据域中，我们重点考察确认收货（交易成功）的业务过程。

在确认收货的业务过程中，主要有商品和收货地点（本教程中，假设收货和购买是同一个地点）两个维度所依赖的业务角度。从商品角度可以定义出以下维度：

• 商品ID
• 商品名称
• 商品价格
• 商品新旧程度 0表示全新，1表示闲置，2表示二手。
• 商品类目ID
• 商品类目名称
• 品类ID
• 品类名称
• 买家ID
• 商品状态 0表示正常，1表示用户删除，2表示下架，3表示从未上架。
• 商品所在城市
• 商品所在省份

从地域角度，可以定义出以下维度：

• 买家ID
• 城市code
• 城市名称
• 省份code
• 省份名称
• 作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以A公司的商品维度为例，有且只允许有一种维度定义。例如，省份code这个维度，对于任何业务过程所传达的信息都是一致的。

设计维表

完成维度定义后，您可以对维度进行补充，进而生成维表。维表的设计需要注意：

• 建议维表单表信息不超过1000万条。
• 维表与其他表进行Join时，建议您使用Map Join。
• 避免过于频繁的更新维表的数据。

在设计维表时，您需要从下列方面进行考虑：

维表中数据的稳定性。

• 例如，A公司电商会员通常不会出现消亡，但会员数据可能在任何时候更新，此时要考虑创建单个分区存储全量数据。如果存在不会更新的记录，您可能需要分别创建历史表与日常表。日常表用于存放当前有效的记录，保持表的数据量不会膨胀；历史表根据消亡时间插入对应分区，使用单个分区存放分区对应时间的消亡记录。

维表是否需要垂直拆分？

• 如果一个维表存在大量属性不被使用，或由于承载过多属性字段导致查询变慢，则需要考虑对字段进行拆分，创建多个维表。

维表是否需要水平拆分？

• 如果记录之间有明显的界限，可以考虑拆成多个表或设计成多级分区。

核心维表的产出时间。通常有严格的要求。
设计维表的主要步骤如下：

1. 初步定义维度。
   保证维度的一致性。

2. 确定主维表（中心事实表，本教程中采用星型模型）。
   此处的主维表通常是数据引入层（ODS）表，直接与业务系统同步。例如，s_auction是与前台商品中心系统同步的商品表，此表即是主维表。

3. 确定相关维表。
   数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、卖家和店铺等维度存在关联关系。

4. 确定维度属性。
   主要包括两个阶段。第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。以商品维度为例，从主维表（s_auction）、类目、卖家和店铺等相关维表中选择维度属性或生成新的维度属性。维度属性的设计需要注意：

   • 尽可能生成丰富的维度属性。
   • 尽可能多地给出富有意义的文字性描述。
   • 区分数值型属性和事实。
   • 尽量沉淀出通用的维度属性。

公共维度汇总层（DIM）维表规范

公共维度汇总层（DIM）维表命名规范：dim_{业务板块名称/pub}{维度定义}[{自定义命名标签}]，pub是与具体业务板块无关或各个业务板块都可公用的维度。
例如，时间维度
公共区域维表 : dim_pub_area
A公司电商板块的商品全量表 : dim_asale_itm