数仓学习笔记

目录

1.数据处理方式

2.数据建模

2.1关系建模

2.1维度建模

3.维度表分类

3.1维度表

 3.2事实表

3.2.1事实表特征

3.2.2事实表分类 

4.数据组织类型 

4.1星型模型

4.2雪花模型

 4.3.星座模型

5.数仓特征 

5.1. 面向主题

5.2. 集成性

5.3. 不可更新

5.4. 时变性

 6. 数据仓库分层

6.1 数仓分层原因

6.2 数仓分层好处

6.3 数仓分层明细 

6.3.1 ODS原始数据层

6.3.2 DW数据仓库层

6.3.3 ADS数据服务层

7.阿里数仓五层 

 7.1. ODS

7.2. DWD

7.3. DWS

7.4. DWT

7.5. ADS

8.数据仓库规范设计

8.1. 表命名规范

 8.2. 开发规范

 8.3. 流程规范

9. 常见概念描述

9.1 数据仓库

9.2 数据集市

9.3. 数据孤岛 

9.4. 数据湖

 9.5. 数据中台

10. 宽表窄表

10.1 宽表

10.2 窄表

11. ETL

11.1 概念：

11.2 模块介绍

---

1.数据处理方式

数据处理方式主要有两种，OLAP和OLTP

• 联机事务处理OLTP（on-line transaction processing）
• 联机分析处理OLAP（on-line analytical processing）

1. OLTP要求遵循ACID原则，是针对事务管理的处理方式，要求快速响应，当前数据量相对较小，但是每天生成的日志数据会很大，主要关注增删改查，典型的例如Mysql。
2. OLAP分析速度相对较慢，历史数据量大，查询频率相对较低，处理结果提供给分析决策人员使用，是一个多维模型。

OLAP基本操作：

• 上卷：roll-up drill-up
  • 通过一个维的概念分层向上攀升或者通过维归约在数据立方体上进行聚集。
  • 比如城市统计数据维度到省级统计数据维度。
• 下钻：drill-down
  • 下钻是上卷的逆操作，由不太详细的数据到更详细的数据
  • 下钻可以通过沿维的概念分层向下或引入附加的维实现。
• 切片：slice
  • 在给定的立方体一个维上进行选择，从而定义一个子立方体
• 切块：dice
  • 通过两个或多个维上进行选择，定义一个子立方体
• 转轴：pivot
  • 是一种目视操作，就像是一个二维表的行列转换，两个维度互换
• 钻过：drill-across
  • 其执行会涉及多个事实表的查询
• 钻透：drill-through
  • 下钻透过多维数据立方直达RDMS表

2.数据建模

数据建模指的是对现实世界各类数据的抽象组织，确定数据库需管辖的范围、数据的组织形式等直至转化成现实的数据库。

2.1关系建模

符合三范式的标准，减少了数据的冗余，提高了查询的效率，但是进行数据分析的时候有可能会导致表的层次比较深，建表的话用powerdesigner实现即可，学校大作业已实现多次，不再赘述。

2.1维度建模

维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成需求分析，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。

        维度建模优缺点：

• 优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快完成分析需求，较好的大规模复杂查询的响应性能
• 缺点：维度表的冗余会比较多，视野狭窄。

 

 两者差别：

关系建模录入数据简单，维度建模处理数据、数据分析简单。

3.维度表分类

在维度建模中，将度量称为“事实”，将环境描述为“维度”。 

3.1维度表

 一般是对事实的描述信息，每一张维度表对应现实世界中的一个对象或概念。

维度表特征

• 维度表的范围很宽
• 跟事实表相比，行数较少（通常少于10万行）
• 内容相对固定

 维度建模四部曲

选择业务处理过程>定义粒度>选择维度>确定事实

• 选择业务：处理感兴趣的业务线，如下单，支付，退款，活动
• 声明粒度：一行代表信息：一条订单？一天的订单？一周的订单？选择最小粒度
• 确认维度：维度退化：谁 什么时间 什么地点
• 确认事实：度量值：如个数、件数、金额。

 设计原则

