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

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

OLTP和OLAP分不清?

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

  1. OLTP (online transaction processing 联机事务处理),典型代表如 mysql,擅长事务处理,能够在数据操作时保持强一致性和原子性,支持数据的数据频繁插入或修改,数据模型一般为实体-关系模型(E-R),主要为了查询或者改变数据记录。对于银行证券公司的账务系统来说为了保证准确性当然首选OLTP型数据库。但是数据量过大的话,OLTP就有些力不从心了。
  2. 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 的问题在于:

  1. 短板效应;以节点为计算单位,如果一个节点总是执行的慢于集群中其他的节点,整个集群的性能就会受限于这个故障节点的执行速度,无论集群有多少节点,都不会有所提高;
  2. 不方便扩展;MPP为了速度,需要对导入的数据进行自定义的格式优化,以便后续查询时能加速(所以更适合存储高密度价值数据)。数据存储相当于黑箱,导致数据很难被别的系统读取。也就导致执行引擎和存储紧耦合,不方便进行执行引擎扩展。数据与节点绑定,而且元数据也相当于一个黑箱的话更是难以对集群规模进行扩展。
  3. 并发的限制;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常见的短板问题。

预计算

数据都以时间序列的方式进入系统并经过数据预聚合和建立索引,因为是预计算,所以应对多维查询时速度非常快(计算时间复杂度O(1))且稳定,支持高并发,支持集群扩展。缺点是灵活性较差。kylin就是典型代表,Kylin的核心思想是预计算利用空间换时间来加速查询模式固定的OLAP查询。。

总结

MPP型OLAP MPP on Hadoop HadoopOLAP 预计算MOLAP
GreenPlum Presto内存计算引擎 Hive Kylin
Impala SparkSQL Doris

参考

分布式SQL查询引擎Presto原理介绍

主流开源OLAP系统的分类及核心技术点-温正湖

浅谈OLAP系统核心技术点

你可能感兴趣的:(数据库,大数据,java,分布式,hadoop)