数据仓库入门
一：引入
1.介绍
数据仓库的广泛应用·
- 传统数据仓库（技术成熟）·
- 大数据数据仓库（未来趋势）
体系化数据仓库理论·
- 什么是数据仓库？它是如何发展而来的·
- 数据仓库的整体架构？·
- 数据仓库建模？·
- 数据仓库生产经验？·
- 数据仓库落地&实践开发
2.内容
 |
二：简介
2.1诞生背景
数据仓库诞生原因
- 历史数据积存·
- 企业数据分析需要
历史数据积存·
- 历史数据使用频率低，堆积在业务库中，导致性能下降
 |
企业数据分析需要
各个部门自己建立独立的数据抽取系统，导致数据不一致
 |
作用一：将调用频率较低的冷数据放在仓库；感觉就像热数据放在“内存”，冷数据存在“硬盘”里
作用二： 协调多个部门的资源；保证数据一致性；权限管理；数据集成；数据标准化；
2.2基本概述
数据仓库（Data Warehouse,DW)·
- 由数据仓库之父比尔·恩门（Bill Inmon）提出·
- 数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合·
- 主要用于组织积累的历史数据，并使用分析方法（OLAP、数据分析）进行分析整理，进而辅助决策，为管理者、企业系统提供数据支持，构建商业智能
 |
数据仓库特点·
- 面向主题：为数据分析提供服务，根据主题将原始数据集合在一起
- 集成：原始数据来源于不同数据源，要整合成最终数据，需要经过抽取、清洗、转换的过程
- 非易失：保存的数据是一系列历史快照，不允许被修改，只允许通过工具进行查询、分析
- 时变性：数仓会定期接收、集成新的数据，从而反映出数据的最新变化
 |
 |
数据仓库 VS数据库·
- 数据库面向事务设计，属于OLTP（在线事务处理）系统，主要操作是随机读写；在设计时尽量避免冗余，常采用符合范式规范来设计。（OLTP/OLAP就像PBI里的表格和矩阵，对应面向事务和面向分析）
- 数据仓库是面向主题设计的，属于OLAP（在线分析处理）系统，主要操作是批量读写；关注数据整合，以及分析、处理性能；会有意引入冗余，采用反范式方式设计。（反范式设计：尽量是宽表，空间换时间）
 |
2.3技术实现
数据仓库建设方案·
- 传统数据仓库
- 大数据数据仓库
传统数据仓库·
- 由关系型数据库组成MPP（大规模并行处理）集群；（有点像物理里的串联）
 |
局限性问题：
|
大数据数据仓库
- 利用大数据天然的扩展性，完成海量数据的存放·
- 将SQL转换为大数据计算引擎任务，完成数据分析
 |
局限性问题：
|
2.4MPP&分布式架构
2.4.1MPP架构·
- 传统数仓中常见的技术架构，将单机数据库节点组成集群，提升整体处理性能·
- 节点间为非共享架构（Share Nothing），每个节点都有独立的磁盘存储系统和内存系统·
- 每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供服务·
- 设计上优先考虑C（一致性），其次考虑A（可用性），尽量做好P（分区容错性）
架构优点·
- 运算方式精细，延迟低、吞吐低·
- 适合中等规模的结构化数据处理
 |
架构缺点·
- 存储位置不透明，通过Hash确定数据所在的物理节点，查询任务在所有节点均会执行·
- 并行计算时，单节点瓶颈会成为整个系统短板，容错性差·
- 分布式事务的实现会导致扩展性降低
 |
2.4.2分布式架构·
- 大数据中常见的技术架构，也称为Hadoop架构/批处理架构·
- 各节点实现场地自治（可以单独运行局部应用），数据在集群中全局透明共享·
- 每台节点通过局域网或广域网相连，节点间的通信开销较大，在运算时致力减少数据移动·
- 优先考虑的是P（分区容错性），然后是A（可用性），最后再考虑C（一致性）
架构特点·
- 解决了单点故障问题，会将出错的任务调度到其他副本节点·
- 运算方式粗犷，吞吐量大·
- 扩展性极强，适合处理非结构化、半结构化数据·
- 需要将中间结果进行存储，且数据移动开销较大
- （将分布的计算资源、存储资源集中起来）
 |
2.4.3MPP+分布式架构·
- 数据存储采用分布式架构中的公共存储，提高分区容错性·
- 上层架构采用MPP，减少运算延迟
2.5常见产品
 |
三：架构
3.1 架构图
 |
