数据开发/数仓工程师上手指南(二)数仓构建分层概念

前言

回顾上篇文章我们可以用思维导图一遍概览：

在了解了数仓的基本架构之后，我们还需要掌握数仓构建方法，也就是了解数仓是如何建模的，有什么规则和通用方法。我们应该如何去构建一个性能良好、稳定高效、契合业务的数据仓库。

一、数仓建模的好处

首先明确一点，好的数据仓库能够支持复杂数据分析和决策，能够提供高性能查询，能够做到数据的通用集成和保持数据的一致性，可以说得上是面向业务分析的数据库。数据库表设计我们向来有很多方法进行构建，同样数仓建模也有普遍获得认可的方法来达到想要的结果。

数仓功能本质就是通过建模来达成对复杂业务的抽象，清晰准确完整的刻画业务场景，以便用户通过业务视角便捷的获取所需数据，完成对业务活动的度量。我们以两个实际行业应用案例来看：

案例一：零售行业

• 背景：某大型零售企业希望通过数据分析提高销售业绩。
• 实施：构建数据仓库，集成销售数据、客户数据和库存数据，采用星型模型设计。
• 效果：通过OLAP分析，企业能够实时监控销售情况，了解各个产品线的销售趋势和客户行为，优化库存管理，制定精准的市场营销策略。

案例二：银行业

• 背景：某银行希望提升风险管理能力和客户服务水平。
• 实施：构建数据仓库，集成交易数据、客户数据和风险评估数据，采用雪花型模型设计。
• 效果：通过数据仓库的多维分析和数据挖掘，银行能够识别高风险客户和交易，提升风控能力；同时，分析客户行为数据，提供个性化的金融服务，提升客户满意度。

好的数据仓库模型的设计和实施，为企业和组织提供了强大的数据集成、管理和分析能力，支持复杂的数据分析和科学决策，提高业务敏捷性和市场竞争力。通过集成和标准化数据，优化查询性能，存储历史数据，管理数据质量，支持决策支持系统，数据仓库模型成为现代企业数据管理和业务分析的核心工具。

二、数仓分层概念

2.1分层概念

需要明确一点的是，我们的模型最终导向都是主张从分析决策的需求出发构建模型，为分析需求服务。那么我们首先需要理解构建数仓的几个基本分层概念：

2.1.1业务板块

首先需要明确公司构建数仓具体需要使用在哪些业务上，比如是用于电商系统，或者是投资系统，不同的业务系统需要构建唯一的数仓，不能N:1的构建数仓，以免数据混淆污染。

2.1.2数据域

从业务的角度，对数据进行总体的归类和划分，形成的有边界的数据范围。面向业务分析，将业务过程或者维度进行抽象的集合一个数据域代表一个特定的业务领域或主题领域，如销售、财务、人力资源、库存管理等。每个数据域包含特定的业务事实和与这些事实相关的维度。

比如：

销售数据域

• 事实表：销售事实表（如销售交易、订单详情）
• 维度表：产品维度表、客户维度表、时间维度表、销售人员维度表、地区维度表

财务数据域

• 事实表：财务事实表（如收入、支出、利润）
• 维度表：账户维度表、时间维度表、部门维度表、费用类别维度表

人力资源数据域

• 事实表：员工事实表（如员工信息、考勤记录）
• 维度表：员工维度表、部门维度表、职位维度表、时间维度表

数据域的设计需要全面考虑业务需求、数据来源、数据质量和数据模型，以确保构建一个高效、可靠的数据仓库系统。

2.1.3维度

维度是数据仓库中的一个类别，用于描述业务过程的上下文信息。维度为数据分析提供了不同的视角和分类方式，例如时间、地点、产品、客户等。

特征：

• 描述性：维度通常包含描述性的信息，例如产品名称、客户名称、时间日期等。
• 分类和分组：维度允许数据按不同的类别和层次进行分类和分组，以支持多维分析。
• 层次结构：维度通常具有层次结构，例如时间维度可以包括年、季度、月、日等层次。

示例：

• 时间维度：包含年、季度、月、日等信息。
• 产品维度：包含产品ID、产品名称、类别、品牌等信息。
• 客户维度：包含客户ID、客户名称、地址、客户类别等信息。

产品维度表：

CREATE TABLE Dim_Product (
    Product_ID INT PRIMARY KEY,
    Product_Name VARCHAR(100),
    Product_Category VARCHAR(50),
    Product_Brand VARCHAR(50)
);
​

维度建模是一种数据仓库设计方法，专注于优化数据的存储和查询性能，以支持高效的数据分析和业务决策。维度建模通常采用星型模型、雪花型模型或星座模型。

	星型模型	雪花模型	星座模型
概念	所有的维度表都和事实表相连，较为简单的模型，不存在渐变维度，所以数据有一定的冗余。	雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。但是难以维护，加大开发难度。	很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
查询速度	快，不需要和外表关联进行查询和数据分析，因此效率相对较高。	较慢，需要join的表⽐较多所以其性能并不⼀定⽐星型模型⾼。	较快，适用于跨主题的复杂分析，可以支持多种业务过程的数据分析。
冗余度	高，星型架构是⼀种⾮正规化的结构，多维数据集的每⼀个维度都直接与事实表相连接，不存在渐变维度，所以数据有⼀点的冗余。如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余	低，它对星型模型的维表进⼀步层次化，原有的各维表可能被扩展为⼩的事实表，形成⼀些局部的 "层次 " 表，去重冗余。如将地域维表分解为国家，省份，城市等维表。	较低，共享的维度表为多个事实表提供描述信息。由于维度表被多个事实表共享，相比于每个事实表各自拥有独立的维度表，数据冗余度较低。
可读性	容易	差	容易
表数量	少	多	较少

