• 微信公众号:美女很有趣。 工作之余,放松一下,关注即送10G+美女照片!

【转载】大数据OLAP系统–开源组件方案对比

开发技术 开发技术 3小时前 3次浏览

开源大数据OLAP组件,可以分为MOLAP和ROLAP两类。ROLAP中又可细分为MPP数据库和SQL引擎两类。对于SQL引擎又可以再细分为基于MPP架构的SQL引擎和基于通用计算框架的SQL引擎:

 
【转载】大数据OLAP系统--开源组件方案对比
  1. MOLAP一般对数据存储有优化,并且进行部分预计算,因此查询性能最高。但通常对查询灵活性有限制。

  2. MPP数据库是个完整的数据库,通常数据需要导入其中才能完成OLAP功能。MPP数据库在数据入库时对数据分布可以做优化,虽然入库效率有一定下降,但是对后期查询性能的提高有很大帮助。MPP数据库可以提供灵活的即席查询能力,但一般对查询数据量有一定限制,无法支撑特别大的数据量的查询。

  3. SQL引擎只提供SQL执行的能力,本身一般不负责数据存储,通常可以对接多种数据储存,如HDFS、HBase、MySQL等。有的还支持联邦查询能力,可以对多个异构数据源进行联合分析。SQL引擎中,基于MPP架构的SQL引擎,一般对在线查询场景有特殊优化,所以端到端查询性能一般要高于基于通用计算框架的SQL引擎;但是在容错性和数据量方面又会逊于基于通用计算框架的SQL引擎。

总之,可以说没有一个OLAP系统能同时在处理规模,灵活性和性能这三个方面做到完美,用户需要基于自己的需求进行取舍和选型。

2.1 开源MOLAP系统分析

2.1.1 Kylin

Apache Kylin 是一个开源的分布式分析引擎,提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析(OLAP)能力以支持超大规模数据,它能在亚秒内查询巨大的 Hive 表。Kylin的核心思想是预计算,理论基础是:以空间换时间。即将多维分析可能用到的度量进行预计算,将计算好的结果保存成Cube并存储到HBase中,供查询时直接访问。把高复杂度的聚合运算,多表连接等操作转换成对预计算结果的查询。

 
【转载】大数据OLAP系统--开源组件方案对比

Kylin的核心模块:

  1. REST Server:提供 Restful 接口,例如创建、构建、刷新、合并等 Cube 相关操作,Kylin 的 Projects、Tables 等元数据管理,用户访问权限控制,SQL 的查询等;

  2. Query Engine:使用开源的 Apache Calcite 框架来实现 SQL 解析,可以理解为 SQL 引擎层;

  3. Routing:负责将解析 SQL 生成的执行计划转换成 Cube 缓存的查询,这部分查询是可以在秒级甚至毫秒级完成;

  4. Metadata:Kylin 中有大量的元数据信息,包括 Cube 的定义、星型模型的定义、Job 和执行 Job 的输出信息、模型的维度信息等等,Kylin 的元数据和 Cube 都存储在 HBase 中,存储的格式是 json 字符串;

  5. Cube Build Engine:所有模块的基础,它主要负责 Kylin 预计算中创建 Cube,创建的过程是首先通过 Hive 读取原始数据,然后通过一些 MapReduce 或 Spark 计算生成 Htable,最后将数据 load 到 HBase 表中。

整个系统分为两部分:

  1. 离线构建:

    • 数据源在左侧,目前主要是 Hadoop Hive,保存着待分析的用户数据;

    • 根据元数据的定义,下方构建引擎从数据源抽取数据,并构建 Cube;

    • 数据以关系表的形式输入,支持星形模型和雪花模型;

    • 2.5 开始 Spark 是主要的构建技术(以前是MapReduce);

    • 构建后的 Cube 保存在右侧的存储引擎中,一般选用 HBase 作为存储。

  2. 在线查询

    • 用户可以从上方查询系统(Rest API、JDBC/ODBC)发送 SQL 进行查询分析;

    • 无论从哪个接口进入,SQL 最终都会来到 Rest 服务层,再转交给查询引擎进行处理;

    • 查询引擎解析 SQL,生成基于关系表的逻辑执行计划;

    • 然后将其转译为基于 Cube 的物理执行计划;

    • 最后查询预计算生成的 Cube 并产生结果。

  • 优点
  1. 亚秒级查询响应;

  2. 支持百亿、千亿甚至万亿级别交互式分析;

  3. 无缝与 BI 工具集成;

  4. 支持增量刷新;

  • 缺点
  1. 由于 Kylin 是一个分析引擎,只读,不支持 insert, update, delete 等 SQL 操作,用户修改数据的话需要重新批量导入(构建);

  2. 需要预先建立模型后加载数据到 Cube 后才可进行查询

  3. 使用 Kylin 的建模人员需要了解一定的数据仓库知识。