•  维度属性尽量丰富，为数据使用打下基础
• 给出详实的、富有意义的文字描述
• 区分数值类属性和事实
  • 数值类字段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性，如果通常用于参与度量计算，则是作为事实。比如商品价格，可以用于查询约束条件或统计价格区间的商品数量，此时是作为维度属性使用；也可以用于统计某类目下的商品的平均价格，此时是作为事实使用。另外，如果数值型字段是离散值，则作为维度属性存在的可能性较大，如果数值型字段是连续值，则作为度量存在的可能性较大，但并不绝对，需要同时参考字段的具体用途
• 沉淀出通用的维度属性，为建立一致性维度做好铺垫
  • 有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表的不同字段混合处理得到，或通过对单表的某个字段进行解析得到。此时，需要尽可能多的通用的维度属性进行沉淀。
  • 一方面，可以提高下游使用的方便性。
  • 另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。
• 退化维度
  • 在维度类型中，有一个重要的维度称作为退化维度。这种维度指的是直接把一些简单的维度放在事实表中。退化维度就是那些看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表。
• 缓慢变化维
  • 维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维，缓慢变化维一般使用代理键作为维度表的主键。

 3.2事实表

 表中的每行数据代表一个业务。“事实”表示的是业务事件的度量值（可以统计次数、个数、金额等）

3.2.1事实表特征

• 非常的大
• 内容相对较窄
• 经常发生变化，每天新增很多

3.2.2事实表分类 

• 事务性事实表
  • 以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。
  • 一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
• 周期型快照事实表
  • 周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，以具有规律性的、可预见的时间间隔记录事实。
  • 例如每天或每月的总销售金额，或每月的账户余额等。
• 累积型快照事实表
  • 累积快照事实表用于跟踪业务事实的变化，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。
  • 例如数据仓库中可能需要累计或存储订单从下单开始，到订单商品被打包、运输、签收等各个业务阶段的时间点数据，来跟踪订单生命周期的进展情况。
  • 当这个业务过程进行时，事实表的记录也要不断更新。
•  

4.数据组织类型 

4.1星型模型

• 是一种多维的数据关系，它由一个事实表和一组维度表组成。每个维度表都有一个维作为主键，所有这些维的主键组合成事实表的主键。
• 星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，所以数据有一点的冗余。

4.2雪花模型

•  当有一个或多个维度表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。
• 雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的“层次”区域，这些被分解的表都连接到主维度表而不是事实表。
• 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花模型结构去除了数据冗余。

 4.3.星座模型

• 星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故也称为星系模型
• 星座模型是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座模型只反映是否有多个事实表，他们之间是否共享一些维度表。

  模型选择

• 模型的选择跟数据和需求有关系，跟设计没关系。
• 星型还是雪花，取决于性能优先，还是避免冗余、灵活更优先。
• 实际企业开发中，一般不会只选择一种，需要根据情况灵活组合，甚至并存（一层维度或多层维度都保持）。
• 整体来看，更倾向于维度更少的星型模型。尤其是大型数据仓库项目，减少表连接的次数，可以显著提升查询效率。

5.数仓特征 

数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持。它出于分析性报告和决策支持目的的创建。

数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。

数据仓库研究和解决从数据库中获取信息的问题。数据仓库的特征在于面向主题、集成性、稳定性和时变性。

5.1. 面向主题

•  数据仓库中的数据是按照一定的主题域进行组织。
• 主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。而操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离。
• 每一个主题基本对应一个宏观分析领域。
• 主题是对应企业中某一宏观分析领域所涉及的分析对象（重点是分析的对象）。例如“销售分析”就是一个分析领域，这个“销售分析”所涉及到的分析对象为商品、供应商、顾客、仓库等，那么数仓主题可以确定为商品主题、供应商主题、顾客主题、仓库主题；联系到上文“销售分析”可以作为一个主题域；如果“产品分析”是一个分析领域，“产品分析”所涉及到的分析对象为商品、地域、时间、类别等，那么数仓的主题确定为商品主题、地域主题、时间主题、类别主题，“产品分析”也可以作为一个主题域。

