数据仓库原理

1.简介

1.1诞生背景

1. 历史数据积存：历史数据使用频率 低，堆积在业务科中，导致性能下降；
2. 企业数据分析需要：各个部门自己建立独立的数据抽取系统，导致数据不一致；

1.2基本概述（Data Warehouse,DW）

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

1.2.1数据仓库的特点

• 面向主题：为数据分析提供服务，根据主题将原始数据聚合在一起；
• 集成：原始数据来源于不同数据源，要整合成最终数据，需要经过抽取、清洗、转化；
• 非易失：保持的数据是一系列的历史快照，不允许被修改，只允许通过工具进行查询、分析；
• 时变性：数仓会定期接、集成新的数据，从而反映出数据的最新变化；

1.2.2数据库VS数据仓库

类型数据库数据仓库概述数据库面向事业设计，属于OLTP（在线事务处理）系统，主要操作是随机读写；在设计时尽量避免冗余，常采用符合范式规则来设计；数据库面向主题设计，属于OLAP（在线分析处理）系统，主要操作是批量读写；关注数据整合，以及分析、处理性能；会有意引入冗余，采用符合范式规则来设计；面向事务分析数据类型细节、业务数据特点当前的、最新的综合、清洗过的数据目的日常操作历史的、跨时间维护设计模型基于ER模型，面向应用长期信息需求、决策支持操作读/写星形/雪花模型，面向主题数据模型GB到TB>=TB

1.3数据仓库建设方案

传统数据仓库大数据数据仓库
概述
由关系型数据组成MPP(大规模并行处理)集群利用大数据天然的扩展性，完成海量数据的存放
将SQL转化为大数据计算引擎任务，完成数据分析
问题
扩展性有限、热点问题SQL支持率、事务支持

1.4MPP&分布式架构

1.4.1MPP架构

1. 传统数仓中常见的技术架构，将单机数据库节点组成集群，提升整体处理性能 ；
2. 节点间为非共享架构（share Noting），每个节点都有独立的磁盘存储系统和内存系统；
3. 每台数据节点通过专用网络或者商业网络互相连接，彼此协同计算，作为整体提供服务 ；
4. 设计上有限考虑C一致性，其次考虑A(可用性)，尽量做好P(分区容错性)。

1.4.2MPP架构优点

1. 运算方式精细，延迟低、吞吐低；
2. 适合中等规模的结构化数据处理。

1.4.3MPP架构缺点

1. 架构缺点：存储位置不透明，通过Hash确认数据所在的物理节点，查询任务在所有节点均会执行；
2. 并行计算时，单节点瓶颈会成为整个系统短板，容错性差；
3. 分布式事务的实现会导致扩展性降低。

1.4.4分布式架构

1. 大数据中常见的技术架构、也成为hadoop架构/批处理架构；
2. 各节点实现场地自治（可以单独运行局部应用），数据在集群中全局透明共享；
3. 每台节点通过局域性或广域网相连，节点间的通信开销较大，在运算时致力减少数据移动；
4. 优先考虑的是P（分区容错性），然后是A（可用性），最后再考虑C（一致性）

1.4.5MPP+分布式架构

1. 数据存储采用分布式架构中的公共存储，提高容错性；
2. 上层架构采用MPP，减少运算延迟。

1.4.6常见产品

传统数据仓库

• Oracle RAC
• DB2
• Teradata
• greenplunm

大数据数据仓库

• Hive
• Spark sql
• HBase
• impala
• HAWQ
• TIDB

2.架构

2.1架构图

2.2ETL流程

2.2.1ETL--Extract-Transform-Load

1. 将数据从来源端经过抽取（extract）、交互转化（transform）、加载（load）至目的端的过程；
2. 构建数据仓库的重要一环，用户从数据源抽取所需的数据没经过数据清洗，最终按照月线定义好的数据仓库模型，将数据加载到数据仓库中去；
3. ETL规则的设计和实施约占正回购数据仓库搭建工作量的60%-80%。

2.2.1.1数据抽取（Extraction）

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

2.2.1.2抽取方式

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

2.2.2数据转换（Transformation）

数据转化要经历数据清洗和转化两个过程：

