数仓理论- 01 数据仓库简介

数仓理论- 01 数据仓库简介

数仓理论（入门）

参考：b站鹏程

1 概述

数仓简介 架构 建模 最佳实践

2 数仓简介

2.1 数仓诞生背景

历史数据堆积

​ 随着业务增长产生数据，存放在业务数据库中，造成积压，其中部分冷数据，导致业务库的性能下降影响业务，需要将其从业务数据库中转移出去，放在专门的存放历史数据的数据仓库

企业数据分析的需要​ 企业存在多个部门，统一整合数据并抽取分析，辅助管理层决策 也是功能和目的

2.2 数据仓库基本概念

数据仓库是面像主题的，集合的，非易失的，随时间变化的数据集合 主要用于组织积累的历史数据，并使用分析方法(OLAP、数据分析)进行分析整理，进而辅助决策，为管理者，企业系统提供数据支持，构建商业智能

2.3 数据仓库的特点

2.4 数据仓库VS数据库

数据仓库

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

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

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

数据库

​ (1)数据库是面向事务设计的，属于OLTP(在线事务处理)在线事务系统

​ (2)主要操作是随机读写

​ (3)即在设计的时候避免冗余,常常采用符合范式规范来设计

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

2.5.1 传统数仓

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

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

优点：数据迁移更加方便且成本低（因为和业务库用的都是同样的关系型数据库），兼容原有的sql语法，并继承单机型数据库优异的性能 缺点：即使增加了大容量的硬盘，由于数据量大也没办法满足存储需求导致

​ (1) 扩展性有限

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

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

​ (2) 热点问题

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

2.5.2 大数据数据仓库

内容:

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

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

缺点：

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

​ 计算引擎有自己特定的语法，但是企业中的数据都是放在数据库中的结构化数据(就是SQL)咯，如果要整到大数据平台，那时候需要做大量的业务数据迁移工作(语法上的转换成SQL转成大数据处理语法)给到大数据计算引擎处理，后续产品慢慢出现了语法的转换，现有产品的sql支持率也是越来越高

​ (2)事务支持方面

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

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

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

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

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

​ (2)解决了热点问题

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

2.6.1 MMP架构

内容:

将单机数据库节点组成集群，比单机数据库整理性能更优 节点间非共享，每个节点都有自己的独立的磁盘存储系统和内存系统，每个节点不会去关心其他节点的状态以及整个集群的状态 每个集群节点之间通过专用网络和商用网络进行连接，要是要用到其他节点的数据，就得用到高速网络，所以对网络传输要求就很高，搭建成本也是比较高的，并且每个节点是必须得协同，每个节点无法单独运行局部的一个程序，必须依托整个集群向外提供整体服务 由于是关系型数据库组成的集群，所以在架构设计上遵从了关系型数据库的设计理念，设计上优先考虑C(一致性)：事务特性，再考虑A(可用性)，尽量P(分区容错性)，一般CAP中兼顾两个，另一个会差一些

优点:

由于CAP顺序考虑，运算方式精细，更注重锁，事务，包括内外存交互的细节，从而保证了数据的一致性，可靠性 因为精细，所以时间，延迟上都比较，同时精细导致在集群吞吐量上比较差，数据达到一定规模了，就会变成局限规模的一个瓶颈，所以适合中等的规模的结构化数据处理

缺点:

​ (1)数据存储不透明

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

​ (2 )拓展性问题

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

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

2.6.2 分布式架构

内容:

或者叫hadoop架构，或者是批处理架构 各节点可以实现场地自治(可以单独运行局部程序)：每个节点相当于服务器，既包含存储的资源也包含计算的资源，计算资源和存储资源并没有合并在一起，每个节点的存储资源拿出来，然后形成分布式数据存储系统，计算资源是当计算任务分发到各个节点的时候，是可以访问公共存储系统(共享的数据)，找到数据所在位置，所以和mpp不同的点就是可以单独运行局部应用，做到了访问数据的透明，可共享 各个节点是通过局域网和广域网相连，在运算是 致力于减少数据移动(移动计算而非移动数据) 优先考虑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：MPP架构选型，易用性和性能都特别优秀，一体机销售(软硬件捆绑)，可用性和高兵发性能优秀，而且自带数据引擎和查询工具，大型企业数仓选型会用 Greenplum：开源的MPP数据库，基于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的性能

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。