数仓简介
数据仓库
是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合,它可以为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。
面对大数据的多样性,在存储和处理这些大数据时,我们就必须要知道两个重要的技术,其分别是:数据仓库技术、Hadoop。当数据为结构化数据,来自传统的数据源,则采用数据仓库技术来存储和处理这些数据
1. 什么是数据仓库
数据仓库之父 Bill Inmon 将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合,用于支持管理者的决策过程。
数据仓库的目的是构建面向分析的集成化数据环境,为企业提供决策支持。
数据仓库本身并不 “生产” 任何数据;同时自身也不需要 “消费” 任何的数据,数据来源于外部,并且开放给外部应用,这也是为什么叫 “仓库” ,而不叫 “工厂” 的原因。
1.1 数仓诞生背景
历史数据堆积
存在冷数据,导致业务库的性能下降,需要将其从业务数据库中转移出去
企业数据分析的需要
企业存在多个部门,统一整合数据仓库并抽取分析,辅助管理层决策
1.2数据仓库基本概念
数据仓库是面像主题的,集合的,非易失的,随时间变化的数据集合
1.3数据仓库的特点
面向主题的:根据主题将原始数据聚合在一起(零碎表聚合再一起变成大宽表)
集成:原始数据来源于不同数据源,整合成统一规范的最终数据,需要经过抽取,清洗,转换的过程
非易失:保存的数据是一系列历史快照,不允许被修改,用于查和分析
时变性:定期接收,集成新的数据,从而反映出数据的最新变化
2. 数据仓库的基本概念
2.1 数据源
构建一个数据仓库,必然要有充足的数据源,从外部为数据仓库系统提供进行分析的 “原材料” ——数据,这些数据来源称为数据仓库的数据源。
数据源并不局限于传统数据库,可以是非结构化的信息,如爬取日志,也可以是埋点日志。
2.2 ETL
在 BI 项目中 ETL 会花掉整个项目至少 1/3 的时间,ETL 设计的好坏直接关系到 BI 项目的成败。其中,花费时间最长的是 “T”(Transform,清洗、转换)的部分,一般情况下这部分工作量是整个 ETL 的 2/3 。
ETL 是将业务系统中的数据经过抽取(Extract)、清洗转换(Transform)和加载(Load)到数据仓库的过程,目的是将企业中的分散、凌乱、标准不统一的数据整合到一起,为企业的决策提供分析依据。
ETL 处理分为五大模块,分别是:数据抽取、数据清洗、数据转换、规则检查、数据装载。各模块之间灵活组合,形成 ETL 处理流程。
2.4 数据集市
数据集市(Data Market,DM)是为企业特定部门的决策支持而组织起来的一批数据和业务规划。
它是一种小型的、部门级数据仓库,习惯上称之为 “主题域” ,企业的不同部门有不同的 “主题域” ,因而就有不同的数据集市。
数据集市有两种类型:独立型数据集市(Independent Data Mart)和从属型数据集市(Dependent Data Mart)。
独立型数据集市的实质,是为了满足企业内各部门的分析需求而建立的微型数据仓库。
有些企业在实施数据仓库项目时,为了节省投资,尽快见效,针对不同部门的需要,分布建立起这类数据集市,已解决一些较为迫切的问题。
但是,当多个独立的数据集市增长到一定规模后,由于没有统一的数据仓库协调,企业只会又增长出一些新的信息孤岛,仍然不能以整个企业的视角来分析数据。
- 数据库和数据仓库的区别
2.5传统数仓和大数据数仓的建设方案
2.5.1传统数仓
内容:由关系型数据库(单机)组成(大规模并行)的MPP处理集
提前调度业务数据库的数据分配到各个节点进行存储(一般使用hash),各个节点计算出来的结果也是部分结果,汇总成一个总结果
优点:数据迁移成本低(因为和业务库用的都是同样的关系型数据库),兼容原有的sql语法,并继承单机型数据库优异的性能
缺点:即使增加了大容量的硬盘,由于数据量大也没办法满足存储需求导致
(1) 扩展性有限
①单机架构发展过来的,进行功能扩展的时候,通过增加中间件方式,有中间件把数据分发到各个节点,计算任务也是中间件进 行汇总,每个节点本质也是一个数据库,如果需要数据交换(用到其他数据库数据),就需要通过高速网络与其他节点连接,高 速网络的支撑直接决定了节点上线
②分库分表,例如将一张大表分发到各个节点存储,但是由于表粒度很细,也是有上限的。
(2) 热点问题
一张大表分库分表存储,部分库中的数据为热点数据,这个节点就容易存在宕机,超时等问题,从而影响整个系统的性能,节 点出现错误越多。(可以通过数据加盐的方式:表中数据增加前缀,随机分布到各个节点中)
2.5.2 大数据数据仓库
内容:
(1)基于大数据技术(天然的分布式存储、分布式计算),并添加上sql的支持形成的架构
(2)在数据处理方面:为了避免大海量数据的移动,造成IO跟网络的开销,所以使用了移动计算,而不是移动数据的架构(在哪儿存储就在哪儿计算,部分计算结果再进行汇总)
缺点:
(1)初期易用性差(SQL支持率)
计算引擎有自己特定的语法,但是企业中的数据都是放在数据库中的结构化数据(就是SQL)咯,如果要整到大数据平台,那时候需要 做大量的业务数据迁移工作(语法上的转换成SQL转成大数据处理语法)
(2)事务支持方面
分布式结构实现事务比较难,即使是大数据产品对事务的支持也是比较不全的,但是针对数据分析,事务的问题也不是致命的问题
(3)数据量较少的时候计算比较慢
数据量不大,光是数据转换,分发,调度,汇总,整个过程本身就会花很多时间,数据量打达到某个量级,调度时间远远小与计算时 间了
优势:
(1)解决了扩展性的问题
分布式文件系统:默认文件拆分,以128m大小分发到各个节点进行存储,不用考虑分库分表的问题,就是当成文件。上层处理的 时候,采用元数据把文件还原成表结构
(2)解决了热点问题
会对分布式存储的文件进行备份,默认备份三份给到不同的节点,分发计算任务的时候,他是可以选择备份节点中最空闲的一个节 点,就极大降低了热点的问题
2.6 MMP架构和分布式架构的具体区别
2.6.1 MMP架构
内容:
将单机数据库节点组成集群,比单机数据库整理性能肯定会好一些
节点间非共享,每个节点都有自己的独立的磁盘存储系统和内存系统,每个节点不会去关心其他节点的状态以及整个集群的状态
每个集群节点之间通过专用网络和商用网络进行连接,要是要用到其他节点的数据,就得用到高速网络,所以对网络传输要求就很高,搭建成本也是比较高的,并且每个节点是必须得协同,无法单独,必须依托整个集群向外提供整体服务
由于是关系型数据库组成的集群,所以在架构设计上遵从了关系型数据库的设计理念,设计上优先考虑C(一致性):事务特性,再考虑A(可用性),尽量P(分区容错性)
优点:
由于CAP顺序考虑,运算方式精细,更注重锁,事务,包括内外寸交互的细节,从而保证了数据的一致性,可靠性
因为精细,所以时间,延迟上都比较,同时精细导致在集群吞吐量上比较差,数据达到一定规模了,就会变成局限规模的一个瓶颈,所以适合中等的规模的结构化数据处理
缺点:
(1)数据存储不透明
①存储靠的是Hash确定在哪个节点,查询是没法提前知道数据存放在那个节点,查询任务会在所有节点执行,这个是非共享架构决 定的,虽然对性能没啥影响,真正有影响是如下
(2)拓展性问题
并行运算时,一个节点缓慢了,别的节点需要等待,单个节点一定会成为整个系统的短板,改善方式有、把这个缓慢节点上的数据通 过高速网络传到别的节点进行计算,但是节点量比较多,故障率不变,故障节点数增加,瓶颈就会明显,所以扩展行较差
c分布式事务的实现会导致扩展性降低
2.6.2 分布式架构
内容:
或者叫hadoop架构,或者是批处理架构
各节点可以实现场地自治(可以单独运行局部程序):每个节点相当于服务器,既包含存储的资源也包含计算的资源,当计算任务分发到各个节点的时候,是可以访问公共存储系统(共享的数据),找到数据所在位置,做到了访问数据的透明
各个节点是通过局域网和广域网相连,在运算是致力于减少数据移动(移动计算而非移动数据)
优先考虑P(分区容错)然后A(可用性),再然后C(一致性),保证容错性:存储的时候拆分成多个分片,然后分片下多个副本,减少了单层故障的问题,保证了容错性
优点:
文件处理方式粗犷,导致吞吐量特别大,随着数据量大,处理优势明显
采用公共的数据存储,扩展性极强,非常适合处理结构化或者非结构化的数据(指的一些格式化的数据)
2.6.3 MPP架构+分布式架构
内容:
数据存储层采用分布式架构中的公共存储,提高分区容错性(把数据透明化)
上层架构采用MPP架构精细化处理模式,减少运算的延迟
运用场景:
由于延迟较低,运行速度比较快,在实时的流处理场景中经常被采用
2.7常见一些数据仓库的产品
2.7.1传统数仓技术选型
Oracle REC:Oracle集群版本,oracle本身不属于MPP架构,因为他每个节点之间是共享磁盘资源的,当个集群仅100左右的节点,适合数据量不大的场景
Db2:集群版本Db2 DPF,IBM下商业数据库,是’MPP架构的,一般买硬件有时会送,数仓很少用
Teradata:易用性和性能都特别优秀,一体机销售(软硬件捆绑),可用性和高兵发性能优秀,而且自带数据引擎和查询工具,大型企业数仓选型会用
Greenplum:开源的,基于Postgre SQL改造而来的
2.7.1大数据数据仓库
Hive:属于hadoop分布式架构(hadoop生态圈),将sql转换成大数据计算引擎mapreduce进行运算,不过现在也能支持成转成spark,在海量数据的批处理分析计算上,吞吐量大,但是延迟高,有自己的一套sql语法:hivesql,如果业务迁移,也是有一定的复杂度,离线批处理是hive的主场
Spark sql:属于spark生态圈数据产品,诞生是因为hive背后的mapreduce运行速度慢,产生了hive on spark,对比hive,hive需要单独安装和运维,要有一个机群,但是spark sql,只要有一个saprk集群,就可以运行,不需要单独安装
Hbase:是一个 no sql数据库,更适合存储非结构化数据,半结构化数据,特征可以高并发读,不会被关系型数据库中的规则限制:比如表结构的频繁的DDL以及变动对其影响是很小的,试用的场景是:实时流处理的数据存储,还有前段业务系统高并发的业务查询
Impala:是MPP架构的一个数据查询引擎,底层是兼容hive sql,spark sql,hbase,提供的是快速交互查询的服务,是所为数仓补充产品,是一个快速查询的接口
HAWQ:Greenplum在hadoop上的移植产品,批处理架构+MPP,兼容两者性能
TIDB:架构是MPP+SMP,底层也是NO SQL存储,同时可以欧了OLAP,也可以OLTP,更侧重OLTP的性能