2.1.2 Druid

Apache Druid是高性能的实时分析数据库,主要提供对大量的基于时序的数据进行OLAP查询能力。支持毫秒级的快速的交互式查询。

 
【转载】大数据OLAP系统--开源组件方案对比

Druid有几种进程类型,简要描述如下:

  1. Coordinators协调器进程:负责监控数据服务器上的Historicals进程,将Segments分配给特定的服务器,并负责确保Segments在多个Historicals之间保持平衡。

  2. Overlords进程:负责监控数据服务器上的MiddleManager进程,并控制数据获取任务的分配。

  3. Broker代理进程:处理来自外部客户端的查询,将查询转发给数据服务器去执行,并合并来自多个数据服务器的结果,返回给最终用户。

  4. Routers进程:是个可选进程,提供统一的API Gateway,可以将请求路由到Brokers、Overlords和Coordinators。

  5. Historicals进程:负责处理“历史数据”的查询。 它会从Deep Storage下载查询需要的Segments以加速查询。它不负责写入。

  6. MiddleManager进程:负责处理获取到新数据,从外部数据源读取数据并转换成Segments进行存储。

Druid进程可以按照任何方式进行部署,但是为了易于部署,一般建议将它们组织为三种服务器类型:

  1. 主服务器:运行Coordinatos和Overlords进程,负责管理数据获取和数据可用性。

  2. 查询服务器:运行Brokers和可选的Routers进程,处理来自外部客户端的查询。

  3. 数据服务器:运行Historicals和MiddleManagers进程,负责执行数据获取任务并存储所有可查询的数据。

Druid之所以查询如此之快,与它针对多维数据优化的组织和存储方式有很大关系。它将数据索引存储在Segments文件中,Segment文件按列来存储,并通过时间分区来进行横向分割。Druid将数据列分为了三种不同的类型:

 
【转载】大数据OLAP系统--开源组件方案对比
  1. 对于时间列和指标列处理比较简单,直接用lz4压缩存储。一旦查询知道去找哪几行,只需要将它们解压,然后用相应的操作符来操作它们就可以了。

  2. 对于维度列就没那么简单了,因为它们需要支持过滤和聚合操作,因此每个维度需要下面三个数据结构:

    (1) 一个map,Key是维度的值,值是一个整型的id

    (2) 一个存储列的值得列表,用(1)中的map编码的list

    (3) 对于列中的每个值对应一个bitmap,这个bitmap用来指示哪些行包含这个个值。

 
1: 字典
{
    "Justin BIeber": 0,
    "Ke$ha":         1
}

2. 值的列表
[0,
 0,
 1,
 1]

3. bitMap
value="Justin Bieber": [1, 1, 0, 0]
value="Ke$ha":         [0, 0, 1, 1]

为什么要使用这三个数据结构? map将字符串值映射为整数id,以便可以紧凑地表示(2)和(3)中的值。 (3)中的bitmap(也被称为倒排索引)允许快速过滤操作(特别地,bitmap便于快速进行AND和OR运算),这样,对于过滤再聚合的场景,无需访问(2)中的维度值列表。最后,(2)中的值可以被用来支持group by和TopN查询。

  • 优点:
  1. 为分析而设计:为OLAP工作流的探索性分析而构建。它支持各种filter、aggregator和查询类型。

  2. 交互式查询:低延迟数据摄取架构允许事件在它们创建后毫秒内查询。

  3. 高可用:你的数据在系统更新时依然可用、可查询。规模的扩大和缩小不会造成数据丢失。

  4. 可伸缩:每天处理数十亿事件和TB级数据。

  • 缺点:
  1. 不支持更新操作,数据不可更改

  2. 不支持事实表之间的关联

