数据仓库基础

数据仓库基础

本篇笔记仅记录数据仓库的理论知识以及相关技术概念介绍。

前言

数据仓库的诞生原因有两个，一个是历史数据积存；另一个是企业数据分析需要。

详细说明

数据仓库

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

特点

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

数据库与数据仓库的区别

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

数据仓库技术实现

数据仓库建设方案

数据仓库主要分为两种：

• 传统数据仓库：有关系型数据库组成MPP集群（大规模并行处理），有每一个关系型数据库来进行数据计算，当所有节点计算完毕后最终汇总成为一个准确的结果；
• 大数据数据仓库：利用天然的扩展性，完成大量数据的存放。将SQL转换为大数据计算引擎任务，完成数据分析。

两种建设方案数据仓库的优劣

• 传统数据仓库的优缺点：

  • 优点：在数据量没有达到某一个量级的时候，传统数仓可以充分地表现出每个节点的传统关系型数据库的优势；

  • 缺点：当数据量超过某一个量级的时候，传统数仓的扩展性受到制约——分布式数据库中需要使用网络来对各个节点中的数据进行连接，如果数据量过大，则需要告诉网络来满足计算需求；

    ​ 第二个问题就是热点问题。在进行数据运算的时候，如果热点数据存在于一个节点时，在频繁的访问热点数据进行计算的时候，将会对该节点造成相当庞大的负荷。解决办法一般是在热点数据中加入前缀，认为的将热点数据打乱，分散在各个节点来缓解节点压力。该方法会产生其他问题，比如对于网络的需求以及对于热点数据增加前缀的操作所消耗的资源。

• 大数据数据仓库的的优缺点：

  • 优点：解决了扩展性问题。数据的存储使用分布式文件系统，默认将数据按照128MB进行拆分，存放在分布式文件系统中的各个节点；在数据上传的时候，会对数据进行备份存放到不同的节点，在进行数据计算分析的时候会寻找到较为空闲的节点来分配任务完成数据分析。
  • 缺点：SQL支持率较低。大数据计算引擎是由原有的分布式数据库SQL引擎转换为大数据计算引擎，所以SQL的支持率没有传统数仓这种由原有关系型数据库对SQL支持率高，不过对于现今的大数据计算引擎中，对于SQL的支持率也是越来越高；事务支持复杂。大数据架构是分布式架构，对于事务的支持较难；且多数大数据仓库产品对于事务的支持是不全的。不需要担心的是，大数据仓库对于事务的需求并不是很大，主要需要的是读取的操作；数据量较小的时候运算速度没有传统书藏那么高，在大数据数仓中，分配、调度等操作将会消耗一定时间，而当数据量达到一定规模的时候相对于计算时间来说就可以忽略不计了。

整体架构介绍

传统数据仓库的架构

MPP架构

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

架构优点：

• 运算方式进行，延迟低，吞吐低；
• 适合中等高规模的结构化数据处理。

架构缺点：

• 单个节点脱离集群后无法自主完成任务。
• 架构位置不透明，通过Hash确定数据所在的物理节点，查询任务在所有节点均会执行；
• 并行计算时，单节点瓶颈会成为整个系统短板，容错性差；
• 分布式事务的实现会导致扩展性降低。

分布式架构

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

MPP + 分布式架构

数据存储采用分布式架构中的公共存储，提高分区容错性；

上层架构采用MPP，减少运算延迟。

数据仓库常见产品

传统数仓

Oracle RAC

• Oracle的集群版本，商业数据库；
• 不属于MPP架构，每个节点之间共享资源；
• 整体优势为使用、维护上比较方便；
• 当个集群只能支持100左右的节点，适用于数据量不大的情况；

DB2

• DB2的集群版本是DB2 DBF，是IBM的商业版本，与IBM的兼容性最好，一般伴随IBM的其他产品赠送；
• DB2并不是企业搭建数据仓库的首选产品，多数为使用IBM产品后赠送了DB2，为了节约成本所以大家能DB2 DBF集群；

Teradata

• 商业数据库，一般存在于企业搭建数据仓库的选择中；
• 与DB2的售卖性质相似，与硬件捆绑销售，不过性能还是比较棒的；
• 自带数据引擎以及查询工具，填补了架构上方面的昂贵

Greenplum

• 开源MPP架构中的一个代表，开源成本比较低，老牌MPP数据库的代表；
• 因开源免费，所以在可用性等方面并不是很出色，但根据价格和性能之间的性价比来说依旧吊打其他MPP数据库

大数据数仓

Hive

• 属于Hadoop分布式架构下的主流数仓产品；
• 工作原理是将SQL转换为大数据的计算引擎MapReduce，同时支持Spark（最新版本建议转换为Spark）；
• 处理延时比较大，所以适合海量数据的跑批处理；
• Hive的SQL支持率不高，大约60%左右；

