数仓建模（维度建模）

模型简单易理解：维度建模通过事实表和维度表的构建，将数据仓库中的数据以直观、易于理解的方式组织起来。事实表记录了业务过程中的度量值和事件，如销售额、库存变动等，而维度表则提供了描述这些度量值和事件的环境和上下文，如时间、地点、产品等。这种模型结构使得数据分析师和业务人员能够更容易地理解和解释数据。维度建模是将层次化的数据结构展开为单一层次，构建出来的数据库结构表更加符合人的直觉、易于被人所理解，从而有利于数据的推广使用。易于达成共识，方便查询，不必理解业务系统规范化复杂的3NF模型。
可扩展性好：维度建模具有非常好的可扩展性，能够容纳不可预知的新数据源和新的设计决策。在维度建模中，维度表可以随时添加或修改，而不会对整个数据仓库的结构造成太大的影响。这种灵活性使得数据仓库能够随着业务的发展而不断扩展和适应新的需求。
支持高效的数据分析：维度建模为数据分析提供了高效的数据组织方式。通过事实表和维度表的关联查询，可以轻松地实现多维度的数据分析和挖掘。同时，维度建模还支持复杂的数据聚合和计算操作，使得数据分析师能够更深入地挖掘数据背后的规律和趋势。
可解释性强-标准框架：数据仓库工具书，定义了业界广泛理解的概念。新员工可以快速的掌握数仓的结构，不需要熟悉具体的业务系统数据。工程师和分析师对事实、维度、粒度这些概念都比较了解，可以促进协作。维度建模通过直观的维度和度量，使得数据分析师能够更方便地理解和解释数据的意义。在数据分析过程中，分析师可以根据业务需求选择不同的维度和度量进行组合和分析，从而得出有价值的业务洞察。
快速的响应业务：面向分析构建的，每次不需要编写冗长的SQL，查询大宽表，减少join，方便分析人员和业务人员（不太懂技术，不会写复杂SQL）使用，能快速的响应业务需求。
性能优化：维度建模通过合理的维度设计和规范化，能够显著提高查询性能和数据压缩比。维度表通常包含大量的数据，但这些数据是按照一定的层次和关系组织的，因此在查询时可以利用索引、分区等技术来优化查询性能。此外，维度建模还允许数据库系统和最终用户通过查询工具在数据方面生成强大的假设条件，从而进一步提高数据分析和挖掘的效率。
降低ETL负担：维度建模简化了数据的结构和关系，因此在ETL（Extract, Transform, Load）过程中可以减少数据的转换和整合工作量。在ETL过程中，可以将源数据按照维度建模的要求进行预处理和转换，然后加载到数据仓库中。由于维度建模的数据结构相对简单且规范，因此可以降低ETL过程的复杂性和错误率。

4.2.2 缺点是什么

数据冗余：维度建模可能导致数据冗余。由于维度表通常包含了多个维度级别的详细信息，比如省、市、县等都放在一起，以及事实表与维度表之间的多对多关系，这可能导致相同的数据在多个表中重复存储。在大数据环境下，这种冗余可能会显著增加存储成本，并影响数据的一致性管理。
数据不一致性：由于数据冗余和多个数据源的存在，维度建模中可能会出现数据不一致的问题。例如，当事实表和维度表中的数据更新不同步时，可能会导致查询结果的不准确。为了解决这个问题，需要定期执行数据清洗和一致性检查，但这会增加额外的维护成本。还有一致性维度发生变化，每个主题表都要同步相关维度，对模型冲击比较大，相比范式建模扩展性不好。
难以反向推导：维度建模通常侧重于优化查询性能和分析需求，而可能忽略了数据的原始结构和关系。这导致在需要反向推导或理解数据原始状态时遇到困难。一旦模型设计有误或需要调整，可能需要重新加载和处理大量数据，这既耗时又可能影响业务系统的正常运行。
灵活性和可扩展性受限：维度建模在设计之初就需要明确数据的维度和事实，这限制了模型的灵活性和可扩展性。当业务需求发生变化时，可能需要重新设计维度表或事实表，这会增加维护成本并可能影响数据仓库的性能和稳定性。
对业务变化的适应性差：当业务逻辑发生变化时，维度建模可能需要重新进行维度的定义和数据的预处理。这可能导致大量的工作量和数据冗余，同时也难以保证数据来源的一致性和完整性。
如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。在建设数据仓库的过程中，明细层和集市层分别采用不同的建模方法，比如：明细层采用传统的三范式关系模型：将业务过程描述清楚，将源数据（即业务系统）中隐含的、有歧义的概念进行清晰化。此层灵活地表达业务过程，要保证数据一致性、唯一性、正确性，以尽量少的代价与源数据保持数据同步。（面向技术人员）集市层采用维度模型。集市层是按照业务主题、分主题构建出来的、面向特定部门或人员的数据集合，该层次的数据模型会开放给业务人员使用，进行数据挖掘及业务分析。（面向不懂技术的业务人员，需要简单易理解）