2.2 开源MPP数据库分析

2.2.1 Greenplum

GreenPlum是基于PostgreSQL的开源MPP数据库,具有良好的线性扩展能力,具有高效的并行运算和并行存储特性。

 
【转载】大数据OLAP系统--开源组件方案对比

 

 

Greenplum的系统架构实际上是多台PostgreSQL数据库服务器组成的矩阵,采用无共享(no shareing)的MPP架构:

  1. Master节点:作为数据库的入口,负责客服端连接;对客服端的请求生成查询计划,分发给某个或者所有的Segment节点。

  2. Standby节点 : 作为master节点的备库,提供高可用性。

  3. Interconnect:是GreenPlum的网络层;负责每个节点之间的通信。

  4. Segment节点:为数据节点;接收master分发下来的查询计划;执行返回结果给master节点。

  5. Mirror Segment节点: 作为Segment节点的备库,提供高可用性;通常跟对应的segment节点不在同一台机器上。

  • 优点
  1. 支持多态数据存储,允许用户根据应用定义数据分布方式,可提高查询性能。

  2. 具有高效的SQL优化器,针对OLAP查询进行优化

  • 缺点:
  1. 存在“木桶效应”,单机故障会导致性能严重下降,因此集群规模不能太大。

  2. 并发性能不高,通常无法支持超过30个并发

2.2.2 Clic++kHouse

ClickHouse是Yandex(号称俄罗斯的‘百度’)开源的MPP架构的列式存储数据库。

目前ClickHouse公开的资料相对匮乏,比如在架构设计层面就很难找到完整的资料,甚至连一张整体的架构图都没有。

  • ClickHouse为什么性能这么好?
  1. 着眼硬件。基于将硬件功效最大化的目的,ClickHouse会在内存中进行GROUP BY;与此同时,他们非常在意CPU L3级别的缓存,因为一次L3的缓存失效会带来70~100ns的延迟,意味着在单核CPU上,它会浪费4000万次/秒的运算。正因为注意了这些细节,所以ClickHouse在基准查询中能做到1.75亿次/秒的数据扫描性能。

  2. 注重算法。例如,在字符串搜索方面,针对不同的场景,Clic++kHouse选择了多种算法:对于常量,使用Volnitsky算法;对于非常量,使用CPU的向量化执行SIMD,暴力优化;正则匹配使用re2和hyperscan算法。除了字符串之外,其余的场景也与它类似,Clic++kHouse会使用最合适、最快的算法。如果世面上出现了号称性能强大的新算法,ClickHouse团队会立即将其纳入并进行验证。

  3. 特定场景,特殊优化。针对同一个场景的不同状况,选择使用不同的实现方式,尽可能将性能最大化。对于数据结构比较清晰的场景,会通过代码生成技术实现循环展开,以减少循环次数。

  4. 向量化执行。SIMD被广泛地应用于文本转换、数据过滤、数据解压和JSON转换等场景。相较于单纯地使用CPU,利用寄存器暴力优化也算是一种降维打击了。

  • 优点
  1. 速度快
  • 缺点:
  1. 不支持事务,不支持真正的删除/更新;

  2. 不支持高并发,Clickhouse快是因为采用了并行处理机制,即使一个查询,也会用服务器一半的CPU去执行。

  3. join性能不高

  4. 开源社区主要是俄语为主.

2.3 基于MPP架构的SQL引擎分析

2.3.1 Presto

Presto是Facebook推出分布式SQL交互式查询引擎,完全基于内存的并行计算,支持任意数据源,数据规模GB~PB。

 
【转载】大数据OLAP系统--开源组件方案对比

Presto采用典型的Master-Slave架构:

  1. coordinator:是presto集群的master节点。负责解析SQL语句,生成执行计划,分发执行任务给Worker节点执行。

  2. worker:是执行任务的节点。负责实际查询任务的计算和读写。

  3. discovery service:是将coordinator和worker结合在一起服务。worker节点启动后向discovery service服务注册,coordinator通过discovery service获取注册的worker节点。

  4. connector:presto以插件形式对数据存储层进行了抽象,即connector。可通过connector连接多种数据源,提取数据。

    discovery service 将coordinator和worker结合在一起服务; worker节点启动后向discovery service服务注册 coordinator通过discovery service获取注册的worker节点

