数据夜话之大数据OLAP数据库概览

最新推荐文章于 2024-10-19 13:11:45 发布

剑语2024

最新推荐文章于 2024-10-19 13:11:45 发布

阅读量814

点赞数

文章标签：数据库大数据 java 分布式 hadoop

本文链接：https://blog.csdn.net/stillcoolman/article/details/111028179

版权

当下大数据技术发展如火如荼，各种数据库处理技术层出不穷，可是各种数据库的大致分类清楚吗？能够结合项目数据的业务特点进行选型吗？今天先从OLAP型数据库说起，介绍相关的数据库。

OLTP和OLAP分不清？

我们通常将数据库分为OLTP和OLAP两大类，先了解一下它们的区别：

OLTP (online transaction processing 联机事务处理)，典型代表如 mysql，擅长事务处理，能够在数据操作时保持强一致性和原子性，支持数据的数据频繁插入或修改，数据模型一般为实体-关系模型(E-R)，主要为了查询或者改变数据记录。对于银行证券公司的账务系统来说为了保证准确性当然首选OLTP型数据库。但是数据量过大的话，OLTP就有些力不从心了。
OLAP (online analytical processing 联机分析处理)，例如 greenplum，擅长对大量数据进行多维复杂分析，追求极致性能，而不特别关注数据插入修改等事务性处理的一类数据库系统，数据模型一般为星型或雪花型，主要为了分析规律预测趋势。可以理解为 OLAP 面对的是复杂的多表聚合型查询。

OLAP技术栈

为应该这挑战大数据给传统数据技术带来的巨大挑战，主要发展出三大类OLAP型技术：

MPP架构型OLAP (Massive Parallel Processing)
批处理架构型OLAP
预计算型OLAP

上面三种OLAP型技术按照 建模类型 来划分的话，也可以分为：

MOLAP，M即表示多维(Multidimensional)，一般指预计算型OLAP。
- 它会对原始数据进行预计算得到用户可能需要的所有结果，然后将结果存储到优化过的多维数组存储中，能够快速响应请求。
- 如果业务发生需求变更，需要进行预定模型之外新的查询操作，现有的MOLAP实例就无能为力了，只能重新进行建模和预计算。
- 所以，MOLAP适合业务需求比较固定，数据量较大的场景。
ROLAP，R即表示关系型(Relational)。
- ROLAP在导入增量数据后不用像MOLAP一样进行重复计算，显然更具扩展性。
- ROLAP的使用门槛更低，在完成星型或雪花型模型的构建，创建对应schema的事实表和维度表并导入数据后，用户只需会写出符合需求的SQL，就可以得到想要的结果，但获取查询结果所需的时间无法准确预知，可能秒回，也可能需要花费数十分钟甚至数小时。
- 所以，ROLAP适合业务需求复杂多变的场景。

MPP

MPP架构为应对单机性能无法满足大数据分析的挑战，通过加并发方案，将数据存储于多个子节点中，r使任务并行在每个节点上计算完成后，再将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。

MPP数据存储一般有特定的数据格式，而且行列混合存储，其对复杂关联查询、全表扫描支持好查询速度快，能在秒计甚至毫秒级以内返回查询结果实现即席查询，对于亿级数据的项目能够很好的支持。在同等规模的集群执行相同的数据加工逻辑，即使与Spark对比，MPP所耗费的时间也可能更少些。

但是 MPP 的问题在于：

短板效应；以节点为计算单位，如果一个节点总是执行的慢于集群中其他的节点，整个集群的性能就会受限于这个故障节点的执行速度，无论集群有多少节点，都不会有所提高；
不方便扩展；MPP为了速度，需要对导入的数据进行自定义的格式优化，以便后续查询时能加速(所以更适合存储高密度价值数据)。数据存储相当于黑箱，导致数据很难被别的系统读取。也就导致执行引擎和存储紧耦合，不方便进行执行引擎扩展。数据与节点绑定，而且元数据也相当于一个黑箱的话更是难以对集群规模进行扩展。
并发的限制；MPP的核心就是对查询分配到各个节点进行查询，单个查询快的同时整个系统的并发在50~100左右。

典型代表：Greenplum、Impala、Presto，后两者是 MPP On Hadoop型

批处理

批处理架构，本文特指Hadoop相关技术，也是通过分布式的技术，加并发，来应对大数据量的挑战。这样乍一看，分而治之的思想和 MPP 架构是非常相似，但是批处理Hadoop更加开放，着力点在数据高吞吐处理能力以及大集群扩展能力。

首先，Hadoop型技术将数据直接以平铺的数据文件存储，虽然简单粗暴，但是结合Avro，Parquet等存储格式的引入，批处理更加精细而且扩展性强。
数据的多副本存储使其具有更多“本地化”数据加工的备选节点，而且数据加工处理与数据存储并不绑定，可以根据节点的运行效率动态调整任务分布，每个节点执行任务不平均，给问题节点分配的任务更少。

不过代价就是要通过磁盘共享资源，产生了大量的IO操作，不管是读还是写都会慢。即使SparkSQL在shuffle过程中也一般需要两次数据落盘。

但是，随着 SparkSQL 对SQL语法完备，以及CBO，RBO对SQL语句进行充足优化，而且目前3.0版本还增加了许多运行时动态调整的特性。当下的 Hadoop系批处理框架已经在工程成熟度赶上了MPP型框架。

典型代表：Hive、Spark、Tez(Hive3的执行引擎)、Flink

MPP+批处理

现在也有很多 MPP on Hadoop 型的技术，它们的特点是使用MPP并行去中心化架构，然后基于Hadoop底层数据，可以进行亿级数据的分析型数仓建设(相对于hive、spark则能进行百亿数据的离线数仓建设来说)，例如 Presto，Impala 属于 Sql-on-Hadoop MPP，利用 Hive metastore，直接读取 Parquet、ORC 等文件格式。

以Presto为例，基于内存运算，减少没必要的硬盘IO，但是极吃内存，而且只是对单表的聚合较好，对于多表的join聚合性能一般。由于是MPP架构，在访问Hive数据源的时候，如果其中一台Worker由于 load 数据处理很慢，那么整个查询都会受到影响，因为下游需要等待所有上游的结果，即MPP常见的短板问题。