3.2 ETL流程
ETL -- Extract-Transform-Load·
- 将数据从来源端经过抽取（extract）、交互转换（transform）、加载（load）至目的端的过程·
- 构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去·
- ETL.规则的设计和实施约占整个数据合库搭建工作量的60%~80%
 |
数据抽取（Extraction)·
- 抽取的数据源可以分为结构化数据、非结构化数据、半结构化数据·
- 结构化数据一般采用JDBC、数据库日志方式，非|半结构化数据会监听文件变动
抽取方式·
- 数据抽取方式有全量同步、增量同步两种方式·
- 全量同步会将全部数据进行抽取，一般用于初始化数据装载·
- 增量同步方式会检测数据的变动，抽取发生变动的数据，一般用于数据更新
 |
数据转换（Transformation）·
- 数据转换要经历数据清洗和转换两个阶段
- -数据清洗主要是对出现的重复、二义性、不完整、违反业务或逻辑规则等问题的数据进行统一的处理
- -数据转换主要是对数据进行标准化处理，进行字段、数据类型、数据定义的转换
- 结构化数据在转换过程中的逻辑较为简单，非|半结构化数据的转换会较为复杂
数据加载（Loading）·
- 将最后处理完的数据导入到对应的目标源里
ETL常用工具
 |
3.3数据积存
操作数据层（ODS）·
- 数据与原业务数据保持一致，可以增加字段用来进行数据管理·
- 存储的历史数据是只读的，提供业务系统查询使用·
- 业务系统对历史数据完成修改后，将update_type字段更新为UPDATE，追加回ODS中
- ·在离线数仓中，业务数据定期通过ETL流程导入到ODS中，导入方式有全量、增量两种
- -全量导入：数据第一次导入时，选择此种方式
- -增量导入：数据非第一次导入，每次只需要导入新增、更改的数据，建议使用外连接&全覆盖方式
 |
3.4数据分析
数据明细层（DWD）·
- 数据明细层对ODS层的数据进行清洗、标准化、维度退化（时间、分类、地域）·
- 数据仍然满足3NF模型，为分析运算做准备
 |
数据汇总层（DWS）·
- 数据汇总层的数据对数据明细层的数据，按照分析主题进行计算汇总，存放便于分析的宽表·
- 存储模型并非3NF，而是注重数据聚合，复杂查询、处理性能更优的数仓模型，如维度模型
 |
数据应用层（ADS）·
- 数据应用层也被称为数据集市·
- 存储数据分析结果，为不同业务场景提供接口，减轻数据仓库的负担
- -数据仓库擅长数据分析，直接开放业务查询接口，会加重其负担
 |
四：建模方法
√基本概念
√ ROLAP
√ MOLAP
√多维分析
4.1基本概念
OLTP系统建模方法
- ·OLTP（在线事务处理）系统中，主要操作是随机读写·
- 为了保证数据一致性、减少冗余，常使用关系模型·
- 在关系模型中，使用三范式规则来减少冗余
 |
OLAP（在线联机分析）·
- OLAP系统，主要操作是复杂分析查询；关注数据整合，以及分析、处理性能·
- OLAP根据数据存储的方式不同，又分为ROLAP、MOLAP、HOLAP
OLAP系统分类·
- ROLAP（Relation OLAP,关系型OLAP）：使用关系模型构建，存储系统一般为RDBMS·
- MOLAP（Multidimensional OLAP,多维型OLAP）：预先聚合计算，使用多维数组的形式保存数据结果，加快查询分析时间·
- HOLAP（Hybrid OLAP,混合架构的OLAP）：ROLAP和MOLAP两者的集成；如低层是关系型的，高层是多维矩阵型的；查询效率高于ROLAP，低于MOLAP
4.2 ROLAP
ROLAP系统建模方法·
- 典型的数据仓库建模方法有ER模型、维度模型、Data Value、Anchor
 |
维度模型·
- 维度模型中，表被分为维度表、事实表，维度是对事实的一种组织·
- 维度一般包含分类、时间、地域等
 |
维度模型·
- 维度模型分为星型模型、雪花模型、星座模型·
- 维度模型建立后，方便对数据进行多维分析
 |
星型模型
标准的星型模型，维度只有一层，分析性能最优
雪花模型·
雪花模型具有多层维度，比较接近三范式设计，较为灵活
星座模型·
星座模型基于多个事实表，事实表之间会共享一些维度表·是大型数据仓库中的常态，是业务增长的结果，与模型设计无关
| 星型模型 | 雪花模型· | 星座模型· |
 |
|
|
什么是宽表模型？·
- 宽表模型是维度模型的衍生，适合join性能不佳的数据仓库产品·
- 宽表模型将维度冗余到事实表中，形成宽表，以此减少join操作
 |
