离线数据仓库

满床清梦覆星河

已于 2023-12-14 18:04:18 修改

阅读量2.9k

点赞数 1

分类专栏： Resume Hive 文章标签：数据仓库

于 2023-02-12 20:55:42 首次发布

本文链接：https://blog.csdn.net/qq_40640228/article/details/128996636

版权

1 数据仓库建模

数据模型就是数据组织和存储的方法，注重从业务、数据的存储和使用角度合理存储数据。

维度建模通过将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。

业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单、取消订单、付款、退款等。

1.1 建模工具

PowerDesigner/SQLYog/EZDML…

1.2 数据仓库构建流程

优秀可靠的数仓体系，需要良好的数据分层结构。合理的分层，能够使数据体系更加清晰，使复杂问题得以简化。

一般数仓分层分别为ODS(原始数据层)、DWD(明细数据层)、DIM(公共维度层)、DWS(汇总数据层)、ADS(数据应用层)，根据需要也有可能会划分出STG(贴源层)、DWM(DWD轻度汇总)、DWT(主题宽表)分层。

数据仓库维度建模之前需要梳理出维度清单、指标清单、指标统计周期、原子指标计算逻辑、派生指标计算逻辑、衍生指标计算逻辑、表关联关系等，从而根据这些清单梳理出维度建模中需要的维度和业务过程(事实)，然后根据维度和业务过程之间的关系划分数据域、划分主题域、构建总线矩阵，最后根据业务总线矩阵进行模型设计，一个业务过程对应一个事实表。

在这里插入图片描述

1.2.1 数据调研(业务调研和需求分析)

(1) 业务调研

业务调研主要目标是熟悉业务流程、熟悉业务数据。

熟悉业务流程要求做到明确每个业务的具体流程，需要将该业务所包含的每个业务过程一一列举。

熟悉业务数据要求做到将数据与业务过程对应起来，明确每个业务过程会对哪些表的数据产生影响，以及产生什么影响。需要具体到是新增一条数据还是修改一条数据，并且需要明确新增的内容或是修改的逻辑。

业务分析要注意什么样的业务过程？处理的什么业务？业务的流程是怎样的？以及业务产生了哪些影响(注意业务变化和影响)？

（2）需求分析

需要明确需求所需的业务过程及维度，例如买家下单所需的业务过程就是买家下单，所需的维度有日期，省份，商品品类。

做完业务分析和需求分析之后，要保证每个需求都能找到与之对应的业务过程及维度。

1.2.2 明确数据域

数据仓库设计除了横向的分层外通常也需要根据业务情况纵向划分数据域，以便于数据的管理与应用。通常可以根据业务过程或者部门进行划分。根据业务过程进行划分，需要注意的是一个业务过程只能属于一个数据域。

在这里插入图片描述

(1) 数据域划分案例

用户域、产品域、交易域、营销域、组织域、公共域、行为域

(2) 主题域划分案例

产品域、会员域、交易域、数据安全域、数据治理域、数据资产域、粉丝域、活动域、竞争域、卡券域、积分域、人力域、服务域、库存域、DTC商城域、广告域、内容域、舆情域

1.2.3 构建业务总线矩阵

业务总线矩阵中包含维度模型所需的所有事实（业务过程）以及维度，以及各业务过程与各维度的关系。矩阵的行是一个个业务过程，矩阵的列是一个个的维度，行列的交点表示业务过程与维度的关系，如果两者有关联则使用√标记。

业务总线矩阵表案例：

	时间	用户	地区	商品	优惠券	活动	度量值
订单	√	√	√			√	件数/金额
订单详情	√		√	√			件数/金额
支付	√	√	√				次数/金额
加购	√	√		√			件数/金额
收藏	√	√		√			个数
评价	√	√		√			个数
退款	√	√		√			件数/金额
优惠券领用	√	√			√		个数

总线矩阵每一行代表一个业务过程，业务过程可以理解为整体流程中的节点或者原子性事件，每一列代表维度，一个业务过程需要选择感兴趣的维度，一个业务过程产出一张事务型事实表。构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是，总线矩阵中通常只包含事务型事实表，另外两种类型的事实表需单独设计。

总线矩阵可做可不做，一般根据需求指标拆解，比如最新七天各品牌下单人数，可以拆解出维度为品牌，统计周期为7天，所属业务过程为下单，从而DWD层就可以提取出下单事实表和品牌维度。维度建模其实就是按照需求来拆分指标和业务，ER建模就是从数据中充分理解数据和业务进行整合(建模难度大)