既然Presto是一个交互式的查询引擎,我们最关心的就是Presto实现低延时查询的原理,我认为主要是下面几个关键点:

  1. 完全基于内存的并行计算

  2. 流水线式计算作业

  3. 本地化计算

  4. 动态编译执行计划

  5. 小心使用内存和数据结构

  6. 类BlinkDB的近似查询

  7. GC控制

  • 与Hive的比较:

     
    【转载】大数据OLAP系统--开源组件方案对比

上图显示了MapReduce与Presto的执行过程的不同点,MR每个操作要么需要写磁盘,要么需要等待前一个stage全部完成才开始执行,而Presto将SQL转换为多个stage,每个stage又由多个tasks执行,每个tasks又将分为多个split。所有的task是并行的方式进行允许,stage之间数据是以pipeline形式流式的执行,数据之间的传输也是通过网络以Memory-to-Memory的形式进行,没有磁盘io操作。这也是Presto性能比Hive快很多倍的决定性原因。

  • 与Spark的比较:

    1. 目标:Presto强调查询,但Spark重点强调计算。

    2. 架构:Presto的体系结构与MPP SQL引擎非常相似。这意味着仅针对SQL查询执行进行了高度优化,而Spark是一个通用执行框架,能够运行多个不同的工作负载,如ETL,机器学习等。

    3. 任务启动:Presto的查询没有太多开销。Presto协调器始终处于启动状态并等待查询。而Spark驱动程序启动需要时间与集群管理器协商资源,复制jar,才开始处理。

    4. 任务提交:Spark提交任务并在每个阶段实时应用资源(与presto相比,这种策略可能导致处理速度稍慢); Presto一次申请所需资源,并且一次提交所有任务。

    5. 数据处理:在spark中,数据需要在进入下一阶段之前完全处理。 Presto是流水线式处理模式。只要一个page完成处理,就可以将其发送到下一个task(这种方法大大减少了各种查询的端到端响应时间)。

    6. 内存:两者都是内存存储和计算,当它无法获得足够的内存时,spark会将数据写入磁盘,但presto会导致OOM。

    7. 容错:如果Spark任务失败或数据丢失,它将重新计算。但是presto会导致查询失败。

  • 优点:

  1. 基于内存运算,减少没必要的硬盘IO,所以快。

  2. 都能够处理PB级别的海量数据分析。(虽然能够处理PB级别的海量数据分析,但不是代表Presto把PB级别都放在内存中计算的。而是根据场景,如count,avg等聚合运算,是边读数据边计算,再清内存,再读数据再计算,这种耗的内存并不高。)

  3. 能够连接多个数据源,跨数据源关联查询。

  4. 清晰的架构,是一个能够独立运行的系统,不依赖于任何其他外部系统。部署简单。

  • 缺点:
  1. 不适合多个大表的join操作,因为presto是基于内存的,太多数据内存放不下的。

  2. Presto的一个权衡是不关心中间查询容错。如果其中一个Presto工作节点出现故障(例如,关闭),则大多数情况下正在进行的查询将中止并需要重新启动。

2.3.2 HAWQ

HAWQ是Pivotal公司开源的一个Hadoop原生大规模并行SQL分析引擎,针对的是分析型应用。Apache HAWQ 采用主从(Master-Slave)的改进MPP架构,通过将MPP与批处理系统有效的结合,克服了MPP的一些关键的限制问题,如短板效应、并发限制、扩展性等。其整体架构与Pivotal另一开源MPP数据库Greenplum比较相似:

 
【转载】大数据OLAP系统--开源组件方案对比