模型图

星型模型：

雪花模型：

星座模型：

2.1.4属性（维度属性）

维度所包含的表示维度的列称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。

维度属性的示例

产品维度（Dim_Product） ：

• 产品ID（Product_ID） ：唯一标识每个产品的主键。
• 产品名称（Product_Name） ：产品的名称。
• 产品类别（Product_Category） ：产品所属的类别。
• 产品品牌（Product_Brand） ：产品的品牌。
• 产品价格（Product_Price） ：产品的价格。

2.1.5业务过程

业务过程（Business Process）是企��或组织中为完成特定目标而进行的一系列活动或任务的集合。它描述了如何在组织中进行工作，从开始到结束，涉及人员、系统、数据和其他资源的协调与合作。业务过程在数据仓库和维度建模中起着至关重要的作用，因为它们通常是数据仓库中的事实表的基础。

比如：

销售过程：

• 目标：完成产品销售，生成销售订单。
• 活动：客户下单、订单处理、支付、发货、售后服务。
• 数据仓库：销售事实表记录每笔销售交易，维度表包括产品维度、客户维度、时间维度等。

销售事实表：

CREATE TABLE Fact_Sales (
    Sale_ID INT PRIMARY KEY,
    Product_ID INT,
    Time_ID INT,
    Sales_Amount DECIMAL(10, 2),
    Sales_Quantity INT,
    FOREIGN KEY (Product_ID) REFERENCES Dim_Product(Product_ID),
    FOREIGN KEY (Time_ID) REFERENCES Dim_Time(Time_ID)
);
​

2.1.6度量

在维度建模中，度量（Measure）是用于量化业务过程的数值型数据。度量通常存储在事实表中，并与维度表关联，以提供丰富的上下文信息。度量是数据仓库和商业智能（BI）系统中进行数据分析和报告的核心要素。度量通常为数值型数据，作为事实逻辑表的事实。

定义：

度量是用于量化业务活动的关键数据点，通常是数值型的，可以进行汇总和分析。度量回答了业务过程中的"多少"或"多少次"的问题，如销售金额、订单数量、库存水平等。

比如销售过程中的度量：

销售金额（Sales Amount） ：每笔销售的总金额，可以累加。

销售数量（Sales Quantity） ：每笔销售的产品数量，可以累加。

折扣金额（Discount Amount） ：每笔销售的折扣金额，可以累加。

库存管理过程中的度量：

库存数量（Inventory Quantity） ：每种产品在每个仓库中的库存数量，半累积。

补货次数（Replenishment Count） ：每种产品的补货次数，可以累加。

2.1.7指标

指标分为原子指标和派生指标。原子指标是基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，是具有明确业务含义的名词 ，体现明确的业务统计口径和计算逻辑，例如：

• 原子指标=业务过程+度量
• 派生指标=时间周期+修饰词+原子指标，派生指标可以理解为对原子指标业务统计范围的圈定。

指标直接与业务活动相关，用于反映业务的关键绩效指标（KPIs），比如：

0. 销售收入：衡量某一时间段内的总销售额。
1. 客户获取成本（CAC） ：获取一个新客户的平均成本。
2. 净利润率：净利润占总收入的百分比。
3. 库存周转率：库存在特定时间内被出售和替换的次数。

原子指标对应的为：

• 单笔交易的金额
• 单次访问的时长
• 单个产品的库存数量

2.1.8业务限定

统计的业务范围，筛选出符合业务规则的记录（类似于SQL中where后的条件，不包括时间区间）。

2.1.9统计周期

统计的时间范围，例如最近一天，最近30天等（类似于SQL中where后的时间条件）。

2.1.10统计粒度

统计粒度是统计分析的对象或视角，定义数据需要汇总的程度，可理解为聚合运算时的分组条件（类似于SQL中的group by的对象）。比如：

时间粒度：

• 按秒记录：非常细的时间粒度，适用于需要精确时间戳的数据分析，如服务器日志。
• 按分钟记录：较细的时间粒度，适用于实时数据分析，如交易系统。
• 按天记录：常见的时间粒度，适用于日常业务报表，如每日销售报告。
• 按月记录：较粗的时间粒度，适用于长期趋势分析，如月度财务报告。

细粒度（按天记录） ：

SELECT 
    Time_ID, 
    SUM(Sales_Amount) AS Total_Sales_Amount, 
    SUM(Sales_Quantity) AS Total_Sales_Quantity
FROM 
    Fact_Sales
GROUP BY 
    Time_ID;
​

日期	产品ID	销售数量	销售金额
2024-01-01	1001	10	1000
2024-01-02	1001	15	1500
2024-01-03	1001	12	1200

粗粒度（按月记录） ：

月份	产品ID	销售数量	销售金额
2024-01	1001	37	3700
2024-02	1001	40	4000
2024-03	1001	45	4500

2.1.11具体业务分层拆解

在了解了以上涵盖全面的数仓业务分层概念之后，我们可以来对一个具体的电商业务进行拆解，只需要按照表格填写拆分：

首先业务板块对应就是电商业务，数据域对应为交易域，其中交易域的业务过程和维度可以分解为支付和订单。因为每一笔交易都固定会产生一个订单，其中的动作就是支付。订单的数据属性就是根据订单ID来记录数据。

对于支付这个业务过程，包含支付金额，支付方式和支付时间周期，也可以指定为支付宝支付，那么派生指标就是时间+支付方式+支付金额：

以上就是本期全部内容。我是fanstuck ，有问题大家随时留言讨论 ，对此项目感兴趣的，对此领域感兴趣的不要错过，多谢大家的支持！