1. 数仓基本概念
-
1- 什么是数据仓库呢?
存储数据的仓库, 主要用于存储过去历史发生过的数据,面向主题, 对数据进行统计分析的操作, 从而能够对未来提供决策支持
-
2- 数据仓库最大的特点是什么呢?
数据仓库既不生产数据, 也不消耗数据, 数据来源于各个数据源
-
3- 数据仓库的四大特征:
1- 面向主题: 分析什么 什么就是我们的主题 2- 集成性: 数据从各个数据源汇聚而来, 数据的结构都不一定一样 3- 非易失性(稳定性): 存储都是过去历史的数据, 不会发送变更, 甚至某些数据仓库都不支持修改操作 4- 时变性: 随着时间推移, 将最近发生的数据也需要放置到数据仓库中, 同时分析的方案也无法满足当前需求, 需要变更分析的手段 主题域通常是联系较为紧密的数据主题的集合。 数据域是指面向业务分析,将业务过程或者维度进行抽象的集合。 主题域和数据域的区别: 1)主题域:面向业务过程,将业务活动事件进行抽象的集合,如下单、支付、退款都是业务过程,针对公共明细层(DWD 及 DWM)进行主题划分。 2)数据域:面向业务分析,将业务过程或者维度进行抽象的集合,针对公共汇总层(DWS)进行数据域划分。
-
4- OLAP 和 OLTP区别:
-
5- 什么是ETL:
ETL: 抽取 转换 加载 狭义上ETL: 指的数据从ODS层抽取出来, 对ODS层的数据进行清洗转换处理的操作, 将清洗转换后的数据加载到DW层过程 宽泛的ETL: 指的是数仓的全过程
-
6- 什么是数据仓库 和 数据集市
数据仓库是包含数据集市的, 在一个数据仓库中可以有多个数据集市 数据仓库: 一般指的构建集团数据中心, 基于业务形成各种业务的宽表或者统计宽表 数据集市: 基于部门或者基于主题, 形成主题或者部门相关的统计宽表
2. 数仓分层介绍
回顾:
ODS: 源数据层(临时存储层) 贴源层 作用: 对接数据源, 用于将数据源的数据完整的导入到ODS层中, 一般ODS层的数据和数据源的数据保持一致, 类似于一种数据迁移的操作, 一般在ODS层建表的时候, 会额外增加一个 日期的分区, 用于标记何时进行数据采集 DW: 数据仓库层 作用: 用于进行数据统计分析的操作, 数据来源于 ODS层 APP(DA|ADS | RPT |ST) : 数据应用层(数据展示层) 作用: 存储分析的结果信息, 用于对接相关的应用, 比如 BI图表
数仓分层的作用:
1- 清晰数据结构 2- 复杂问题简单化 3- 便于维护 4- 减少重复开发 5- 高性能
3. 数仓建模方案
3.1 关系模型
数据仓库之父 Bill Inmon 提出的建模方法是从全企业的高度,用实体关系(Entity Relationship,ER)模型来描述企业业务,并用规范化的方式表示出来,在范式理论上符合3NF。
-
关系模式: ER模型图
模型范式:
范式是关系模式满足不同程度的规范化要求的标准, 范式的目的是减少数据冗余,增强数据的一致性。遵循的范式级别越高,数据冗余性就越低。
-
第一范式(1NF): 如果关系模式R的每个关系r的属性都是不可分的数据项,那么就称R是第一范式的模式
-
第二范式(2NF): 如果关系模式R是1NF,且每个非主属性完全函数依赖于候选键,那么就称R是第二范式。
-
第三范式(3NF): 首先要满足第二范式,其次非主属性之间不存在函数依赖。
实体关系模型的基本假设是数据仓库的需求会发生变化,因此实体关系模型设计所要求的高度抽象、独立性,在面对频繁变化时体现出了其优势。另外,实体关系模型所遵循的三范式在减少数据冗余方面有天然优势,在数据量不断膨胀增长的背景下,规范化的数据模型对于降低不必要的数据存储十分有意义。 但是在面对现代OLAP模型中, 数据体量增大, 数据分析体系的完整形成, 关系模式也有着二大问题: 1) 实体关系模型对数仓建模者的视野有较高要求,需要对企业的业务系统和架构充分理解,因此模型构建在学习成本方面有一定的劣势。 2) 对于分析型需求来说,实体关系模型较为松散、零碎,物理表数量多,需要进行大量的关联、查询的性能问题非常凸显。 因此,实体关系模型在OLAP建设体系中更适合基础数据层的建设,目的是将各个系统中的数据以整个企业角度按主题进行相似性组合和合并,并进行一致性处理。
3.2 维度建模
维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程,而维度通常对应业务过程发生时所处的环境。
什么是事实表:
事实表: 指的主题,要统计的主题是什么, 对应事实就是什么, 而主题所对应的表, 其实事实表 事实表一般是一堆主键(外键)的聚集 事实表一般是反应了用户某种行为表 比如说: 订单表, 收藏表, 登录表, 购物车表 ... 事实表分类: 事务事实表 : 最初始确定的事实表 其实就是事务事实表 周期快照事实表: 指的对数据进行提前聚合后表, 比如将事实表按照天聚合统计 结果表 累计快照事实表: 每一条数据, 记录了完整的事件 从开始 到结束整个流程, 一般有多个时间组成
什么是维度表:
维度表: 当对事实表进行统计分析的时候, 可能需要关联一些其他表进行辅助, 这些表其实就是维度表 维度表一般是由平台或者商家来构建的表, 与用户无关, 不会反应用户的行为 比如说: 地区表 商品表 时间表, 分类表... 维度表分类: 高基数维度表: 如果数据量达到几万 或者几十万 甚至几百万的数据量, 一般这样维度表称为高基数维度表 比如: 商品表 , 用户表 低基数维度表: 如果数据量只有几条 或者 几十条 或者几千条, 这样称为低基数维度表 比如: 地区表 时间表 分类表 配置表
数据发展模式y以及对应的模型
● 星型模型: ○ 特点: 只有一个事实表, 也就意味着只有一个分析的主题, 在事实表周围围绕了多张维度表, 维度表与维度表没有任何关联 ○ 数仓发展阶段: 初期 ● 雪花模型: ○ 特点: 只有一个事实表, 也就意味着只有一个分析的主题, 在事实表周围围绕了多张维度表, 维度表可以接着关联其他的维度表 ○ 数仓发展阶段: 异常, 出现畸形状态 在实际数仓中, 这种模型建议越少越好, 尽量避免这种模型产生 ● 星座模型: ○ 特点: 有多个事实表, 也就意味着有了多个分析的主题, 在事实表周围围绕了多张维度表, 在条件吻合的情况下, 事实表之间是可以共享维度表 ○ 数仓发展阶段: 中期 和 后期
维度建模从需求出发,重点关注快速完成需求分析,围绕性能和易理解性构建模型,以事实表与维度表的形式重新组织数据。 在OLAP应用中主要有两大优势: 1):前期建模成本较低,从业务需求出发,快速迭代; 2):查询性能高,通过数据冗余降低查询的复杂度。 主要劣势: 数据冗余, 数据一致性维护增大 因此,从整体来说维度建模的开发和使用成本较低,但是维护成本较高,比较适合在接近业务分析的数据集市层、分析层来使用。
4.数仓建设规范
4.1 数据库划分规范
MySQL:dim/sale/member SQL Server: order/stock Hive: dim:用于存放 维表 表信息及数据 ods:用于存放 ods层 表信息及数据 dwd:用于存放 dwd层 表信息及数据 dwm:用于存放 dwm层 表信息及数据 dws:用于存放 dws层 表信息及数据 ads:用于存放 ads层 表信息及数据 PostgreSQL: dm
4.2 表命名规范
命名规则: 分层_主题_实体+业务+维度_分区 分层:ods dwd dwm dws ads 主题:dim/sale/sold/sell/mem/shop/order/stock 数据域:dim/goods/category/store/marketing/saleorder/abnormal/pay/mem/shop/order 实体+业务+维度: 示例: store_goods_statistics_day store_member_statistics_day 分区: i : 分区表(increment增量) f : 全量表(full全量)
4.3 表字段类型规范
数量类型整数为:bigint 金额类型为:decimal(27, 2),表示:27位有效数字,其中小数部分2位 字符串(名字,描述信息等)类型为:string 日期类型为:string 时间类型为:timestamp
在实际中, 关于数据规范的处理形式
中小公司中: 一般通过文档约束的形式, 告知命名规范, 大家在建设过程中, 基于规范来建设即可 (从某种角度,即使你不这么建设, 其实也能创建成功的) 大型企业: 数据治理平台 (数据治理工程师) 元数据管理: 约束数仓建设的标准, 不断的检测程序员在建设过程中是否满足了规范要求, 如果不满足 治理平台会弹出警告, 并会通知相关人员进行处理
5.数仓建设方案
5.1 甄选数仓分层
回顾:
ODS: 源数据层(临时存储层) 贴源层 作用: 对接数据源, 用于将数据源的数据完整的导入到ODS层中, 一般ODS层的数据和数据源的数据保持一致, 类似于一种数据迁移的操作, 一般在ODS层建表的时候, 会额外增加一个 日期的分区, 用于标记何时进行数据采集 DW: 数据仓库层 作用: 用于进行数据统计分析的操作, 数据来源于 ODS层 APP(DA|ADS | RPT |ST) : 数据应用层(数据展示层) 作用: 存储分析的结果信息, 用于对接相关的应用, 比如 BI图表
-
ODS层: 源数据层
-
作用: 对接数据源, 将数据源中数据加载到ODS层中, 形成一张张表, 一般和数据源中数据保持同样粒度(数据一致)
-
主要用于放置事实表数据, 和少量维度表数据
-
注意: 在导入到ODS层, 可能也会对数据进行预处理工作(清洗) -- 并不一定存在
-
例如:
1) 如果数据直接来源于MYSQL数据源, 可能一般不需要进行预处理工作 本身数据就是结构化数据 2) 如果数据直接来源于某个文件的, 可能需要对文件中数据进行判定, 如果有一些脏乱差的数据, 可能需
-