HAWQ Master节点内部有以下几个重要组件:

  1. 查询解析器(Parser/Analyzer),负责解析查询,并检查语法及语义。最终生成查询树传递给优化器。

  2. 优化器(Optimizer),负责接受查询树,生成查询计划。针对一个查询,可能有数亿个可能的等价的查询计划,但执行性能差异很大。优化器的做用是找出优化的查询计划。

  3. 资源管理器(Resourc++e Manager),资源管理器经过资源代理向全局资源管理器(好比YARN)动态申请资源。并缓存资源。在不须要的时候返回资源。

  4. HDFS元数据缓存(HDFS Catalog Cache),用于HAWQ确定哪些Segment扫描表的哪些部分。HAWQ是把计算派发到数据所在的地方。因此要匹配计算和数据的局部性。如果每一个查询都访问HDFS NameNode会形成NameNode的瓶颈。因此在HAWQ Master节点上创建了HDFS元数据缓存。

  5. 容错服务(Fault Tolerance Service),负责检测哪些节点可用,哪些节点不可用。不可用的机器会被排除出资源池。

  6. 查询派遣器(Dispatcher),优化器优化完查询之后,查询派遣器派遣计划到各个节点上执行,并协调查询执行的整个过程。查询派遣器是整个并行系统的粘合剂。

  7. 元数据服务(Catalog Service),负责存储HAWQ的各类元数据,包括数据库和表信息,以及访问权限信息等。另外,元数据服务也是实现分布式事务的关键。

其余节点为Slave节点。每一个Slave节点上部署有HDFS DataNode,YARN NodeManager以及一个HAWQ Segment。HAWQ Segment在执行查询的时候会启动多个QE (Query Executor, 查询执行器)。查询执行器运行在资源容器里面。节点间数据交换经过Interconnect(高速互联网络)进行。

  • 优点:
  1. 对SQL标准的完善支持:ANSI SQL标准,OLAP扩展,标准JDBC/ODBC支持。

  2. 支持ACID事务特性:这是很多现有基于Hadoop的SQL引擎做不到的,对保证数据一致性很重要。

  3. 动态数据流引擎:基于UDP的高速互联网络。

  4. 多种UDF(用户自定义函数)语言支持:java, python, c/c++, perl, R等。

  5. 动态扩容:动态按需扩容,按照存储大小或者计算需求,秒级添加节点。

  6. 支持MADlib机器学习。

  • 缺点:
  1. 基于GreenPlum实现,技术实现复杂,包含多个组件。比如对于外部数据源,需要通过PXF单独进行处理;

  2. C++实现,对内存的控制比较复杂,如果出现segmentfault直接导致当前node挂掉。

  3. 安装配置复杂;

2.3.3 Impala

Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具

 
【转载】大数据OLAP系统--开源组件方案对比

Impala采用MPP架构,与存储引擎解耦:

  1. impalad(实例*N): 接收client、hue、jdbc或者odbc请求。每当将查询提交到特定节点上的impalad时,该节点充当该查询的“协调器节点”,负责将Query分发到其他impalad节点来并行化查询,所有查询结果返回给中心协调节点。

  2. StateStore(实例*1): 负责收集分布在各个Impalad进程的资源信息、各节点健康状况,同步节点信息;

  3. Catalog Service(实例*1): 分发表的元数据信息到各个Impalad中,每个Impala节点在本地缓存所有元数据。

  • 与Hive的比较:

    Impala 与Hive都是构建在Hadoop之上的数据查询工具,各有不同的侧重点, Hive适合于长时间的批处理查询分析,而Impala适合于实时交互式SQL查询。

    1. 数据存储:使用相同的存储数据池都支持把数据存储于HDFS, HBase。

    2. 元数据:两者使用相同的元数据。

    3. SQL解释处理:比较相似都是通过词法分析生成执行计划。

    4. 执行计划:

      • Hive: 依赖于MapReduce执行框架,执行计划分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会 被编译成多轮MapReduce,则会有更多的写中间结果。由于MapReduce执行框架本身的特点,过多的中间过程会增加整个Query的执行时间。

      • Impala: 把执行计划表现为一棵完整的执行计划树,可以更自然地分发执行计划到各个Impalad执行查询,而不用像Hive那样把它组合成管道型的 map->reduc++e模式,以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle

    5. 数据流:

      • Hive: 采用推的方式,每一个计算节点计算完成后将数据主动推给后续节点。

      • Impala: 采用拉的方式,后续节点通过getNext主动向前面节点要数据,以此方式数据可以流式的返回给客户端,且只要有1条数据被处理完,就可以立即展现出来,而不用等到全部处理完成,更符合SQL交互式查询使用。

    6. 内存使用:

      • Hive: 在执行过程中如果内存放不下所有数据,则会使用外存,以保证Query能顺序执行完。每一轮MapReduce结束,中间结果也会写入HDFS中,同样由于MapReduce执行架构的特性,shuffle过程也会有写本地磁盘的操作。

      • Impala: 在遇到内存放不下数据时,当前版本1.0.1是直接返回错误,而不会利用外存。这使用得Impala目前处理Query会受到一 定的限制。Impala在多个阶段之间利用网络传输数据,在执行过程不会有写磁盘的操作(insert除外)。

    7. 调度:

      • Hive: 任务调度依赖于Hadoop的调度策略。

      • Impala: 调度由自己完成,目前只有一种调度器simple-schedule,它会尽量满足数据的局部性,扫描数据的进程尽量靠近数据本身所在的物理机器。调度器目前还比较简单,还没有考虑负载,网络IO状况等因素进行调度。但目前 Impala已经有对执行过程的性能统计分析,应该以后版本会利用这些统计信息进行调度吧。

    8. 容错:

      • Hive: 依赖于Hadoop的容错能力。

      • Impala: 在查询过程中,没有容错逻辑,如果在执行过程中发生故障,则直接返回错误(这与Impala的设计有关,因为Impala定位于实时查询,一次查询失败, 再查一次就好了,再查一次的成本很低)。

    9. 适用面:

      • Hive: 复杂的批处理查询任务,数据转换任务。

      • Impala:实时数据分析,因为不支持UDF,能处理的问题域有一定的限制。

  • 优点:

    1. 支持SQL查询,快速查询大数据

    2. 可以对已有数据进行查询,减少数据的加载,转换。

    3. 多种存储格式可以选择(Parquet, Text, Avro, RCFile, SequeenceFile)。

    4. 可以与Hive配合使用。

  • 缺点:

    1. 不支持用户定义函数UDF。

    2. 不支持text域的全文搜索。

    3. 不支持Transforms。

    4. 不支持查询期的容错。

    5. 对内存要求高。

