数仓建模与分析建模_数据仓库建模与数据挖掘建模

大家好，又见面了，我是你们的朋友全栈君。

1. 数仓概述

数据仓库： 数据仓库是一个面向主题的、集成的、非易失的、随时间变化的数据集合。重要用于组织积累的历史数据，并且使用分析方法（OLAP、数据分析）进行分析整理，进而辅助决策，为管理者、企业系统提供数据支持，构建商业智能。

面向主题：为数据分析提供服务，根据主题将原始数据集合在一起。

集成的：原始数据来源于不同的数据源，要整合成最终数据，需要经过 ETL（抽取、清洗、转换）的过程。

非易失：保存的数据是一系列历史快照，不允许被修改，只允许通过工具进行查询、分析。

时变性：数仓会定期接收、集成新的数据，从而反映出数据的最新变化。

数据仓库 VS　数据库

数据库面向事务设计，属于OLTP（在线事务处理）系统，主要操作是随机读写，在设计时尽量避免冗余，采用符合范式规则来设计。

数据仓库是面向主题设计的，属于 OLAP（在线分析处理）系统，主要操作是批量读写，关注数据整合，以及分析、处理性能；会有意引入冗余，采用反范式方式设计。

	数据库	数据仓库
面向	事务	分析
数据类型	细节、业务	综合、清洗过的数据
数据特点	当前的、最新的	历史的、跨时间维护
目的	日常操作	长期信息需求、决策支持
设计模式	基于 ER 模型，面向应用	星形 / 雪花模型，面向主题
操作	读 / 写	大多为读
数据规模	GB ~ TB	>= TB

2. 数仓分层

数仓分层：

数据应用层（ADS，Application Data Store）数据主题层（DWT，Data Warehouse Topic）数据汇总层（DWS，Data Warehouse Summary）明细数据层（DWD，Data Warehouse Detail）原始数据层（ODS，Operation Data Store）

数仓为什么分层

隔离原始数据：不论是数据异常还是数据的敏感性，使真实数据与统计数据解耦开
把复杂问题简单化：将复杂任务分解多层，每层处理简单的任务，方便定位各位问题
减少重复开发：规范数据分层，通过中间层数据，能够减少大量重复计算，增加一次计算结果的复用性

ETL 流程：

ETL – Extract – Transform – Load 构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。

数据抽取

抽取的数据源可以分为结构化数据、非结构化数据、半结构化数据
结构化数据一般采用 JDBC、数据库日志方式，非 / 半结构化数据会监听文件变动。

抽取方式

数据抽取方式有全量同步、增量同步两种方式
全量同步会将全部数据进行抽取，一般用于初始化数据装载
增量同步方式会检测数据的变动，抽取发生变动的数据，一般用于数据更新

数据转换

数据转换需要经历数据清洗、转换两个阶段
- 数据清洗：对出现的重复、二义性、不完整、违反业务或逻辑规则等问题的数据进行统一的处理
- 数据转换：对数据进行标准化处理，进行字段、数据类型、数据定义的转换
结构化数据在转换过程中的逻辑较为简单，非 / 半结构化数据的转换较为复杂

数据加载

将最后处理完的数据导入到对应的目标源里

ETL 策略

全量同步：

数据初始化装载时，一定使用全量同步的方式
使用全量同步的方式做周期数据更新，直接覆盖原有数据即可

增量同步：

传统数据整合方案中，大多采用 merger 方式（insert update）
主流大数据平台不支持 update 操作，可采用全外连接数据全量覆盖方式（如果能 join 到说明历史有该数据，则为变化数据；如果join不到，则为新增数据）

如果担心数据更新出错，可以采用分区方式，每天保存最新的全量版本，保留较短周期。

操作数据层（ODS）

数据与原业务数据保持一致，可以通过增加字段方式对数据整理
- 业务系统对历史数据完成修改后，在字段中进行标识，而不覆盖元数据。
存储的历史数据是只读的，提供业务系统查询使用
在离线数仓中，业务数据定期提供 ETL 流程导入到 ODS 中，导入方式有全量、增量。

数据明细层（DWD）