1.2.4 明确统计指标

指标分类	释义
原子指标	基于某一业务过程的度量值,是业务定义中不可再拆解的指标;原子指标包含三要素，分别是业务过程、度量值和聚合逻辑。例如订单总额就是一个典型的原子指标，业务过程为用户下单、度量值为订单金额、聚合逻辑为Sum()求和
派生指标	派生指标=原子指标+业务限定+统计周期+维度或维度的组合（统计粒度）；派生指标通常会对应实际的统计需求。
衍生指标	基于派生指标做二次多元计算的表达式。例如原子指标A和B，C=A/B。衍生指标通常也对应实际的统计需求。

当统计需求足够多时就会出现部分统计需求对应的派生指标相同的情况，这种情况下就可以考虑将公共的派生指标保存下来，从而减少重复计算，提高数据的复用性。这些公共的派生指标统一保存在DWS层。

1.2.5 维度模型设计

维度模型的设计参考业务总线矩阵即可。事务型事实表存在DWD层，维度表存在DIM层。

1.2.6 汇总模型设计

汇总模型设计的参考上述整理出的指标体系(主要是派生指标)即可。汇总表和派生表之间的对应关系是，一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标。

1.3 业务过程和维度

在阿里云Dataphin官方文档中将维度和业务过程(事实)统称为业务实体，业务实体包含业务对象和业务活动，业务对象和业务活动即分别为维度建模中的维度和业务过程(事实)。

1.3.1 业务对象 – 维度

维度表：参与业务的人或事物, 偏静态的实体。通常情况下业务对象是实际存在、不因事件发生而存在的对象。 例如客户、员工、产品等具体的业务对象；地域、组织关系和产品类目等抽象的业务对象。在阿里云Dataphin官方文档中将业务对象划分为一下四类：

1. 普通对象：复杂的, 有很多属性的对象。狭义上，业务对象就是普通对象。例如：零售业务中的买家、商品等可以具象化的实体，或类目、地域等较抽象的实体。

2. 枚举对象：简单的基础对象。例如：性别（男/女/未知），其值可以穷举。

3. 虚拟对象：在业务定义中，没有任何属性的基础对象。例如：姓名。

4. 层级对象：多个业务对象之间有上下级关系,这一组对象就是层级对象。例如：行政区域（国家->省->市->县）。

1.3.2 业务活动 – 业务过程 – 事实

一个或者多个业务对象在某个时间（段）为了达成某种目的，所进行的活动或者是某种活动的结果既是业务过程。事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计。事实表通常包含与该业务过程有关的维度引用(维度表外键)以及度量(通常是可以累加的数字类型字段)。

基本一张事物事实表，由纬度外键，退化纬度，加度量组成,度量可以理解为原子指标。事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等），例如，订单事件中的下单金额。

事实表有三种类型，分别是事务性事实表、周期快照事实表和累计快照事实表。 在阿里云Dataphin官方文档中将事实表称之为业务活动，业务活动分为业务事件、业务快照、业务流程三类，分别对应着事务型事实表、周期型快照事实表、累积型快照事实表。

1.3.2.1 业务事件(事务性事实表)

事务性事实表用来记录各业务过程，保存的是各业务过程的原子操作事件，即最细粒度的操作事件。 粒度是指一行数据所表达的业务细节程度。

事务性事实表存在两点不足之处：

(1) 第一点是针对存量型指标不论是从逻辑上还是效率上都不是最佳方案，比如针对商品库存来说，库存减少和库存增加会对应着两个事务性事实表，当需要统计库存剩余时，则需要对两张表进行数据聚合才能得到统计结果。

(2) 第二点是假如需要统计最近一个月用户下单和支付的平均时间间隔，则需要关联下单事务事实表和支付事务事实表后再计算平均值，逻辑上虽然不复杂，但是因为两张表都是大表，大表与大表的join操作应尽量避免。

而周期型快照事实表和累积型快照事实表则可以弥补业务事实表的不足之处。

1.3.2.2 业务快照(周期型快照事实表)

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（库存、余额等）或者状态型(空气温度、行驶速度)指标。 定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合。使用累积型快照事实表可以避免两个事务事实表关联操作，从而十分简单高效。

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