开源大数据OLAP组件，可以分为MOLAP和ROLAP两类。ROLAP中又可细分为MPP数据库和SQL引擎两类。对于SQL引擎又可以再细分为基于MPP架构的SQL引擎和基于通用计算框架的SQL引擎：
总之，可以说没有一个OLAP系统能同时在处理规模，灵活性和性能这三个方面做到完美，用户需要基于自己的需求进行取舍和选型。
Apache Kylin 是一个开源的分布式分析引擎，提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，它能在亚秒内查询巨大的 Hive 表。Kylin的核心思想是预计算，理论基础是：以空间换时间。即将多维分析可能用到的度量进行预计算，将计算好的结果保存成Cube并存储到HBase中，供查询时直接访问。把高复杂度的聚合运算，多表连接等操作转换成对预计算结果的查询。
Kylin的核心模块：
整个系统分为两部分：
-
优点：
-
缺点：
Apache Druid是高性能的实时分析数据库，主要提供对大量的基于时序的数据进行OLAP查询能力。支持毫秒级的快速的交互式查询。
Druid有几种进程类型，简要描述如下：
Druid进程可以按照任何方式进行部署，但是为了易于部署，一般建议将它们组织为三种服务器类型：
Druid之所以查询如此之快，与它针对多维数据优化的组织和存储方式有很大关系。它将数据索引存储在Segments文件中，Segment文件按列来存储，并通过时间分区来进行横向分割。Druid将数据列分为了三种不同的类型：
为什么要使用这三个数据结构？ map将字符串值映射为整数id，以便可以紧凑地表示（2）和（3）中的值。 （3）中的bitmap（也被称为倒排索引）允许快速过滤操作（特别地，bitmap便于快速进行AND和OR运算），这样，对于过滤再聚合的场景，无需访问（2）中的维度值列表。最后，（2）中的值可以被用来支持group by和TopN查询。
-
*优点：
-
*缺点：
GreenPlum是基于PostgreSQL的开源MPP数据库，具有良好的线性扩展能力，具有高效的并行运算和并行存储特性。
Greenplum的系统架构实际上是多台PostgreSQL数据库服务器组成的矩阵，采用无共享(no shareing)的MPP架构：
-
优点：
-
*缺点：
ClickHouse是Yandex（号称俄罗斯的’百度’）开源的MPP架构的列式存储数据库。
目前ClickHouse公开的资料相对匮乏，比如在架构设计层面就很难找到完整的资料，甚至连一张整体的架构图都没有。
-
ClickHouse为什么性能这么好？
-
优点：
-
*缺点：
Presto是Facebook推出分布式SQL交互式查询引擎，完全基于内存的并行计算，支持任意数据源，数据规模GB~PB。
Presto采用典型的Master-Slave架构：
既然Presto是一个交互式的查询引擎，我们最关心的就是Presto实现低延时查询的原理，我认为主要是下面几个关键点：
- *与Hive的比较：
上图显示了MapReduce与Presto的执行过程的不同点，MR每个操作要么需要写磁盘，要么需要等待前一个stage全部完成才开始执行，而Presto将SQL转换为多个stage，每个stage又由多个tasks执行，每个tasks又将分为多个split。所有的task是并行的方式进行允许，stage之间数据是以pipeline形式流式的执行，数据之间的传输也是通过网络以Memory-to-Memory的形式进行，没有磁盘io操作。这也是Presto性能比Hive快很多倍的决定性原因。
- 与Spark的比较：
- 目标：Presto强调查询，但Spark重点强调计算。
- 架构：Presto的体系结构与MPP SQL引擎非常相似。这意味着仅针对SQL查询执行进行了高度优化，而Spark是一个通用执行框架，能够运行多个不同的工作负载，如ETL，机器学习等。
- 任务启动：Presto的查询没有太多开销。Presto协调器始终处于启动状态并等待查询。而Spark驱动程序启动需要时间与集群管理器协商资源，复制jar，才开始处理。
- 任务提交：Spark提交任务并在每个阶段实时应用资源（与presto相比，这种策略可能导致处理速度稍慢）; Presto一次申请所需资源，并且一次提交所有任务。
- 数据处理：在spark中，数据需要在进入下一阶段之前完全处理。 Presto是流水线式处理模式。只要一个page完成处理，就可以将其发送到下一个task（这种方法大大减少了各种查询的端到端响应时间）。
- 内存：两者都是内存存储和计算，当它无法获得足够的内存时，spark会将数据写入磁盘，但presto会导致OOM。
- 容错：如果Spark任务失败或数据丢失，它将重新计算。但是presto会导致查询失败。
-
*优点：
-
*缺点：
HAWQ是Pivotal公司开源的一个Hadoop原生大规模并行SQL分析引擎，针对的是分析型应用。Apache HAWQ 采用主从（Master-Slave）的改进MPP架构，通过将MPP与批处理系统有效的结合，克服了MPP的一些关键的限制问题，如短板效应、并发限制、扩展性等。其整体架构与Pivotal另一开源MPP数据库Greenplum比较相似：
HAWQ Master节点内部有以下几个重要组件：
其余节点为Slave节点。每一个Slave节点上部署有HDFS DataNode，YARN NodeManager以及一个HAWQ Segment。HAWQ Segment在执行查询的时候会启动多个QE (Query Executor, 查询执行器)。查询执行器运行在资源容器里面。节点间数据交换经过Interconnect（高速互联网络）进行。
-
*优点：
-
*缺点：
Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具。
Impala采用MPP架构，与存储引擎解耦：
- 与Hive的比较： Impala 与Hive都是构建在Hadoop之上的数据查询工具，各有不同的侧重点， Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询。
- 数据存储：使用相同的存储数据池都支持把数据存储于HDFS, HBase。
- 元数据：两者使用相同的元数据。
- SQL解释处理：比较相似都是通过词法分析生成执行计划。
- 执行计划：
- Hive: 依赖于MapReduce执行框架，执行计划分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会 被编译成多轮MapReduce，则会有更多的写中间结果。由于MapReduce执行框架本身的特点，过多的中间过程会增加整个Query的执行时间。
- Impala: 把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，而不用像Hive那样把它组合成管道型的 map->reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。
- 数据流：
- Hive: 采用推的方式，每一个计算节点计算完成后将数据主动推给后续节点。
- Impala: 采用拉的方式，后续节点通过getNext主动向前面节点要数据，以此方式数据可以流式的返回给客户端，且只要有1条数据被处理完，就可以立即展现出来，而不用等到全部处理完成，更符合SQL交互式查询使用。
- 内存使用：
- Hive: 在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完。每一轮MapReduce结束，中间结果也会写入HDFS中，同样由于MapReduce执行架构的特性，shuffle过程也会有写本地磁盘的操作。
- Impala: 在遇到内存放不下数据时，当前版本1.0.1是直接返回错误，而不会利用外存。这使用得Impala目前处理Query会受到一 定的限制。Impala在多个阶段之间利用网络传输数据，在执行过程不会有写磁盘的操作（insert除外）。
- 调度：
- Hive: 任务调度依赖于Hadoop的调度策略。
- Impala: 调度由自己完成，目前只有一种调度器simple-schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的物理机器。调度器目前还比较简单，还没有考虑负载，网络IO状况等因素进行调度。但目前 Impala已经有对执行过程的性能统计分析，应该以后版本会利用这些统计信息进行调度吧。
- 容错：
- Hive: 依赖于Hadoop的容错能力。
- Impala: 在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误（这与Impala的设计有关，因为Impala定位于实时查询，一次查询失败， 再查一次就好了，再查一次的成本很低）。
- 适用面：
- Hive: 复杂的批处理查询任务，数据转换任务。
- Impala：实时数据分析，因为不支持UDF，能处理的问题域有一定的限制。
- 优点：
- 支持SQL查询，快速查询大数据。
- 可以对已有数据进行查询，减少数据的加载，转换。
- 多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）。
- 可以与Hive配合使用。
- 缺点：
- 不支持用户定义函数UDF。
- 不支持text域的全文搜索。
- 不支持Transforms。
- 不支持查询期的容错。
- 对内存要求高。
Drill是MapR开源的一个低延迟的大数据集的分布式SQL查询引擎，是谷歌Dremel的开源实现。它支持对本地文件、HDFS、HBASE等数据进行数据查询，也支持对如JSON等schema-free的数据进行查询。
从架构上看，与同是源自Dremel的Impala比较类似。Drill的核心是DrillBit，它主要负责接收客户端的请求，处理查询，并将结果返回给客户端。 Drill的查询流程包括以下步骤：
-
*优点：
-
*缺点：
Spark SQL与传统 DBMS 的查询优化器 + 执行器的架构较为类似，只不过其执行器是在分布式环境中实现，并采用的 Spark 作为执行引擎：
Spark SQL 的查询优化是Catalyst，Catalyst 将 SQL 语言翻译成最终的执行计划，并在这个过程中进行查询优化。这里和传统不太一样的地方就在于， SQL 经过查询优化器最终转换为可执行的查询计划是一个查询树，传统 DB 就可以执行这个查询计划了。而 Spark SQL 最后执行还是会在 Spark 内将这棵执行计划树转换为 Spark 的有向无环图DAG 再执行。
-
*优点：
-
*缺点：
Hive是一个构建于Hadoop顶层的数据仓库工具。定义了简单的类似SQL 的查询语言——HiveQL，可以将HiveQL查询转换为MapReduce 的任务在Hadoop集群上执行。
-
*优点：
-
*缺点：
Original: https://www.cnblogs.com/laoqing/p/14874567.html
Author: 张永清
Title: 【转载】大数据OLAP系统–开源组件方案对比
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/562801/
转载文章受原作者版权保护。转载请注明原作者出处！