可以通过优化维度表的设计、加强数据清洗和一致性检查、提高查询性能等方式来改进维度建模的效果。

4.3 维度建模-星型模型

星型模型VS雪花模型，根据事实表和维度表之间的关系，我们将常见的模型分为星型模型和雪花模型。星型模型更适用于做指标分析，而雪花模型更适用于做维度分析。

	星型模型	雪花模型
概念	当所有的维度表都是和事实表直接相连的时候，整个图形看上去就像是一个星星，我们称之为星型模型。	当有多个维度表没有直接和事实表相连，而是通过其它的维度表，间接的连接在事实表上，其图形就像是一个雪花，因此我们称之为雪花模型，雪花模型的优点是减少了数据冗余，在办进行数据统计或分析的时候，需要和其他的表进行关联
图
查询速度	快有数据的冗余，很多的统计情况下，不需要和外表关联进行查询和数据分析，因此效率相对较高。	慢在分析数据的时候，需要join的表⽐较多所以其性能并不⼀定⽐星型模型⾼。
冗余度	高星型架构是⼀种⾮正规化的结构，多维数据集的每⼀个维度都直接与事实表相连接，不存在渐变维度，所以数据有⼀点的冗余。如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余	低它对星型模型的维表进⼀步层次化，原有的各维表可能被扩展为⼩的事实表，形成⼀些局部的 "层次 " 表，去重冗余。如将地域维表分解为国家，省份，城市等维表。
可读性	容易	差
表数量	少	多

4.4 维度建模-维度

4.4.1 维度之缓慢变化维

什么是缓慢变化维：随着业务的发展，维度表中的属性会随着业务的发展而变化，但变化的频率一般比较慢，故称为缓慢变化维。

处理缓慢变化维的方法

4.4.2 维度层次

同一类属性存在多对一的关系，具有上卷的形式，可以设计为层次维度

1）固定深度的层次

层次已固定的维度属性，例如右侧的日期维度，日、月，季度，年。处理方案：采用列打平的方式来设计
2）可变深度的层次

层次不固定的维度属性，

例如物流业务线的组织架构，不仅层次不一致，而且会在某一个层次中间和末尾增加一层。

处理方案：

1.采用类似固定深度层次的方案，提前预留足够的列打平设计。

2.采用递归父子关系方式，同时保存每个叶子节点到各个层次的关系和深度值。

4.4.3 维度之常见应用

1、角色扮演维

同一个物理维度在不同的场景中，代表不同的业务含义，通常会被事实表多次引用，技术上通过创建视图来引用。

设计案例：日期维度可以作为下单日期，可以作为支付日期，物流站点维度可以作为快递员的组织归属站点，也可以作为快递员绑点站点。

2、杂项维度

1）业务系统的一些非关键的标识维度，不适合单独常见维度，可以合并到统杂项维度

2）利用杂项维度，减少维度模型的结构变更

设计案例：配送员汇总事实表，设置了杂项维度，合并【是否过风控】+【是否自然日】+【是否高峰期】等维度组成合并成一个维度，避免了维度模型的调整

3、退化维度

业务系统的标识符，没有维度表与它连接，所以叫退化维度

4、其它维度

微型维度、多值维度、步骤维度

4.5 维度建模-事实

事实就是一种度量

4.5.1 事实的分类

可加型事实：可以按维度进行聚合，例如金额、件数

半可加型事实：仅在特定的维度下有含义，例如账户余额

不可加型事实：不具备可加性，例如比率值

4.5.2 事实表的分类

事务事实表、周期快照事实表、累计快照事实

