数仓知识点

最新推荐文章于 2024-05-15 10:15:00 发布

原创最新推荐文章于 2024-05-15 10:15:00 发布 · 970 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#数据仓库

本文介绍了数据建模的不同模型，包括星型、雪花和星座模型，以及三范式建模方法。维度建模在数据分析中的重要性被强调，同时阐述了数仓分层的目的和好处，如提升查询效率和保证数据一致性。此外，讨论了主题域划分、事实表的创建过程以及缓慢变化维的处理策略。文章还提到了数据仓库的一致性保证和性能优化方法，强调了数仓建设的步骤和重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

数据建模模型

星型模型

以一个事实表为中心；
所有维度表直接连接事实表；
所有维度表之间没有关联；
每个维度表主键为单列，主键位于事实表，维度信息位于维度表，通过 id 关联；
以事实表为核心，维表围绕核心呈现星形分布

雪花模型

以一个事实表为中心；
维度表可以拥有其他维度表；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-refIgT48-1689858540492)(%E6%95%B0%E6%8D%AE%E4%BB%93%E5%BA%93.assets/image-20230622095034708.png)]

星座模型

基于多个事实表，共享维度信息；
多个维度可以是多个事实表共享；

在这里插入图片描述

三范式建模

E-R 实体-> 关系模型，强调数据非冗余，满足 3NF，面向主题的抽象

1NF：属性不可再分
2NF：列不可部分依赖
3NF: 列不可传递依赖

关系模型：

过程比较长，要理解每个 3NF 关系，业务过程，实施周期长
自上而下建立，从数据源 - 数据仓库 - 数据集市，以数据源为导向，模型偏向 3NF
企业主题的抽象，不单独描述某个业务

这种建模方式是整合数据，其目的是将整个企业的数据进行组合和合并，并进行规范处理，减少数据冗余性，保证数据的一致性。这种模型不适合直接用于分析统计。

维度建模

维度建模将复杂的业务通过事实和维度两个概念进行呈现。

按照事实表，维度表构建数据集市，星型模型，雪花模型，星座模型
适合部门，小范围的主体进行快速构建，不满足 3NF
以业务过程为中心，自下而上的建立，从数据集市(主题划分) - 数据仓库 - 数据抽取，
以需求为导向，模型为星型模型，星座模型，混合模型
增加了数据冗余，可以保障数据的完整性
建模越规范，划分的表越多，进行关联查询的表越多

维度建模以数据分析作为出发点，为数据分析服务。因此它关注的重点是用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。

数仓分层用处

用空间换时间 ，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作。

数仓分层好处

清晰的数据结构，每层都有职责和作用，在发生问题时，易于定位、追踪血缘
减少重复开发，开发中间层，宽表，减少重复计算
统一数据口径
复杂问题简单化，一个复杂的问题可以拆分为多个步骤，每一次解决一个特定的问题；

主题域（业务过程）

主题域是对业务过程的高度概括总结；

划分主题域

在业务调研之后，就可以划分主题域

按照业务系统（基于不同的部门，实际还是按照业务过程）：机台，游戏，用户，订单，设备，商品
按照业务过程：下单购买，投注，启动，奖励，异常

划分主题域的好处

可以基于门类把数据抽象为一类，易于管理

拉链表的理解，全量拉链表，增量拉链表

全量表：每次获取全量数据
增量表：每次获取增量数据
拉链表：每日全量 & 每日增量，用于维护历史状态，以及最新状态数据的一种表。

新增散列：开始时间，结束时间，有效标示

拉链表的构建过程

在这里插入图片描述

拉取第一天的状态数据放入拉链表，并设置开始生效时间和生效结束时间（第一次肯定是无效大）；
拉取第二天的状态数据放入临时拉链表；
将第一天的拉链表数据与第二天的源表数据left join修改第一天拉链表状态的时间，并放入临时拉链表；
将临时拉链表中的数据覆盖拉链表的数据，完成拉链表的构建。

事实表创建过程

选择业务过程

维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求及日后的易扩展性等进行选择业务。
声明粒度

在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。
确认维度

如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性。将事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一
确认事实

事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。

在这里插入图片描述

数仓分层实战

在这里插入图片描述

数据源`ODS`

将各个业务数据导入到大数据平台，作为业务数据的快照存储
无需对数据做任何处理，直接保存即可。

数据明细层`DW`