2.3.4 Drill

Drill是MapR开源的一个低延迟的大数据集的分布式SQL查询引擎,是谷歌Dremel的开源实现。它支持对本地文件、HDFS、HBASE等数据进行数据查询,也支持对如JSON等schema-free的数据进行查询。

 
【转载】大数据OLAP系统--开源组件方案对比

从架构上看,与同是源自Dremel的Impala比较类似。Drill的核心是DrillBit,它主要负责接收客户端的请求,处理查询,并将结果返回给客户端。 Drill的查询流程包括以下步骤:

  1. Drill客户端发起查询,任意DrilBit都可以接受来自客户端的查询

  2. 收到请求的DrillBit成为驱动节点(Foreman),对查询进行分析优化生成执行计划,之后将执行计划划分成各个片段(Fragment),并确定合适的节点来执行。

  3. 各个节点执行查询片段(Fragment),并将结果返回给驱动节点

  4. 驱动节点将结果返回给客户端

  • 优点:
  1. 能够自动解析数据(json,text,parquet)的结构。

  2. 支持自定义的嵌套数据集,数据灵活,,支持查询复杂的半结构化数据。

  3. 与Hive一体化(Hive表和视图的查询,支持所有的Hive文件格式和HiveUDFS)。

  4. 支持多数据源,包括NoSQL数据库。

  5. 可以方便的与第三方BI工具对接。

  • 缺点:
  1. SQL语法和常规SQL有区别,一般是如“select * from 插件名.表名”的形式。

  2. 安装部署比较复杂。

  3. GC机制还有待提高。

2.4 基于通用计算框架的SQL引擎分析

2.4.1 SparkSQL

Spark SQL与传统 DBMS 的查询优化器 + 执行器的架构较为类似,只不过其执行器是在分布式环境中实现,并采用的 Spark 作为执行引擎:

 
【转载】大数据OLAP系统--开源组件方案对比

Spark SQL 的查询优化是Catalyst,Catalyst 将 SQL 语言翻译成最终的执行计划,并在这个过程中进行查询优化。这里和传统不太一样的地方就在于, SQL 经过查询优化器最终转换为可执行的查询计划是一个查询树,传统 DB 就可以执行这个查询计划了。而 Spark SQL 最后执行还是会在 Spark 内将这棵执行计划树转换为 Spark 的有向无环图DAG 再执行。

 
【转载】大数据OLAP系统--开源组件方案对比
  • 优点:
  1. sql查询与spar无缝融合

  2. 兼容HiveQL

  • 缺点:
  1. 查询性能不高

  2. 以thrift server方式提供的SparkSQL服务不支持多种数据源,必须使用DataFrame API。