1、事务事实：记录的事务操作过程的事实，最原子的数据，粒度通常是每个事务记录一条记录，只有当天数据才会进入当天的事实表中，相当于每个分区里面都是每天的数据。

id	name	regist_time	dt
100356	张XX	2021-10-01 08:02:10	20211001
200389	李xxx	2021-10-02 11:09:20	20211002

2、周期快照事实表

具有规律性的、可预见的时间间隔来记录事实，用来观察在间隔周期内的度量，时间间隔如每天、每月、每年等，粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。

id	order_cnt	user_cnt	dt
130000356	32	28	20211001
224000389	12	12	20211001

3、累积快照事实表

适合流水线过程中的已明确关键里程信息或已建立好的可预测的工作流，不存储发生的每一个事务信息，累积事实表源于事务，提供了关键过程时间的连续场景描述，代表的是完全覆盖一个事件或产品的生命周期时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。

例如订单累计快照事实表会有下单日期、付款日期，发货日期，收货日期等时间点。

order_id

poi_id

user_id

push_time

grap_time

arrived_time

status

16589600009723

300876

100356

2021-10-01 11:02:10

2021-10-01 08:02:10

9999-01-01 01:00:00

20211001

16200000003455

300087

200389

2021-10-01 09:10:33

2021-10-01 09:12:33

2021-10-01 10:02:09

20211001

事实表的比对

	事务事实表	周期快照事实表	累积快照事实表
时间特点	离散事务时间点	固定的时间间隔	时间跨度不确定
粒度	每行代表一个事务度量事件	每行代表一个周期内的实体状态	每行代表一个实体的生命周期
日期维度	事务事件
适用场景	针对业务过程的事务分析	针对实体的状态分析	针对实体的生命周期分析
更新策略	不更新	周期结束时定期更新	业务过程更新时同步更新

设计的注意事项

粒度：每行中的数据是一个特定级别的细节数据

存储：应该尽量将来源于同一个业务过程的底层度量结果存储于一个维度模型中。

4.6 维度建模-建模步骤

业务建模=>逻辑建模=>物理建模。

4.6.1 业务建模（Conceptual Data Model）

梳理业务流程、统一业务概念、收集业务指标。

梳理业务流程，输入：（1）阅读BRD/MRD/PRD、技术方案、ER模型文档深入了解业务背景知识、各个系统的数据存储关系。（2）对相关业务人员进行调研，了解业务操作和日常工作，收集业务对数据的诉求，收集存量的报表。输出：（1）业务流程图；（2）业务知识文档；（3）特殊业务场景和坑点；（4）业务指标定义。

业务建模-划分主题

为什么划分主题？（1）明确主题边界，确认主题建设范围，分而治之，达成共识。例如：物流主题负责物流承运相关流程的核心数据，派单相关的划分到调度。（2）便于用户从较高层次理解使用数仓，提升检索数据效率。例如：数据地图提供按主题引导。（3）数据仓库管理的基础。例如：主题分工各负其责、业务过程归属，指标体系归类，元数据管理。

主题：指面向业务分析的场景下，将业务数据或分析视角数据进行重新抽象组织的集合，是从较高层次对企业业务进行划分的方式和组织。

常见分类如下：

业务主题：交易，履约、运力 (在B3层划分)

分析主题: 运力体验、盈亏分析，活动效果分析 (在B1层划分)

如何划分主题？

（1）按主业务流程进行划分

例如：提供物流履约服务就是主业务流程，根据业务上下游相关性，提供物流履约服务可以进一步拆解为销售、定价、交易、调度、履约、结算、售后(体验)等不同业务领域，可以对相应的业务领域构建对应的主题。

此类主题的特点是有多个参与主体参与；例如：履约主题需要由商家、配送员、用户等共同参与。

（2）对支撑业务流程按参与主体划分

例如：对于物流来说，参与主体有商家、配送员、用户等；可以对参与主体分别构建主题，用于存放与参与主体相关的支撑性业务流程。

例如：对人员招募、人员注册、人员入职、人员在职、人员离职等业务过程构建人员运营主题。

（3）按分析的视角划分

结合业务分析的场景进行抽象的主题，例如：人员体验、盈亏分析，人员留存，可以对这些分析主题进行专题的建设。

主题划分的依据

