数仓理论（入门）- 01 数据仓库简介_数据仓库背景

数仓理论（入门）

参考：b站鹏程

1 概述

1. 数仓简介

2. 架构

3. 建模

4. 最佳实践

2 数仓简介

2.1 数仓诞生背景

1. 历史数据堆积

​ 存在冷数据，导致业务库的性能下降，需要将其从业务数据库中转移出去

2. 企业数据分析的需要

​ 企业存在多个部门，统一整合数据仓库并抽取分析，辅助管理层决策

2.2数据仓库基本概念

​ 数据仓库是面像主题的，集合的，非易失的，随时间变化的数据集合

2.3数据仓库的特点

1. 面向主题的：根据主题将原始数据聚合在一起（零碎表聚合再一起变成大宽表）
2. 集成:原始数据来源于不同数据源，整合成统一规范的最终数据，需要经过抽取，清洗，转换的过程
3. 非易失：保存的数据是一系列历史快照，不允许被修改，用于查和分析
4. 时变性：定期接收，集成新的数据，从而反映出数据的最新变化

2.4数据仓库VS数据库

1. 数据仓库

​ (1) 面向主题的，OLAP（Online Analysis Process）在线分析处理系统;

​ (2) 主要操作是批量读写:关注数据整合（group by ，count）的分析、处理性能

​ (3) 会有意引入冗余，采用反范式设计（关联多张表形成宽表，便于分析，减少了和其他表的连接）

2. 数据库

​ 略

2.5传统数仓和大数据数仓的建设方案

2.5.1传统数仓

1. 内容：由关系型数据库(单机)组成（大规模并行)的MPP处理集

​ 提前调度业务数据库的数据分配到各个节点进行存储(一般使用hash)，各个节点计算出来的结果也是部分结果，汇总成一个总结果

2. 优点：数据迁移成本低（因为和业务库用的都是同样的关系型数据库），兼容原有的sql语法，并继承单机型数据库优异的性能

3. 缺点：即使增加了大容量的硬盘，由于数据量大也没办法满足存储需求导致

​ (1) 扩展性有限

​ ①单机架构发展过来的，进行功能扩展的时候，通过增加中间件方式，有中间件把数据分发到各个节点，计算任务也是中间件进 行汇总，每个节点本质也是一个数据库，如果需要数据交换(用到其他数据库数据)，就需要通过高速网络与其他节点连接，高 速网络的支撑直接决定了节点上线

​ ②分库分表，例如将一张大表分发到各个节点存储，但是由于表粒度很细，也是有上限的。

​ (2) 热点问题

​ 一张大表分库分表存储，部分库中的数据为热点数据，这个节点就容易存在宕机，超时等问题，从而影响整个系统的性能，节 点出现错误越多。(可以通过数据加盐的方式：表中数据增加前缀，随机分布到各个节点中)

2.5.2 大数据数据仓库

1. 内容:

​ (1)基于大数据技术(天然的分布式存储、分布式计算)，并添加上sql的支持形成的架构

​ (2)在数据处理方面：为了避免大海量数据的移动，造成IO跟网络的开销，所以使用了移动计算，而不是移动数据的架构(在哪儿存储就在哪儿计算，部分计算结果再进行汇总)

2. 缺点：

​ (1)初期易用性差(SQL支持率)

​ 计算引擎有自己特定的语法，但是企业中的数据都是放在数据库中的结构化数据(就是SQL)咯，如果要整到大数据平台，那时候需要 做大量的业务数据迁移工作(语法上的转换成SQL转成大数据处理语法)

​ (2)事务支持方面

​ 分布式结构实现事务比较难，即使是大数据产品对事务的支持也是比较不全的，但是针对数据分析，事务的问题也不是致命的问题

​ (3)数据量较少的时候计算比较慢

​ 数据量不大，光是数据转换，分发，调度，汇总，整个过程本身就会花很多时间，数据量打达到某个量级，调度时间远远小与计算时 间了

3. 优势:

(1)解决了扩展性的问题

​ 分布式文件系统：默认文件拆分，以128m大小分发到各个节点进行存储，不用考虑分库分表的问题，就是当成文件。上层处理的 时候，采用元数据把文件还原成表结构

​ (2)解决了热点问题

​ 会对分布式存储的文件进行备份，默认备份三份给到不同的节点，分发计算任务的时候，他是可以选择备份节点中最空闲的一个节 点，就极大降低了热点的问题

2.6 MMP架构和分布式架构的具体区别

2.6.1 MMP架构

1. 内容:

• 将单机数据库节点组成集群，比单机数据库整理性能肯定会好一些

• 节点间非共享，每个节点都有自己的独立的磁盘存储系统和内存系统，每个节点不会去关心其他节点的状态以及整个集群的状态