数据明细层对 ODS 层的数据进行清洗、标准化、维度退化（时间、分类、地域）
满足 3NF 模型，用于数据分析

数据汇总层（DWS）

对 DWD 层的数据，按照主题进行计算汇总，存放的是便于分析的宽表
非 3NF，注重数据聚合

数据应用层（ADS）

数据应用层也被称为数据集市
存储数据分析结果，为不同业务场景提供接口，减轻数据仓库的负担
为数据应用层的报表决策、并发查询、搜索检索提供支持

3. 模型分类

OLTP（在线事务处理）系统中，主要操作是随机读写，为了保证数据一致性、减少冗余、常使用关系模型，满足第三范式。

OLAP（在线联机分析）系统中，主要操作是复杂的分析查询；关注数据整合，以及分析、处理性能。

OLAP 按照数据存储方式的不同，可分为 ROLAP、MOLAP、HOLAP。 ROLAP（关系型 OLAP，Relation OLAP）：使用关系模型构建，存储系统一般为 RDBMS MOLAP（多维性 OLAP，Multidimensional OLAP）：预先聚合计算，使用多维数组的形式保存数据结果，加快查询分析时间 HOLAP（混合架构的 OLAP，Hybrid OLAP）：两者的集成，如底层是关系模型，高层是多为矩阵型；查询效率高于 ROLAP，低于 MOLAP

ROLAP 系统建模

ROLAP：ER 模型、维度模型、Data Value、Anchor

ER 模型：
1. 出发点是整合数据，为数据分析决策提供服务
2. 需要全面了解业务和数据
3. 实施周期长
4. 对建模人员能力要求高
维度模型：
1. 为分析需求服务，更快完成需求分析
2. 具有较大规模复杂查询的响应性能
3. 最流行的数仓建模方法
Data Value
1. ER 模型的衍生
2. 强调数据的历史性、可追溯性、原子性
3. 弱化一致性处理和整合
4. 引入范式，应对源系统的扩展性
Anchor
1. Data Value 模型的衍生
2. 初衷为设计一个高度扩展模型
3. 会带来较多的 join 操作

维度模型

维度模型的分类

星型模型：维度只有一层，分析性能最优

雪花模型：具有多层维度，比较接近 3NF，较为灵活

星座模型：基于多个事实表，事实表之间会共享一些维度表

模型选择：优先考虑星型模型

维度模型表的分类

事实表：

一个现实存在的业务对象，每行数据代表一个业务事件。

维度表：

对事实的描述信息。
每一张维度表对应现实世界中的一个对象或者概念，如用户、商品、日期、地区。
通常使用维度对事实表中的数据进行统计、聚合运算。

事务事实表：

以每个事务或事件为单位，随着业务不断产生的数据，一旦产生不会再变化，比如交易流水、操作日志、出库入库记录。

周期快照事实表：

不会保留所有数据，只保留固定时间间隔的数据。
随着业务周期的推进而变化，可完成间隔周期内的度量统计，比如年、季度累计。
使用周期状态度量的组合，如年累计订单数（年是周期、订单总户数是度量）。

累计快照事实表：

用于跟踪业务事实的变化。
记录不确定周期的度量统计，完全覆盖一个事实的生命周期，如订单状态。
通常具有多个时间字段，用于记录生命周期中关键的时间点（如下单时间、支付时间、确认收货时间）。

实现方式一 使用日期分期表，全量数据记录，每天的分区存储昨天全量数据与当天的增量数据合并的结果数据量大会导致全量表膨胀，存储大量永远不更新的冷数据，降低性能使用于数据量少的情况
实现方式二 使用日期分期表，推测数据最长生命周期，存储周期内数据；周期外的冷数据存储到归档表需要保留多天的分区数据，存储消耗依然很大
实现方式三 使用日期分区表，以业务实体的结束时间分区，每天的分区存放当天结束的数据；设计一个时间非常大的分区，如 9999-12-31，存放截至当前未结束的数据已结束的数据存放到相应的分区，存放未结束数据分区，数据量不会太大，ETL 性能好无存储浪费，数据全局唯一业务系统可能无法标识业务实体的结束时间，可以使用其他相关业务系统的结束标志作为此业务系统的结束，也可以使用最长生命周期时间或者前端系统的数据归档时间