业务相关性原则：主题应该与业务需求密切相关，按照业务过程或业务功能进行划分。确保主题能够满足用户对特定业务领域的数据需求，便于业务分析和决策。
数据可比性原则：将具有相似属性和含义的数据放在同一个主题下，以便于数据的比较和分析。主题内的数据应该具有一致的定义和格式，方便用户进行数据的比较和统计。
数据可扩展性原则：主题应该具有良好的扩展性，能够适应业务的变化和扩展。在划分主题时，需要考虑到未来可能的业务需求和数据增长，避免频繁的主题调整和数据迁移。
数据可维护性原则：主题应该具有良好的可维护性，方便数据的更新和维护。在划分主题时，需要考虑到数据的来源和更新频率，确保数据的及时性和准确性。

4.6.2 逻辑建模（Logical Data Model）

梳理总线矩阵、划分业务过程、确定粒度/维度/事实/维度表/事实表设计。

1、构建总线矩阵

一致性维度：在数据仓库体系内部统一的维度关键字、一致的列名称、属性定义和属性值

一致性事实：在数据仓库体系内部每个度量统一的统计口径，对应唯一的业务概念术语

业务流程是由各个具体的事务流程组成，而事务是由各个业务系统支撑的业务过程来组成的，

可以转换成总线矩阵上的行、列最终形成维度模型

行：代表公司组织的一个业务过程

列：一致性维度

通过总线矩阵，可以清晰地识别出哪些业务过程需要哪些公共维度，并据此设计相应的维度表和事实表。这样，不仅能够保证数据的一致性和准确性，还能够提高数据仓库的查询性能和分析效率。

2、维度表设计

确定维度、填充维度属性、审查相关属性。

是否应该分层，是否可以拆分或整合。

3、事实表设计

1）选择业务过程：通过对业务的梳理和可用数据源的总和考虑，决定对那个业务过程展开建模，在主题域内根据情况会抽象新增/合并业务过程。

2）声明粒度：对于事务表，尽量保持最明细的粒度，原子数据能够提供最佳的分析灵活性。

3）确定维度：事实表的粒度确认完毕后，维度的选择就比较直接了。尽可能包含业务过程下所有维度；考虑是否退化维度；识别剩余的维度或维度属性是否必须；避免出现蜈蚣表；

4）确定事实：确定将那些事实放到事实表中，事实必须和粒度吻合。注意同一类指标的单位要统一。尽可能包含业务过程下所有原子指标，只选择和业务过程相关的原子指标，统一同类指标的单位。

4.6.3 物理建模（Physical Data Model）

定义物理模型、存储方式。

确定表名称/表文件格式/字段名称/字段类型及存储路径等

确定分区方式，一级分区/双分区/多级分区，分区字段的选择(时间年月日、业务字段)

确定数据初始范围

4.7 数仓整体分层

4.7.1 分层规范

层次	定义	对各层含义的具体理解	引擎
ODS	ods接入层,主要负责各种数据源的接入	接入层由工具完成，当前主要有mysql 和流量日志数据源。该层不对外开放	hive
ODS	ods准备区，主要完成进入dwd数据的准备工作，完成和接入层的解耦合。	由于接入层由工具完成，不受我们控制。我们需要在此基础上做一些解耦操作(生成快照表)，同时完成进入dwd的准备工作，例如过滤压测数据、脱敏操作等。在建模方式上基本和源系统结构保持一致。对于部分临时性探索分析，不一定会构建dwd，可以考虑对外开放这部分数据权限；其它场景均应该访问dwd处理过后的数据	hive
DIM	一致性维度层，对业务过程中的维度进行统一定义，消除不一致性，是实现总线架构基础。维度分为普通维度和衍生维度，区别在于衍生维度需要通过复杂计算(跨事实表、跨时间周期汇总）等才能产生	基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应	hive
DWD	Data Warehouse Detail 明细数据层，作为数据仓库最核心的区域，主要作用是通过数据加工与整合，完成对业务的抽象，对外提供简单、准确、详尽、一致的数据模型。	这部分主要完成以下工作： 1) 按业务主题域，采用维度建模面向业务过程构建明细事实表，完成对业务的抽象，及逻辑的封装，屏蔽数据源变化 2）完成统一指标的定义，指标定义规范注：DWD层的原子指标、衍生指标均不跨业务主题 3）数据质量保证	hive
DWS	Data Warehouse Summary汇总数据层，完成明细数据的汇总	主要对DWD层按照常用维度组合进行预聚合，不做任何逻辑封装，提升查询性能。时间类的衍生指标也存于该层，例如最近30天接单量。对于不可加指标(例如count distinct)，有三种实现方案，基于doris的ROLAP，基于kylin的MOLAP和基于hive的cube表，具体可以根据实际场景选择通常会有三类汇总表，分别是最近1天、最近N天、历史截止当天注：为了保证低耦合，高内聚，DWS层的聚合不跨业务主题	hive、kylin、doris
DM	为满足具体分析场景的数据特点和易用性，而构建的面向不同垂直领域的数据集市层，例如盈亏集市、AB集市、运力集市、商集市等；	基于DWD、DWS层和DIM的数据构建，内部数据可跨B3层主题域整合，或基于商业模型进行场景化的数据加工，满足业务、商分和产研的具体分析诉求，达成低成本、易使用的获取和分析数据的诉求；	hive、kylin、doris
APP	Application数据应用层，面向具体应用(报表、数据服务)构建，用于满足不同应用的个性化需求（例如行列转换，特殊排序要求)	面向具体应用构建，满足性能和客户化展示需求	kylin、doris、mysql、es