事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据 – 粒度。
同一个事实表中的所有度量必须是完全相同的粒度
维度表一般是单一主键，少数为联合主键
维度表不要出现重复数据
最实用的事实就是数值类型和可加类事实。
- 可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实；
- 如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性。
- 但是还是要结合业务进行最终判断是维度还是事实。

数据轻度汇总`DM`

开始对数据进行汇总，但是不是完全汇总，只是对相同粒度的数据进行关联汇总
不同粒度但是有关系的数据也可进行汇总，此时需要将粒度通过聚合等操作进行统一

数据应用层`APP, ADS`

数据应用层的表就是提供给用户使用的
直接进行报表展示，或提供给数据分析的同事所需的数据，或其他的业务支撑。

数仓的重要性

数据模型是数据组织和存储方法，强调从业务、数据存储和使用角度合理存储数据，只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用。

数据的准确性；
数据的真正价值在于数据驱动决策，通过数据指导运营。

元数据管理

技术元数据

存储元数据，如表、字段、分区等信息。记录了表的中英文名及表状态，分区信息，责任人信息、对应主题、文件大小、表类型、生命周期、权限信息等

运行元数据：类似于 Hive Job 日志，包括作业类型，实例名称，输入输出，SQL，运行参数，执行时间，执行引擎

数据开发平台中数据同步，计算任务，任务调度等信息

数据质量和运维相关元数据，如任务监控，运维报警，数据质量，故障等信息，包括任务监控运行日志，告警配置及运行日志，故障信息等
业务元数据

包括维度编码，字段类型，创建人，创建时间，状态等；业务过程，指标(包含指标名称，指标编码，业务口径，指标类型，责任人，创建时间，状态， sql)，安全等级，计算逻辑等的规范化定义，用于更好地管理和使用数据；数据应用元数据，如数据报表，数据产品等的配置和运行元数据。

a. Excel 手工录入保存
b. 自研系统
c. Atlas 元数据管理

事实表

事务事实表

粒度比较低，面向事务，其粒度是每一行对应一个事务，它是最细粒度的事实表

设计流程
- 选择业务过程（选择业务过程可以确定有哪些事务型事实表）
  
  在业务系统中，挑选我们感兴趣的业务过程。一个业务过程对应一张事务性事实表
- 声明粒度（可以确定每张事务型事实表的每行数据是什么）
  
  精确定义每张事务性事实表的每行数据表示什么，尽可能选择最细粒度（秒，商品，人），用于后续各种需求的处理。
- 确定维度（可以确定每张事务型事实表的维度外键）
  
  确定与事务性事实表相关的维度数据，尽量多的选择与业务过程相关的环境信息
- 确定事实（可以确定每张事务型事实表的度量值字段）
  
  每个业务过程的度量值（次数、个数、金币、金额）

周期快照事实表

按照一定的时间周期间隔来捕捉事务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充通常粒度比较高，例如账户月平均月事实表

设计流程
- 确定粒度
  
  周期型快照事实表的粒度可由采样周期和维度描述，故确定采样周期和维度后即可确定粒度。
- 确认事实
  
  周期型快照事实表的粒度可由采样周期和维度描述，故确定采样周期和维度后即可确定粒度。
  - 可加事实
    
    按照与事实表相关的所有维度进行累加，例如事务型事实表中的事实。
  - 半可加事实
    
    只能按照与事实表相关的一部分维度进行累加，例如周期型快照事实表中的事实。
  - 不可加事实
    
    完全不具备可加性，例如比率型事实。不可加事实通常需要转化为可加事实，例如比率可转化为分子和分母。

累积快照事实表

用来记录具有时间跨度的业务处理过程的整个过程的信息，每个生命周期一行，通常这类事实表比较少见

订单id	用户id	下单日期	支付日期	发货日期	确认收货日期	订单金额	支付金额
1001	1234	2020-06-14	2020-06-15	2020-06-16	2020-06-17	1000	1000

设计流程
- 选择业务过程
  
  选择一个业务流程中需要关联分析的多个关键业务过程，多个业务过程对应一张累积型快照事实表。
- 声明粒度
  
  精确定义每行数据表示的是什么，尽量选择最小粒度。
- 确认维度
  
  选择一个业务流程中需要关联分析的多个关键业务过程，多个业务过程对应一张累积型快照事实表。
- 确认事实
  
  选择各业务过程的度量值。