5.2. 集成性

数据仓库中的数据是在原有分散的数据库数据抽取、清洗的基础上经过加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。面向事务处理的操作性数据库通常与某些特定的应用相关，数据库之间相互独立，往往是异构的。

数据仓库的数据有来自分散的操作型数据数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库，这一步是数据仓库中最关键、最复杂的一步，所有完成的工作有：

1. 要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不统一等等。
2. 进行数据综合和计算，数据仓库中的数据综合工作可以在从源数据库中抽取时生成，但许多是在数据仓库内部生成的。

下图说明一个银行公司综合数据的简单处理过程，其中数据仓库中与“定期存款账户”主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同、数据格式也可能不同。把不同来源的数据存储在数据仓库中，需要除去这些不一致性。

5.3. 不可更新

就是数据导入数据仓库之后不可更改，更改会破坏源数据，导致分析出错误。

数仓中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

5.4. 时变性

数据仓库的数据随时间的变化表现在以下几个方面：

1. 数据仓库的数据时效一般要远远长于操作型数据库数据的时效
2. 操作型数据库库存的是当前数据，而数据仓库中存储的是历史数据
3. 数据仓库中的数据是按照时间顺序进行追加的，它们都带有时间属性

 6. 数据仓库分层

按照数据流入流出的过程，数据仓库架构可以分为三层--源数据、数据仓库、数据应用。

6.1 数仓分层原因

• 用空间换时间
• 增强扩展性
• 分层管理
  • 把一个大的复杂的步骤拆分开来，既简化了开发难度，当后期数据发生错误时，只需要局部调整某个步骤即可

6.2 数仓分层好处

• 清晰数据结构
• 方便数据血缘追踪
• 减少重复开发
• 把复杂问题简单化
• 屏蔽原始数据的异常

6.3 数仓分层明细 

数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三层

• 1 ods
• 2 dw
• 3 ads

6.3.1 ODS原始数据层

