数据开发/数仓工程师上手指南(五)CDM-DIM层搭建规范及流程

前言

在上篇文章的进度和基础之上，我们已经算是构建好了ODS数据引入层，ODS这一层构建的比较简单，没有很多限制规范，但是CDM数据公共层可以算得上是数据仓库的主题，之前我们也将DWD数据明细层、DIM数据维度层和DWS公共汇总层都归纳为这一层层级结构。所有在构建这一层中需要注意的规范和事项比较多，当然对以后数据仓库的维护和优化也会起到很大的帮助，需要细心耐心的搭建规划。那么我们将在本章完成DWD/DIM/DWS这三层的具体搭建和设计规范。

CDM概述及构成

CDM层，即Common Data Model层，是数据仓库中的核心层次，它定义了数据仓库中使用的共同数据结构和业务规则。CDM层提供了一个统一的视图，将不同的数据源和数据格式映射到一个通用的模型中，使得数据分析人员可以更容易地进行数据整合和分析。

• 公共维度层（DIM）：基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
• 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。
• 明细粒度事实层（DWD）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。明细粒度事实层的表通常也被称为逻辑事实表。

CDM层的目的是为了建立一个一致性的维度和可复用的面向分析和统计的明细事实表及汇总公共粒度的指标，从而降低数据计算口径和算法不统一的风险，提高数据的复用性和查询效率。这一方面可以参考一名博主CDM层在整体架构中，实际构建的表作业：

DIM层构建

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

定义维度

在划分数据域、构建总线矩阵时，需要结合对业务过程的分析定义维度。在招标业务过程中，供应商和投标是两个关键维度，它们对分析招标活动的各个方面至关重要。构建这两个维度的DIM层，需要系统化的步骤和清晰的业务逻辑。

1.确定业务需求和数据来源

供应商维度（Dim_Supplier）：

• 业务需求：需要记录和分析每个供应商的基本信息、资质、历史表现等。
• 数据来源：供应商管理系统、资质认证系统、历史交易记录等。

投标维度（Dim_Bid）：

• 业务需求：需要记录和分析每个投标的具体信息、投标时间、金额、供应商等。
• 数据来源：投标管理系统、项目管理系统、评标系统等。

2. 设计维度表结构

完成维度定义后，可以对维度进行补充，进而生成维表。DIM 层表是用于维度关联的，要通过主键去获取相关维度信息，这种场景下 K-V 类型数据库的效率较高。常见的 K-V 类型数据库有 Redis、HBase，而 Redis 的数据常驻内存，会给内存造成较大压力，因而选用 HBase 存储维度数据。

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

在设计维表时，需要考虑有以下几点：

1.维表中数据的稳定性

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

2.维表是否需要垂直拆分

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

3.维表是否需要水平拆分

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

设计维表的主要步骤如下：

1. 初步定义维度。 保证维度的一致性。
2. 确定主维表（中心事实表，本教程中采用星型模型）。 此处的主维表通常是数据引入层（ODS）表，直接与业务系统同步。例如，s_auction是与前台商品中心系统同步的商品表，此表即是主维表。
3. 确定相关维表。 数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、卖家和店铺等维度存在关联关系。
4. 确定维度属性。 主要包括两个阶段。第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。以商品维度为例，从主维表（s_auction）、类目、卖家和店铺等相关维表中选择维度属性或生成新的维度属性。维度属性的设计需要注意：
   • 尽可能生成丰富的维度属性。
   • 尽可能多地给出富有意义的文字性描述。
   • 区分数值型属性和事实。
   • 尽量沉淀出通用的维度属性。

设计招标业务维表，可以参考：

供应商维度表（Dim_Supplier）：

• 供应商ID（Supplier_ID）
• 供应商名称（Supplier_Name）
• 行业（Industry）
• 资质（Qualification）
• 评级（Rating）
• 国家（Country）
• 城市（City）
• 注册日期（Registration_Date）

投标维度表（Dim_Bid）：

• 投标ID（Bid_ID）
• 供应商ID（Supplier_ID）
• 项目ID（Project_ID）
• 投标金额（Bid_Amount）
• 投标日期（Bid_Date）
• 投标状态（Bid_Status）

3.DIM表命名规范

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

4.创建SQL DLL建表语句

供应商维度表(Dim_Supplier):

CREATE TABLE Dim_Supplier_da (
    Supplier_ID INT PRIMARY KEY,
    Supplier_Name VARCHAR(100) NOT NULL,
    Industry VARCHAR(50),
    Qualification VARCHAR(50),
    Rating VARCHAR(10),
    Country VARCHAR(50),
    City VARCHAR(50),
    Registration_Date DATE
);
​

投标维度表（Dim_Bid）:

CREATE TABLE Dim_Bid_da(
    Bid_ID INT PRIMARY KEY,
    Supplier_ID INT NOT NULL,
    Project_ID INT NOT NULL,
    Bid_Amount DECIMAL(10,2) NOT NULL,
    Bid_Date DATE NOT NULL,
    Bid_Status VARCHAR(20),
    FOREIGN KEY (Supplier_ID) REFERENCES Dim_Supplier(Supplier_ID),
    FOREIGN KEY (Project_ID) REFERENCES Dim_Project(Project_ID)
);

在具体实现上，DIM层通常通过使用‌Flink等流处理框架从源系统中消费数据，并进行必要的转换和处理。