数仓简介
数据仓库
是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合，它可以为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。
面对大数据的多样性，在存储和处理这些大数据时，我们就必须要知道两个重要的技术，其分别是：数据仓库技术、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的性能