4.3 MOLAP
MOLAP系统建模方法·
- MOLAP将数据进行预结算，并将聚合结果存储到CUBE模型中·
- CUBE模型以多维数组的形式，物化到存储系统中，加快后续的查询·
- 生成CUBE需要大量的时间、空间，维度预处理可能会导致数据膨胀
 |
常见MOLAP产品·
- Kylin·
- Druid
 |
4.4 多维分析
OLAP多维分析·
- OLAP主要操作是复杂查询，可以多表关联，使用COUNT、SUM、AVG等聚合函数·
- OLAP对复杂查询操作做了直观的定义，包括钻取、切片、切块、旋转
 |
钻取·
- 对维度不同层次的分析，通过改变维度的层次来变换分析的粒度·
- 钻取包括上卷（Roll-up）、下钻（Drill-down）·
- 上卷（Roll-up），也称为向上钻取，指从低层次到高层次的切换·
- 下钻（Drill-down)，指从高层次到低层次的切换
 |
切片(Slice)、切块(Dice)·
- 选择某个维度进行分割称为切片·
- 按照多维进行的切片称为切块
 |
旋转（Pivot)·
- 对维度方向的互换，类似于交换坐标轴上卷（Roll-up）
 |
五：最佳实践
√表的分类
√ETL策略
√任务调度
5.1表的分类
维度建模中的表类型·
- 事实表·
- 维度表·
- 事务事实表·
- 周期快照事实表·
- 累积快照事实表
事实表·
- 一般是指一个现实存在的业务对象，比如用户，商品，商家，销售员等等
维度表·
- 一般是指对应一些业务状态，代码的解释表。也可以称之为码表·通常使用维度对事实表中的数据进行统计、聚合运算
事务事实表·
- 随着业务不断产生的数据，一旦产生不会再变化，如交易流水、操作日志、出库入库记录
周期快照事实表·
- 随着业务周期型的推进而变化，完成间隔周期内的度量统计，如年、季度累计·使用周期+状态度量的组合，如年累计订单数，年是周期，订单总数是量度
累积快照事实表·
- 记录不确定周期的度量统计，完全覆盖一个事实的生命周期，如订单状态表·通常有多个时间字段，用于记录生命周期中的关键时间点·只有一条记录，针对此记录不断更新
|
 |
|
 |
|
 |
|
 |
|
 |
实现方式
实现方式一·
- 使用日期分区表，全量数据记录，每天的分区存储昨天全量数据与当天增量数据合并的结果·
- 数据量大会导致全量表膨胀，存储大量永远不更新的冷数据，对性能影响较大·适用于数据量少的情况
实现方式二·
- 使用日期分区表，推测数据最长生命周期，存储周期内数据；周期外的冷数据存储到归档表·
- 需要保留多天的分区数据，存储消耗依然很大
实现方式三·
- 使用日期分区表，以业务实体的结束时间分区，每天的分区存放当天结束的数据；设计一个时间非常大的分区，如9999-12-31，存放截止当前未结束的数据·
- 已结束的数据存放到相应分区，存放未结束数据的分区，数据量也不会很大，ETL性能好·
- 无存储浪费，数据全局唯一·
- 业务系统可能无法标识业务实体的结束时间，可以使用其它相关业务系统的结束标志作为此业务系统的结束，也可以使用最长生命周期时间或前端系统的数据归档时间
拉链表·
- 拉链表记录每条信息的生命周期，用于保留数据的所有历史（变更）状态·
- 拉链表将表数据的随机修改方式，变为顺序追加
 |
5.2 ETL策略
全量同步·
- 数据初始化装载一定使用全量同步的方式·
- 因为业务、技术原因，使用全量同步的方式做周期数据更新，直接覆盖原有数据即可
增量同步·
- 传统数据整合方案中，大多采用merge方式（update+insert）·
- 主流大数据平台不支持update操作，可采用全外连接+数据全量覆盖方式-如果担心数据更新出错，可以采用分区方式，每天保存最新的全量版本，保留较短周期
 |
5.3 任务调度
为什么需要任务调度？·
- 解决任务单元间的依赖关系·
- 自动化完成任务的定时执行
常见任务类型·
- Shell・
- Java程序・
- Mapreduce程序・
- SQL脚本
 |
常见调度工具·
- Azkaban
- Oozie
 |
六：项目实战
√项目概述
√数据描述
√架构设计
√环境搭建
√项目开发
END
标签：架构,入门,模型,数据仓库,OLAP,维度,数据 From： https://www.cnblogs.com/zeon/p/16630567.html