• 数据清洗主要是对出现的重复、二义性、不完整、违反业务或逻辑规则等问题的数据进行统一的处理；
• 数据转化主要是对数据进行标准化处理，进行字段、数据类型、数据定义的转换；

结构化数据再转化过程中的逻辑较为简单，非/半结构化数据的转化

数据加载（Loading）

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

2.2.3ETL过程

结构化数据ETL工具

• Sqoop
• Kettle
• Datastage
• Informatica
• Kafka

非/半结构化数据ETL工具

• Flume
• Logstash

2.3数据积存

2.3.1操作数据层（ODS）

1. 数据与原业务数据保存一致，可以增加字段来进行数据管理（update_time、from、update_type）；
2. 存储的历史数据是只读的，提供业务系统查询使用；
3. 业务系统对历史数据完成修改后，将update_type字段更新为UPDATE,追加回ODS中；

在离线数仓中，业务数据定期通过ETL流程到ODS中，导入方式有全量、增量两种：

• 全量导入：数据第一次导入时，选择此种方式；
• 增量导入：数据非第一次导入，每次只需要导入新增、更改的数据，建议使用外连接&全覆盖方式

2.4数据分析

2.4.1数据明细层（DWD）

1. 数据明细层对ODS的数据进行清洗、标准化、维度退化（把时间、分类、地域这类维度加入表内）
2. 数据仍然满足3NF模型，为数据预算做准备

2.4.2数据汇总层（DWS）

1. 数据汇总层的数据对数据明细层的数据，按照分析主题进行计算汇总，存放便于分析的宽表；
2. 存储模型并非3NF，而是注重数据聚合，复杂查询、处理性能更优的数仓模型，如维度模型；

2.4.3数据应用层（ADS）

1. 数据应用层也被称为数据集市；
2. 存储数据分析结果，为不同业务场景提供接口，减轻数据仓库的负担；
3. 数据仓库擅长数据分析，直接开放业务查询接口，会加重其负担；
4. 数据应用层（kylin报表决策、HBase并发查询、ElasticSearch搜索检索）

3.建模

3.1基本概念

3.1.1OLTP系统建模方法

1. OLTP（在线事业处理）系统中，主要操作时随机读写；
2. 为了保证数据一致性、减少冗余，常使用关系模型（ER模型）；
3. 在关系模型中，使用三范式规则来减少冗余；

3.1.2OLAP（在线联机分析）

1. OLAP系统，主要操作时复杂分析查询；关注数据整合，以及分析、处理性能；
2. OLAP根据数据存储的方式不同，有分为ROLAP、MOLAP、HOLAP;

OLAP系统分类

1. ROLAP(Relation OLAP):使用关系模型构建，存储系统一般为RDBMS
2. MOLAP(Multidimensional OLAP，多维型OLAP)：预先聚合计算，使用多为数组的形式保存数据结果，加快查询分析时间；
3. HOLAP（hybird PLAP，混合架构的OLAP）:ROLAP和MOLAP两者的集成；如低层时关系型的，高层时多维矩阵型的；查询效率高于ROLAP,低于MOLAP；

3.2ROLAP系统建模方法

典型的数据仓库建模方法有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操作

3.2.1维度模型

• 维度模型中，表被分为维度表、事实表，维度是对事实的一种组织；
• 维度一般包含分类、时间、地域等
• 唯独模型分为星型模型、雪花模型、星座模型
• 唯独模型建立后，方便对数据进行多维分析

星型模型

• 标准的星型模型，维度只有一层，分析性能最优

雪花模型

• 雪花模型具有多层维度，比较接近三范式设计，较为灵活

星座模型

• 星座模型基于多个事实表，事实表之间会共享一些维度表；
• 式大型数据仓库中的常态，式业务增长的结果，与模型设计无关；

什么是宽表模型

• 宽表模型式维度模型的衍生，适合join性能不佳的数据仓库产品；
• 宽表模型将维度冗余到事实表中，形成宽表，以此减少join操作；

3.3MOLAP

3.3.1MOLAP系统建模方法

1. MOLAP将数据进行预结算，并将聚合结果存储到CUBE模型中;
2. CUBE模型以多维数组的形式，物化到存储系统中，加快了后续的查询；
3. 生产CUBE需要大量的时间、空间，维度预处理可能会导致数据膨胀；

** 常见的MOLAP产品**

• Kylin
• Druid