4.7.2 为什么分层（分层好处）

分层其实是一种数学思想，ETL直接从源到目标，所有逻辑就会杂糅在一起从而导致维护困难，所以我们会自然而然想到分层、封装等，把相近的逻辑放到一起。
分层是站在数仓全集的视角，对于一系列的计算过程抽象出通用的职责，规定每一层只做某些职责，每一层有自己独特的命名，并且不同层之间有明确的前后关系。

降低维护成本：修改成百上千行逻辑杂糅的ETL，需要一点一点理逻辑，修改维护成本相当高。通过将复杂的任务分解成多个步骤完成，每一层只处理单一的步骤，使得整个数据处理流程更加清晰和易于维护。这种分层设计有助于降低问题的复杂度，提高数据处理的效率。
隔离变化，屏蔽原始数据的异常：分层设计有助于将原始数据与加工后的数据隔离开来，避免原始数据的异常对后续数据处理和分析的影响。同时，通过分层可以对不同层的数据进行权限管理，确保数据的安全性和隐私性。
数据复用，提升一致性和开发效率：规范数据分层，开发一些通用的中间层数据，能够极大地减少重复计算和数据开发的工作量。不同的业务部门或项目可以共享这些中间层数据，避免了数据的重复处理，提高了数据资源的利用效率。
结构更清晰（统一）：每个数据分层都有其特定的作用域和职责，使得数据在使用和维护时更加方便和理解。例如，数据源层负责数据的采集和接入，数据加工层负责数据的整合和清洗等。这种清晰的层次结构有助于技术人员更好地协调开发和数据共享。
血缘清晰：通过命名规范区分不同的层，开发按照相同顺序进行生产，分层设计使得数据的来源和流向更加明确，避免开发和调度循环依赖。当数据出现问题时，可以快速定位到问题所在，并了解其对其他层次的影响范围，从而及时采取措施进行修复。
用空间换时间：开发角度，一次计算多出使用，节省计算成本；使用角度：通过大量的预处理来提升商分、业务的用户体验（效率），数据仓库会存储大量的冗余数据。这种设计虽然增加了存储空间的需求，但能够显著提高数据查询和分析的效率，满足用户对数据实时性和准确性的要求。
数据安全：通过分层设计，可以更方便地对不同层的数据进行安全控制。例如，对敏感数据进行加密存储和访问控制，防止数据泄露和非法访问。
增强扩展性，利于后期维护：分层设计使得数据仓库具有良好的扩展性和灵活性。随着业务的发展和变化，可以方便地调整和优化数据仓库的结构和层次，以满足新的业务需求和数据处理要求。同时，分层设计也有助于降低数据仓库的维护成本和提高维护效率。

综上所述，数据仓库分层设计是出于提高数据处理效率、降低问题复杂度、优化数据结构、实现数据血缘追踪、减少重复开发、保障数据安全以及增强扩展性和维护性等多方面的考虑。这种设计方式在现代数据管理和分析中发挥着重要作用。