• operate data store(操作数据-存储
• 该层是最接近数据源中数据的一层，数据源中数据，经过ETL（抽取、洗净、传输），装入ODS层
• 本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。
• 例如：MySQL里面的一张表可以通过sqoop直接抽取到ODS层

6.3.2 DW数据仓库层

• Data warehouse(数据仓库
• 该层从ODS层中获得的数据按照主题建立各种数据模型。
• 例如以研究人的旅游消费为主题的数据集中，可以结合航空公司的登机出行信息和银联系统的刷卡记录进行结合分析，产生数据集。
• 四个概念：维、事实、指标、粒度
  • 维度：维度表是事实表不可或缺的组成部分。维度表包含业务过程度量事件有关的文本环境。他用来描述与“谁、什么、哪里、如何、何时、为什么”有关的事件。
  • 事实：事实涉及来自业务过程的度量，基本都以数量值表示
  • 指标：指标是业务流程节点上的一个数值。比如销量、价格、成本等。
  • 粒度：粒度就是业务流程中对度量的单位，比如商品是按件记录度量，还是按批记录度量。

6.3.3 ADS数据服务层

• Application Data Service（应用数据服务
• 该层主要是提供数据产品和数据分析使用的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。
• 例如：我们数据报表或者是大宽表，一般就放在这里。

---

7.阿里数仓五层 

• ODS
• DWD（Data Warehouse Detail）明细数据层
• DWS（Data Warehouse Service）服务数据层
• DWT（Data Warehouse Topic）主题数据层
• ADS

 7.1. ODS

• 功能：ODS层是数据仓库准备层，为DWD层提供基础原始数据，可减少对业务系统的影响。
• 建模方式及原则：从业务系统增量（就是抽新增的那部分数据）抽取、保留时间由业务需求决定、可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致，按主题逻辑划分。

7.2. DWD

• 功能：为DW层提供来源明细数据，提供业务系统细节数据的长期沉淀，为未来分析类需求的扩展提供历史数据支撑
• 建模方式及原则：数据模型与ODS层一致，不做清洗转换处理、为支持数据重跑可额外增加数据业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge操作。（就是进行一些简单的汇总操作）

7.3. DWS

• 功能：
  • 为DW、ST提供细粒度数据，细化成DWB和DWS
  • DWB是根据DWD明细数据进行转换，如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理、IP清晰转换、账号、余额清洗、资金来源清洗等
  • DWS是根据DWB层数据按各个维度ID进行高粒度汇总聚合，如按交易来源，交易类型进行汇合
• 建模方式及原则：
  • 聚合、汇总增加派生事实
  • 关联其他主题的事实表，DW层可能会跨主题域
  • DWB保持低粒度汇总加工数据，DWS保持高粒度汇总数据
  • 数据模型可能采用反范式涉及，合并信息等。

7.4. DWT

• 功能：
  • 可以是一些宽表，是根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段进行汇总统计并作为单独的列进行存储。
  • 满足一些特定查询、数据挖掘应用
  • 应用集市数据存储
• 建模方式及原则：
  • 尽量减少数据访问时计算（优化检索）
  • 维度建模，星型模型
  • 分表存储

7.5. ADS

• 功能：
  • ST层面向用户应用和分析需求，包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析，面向最终结果用户。
  • 例如银行分析销售数据，可能会综合时间周期、产品类别、分销渠道、地理分布、客户群类等多种因素来考量。
• 建模方式及原则：
  • 保持数据量小
  • 维度建模，星形模型
  • 各位维度代理键+度量
  • 增加业务数据字段，支持数据重跑
  • 不分表存储

8.数据仓库规范设计

目的在于约束N个人对齐认知，按照一个标准或流程进行开发，以保证数据一致性，流程清晰且稳定。

提高开发效率，提升质量，降低沟通对齐成本，降低运维成本等。

8.1. 表命名规范

表名需要见名知义，通过表名就可以知道它是哪个业务域，干嘛用的，什么粒度的数据。

• 常规表
  • 规范：分层前缀[dwd|dws|ads|bi]_业务域_主题域_粒度
    • 业务域、主题域我们都可以用词根的方式枚举清楚，不断完善，粒度也是同样的，主要是时间粒度、日、月、年、周的等，使用词根定义好简称
    • 例如：dwd_xxx_xxx_da(di：每日增量，da：每日全量，mi：每月增量，ma：每月全量)
• 中间表
  • 中间表一般出现在Job中，是Job中临时存储的中间数据的表，中间表的作用域只限于当前Job执行过程中，一旦执行完成，该表的使命就完成了，可以删除掉。
  • 规范：mid_table_name_[0~9|dim]
    • table_name是任务中目标表的名字，通常来说一个任务只有一个目标表
    • 碰到需要补全维度的表，可以用dim结尾。
• 临时表
  • 临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用的表，是可以随时删除的表
  • 规范：tmp_xxx
  • 只要加上tmp开头即可，其他名字随意，注意tmp开头的表不要用来实际使用，只是测试验证而已。
• 维度表
• 维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层表抽象出来，也可以手工来维护。
• 规范：dim_xxx
• 维度表，统一以dim开头，后面加上对该指标的描述，可以自由发挥。

 8.2. 开发规范

 8.3. 流程规范

 。。。

9. 常见概念描述

9.1 数据仓库

。。。

9.2 数据集市

• 概念：
  • 数据集市可以理解为是一种“小型数据仓库”，它只包含单个主题，且关注范围也非全局。数据集市可以分为两种。
• 分类：
  • 独立数据集市，这类数据集市有自己的源数据库和ETL架构；
  • 非独立数据集市，这种数据集市没有自己的源系统，它的数据来自数据仓库。
• 应用场景： 
  • 数据集市是数仓之上更聚集的业务主题合集，更偏向于应对业务数据快速高效应用的需求，一般用于商业智能系统中探索式和交互式数据分析应用。
  • 数据集市是一个结构概念，它是企业级数据仓库的一个子集，主要面向部门级业务，并且只面向某个特定的主题。

9.3. 数据孤岛 

业务系统之间各自为政、相互独立造成的数据孤岛，体现在业务不集成、流程不互通、数据不共享。

9.4. 数据湖

• 概念：
  • 数据集市就像是一瓶清洗过的、包装过的和结构化易于使用的水。
  • 数据湖更像是在自然状态下的水，数据流从源系统流向这个湖。用户可以在数据湖里校验，取样或完全的使用数据。
• 特点：
  • 从源系统导入所有的数据，没有数据流失。
  • 数据存储时没有经过转换或只是简单的处理。
  • 数据转换和定义schema用于满足分析需求。
• 应用需求：
  • 以大数据技术为基础有多样化数据结构海量大数据存储需求，也可作为数据仓库或者数据集市的数据源。
• 数据湖是一种数据存储理念，存储企业各种各样的原始数据的大型仓库，包括结构化、非结构、二进制图像、音频、视频等等。

 9.5. 数据中台

• 数据中台建立后，会形成数据API，为企业和客户提供高效的各种数据服务。
• 数据中台不是一套软件，也不是一个信息系统，而是一系列数据组件的集合，企业基于自身的信息化建设基础、数据基础以及业务特点对数据中台的能力进行定义，基于能力定义利用数据组件搭建自己的数据中台。
• 应用场景：
  • 将数据服务化提供给业务系统，目的是将数据能力渗透到业务的各个环节，不限于决策分析。
• 数据中台是一个逻辑概念，为业务提供服务的主要方式是数据API，它包括了数据仓库，大数据、数据治理领域的内容。

 总结（数仓+服务）

10. 宽表窄表

10.1 宽表

通常不符合三范式，坏处是数据的大量冗余，好处是提高了查询的效率。

10.2 窄表

严格按照数据库涉及三范式。尽量减少数据冗余，但是缺点是修改一个数据可能需要修改多张表。

方便扩展，能适应各种复杂的数据结构（树形、继承等），无论有多少配置，都不用修改表结构。但代码逻辑可能需要包装一下。

11. ETL

11.1 概念：

• ETL就是将业务系统的数据经过抽取（Extract）、清洗转换（Transform）、之后加载（Load）到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。
• 五大模块：
  • 数据抽取、数据清洗、库内转换、规则检查、数据加载。
  • 各模块可灵活组合，形成ETL处理流程 

11.2 模块介绍

• 数据抽取
  • 确定数据源，需要确定从哪些源系统进行数据抽取
  • 定义数据接口，对每个源文件及系统的每个字段进行详细说明
  • 确定数据抽取的方法：是主动抽取还是由源系统推送？是增量抽取还是全量抽取？是按照每日抽取还是按照每月抽取？
• 数据清洗
  • 主要将不完整数据、错误数据、重复数据进行处理
• 数据转换 
  • 空值处理：可捕获字段空值，进行加载或替换为其他含义数据，或数据分流问题库
  • 数值标准：统一源数据、统一标准字段、统一字段类型定义
  • 数据拆分：依据业务需求做数据拆分，如身份证号，拆分区划、出生日期、性别等。
  • 数据验证：时间规则、业务规则、自定义规则
  • 数据替换：对于因业务因素，可实现无效数据、缺失数据的替换
  • 数据关联：关联其他数据或数字，保障数据完整性

主体内容和图片来自网课（不知道具体名字，b站上找的），如有侵权请告知