2.4.2 Hive

Hive是一个构建于Hadoop顶层的数据仓库工具。定义了简单的类似SQL 的查询语言——HiveQL,可以将HiveQL查询转换为MapReduce 的任务在Hadoop集群上执行。

【转载】大数据OLAP系统--开源组件方案对比
image-20200803091119996.png
  • 优点:
  1. 高可靠、高容错:HiveServer采用集群模式。双MetaStor。超时重试机制。

  2. 类SQL:类似SQL语法,内置大量函数。

  3. 可扩展:自定义存储格式,自定义函数。

  4. 多接口:Beeline,JDBC,ODBC,Python,Thrift。

  • 缺点:
  1. 延迟较高:默认MR为执行引擎,MR延迟较高。

  2. 不支持物化视图:Hive支持普通视图,不支持物化视图。Hive不能再视图上更新、插入、删除数据。

  3. 不适用OLTP:暂不支持列级别的数据添加、更新、删除操作。

2.5 各组件性能对比

测试数据来源于:开源OLAP引擎测评报告。通过测试以及相关调研编写了各组件各个方面的综合对比分析表,这里采用5分为满分来比较,如下表:

 
 
 
  1. SparkSQL是Hadoop中另一个著名的SQL引擎,它以Spark作为底层计算框架,Spark使用RDD作为分布式程序的工作集合,它提供一种分布式共享内存的受限形式。在分布式共享内存系统中,应用可以向全局地址空间的任意位置进行读写作,而RDD是只读的,对其只能进行创建、转化和求值等作。这种内存操作大大提高了计算速度。SparkSql的性能相对其他的组件要差一些,多表单表查询性能都不突出。

  2. Impala官方宣传其计算速度是一大优点,在实际测试中我们也发现它的多表查询性能和presto差不多,但是单表查询方面却不如presto好。而且Impala有很多不支持的地方,例如:不支持update、delete操作,不支持Date数据类型,不支持ORC文件格式等等,所以我们查询时采用parquet格式进行查询,而且Impala在查询时占用的内存很大。

  3. Presto综合性能比起来要比其余组件好一些,无论是查询性能还是支持的数据源和数据格式方面都要突出一些,在单表查询时性能靠前,多表查询方面性能也很突出。由于Presto是完全基于内存的并行计算,所以presto在查询时占用的内存也不少,但是发现要比Impala少一些,比如多表join需要很大的内存,Impala占用的内存比presto要多。

  4. HAWQ 吸收了先进的基于成本的 SQL 查询优化器,自动生成执行计划,可优化使用hadoop 集群资源。HAWQ 采用 Dynamic pipelining 技术解决这一关键问题。Dynamic pipelining 是一种并行数据流框架,利用线性可扩展加速Hadoop查询,数据直接存储在HDFS上,并且其SQL查询优化器已经为基于HDFS的文件系统性能特征进行过细致的优化。但是我们发现HAWQ在多表查询时比Presto、Impala差一些;而且不适合单表的复杂聚合操作,单表测试性能方面要比其余四种组件差很多,hawq环境搭建也遇到了诸多问题。

  5. ClickHouse 作为目前所有开源MPP计算框架中计算速度最快的,它在做多列的表,同时行数很多的表的查询时,性能是很让人兴奋的,但是在做多表的join时,它的性能是不如单宽表查询的。性能测试结果表明ClickHouse在单表查询方面表现出很大的性能优势,但是在多表查询中性能却比较差,不如presto、impala、hawq的效果好。

  6. GreenPlum作为关系型数据库产品,它的特点主要就是查询速度快,数据装载速度快,批量DML处理快。而且性能可以随着硬件的添加,呈线性增加,拥有非常良好的可扩展性。因此,它主要适用于面向分析的应用。比如构建企业级ODS/EDW,或者数据集市等,GREENPLUM都是不错的选择。

【转载】大数据OLAP系统--开源组件方案对比

 

 

转载链接:https://www.jianshu.com/p/4b3bcbabad77
来源:简书


程序员灯塔
转载请注明原文链接:【转载】大数据OLAP系统–开源组件方案对比
喜欢 (0)