拉链表：

记录每条信息的生命周期，用于保留数据的所有历史（变更）状态
拉链表将表数据的随机修改方式，变为顺序追加

宽表模型

宽表模型是维度模型的衍生，适合 join 性能不佳的数仓产品。宽表模型是将维度冗余到事实表中，形成宽表，依次减少 join 操作。

宽表出现在DWD层、DWS层，由于宽表是将不同的内容组合到一张表中，所以宽表不满足范式要求，但是再增加冗余的同时提高了查新的性能（减少 join）。

MOLAP 系统建模

MOLAP 将数据进行预结算，并将数据结构存储到 CUBE 模型中。MOLAP 产品：Kylin、Druid

CUBE 模型以多维数组的形式，物化到存储系统中，加快后续的查询。生成 CUBE 需要大量的时间、空间，维度预处理可能会导致数据膨胀。

MOLAP 对复杂查询操作做了直观的定义，包括钻取、切片、切块、旋转。

钻取：

钻取是对不同层次的分析，通过改变维度的层次来变化分析的粒度。

钻取包括上卷（Roll-up）、下钻（Drill-down）。

上卷：向上钻取，指从底层次到高层次的却换
下钻：指从高层次到低层次的切换

切片（Slice）：

选择某个维度进行分隔称为切片

切块（Dice）：

按照多维进行的切片称为切块

旋转（Pivot）：

对维度方向的互换，类似于交换坐标轴上卷。

[外链图片转存中…(img-uQis5F2c-1645262440294)]

范式

第一范式：属性不可分割

第二范式：消除不分函数依赖

第三范式：消除传递依赖

关系建模与维度建模

关系建模：将复杂的数据抽象为两个概念——实体和关系，并使用规范化的方式表示出来。

维度建模：模型相对清晰、简洁。维度模型以数据分析作为出发点，不遵循三范式，故数据存在一定的冗余。维度模型面向业务，将业务用事实表和维度表呈现出来。

4. 数仓建模方法

ODS：

数据类型：用户行为数据、业务数据
规划处理
- 保持数据源不做修改，起到备份数据的作用
- 数据采用压缩，减少磁盘存储空间
- 创建分区表，防止后续的全表扫描

DWD：

DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

维度建模一般按照以下四个步骤：选择业务过程→声明粒度→确认维度→确认事实。

选择业务过程
- 在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
声明粒度
- 数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
- 声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
确认维度
- 确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。
确认事实
- 此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。
- 在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

DWD层是以业务过程为驱动。 DWS层、ADS层都是以需求为驱动，和维度建模已经没有关系了。 DWS层建宽表，按照主题去建表。主题相当于观察问题的角度，对应着维度表。

DWS：

DWS称宽表层，这两层的设计思想大致相同，通过以下案例进行阐述。

问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额
处理办法：都是将省份表和订单表进行join，group by省份，然后计算。同样数据被计算了两次，实际上类似的场景还会更多。

那怎么设计能避免重复计算呢？针对上述场景，可以设计一张地区宽表，其主键为地区ID，字段包含为：下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算，并将结果保存在该宽表中，这样就能有效避免数据的重复计算。

总结：
- 需要建哪些宽表：以维度为基准。
- 宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。

ADS：

如对电商系统各大主题指标分别进行分析。

5. 写在最后

事实表同步策略：

事务型事实表：适用于数据写入后不会发生变化的业务，增量同步；
周期型快照事实表：只关心每天、每周（时间间隔）的结果，每个周期全量同步
累积性全量事实表：适用于会发生周期性变化的业务，数据多累计写入（修改），新增及变化同步

DWD层构建维度模型策略：

确认维度模型中的事实表
声明事实表的（最小）粒度，及声明每行数据是什么
确认事实表的维度外键有哪些
确实事实表的度量值字段

❤️ END ❤️

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/190379.html原文链接：https://javaforall.cn

数据库 sql 数据分析存储

0 人点赞