Spark SQL

• 属于Spark生态圈的产品，诞生的原因主要为了支持Hive（Hive源生的MapReduce计算速度过于缓慢）；
• SparkSQL的开发较为灵活，对于转换为的Spark引擎的支持更强，效率较高。

HBase

• 属于大数据NOSQL数据库，相比较结构化数据来说，更加适合存储非结构化、半结构化数据库；
• 主要特性石高并发读；
• 底层NOSQL，不被关系型数据库的规则所约束（即表间关系的变化对于该数据库的影响较小）；
• 主要面向实时流处理系统以及前端业务系统的高并发业务查询以及非结构化、半结构化数据存储。

Impala

• 属于MPP架构的数据查询引擎，底层加绒以上几个数据库，提供快速交互查询的服务；

HAWQ

• 属于Greenplum在Hadoop上的移植产品，是一各分布式+MPP架构的产品；
• SQL支持率较高，性能较为出色；

TIDB

• 不属于常见的MPP+分布式架构，属于自己独有的MPP+SMP架构；
• 底层属于NOSQL存储，支持SQL语法，兼容MySQL；
• 该数据库主要面向的是OLTP，改性能对数仓没有太大的性能提升，熟悉即可。

数据仓库架构详解

架构图

根据数据流动方向为自下向上：

• ETL（数据同步模块）：将数据从数据源抽取，进行交互转换，而后在加载到目的地的过程；

  • Extract：抽取；
  • Transform：转换；
  • Load：加载。

  数据仓库需要定期从业务数据库同步数据，有ETL实现；对于从关系数据库中抽取数据处理并不复杂，但是在半结构或非结构数据中抽取则会在转换等方面耗费较多时间；

• ODS（操作数据源层）：数据通过ETL抽取到ODS层中，与原始数据保持一致，不做加工；数据到ODS层中不允许修改（不易失性）；

• CDM（公共维度模型层）：该层为数据分析提供服务

  • DWD（数据明细层）：接收ODS层的数据，因为ODS层不对数据进行修改（数据的类型，结构等不同），将数据的类型、字段约束等进行修改（清洗）后，存放到DWD中；

  • DWS（数据汇总层）：数据经过DWD清洗之后，将进入到DWS中进行汇总（即，按照主题来对数据进行整理汇总）。该过程中会将DWD中零散的表汇总成宽表来处理（汇总的宽表脱离了三范式），提升执行效率。数据建模出现在这一层。

    程序执行人员会根据DWS中的数据进行相关运算，运算结束后会将结果提交给数据应用层。

• ADS（数据应用层）：计算的结果在ADS层展示给应用程序来看。

  • ADS一般可以被单独分出，成为数据集市层；
  • ADS被单独分出后，可以采用与CDM层不同体系或框架的产品；
  • ADS可以使用传统的数据库来搭建，并对应用提供访问接口。

ETL流程详解

• 将数据从数据源抽取、交互转换、加载至目的端的过程；
• 该环节为构建数据仓库的重要一环，用户从数据元抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型将数据加载到数据仓库去；
• ETL规则的设计和实施约占整个数据仓库工作量的60%~80%。

数据抽取（Extraction）

• 抽取结构化数据一般采用JDBC连接数据库对数据库中的数据进行抽取，但这势必会影响数据库正常运行的效率，所以企业基本都会采用在凌晨进行抽取；
• 通过JDBC去申请数据库的IO来进行数据抽取的速度较慢，而且在金融行业等数据库的安全性要求极高的企业中是禁止直接通过JDBC连接数据库进行数据抽取的；
• 建议在对结构化数据库中的信息进行采集的时候，采用采集数据库日志的方式来采集（数据库日志存在数据库所在的本地文件中，采集日志不会涉及数据库的IO），但是采集到的的WAL文件数据需要进过解密才能获取到数据库中的数据，所以该过程无法使用人工来完成；
• 抽取非结构化数据的时候可以直接抽取存储文件（非结构化数据可以监听文件是否有变动，对需要抽取的数据采用直接抽取文件中的数据即可）；

数据抽取方式

• 数据抽取方式分为以下两种：
  • 全量同步：将全部数据进行抽取，一般用于初始化数据装载（全量同步一般只需要在第一次时执行）；
  • 增量同步：会检测数据的变动，抽取发生变动的数据，，一般用于数据更新。

数据转换

• 数据转换需要以下两个阶段：

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

• 结构化数据转换过程比较简单，非结构化数据转换较为复杂。

数据加载

• 将最后处理玩的数据导入到对应的目标源中。

ETL常见工具

结构化数据ETL工具