• 每个集群节点之间通过专用网络和商用网络进行连接，要是要用到其他节点的数据，就得用到高速网络，所以对网络传输要求就很高，搭建成本也是比较高的，并且每个节点是必须得协同，无法单独，必须依托整个集群向外提供整体服务

• 由于是关系型数据库组成的集群，所以在架构设计上遵从了关系型数据库的设计理念，设计上优先考虑C(一致性)：事务特性，再考虑A(可用性)，尽量P(分区容错性)

2. 优点:

• 由于CAP顺序考虑，运算方式精细，更注重锁，事务，包括内外寸交互的细节，从而保证了数据的一致性，可靠性

• 因为精细，所以时间，延迟上都比较，同时精细导致在集群吞吐量上比较差，数据达到一定规模了，就会变成局限规模的一个瓶颈，所以适合中等的规模的结构化数据处理

3. 缺点:

​ (1)数据存储不透明

​ ①存储靠的是Hash确定在哪个节点，查询是没法提前知道数据存放在那个节点，查询任务会在所有节点执行，这个是非共享架构决 定的，虽然对性能没啥影响，真正有影响是如下

​ (2)拓展性问题

​ 并行运算时，一个节点缓慢了，别的节点需要等待，单个节点一定会成为整个系统的短板，改善方式有、把这个缓慢节点上的数据通 过高速网络传到别的节点进行计算,但是节点量比较多，故障率不变，故障节点数增加，瓶颈就会明显，所以扩展行较差

​ c分布式事务的实现会导致扩展性降低

2.6.2 分布式架构

1. 内容:

• 或者叫hadoop架构，或者是批处理架构
• 各节点可以实现场地自治(可以单独运行局部程序)：每个节点相当于服务器，既包含存储的资源也包含计算的资源，当计算任务分发到各个节点的时候，是可以访问公共存储系统(共享的数据)，找到数据所在位置，做到了访问数据的透明
• 各个节点是通过局域网和广域网相连，在运算是致力于减少数据移动(移动计算而非移动数据)
• 优先考虑P(分区容错)然后A(可用性),再然后C(一致性)，保证容错性：存储的时候拆分成多个分片，然后分片下多个副本，减少了单层故障的问题，保证了容错性

2. 优点:

• 文件处理方式粗犷，导致吞吐量特别大，随着数据量大，处理优势明显
• 采用公共的数据存储，扩展性极强，非常适合处理结构化或者非结构化的数据(指的一些格式化的数据)

2.6.3 MPP架构+分布式架构

1. 内容：

• 数据存储层采用分布式架构中的公共存储，提高分区容错性(把数据透明化)
• 上层架构采用MPP架构精细化处理模式，减少运算的延迟

2. 运用场景：

• 由于延迟较低，运行速度比较快，在实时的流处理场景中经常被采用

2.7常见一些数据仓库的产品

2.7.1传统数仓技术选型

1. Oracle REC:Oracle集群版本，oracle本身不属于MPP架构，因为他每个节点之间是共享磁盘资源的，当个集群仅100左右的节点，适合数据量不大的场景
2. Db2:集群版本Db2 DPF,IBM下商业数据库，是’MPP架构的，一般买硬件有时会送，数仓很少用
3. Teradata：易用性和性能都特别优秀，一体机销售(软硬件捆绑)，可用性和高兵发性能优秀，而且自带数据引擎和查询工具，大型企业数仓选型会用
4. Greenplum：开源的，基于Postgre SQL改造而来的

2.7.1大数据数据仓库

1. Hive:属于hadoop分布式架构(hadoop生态圈)，将sql转换成大数据计算引擎mapreduce进行运算，不过现在也能支持成转成spark，在海量数据的批处理分析计算上，吞吐量大，但是延迟高，有自己的一套sql语法：hivesql，如果业务迁移，也是有一定的复杂度，离线批处理是hive的主场
2. Spark sql:属于spark生态圈数据产品，诞生是因为hive背后的mapreduce运行速度慢，产生了hive on spark，对比hive，hive需要单独安装和运维，要有一个机群，但是spark sql，只要有一个saprk集群，就可以运行，不需要单独安装
3. Hbase:是一个 no sql数据库，更适合存储非结构化数据，半结构化数据，特征可以高并发读，不会被关系型数据库中的规则限制:比如表结构的频繁的DDL以及变动对其影响是很小的，试用的场景是:实时流处理的数据存储，还有前段业务系统高并发的业务查询
4. Impala:是MPP架构的一个数据查询引擎，底层是兼容hive sql，spark sql，hbase，提供的是快速交互查询的服务，是所为数仓补充产品，是一个快速查询的接口
5. HAWQ:Greenplum在hadoop上的移植产品，批处理架构+MPP，兼容两者性能
6. TIDB:架构是MPP+SMP,底层也是NO SQL存储，同时可以欧了OLAP,也可以OLTP,更侧重OLTP的性能