缓慢变化维的处理

直接覆盖原值，类似于全量表
增加维度行：在为维度成员增加行时，需为其分配新的主代理键。并且至少需要在维度行再增加三行：有效日期、截止日期、行标识。类似于拉链表的设计
新增属性列：开始时间，结束时间

维度退化

维度退化是指在DWD层抽取主题域数据时，将常见的维度退化到事实表中。

对维度常见的处理方式为：

某个维度表只有一个描述时，可以将该维度描述作为DWD表数据的一部分；
某个维度表中有多个描述时，可以将该维度id作为DWD表数据的一部分；

维度属性也可以存储到事实表中，这种存储到事实表中的维度列被称为“退化维度”。与其他存储在维表中的维度一样，退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。那么究竟怎么定义退化维度呢？比如说订单id，这种量级很大的维度，没必要用一张维度表来进行存储，而我们进行数据查询或者数据过滤的时候又非常需要，所以这种就冗余在事实表里面，这种就叫退化维度，citycode这种我们也会冗余在事实表里面，但是它有对应的维度表，所以它不是退化维度。

数仓一致性是如何保证的

数仓一致性是指多个数仓系统之间的数据保持一致性。这通常是通过使用两阶段提交（2PC）或多版本并发控制（MVCC）来实现的。

两阶段提交是一种分布式事务处理协议，用于在多个数据库系统之间保证事务的一致性。它包括两个阶段：第一阶段是预提交阶段，所有参与者都会把事务的更改提交到本地数据库中，但是这些更改并不会对其他系统可见。在第二阶段，所有参与者都会把事务提交到其他系统中，从而使得所有系统的数据保持一致。

多版本并发控制是另一种用于维护数仓一致性的方法。它通过在每个事务中保存一个版本号来实现。当一个事务开始时，它会读取当前的版本号，然后在更新数据时将版本号加 1。这样，如果另一个事务试图在相同的数据上进行更新，它会检测到版本号不匹配，从而防止冲突。

提高查询效率

优化数据库结构，统一管理所有数据，减少查询的次数；
使用缓存技术，将查询结果保存到内存中，加速查询；
合理利用索引，提高查询的效率；
采用分布式系统，将查询任务分发到多台机器，提高查询速度；
采用消息队列技术，将批量数据进行拆分，减少查询时间；
利用数据库定时备份技术，减少查询时间；
采用数据库分片技术，将数据分布到多个数据库，提高查询效率；
采用数据库视图技术，将复杂的SQL语句拆分为多个简单的SQL语句，提高查询效率；
采用SQL优化技术，充分利用数据库的索引，提高查询效率；
采用数据库集群技术，将数据分布到多个数据库服务器，提高查询效率；

数仓高内聚低耦合是怎么做的

高内聚

强调模块内部的相对独立性，要求模块内部的元素尽可能的完成一个功能，不混杂其他功能，从而使模块保持简洁，易于理解和管理。
低耦合

模块之间的耦合度要尽可能的低，避免模块之间的复杂依赖，使得每个模块都可以独立存在，从而减少模块间的相互影响，提高系统的可维护性。

一般复杂的公共逻辑可以采用抽象类和抽象方法的方式下沉到共有模块中，然后由相关子类去实现抽象方法，来实现不同的功能。这样可以将复杂的逻辑拆分成各个子类，使得类之间的耦合度降低，提高代码的可维护性。

数仓中多重粒度的作用

在数据仓库中，粒度是指数据的细度。粒度越高，表示数据越细致，每个数据点所包含的信息量也就越大。粒度越低，表示数据的概括性越强，每个数据点所包含的信息量也就越小。

在数据仓库中，多重粒度指的是将数据按照多个不同的粒度进行存储，以便在需要时更方便地进行查询和分析。例如，可以将数据按年、月、日等不同的粒度进行存储，以便根据需里对数据进行按年、按月、按日等不同维度的分析。

多重粒度数据仓库可以让我们更方便地对数据进行分析和查询，具体有以下几点作用:

提高查询效率: 将数据按照多个不同粒度存储，可以让我们更快地找到所需的数据。例如，如果我们需要查询某一天的销售数据，直接查询按日粒度存储的数据即可，而不用扫描整个数据仓库。
减少数据冗余:在数据仓库中，将数据按照多个粒度存储，可以减少数据几余，节省空间。例如，如果我们将每一天的销售数据都单独存储，那么一年的数据就需要存储 365 天的数据;如果将每一月的销售数据存储，则一年的数据只需要存储 12 个月的数据。
方便数据分析:多重粒度数据仓库可以让我们更方便地对数据进行分析。例如，如果我们想要对某一天的销售数据进行分析，可以直接查询按日粒度存储的数据;如果想要对某-月的销售数据进行分析，可以直接查询按月粒度存储的。

在数据仓库中实现多重粒度是指在数据仓库中设计多种方式来表示和存储时间相关的数据。这样就可以在不同的粒度(例如年、月、日、小时等)》上查询数据，从而满足不同的分析需求

时间维度表

将时间的不同粒度分别建立为单独的维度表，并与事实表进行关联。例如，可以建立年、月、日、小时等维度表，并通过外键关联到事实表中。
时间层级表

将时间的不同粒度存储在同一个表中，并设计为层级结构。例如，可以将时间表设计为“年-月-日-小时”的层级结构，将每个时间点都存储在同一个表中。

具体选择哪种方式，取决于业务需求和数据查询的频率。

时间维度表的优势在于查询速度快，但维护成本较高，需要单独维护多个表。

时间层级表的优势在于维护成本低，但查询速度可能较慢。

粒度操作

上卷

上卷指的是增加粒度，将原来比较细的粒度提升到更大的粒度，从而让整体更清晰，更容易理解，更容易把握。
下钻

下钻指的是减小粒度，将原来比较粗的粒度放低到更细的粒度，从而更加细致的把握数据的细节，更加清楚的把握数据的特征。
切片

切片指的是将数据分割成若干个数据片，从而更加方便地进行管理和操作。
切块

切块指的是将数据分割成若干个数据块，从而更加方便地进行管理和操作。
旋转

旋转指的是对数据进行旋转操作，从而让数据看起来更加美观，更容易理解。
拉伸

拉伸指的是对数据进行拉伸操作，从而让数据看起来更加清晰，更容易理解。
锯齿

锯齿指的是对数据进行锯齿操作，从而让数据看起来更加精细，更容易理解。

数仓建设步骤（重点）

数仓建设是遵循纵向分层开发，横向划分主题域设计。数仓建模的过程分为业务建模、领域建模、逻辑建模和物理建模。

梳理业务流程

找到核心业务流程，找到谁，在什么环节，做什么关键动作，得到什么结果。
垂直切分（划分主题域）
- 数仓的建设方式： 自下而上 和 自顶而下。自下而上,简单快捷，快速交活。要全面支撑，就顶层规划，分步实施，交活稍微慢点。
- 同时按照业务领域划分主题域。主题域的划分方法有：按业务流划分（推荐）、按需求分、按职责分、按产品功能分等。
指标体系梳理（DWS）
- 指标的意义在于统一语言，统一口径。所以指标的定义必须有严格的标准。
- 指标可分为原子指标、派生指标和衍生指标。
- 依照指标体系建设标准，开始梳理指标体系。整个体系同样要以业务为核心进行梳理。同时梳理每个业务过程所需的维度。
- 如果分析出这个业务过程应该有这个指标，但是没有数据，请标注出来，提出收集数据的需求。
表实体关系调研（DWD）
- 每个业务动作都会有数据产生。我们将能够获取到的数据，提取实体，绘制ER图，便于之后的维度建模。
- 同样以业务过程为起点向下梳理，此时的核心是业务表。把每张表中涉及的维度、指标都整理出来。
维度梳理（DIM）
- 维度标准化是将各个业务系统中相同的维度进行统一的过程。字段名称、代码、名字都可能不一样，需要完全掌握，并标准化。
- 维度的标准尽可能参照国家标准、行业标准。绝大多数业务系统中的级联就是多层级维度。
数仓分层
- 每一层采用的建模方法都不一样，其核心是逐层解耦，减少重复计算，降低烟囱式开发。越到底层，越接近业务发生的记录，越到上层，越接近业务目标。
- 依托数仓分层的设计理论，根据实际业务场景，我们就可以梳理出整体的数据流向图。这张图会很清晰的告诉所有人，数据从那来，到哪里去，最终提供什么样的服务。
物理模型建立（开发）
- 真正进入纯代码阶段。数仓、ETL工具选型；ETL流程开发；cube的建立；任务调度，设定更新方式、更新频率；每日查看日志、监控etl执行情况等等