• Sqoop

将结构化数据库通过JDBC连接后，采用并发处理，将数据批量导入到大数据数据仓库（建议使用1.x版本）。

• Kettle

该工具开源免费，且提供可视化界面。

• Datastage

收费

• Informatica

收费

• Kafka

是一个消息队列，并且提供ETL功能，可以将数据存入该队列中，等待对数据的整理抽取、

非/半结构化数据

• Flume

支持对文件、端口等数据进行监控，如果检测到文件发生变动，则会将其加载到数据源中。

• Logstash

同上。

操作数据层（ODS）

• 保存的数据与原业务的数据保持一致，通过增加字段用来进行数据管理；
• 存储的历史数据是只读的，提供业务系统查询使用；
• 业务系统对历史数据完成修改后，将update_type字段更新为UPDATE，追加会ODS中（数据库中进行数据修改，然后再将修改的数据追加回ODS）；

建议在追加数据的时候采用外连接的方式来判断新增数据和修改数据，在内存中将修改数据修改完毕后，将ODS层中的数据覆盖掉，保证业务系统与数据仓库的数据一致

公共维度模型层（CDM）

数据明细层（DWD）

• 数据明细层对该层的数据进行清洗、标准化、维度退化（时间、分类、地域）；
• 数据仍然满足3NF模型，为分析数据做准备。

数据汇总层（DWS）

• 即将DWD中的3NF零散表按照分析主体进行计算汇总，存放便于分析的宽表（宽表模型）；
• 存储模型并非3NF，主要注重数据聚合，复杂查询、处理性能更有的数仓模型。

数据应用层（ADS）

• 存储数据分析结果，为不同业务场景提供接口，减轻数据仓库的负担；
• 如果直接将数据仓库的接口暴露出来，会加重数据仓库的服务负载，所以一般使用工具搭建一个专门的查询工具来查询结果。

数据仓库建模

OLAP与OLTP的区别

OLTP

• OLTP（在线事务处理）系统中，主要操作时随机读写，一般来说是针对于常见的业务系统数据库的操作；
• 为了保证数据一致性、减少冗余，常使用关系模型（E-R）来表示数据关系；
• 关系模型中，使用3NF规则减少冗余

OLAP（在线联机分析）

• 主要操作时复杂分析的查询，关注数据整合，以及分析、处理性能；
• OLAP根据数据存储的方式不同，又分为ROLAP、MOLAP、HOLAP；
• 主要目的就是加强数据分析功能。

LOAP分类：

• ROLAP：关系型OLAP，使用关系模型构建，存储系统一般为RDBMS；
• MOLAP：多维性OLAP，预先聚合计算，使用多维数组的形式保存数据结果，加快查询分析时间；
• HOLAP：或和架构OLAP，以上两种的集成，底层是关系型，高层是多维矩阵型，查询效率高于ROLAP，低于MOLAP。

ROLAP建模方法

ROLAP建模依赖关系数据库的关系，MOLAP以及HOLAP的建模依赖于产品的架构、技术等

• 典型的数据仓库建模方法有E-R模型（与常规E-R图不一样，该模型更适合大数据数仓的关系模型）、维度模型、Data Value、Anchor；
• 最流行的是维度模型，其余三种模型属于同源衍生品，适合于基于已有数据库且数据库变化不大的情况。

维度模型

• 维度模型中，表被分为维度表、事实表，维度是对事实的一种组织；
• 维度一般包含分类、时间、地域。

维度模型主要分为以下几类：

• 星形模型：标准的星形模型只有一层维度，分析性能最优，星形的核心为事实表，周围拓展产生的是维度表，根据维度表可以按照满足设计的需求来对数据进行分析。
• 雪花模型：雪花模型一般具有多层维度，比较接近3NF，比较灵活，性能较差；
• 星座模型：星座模型可以理解为星形模型和雪花模型的集合；
• 宽表模型：维度模型的衍生，以上三种模型的操作需要join操作，大数据数仓在执行join操作的时候需要大量的移动数据，性能不佳。

MOLAP系统建模方法

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

MOLAP产品

• Kylin：开源；

• Druid：主要面向时空数据库。

OLAP多维分析

• OLAP主要操作时复杂查询，可以夺标关联，使用count、sum、avg等聚合函数；
• OLAP对复杂查询操作做了直观的定义，包括钻取、切片、切块、旋转。

钻取

• 对维度不同层次的分析，通过改变维度的层次来变换分析的力度；
• 钻取包括上卷、下钻；
• 上卷：从低层次到高层次的转换；
• 下钻：只从高层次到低层次的切换。

切片、切块

• 选择某个维度进行切割叫做切片；
• 选择多个维度进行分割叫做切块。

旋转

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