OLAP 如何选型

一、OLAP 简介

OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。与此相对的是OLTP（on-line transaction processing）联机事务处理系统。

联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的。OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。

Codd认为联机事务处理（OLTP）已不能满足终端用户对数据库查询分析的要求，SQL对大数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，Codd提出了多维数据库和多维分析的概念，即OLAP。

OLAP委员会对联机分析处理的定义为：从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业多维特性的数据称为信息数据，使分析人员、管理人员或执行人员能够从多种角度对信息数据进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或多维环境特定的查询和报表需求，它的技术核心是”维”这个概念，因此OLAP也可以说是多维数据分析工具的集合。

二、OLAP 的准则和特性

E.F.Codd提出了关于OLAP的12条准则

准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力准则
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次

OLAP场景的关键特征

大多数是读请求
数据总是以相当大的批(> 1000 rows)进行写入
不修改已添加的数据
每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
宽表，即每个表包含着大量的列
较少的查询(通常每台服务器每秒数百个查询或更少)
对于简单查询，允许延迟大约50毫秒
列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
事务不是必须的
对数据一致性要求低
每一个查询除了一个大表外都很小
查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中

OLTP系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作，强调事务性；
OLAP系统则强调数据分析，强调SQL执行时长，强调磁盘I/O，强调分区。

三、OLAP 开源引擎

目前市面上主流的开源OLAP引擎包含不限于：Hive、Hawq、Presto、Kylin、Impala、Sparksql、Druid、Clickhouse、Greeplum等，可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。

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

MOLAP一般对数据存储有优化，并且进行部分预计算，因此查询性能最高。但通常对查询灵活性有限制。

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

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

3.1 Kylin

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

Kylin的主要特点是预计算，提前计算好各个cube，这样的优点是查询快速，秒级延迟；缺点也非常明显，灵活性不足，无法做一些探索式的，关联性的数据分析。

Kylin的核心模块：

REST Server：提供 Restful 接口，例如创建、构建、刷新、合并等 Cube 相关操作，Kylin 的 Projects、Tables 等元数据管理，用户访问权限控制，SQL 的查询等；
Query Engine：使用开源的 Apache Calcite 框架来实现 SQL 解析，可以理解为 SQL 引擎层；
Routing：负责将解析 SQL 生成的执行计划转换成 Cube 缓存的查询，这部分查询是可以在秒级甚至毫秒级完成；
Metadata：Kylin 中有大量的元数据信息，包括 Cube 的定义、星型模型的定义、Job 和执行 Job 的输出信息、模型的维度信息等等，Kylin 的元数据和 Cube 都存储在 HBase 中，存储的格式是 json 字符串；
Cube Build Engine：所有模块的基础，它主要负责 Kylin 预计算中创建 Cube，创建的过程是首先通过 Hive 读取原始数据，然后通过一些 MapReduce 或 Spark 计算生成 Htable，最后将数据 load 到 HBase 表中。

整个系统分为两部分：

离线构建：
1）数据源在左侧，目前主要是 Hadoop Hive，保存着待分析的用户数据；
2）根据元数据的定义，下方构建引擎从数据源抽取数据，并构建 Cube；
3）数据以关系表的形式输入，支持星形模型和雪花模型；
4）2.5 开始 Spark 是主要的构建技术（以前是MapReduce）；
5）构建后的 Cube 保存在右侧的存储引擎中，一般选用 HBase 作为存储。
在线查询
1）用户可以从上方查询系统（Rest API、JDBC/ODBC）发送 SQL 进行查询分析；
2）无论从哪个接口进入，SQL 最终都会来到 Rest 服务层，再转交给查询引擎进行处理；
3）查询引擎解析 SQL，生成基于关系表的逻辑执行计划；
4）然后将其转译为基于 Cube 的物理执行计划；
5）最后查询预计算生成的 Cube 并产生结果。

优点：

1）亚秒级查询响应；
2）支持百亿、千亿甚至万亿级别交互式分析；
3）无缝与 BI 工具集成；
4）支持增量刷新；

缺点：

1）由于 Kylin 是一个分析引擎，只读，不支持 insert, update, delete 等 SQL 操作，用户修改数据的话需要重新批量导入（构建）；
2）需要预先建立模型后加载数据到 Cube 后才可进行查询；
3）使用 Kylin 的建模人员需要了解一定的数据仓库知识。

3.2 Druid

Druid 是一个高效的数据查询系统，主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。

Druid是专为海量数据集上的做高性能 OLAP而设计的数据存储和分析系统。

Druid 采用了shared-nothing架构与lambda架构。

Druid的核心设计结合了数据仓库，时间序列数据库和搜索系统的思想，以创建一个统一的系统，用于针对各种用例的实时分析。Druid将这三个系统中每个系统的关键特征合并到其接收层，存储格式，查询层和核心体系结构中。

目前 Druid 的去重都是非精确的，Druid 适合处理星型模型的数据，不支持关联操作。也不支持数据的更新。

Druid有几种进程类型，简要描述如下：

Coordinators协调器进程：负责监控数据服务器上的Historicals进程，将Segments分配给特定的服务器，并负责确保Segments在多个Historicals之间保持平衡。
Overlords进程：负责监控数据服务器上的MiddleManager进程，并控制数据获取任务的分配。
Broker代理进程：处理来自外部客户端的查询，将查询转发给数据服务器去执行，并合并来自多个数据服务器的结果，返回给最终用户。
Routers进程：是个可选进程，提供统一的API Gateway，可以将请求路由到Brokers、Overlords和Coordinators。
Historicals进程：负责处理“历史数据”的查询。它会从Deep Storage下载查询需要的Segments以加速查询。它不负责写入。
MiddleManager进程：负责处理获取到新数据，从外部数据源读取数据并转换成Segments进行存储。

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

主服务器：运行Coordinatos和Overlords进程，负责管理数据获取和数据可用性。
查询服务器：运行Brokers和可选的Routers进程，处理来自外部客户端的查询。
数据服务器：运行Historicals和MiddleManagers进程，负责执行数据获取任务并存储所有可查询的数据。

特点：

面向列的存储：Druid 单独存储和压缩每一列，只需要读取特定查询所需的列，支持快速扫描、排名和 groupBys。
本地搜索索引：Druid 为字符串值创建倒排索引以进行快速搜索和过滤。
流式传输和批量摄取：适用于 Apache Kafka、HDFS、AWS S3、流处理器等的开箱即用连接器。
灵活的模式：Druid 优雅地处理不断变化的模式和嵌套数据。
时间优化分区：Druid根据时间对数据进行智能分区，基于时间的查询速度明显快于传统数据库。
SQL 支持：除了其原生的基于 JSON 的语言外，Druid 还通过 HTTP 或 JDBC 使用SQL。
水平扩展性：Druid 已在生产中用于每秒摄取数百万个事件、保留多年数据并提供亚秒级查询。
操作简单：只需添加或删除服务器即可扩大或缩小规模，Druid 会自动重新平衡。容错架构围绕服务器故障进行路由。

使用场景：

1）需要实时分析，查询延迟为100毫秒到几秒钟；
2）插入率非常高，但更新不常见；
3）大多数查询都是聚合和报告查询；
4）数据有一个时间组件；
5）每个查询只能访问一个大的分布式表；
6）有高基数数据列，对它们进行快速计数和排名；
7）需要交互式和快速探究大量数据。

缺点：

1）灵活性适中，虽然维度之间随意组合，但不支持adhoc查询，不能自由组合查询，且丢失了明细数据（不采用roll-up情况下可以进行明细查询）；
2）易用性较差，不支持join，不支持更新，sql支持很弱(有些插件类似于pinot的PQL语言)，只能JSON格式查询，对于去重操作不能精准去重；
3）处理方式复杂，需要流处理引擎将数据join成宽表，维护相对复杂；对内存要求较高。

3.3 Greenplum

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

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

Master节点：作为数据库的入口，负责客服端连接；对客服端的请求生成查询计划，分发给某个或者所有的Segment节点；
Standby节点 : 作为master节点的备库，提供高可用性；
Interconnect：是GreenPlum的网络层；负责每个节点之间的通信；
Segment节点：为数据节点；接收master分发下来的查询计划；执行返回结果给master节点；
Mirror Segment节点： 作为Segment节点的备库，提供高可用性；通常跟对应的segment节点不在同一台机器上。

优点：

1）支持多态数据存储，允许用户根据应用定义数据分布方式，可提高查询性能；
2）具有高效的SQL优化器，针对OLAP查询进行优化。

缺点：

1）存在木桶效应，单机故障会导致性能严重下降，因此集群规模不能太大；
2）并发性能不高，通常无法支持超过30个并发。

3.4 ClickHouse

ClickHouse 的全称是Click Stream，Data WareHouse，简称ClickHouse，是俄罗斯 Yandex 公司于2016年开源的列式存储数据库（DBMS)，主要用于联机分析处理查询（OLAP），能够使用SQL 查询实时生成分析数据报告。
目前ClickHouse公开的资料相对匮乏，比如在架构设计层面就很难找到完整的资料，甚至连一张整体的架构图都没有。

ClickHouse为什么性能这么好？

着眼硬件：基于将硬件功效最大化的目的，ClickHouse会在内存中进行GROUP BY；与此同时，他们非常在意CPU L3级别的缓存，因为一次L3的缓存失效会带来70～100ns的延迟，意味着在单核CPU上，它会浪费4000万次/秒的运算。正因为注意了这些细节，所以ClickHouse在基准查询中能做到1.75亿次/秒的数据扫描性能。
注重算法：例如，在字符串搜索方面，针对不同的场景，ClickHouse选择了多种算法：对于常量，使用Volnitsky算法；对于非常量，使用CPU的向量化执行SIMD，暴力优化；正则匹配使用re2和hyperscan算法。除了字符串之外，其余的场景也与它类似，ClickHouse会使用最合适、最快的算法。如果世面上出现了号称性能强大的新算法，ClickHouse团队会立即将其纳入并进行验证。
特定场景，特殊优化：针对同一个场景的不同状况，选择使用不同的实现方式，尽可能将性能最大化。对于数据结构比较清晰的场景，会通过代码生成技术实现循环展开，以减少循环次数。
向量化执行：SIMD被广泛地应用于文本转换、数据过滤、数据解压和JSON转换等场景。相较于单纯地使用CPU，利用寄存器暴力优化也算是一种降维打击了。

优点：

1）为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；
2）数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
3）索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
4）写入速度非常快，50-200M/s，对于大量的数据更新非常适用。

缺点：

1）不支持事务，不支持真正的删除/更新；
2）不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；
3）SQL满足日常使用80%以上的语法，join写法比较特殊；最新版已支持类似SQL的join，但性能不好；
4）尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；
5）Clickhouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。

3.5 Impala

Impala 是Cloudera 公司推出，提供对 HDFS、Hbase 数据的高性能、低延迟的交互式 SQL 查询功能。

Impala 使用 Hive的元数据, 完全在内存中计算。是CDH 平台首选的 PB 级大数据实时查询分析引擎。

Impala采用MPP架构，与存储引擎解耦：

Impalad进程：是核心进程，负责接收查询请求并向多个数据节点分发任务。
statestored进程：负责监控所有Impalad进程，并向集群中的节点报告各个Impalad进程的状态。
catalogd进程：负责广播通知元数据的最新信息。

Impala的特性包括：

1）支持Parquet、Avro、Text、RCFile、SequenceFile等多种文件格式；
2）支持存储在HDFS、HBase、Amazon S3上的数据操作；
3）支持多种压缩编码方式：Snappy、Gzip、Deflate、Bzip2、LZO；
4）支持UDF和UDAF；
5）自动以最有效的顺序进行表连接；
6）允许定义查询的优先级排队策略；
7）支持多用户并发查询；
8）支持数据缓存；
9）提供计算统计信息（COMPUTE STATS）；
10）提供窗口函数（聚合 OVER PARTITION, RANK, LEAD, LAG, NTILE等等）以支持高级分析功能；
11）支持使用磁盘进行连接和聚合，当操作使用的内存溢出时转为磁盘操作；
12）允许在where子句中使用子查询；
13）允许增量统计——只在新数据或改变的数据上执行统计计算；
14）支持maps、structs、arrays上的复杂嵌套查询；
15）可以使用impala插入或更新HBase。

优点：

1）支持SQL查询，快速查询大数据；
2）可以对已有数据进行查询，减少数据的加载，转换；
3）多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）；
4）可以与Hive配合使用。

缺点：

1）不支持用户定义函数UDF；
2）不支持text域的全文搜索；
3）不支持Transforms；
4）不支持查询期的容错；
5）对内存要求高。

3.6 Hawq

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

下图提供了典型 HAWQ 部署的高级架构视图

下图提供了构成 HAWQ 的软件组件的另一种视图

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

1）查询解析器（Parser/Analyzer），负责解析查询，并检查语法及语义。最终生成查询树传递给优化器。
2）优化器（Optimizer），负责接受查询树，生成查询计划。针对一个查询，可能有数亿个可能的等价的查询计划，但执行性能差异很大。优化器的做用是找出优化的查询计划。
3）资源管理器（Resource 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的各类元数据，包括数据库和表信息，以及访问权限信息等。另外，元数据服务也是实现分布式事务的关键。
8）其余节点为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）安装配置复杂。

3.7 Presto

Presto 是由 Facebook 推出的一个基于Java开发的开源分布式SQL查询引擎，数据量支持GB到TB字节，presto本身不存数据，但是可以接入很多数据源，它使得用SQL访问任何数据源成为可能，而且支持跨数据源的级联查询。你可以使用Presto通过水平扩展查询处理的方式来查询大型数据集。

Presto相比ClickHouse优点主要是多表join效果好。相比ClickHouse的支持功能简单，场景支持单一，Presto支持复杂的查询，应用范围更广。

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节点。

优点：

1）基于内存运算，减少没必要的硬盘IO；
2）都能够处理PB级别的海量数据分析；（虽然能够处理PB级别的海量数据分析，但不是代表Presto把PB级别都放在内存中计算的。而是根据场景，如count，avg等聚合运算，是边读数据边计算，再清内存，再读数据再计算，这种耗的内存并不高。）
3）能够连接多个数据源，跨数据源关联查询；
4）清晰的架构，是一个能够独立运行的系统，不依赖于任何其他外部系统。部署简单。

缺点：

1）不适合多个大表的join操作，因为presto是基于内存的，太多数据内存放不下的；
2）Presto的一个权衡是不关心中间查询容错。如果其中一个Presto工作节点出现故障（例如，关闭），则大多数情况下正在进行的查询将中止并需要重新启动。

3.8 Drill

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

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

1）Drill客户端发起查询，任意DrilBit都可以接受来自客户端的查询；
2）收到请求的DrillBit成为驱动节点（Foreman），对查询进行分析优化生成执行计划，之后将执行计划划分成各个片段（Fragment），并确定合适的节点来执行；
3）各个节点执行查询片段（Fragment），并将结果返回给驱动节点；
4）驱动节点将结果返回给客户端。

优点：

1）几乎可以查询任何类型的NoSQL数据库（包含 Hbase、MongoDB、ElasticSearch、Cassandra、Druid、Kudu、Kafka、OpenTSDB、HDFS、Amazon S3、Azure Blob Storage、Google Cloud Storage、Swift、NAS和本地文件。可以在单次查询中组合多个数据源（联邦查询）。）；
2）在处理数据之前，无需加载数据、创建和维护模式或转换数据。相反，只需在 SQL 查询中包含 Hadoop 目录、MongoDB 集合或 S3 存储桶的路径；
3）Drill 是唯一支持复杂数据的列式查询引擎。它具有用于复杂数据的内存切碎柱状表示，这使 Drill 能够通过内部 JSON 文档模型的灵活性实现柱状速度；
4）可以使用 Tableau、Qlik、MicroStrategy、Spotfire、SAS 和 Excel 等标准 BI/分析工具；
5）Drill 的对称架构（所有节点都相同）和简单的安装使得部署和扩展集群变得容易；
6）Drill 不是世界上第一个查询引擎，但它是第一个兼具灵活性和速度的查询引擎。为了实现这一点，Drill 具有完全不同的架构，可以在不牺牲 JSON 文档模型提供的灵活性的情况下实现破纪录的性能。

缺点：

1） drill语法和常规sql有区别,一般是如 select * from 插件名.表名 的形式。主要是因为drill查询不同数据源时需要切换不同的插件；
2）技术线太长，不容易切合到实际生产线上去；
3）国内使用较少，没有大型成功案例，不够大众化，出现问题可能维护起来比较困难。资料比较少。

3.9 Hive

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

hdfs可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。

对于Hive主要针对的是OLAP应用，其底层是HDFS分布式文件系统，HDFS一般只用于查询分析统计，而不能是常见的CUD操作，Hive需要从已有的数据库或日志进行同步最终入到HDFS文件系统中，当前要做到增量实时同步都相当困难。

优点：

1）高可靠、高容错：HiveServer采用集群模式，双MetaStor，超时重试机制；
2）类SQL：类似SQL语法，内置大量函数；
3）可扩展：自定义存储格式，自定义函数；
4）多接口：Beeline，JDBC，ODBC，Python，Thrift。

缺点：

1）延迟较高：默认MR为执行引擎，MR延迟较高；
2）不支持物化视图：Hive支持普通视图，不支持物化视图。Hive不能再视图上更新、插入、删除数据；
3）不适用OLTP：暂不支持列级别的数据添加、更新、删除操作。

3.10 Spark SQL

Spark SQL 的前身是Shark，它将 SQL 查询与 Spark 程序无缝集成，可以将结构化数据作为 Spark 的 RDD 进行查询。Spark SQL作为Spark生态的一员继续发展，而不再受限于Hive，只是兼容Hive。

Spark SQL提供了sql访问和API访问的接口。支持访问各式各样的数据源，包括Hive, Avro, Parquet, ORC, JSON 和 JDBC。

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

SparkSQL的架构图如下：

优点：

1）支持多种数据源；
2）易整合，有各种API；
3）兼容HiveQL。

缺点：

1）查询性能不高；
2）以thrift server方式提供的SparkSQL服务不支持多种数据源，必须使用DataFrame API。

四、各组件性能对比

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

SparkSQL是Hadoop中另一个著名的SQL引擎，它以Spark作为底层计算框架，Spark使用RDD作为分布式程序的工作集合，它提供一种分布式共享内存的受限形式。在分布式共享内存系统中，应用可以向全局地址空间的任意位置进行读写作，而RDD是只读的，对其只能进行创建、转化和求值等作。这种内存操作大大提高了计算速度。SparkSql的性能相对其他的组件要差一些，多表单表查询性能都不突出。
Impala官方宣传其计算速度是一大优点，在实际测试中我们也发现它的多表查询性能和presto差不多，但是单表查询方面却不如presto好。而且Impala有很多不支持的地方，例如：不支持update、delete操作，不支持Date数据类型，不支持ORC文件格式等等，所以我们查询时采用parquet格式进行查询，而且Impala在查询时占用的内存很大。
Presto综合性能比起来要比其余组件好一些，无论是查询性能还是支持的数据源和数据格式方面都要突出一些，在单表查询时性能靠前，多表查询方面性能也很突出。由于Presto是完全基于内存的并行计算，所以presto在查询时占用的内存也不少，但是发现要比Impala少一些，比如多表join需要很大的内存，Impala占用的内存比presto要多。
HAWQ 吸收了先进的基于成本的 SQL 查询优化器，自动生成执行计划，可优化使用hadoop 集群资源。HAWQ 采用 Dynamic pipelining 技术解决这一关键问题。Dynamic pipelining 是一种并行数据流框架，利用线性可扩展加速Hadoop查询，数据直接存储在HDFS上，并且其SQL查询优化器已经为基于HDFS的文件系统性能特征进行过细致的优化。但是我们发现HAWQ在多表查询时比Presto、Impala差一些；而且不适合单表的复杂聚合操作，单表测试性能方面要比其余四种组件差很多，hawq环境搭建也遇到了诸多问题。
ClickHouse 作为目前所有开源MPP计算框架中计算速度最快的，它在做多列的表，同时行数很多的表的查询时，性能是很让人兴奋的，但是在做多表的join时，它的性能是不如单宽表查询的。性能测试结果表明ClickHouse在单表查询方面表现出很大的性能优势，但是在多表查询中性能却比较差，不如presto、impala、hawq的效果好。
GreenPlum作为关系型数据库产品，它的特点主要就是查询速度快，数据装载速度快，批量DML处理快。而且性能可以随着硬件的添加，呈线性增加，拥有非常良好的可扩展性。因此，它主要适用于面向分析的应用。比如构建企业级ODS/EDW，或者数据集市等，GREENPLUM都是不错的选择。

OLAP大混战对比分析： 仅供参考

引擎/对比项目	Kylin	Presto	Impala	Druid	SpaqkSql	ElasticSearch	Kudu	ClickHouse	Doris	TiDB	Hive	Greenplum	SnappyData	Hawq
亚秒级响应	Y	N	Y	Y	N	N	Y（据说可以到达秒级）	单表查询Y，多表查询N	Y（ms-s性能高于Kylin‘）	N	N	Y	Y	N
高并发	Y	N	Y	Y	N	N	Y	N	N	Y	Y	N	Y	Y
百亿数据集	Y	Y	Y	Y	Y	Y	Y		Y	Y	N	N	Y
SQL支持	Y	Y	Y	N（开发中）	Y	N	Y（结合Impala可支持SQL查询）	Y（支持Sql中基本语法对于开窗函数还不支持）	Y	Y	Y	Y	Y	Y
离线	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
实时	N（开发中，目前主要支持Kafka 流构建 Cube）	N	N	Y	N	Y	Y（Spark Streaming）	Y（实时数据分析领域的黑马）	Y	Y	N	N	Y	N
精准去重能力	Y	Y	Y	N	Y	N	Y	Y	Y	Y	Y	Y	Y	Y
是否支持明细查询	N	Y	N	N	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
多表join	Y	Y	Y	N	Y	N	Y	Y	Y	Y	Y	Y	Y	Y
能否更改模型	N	Y	N	N	Y	N	Y	Y（更换表引擎）	N	Y	Y	N	Y	未知
JDBC/ODBC for BI集成	Y	Y	N	N	Y	N	Y	N	Y	Y	Y	N	Y	Y
WEB GUI	Y	Y	Y	N	N	N	Y	Y	N	Y	N	未知	未知	Y
REST API	Y	N	Y	N	N	Y	N	N	N	N	N	未知	N	N
社区活跃度	活跃	活跃	活跃	活跃	活跃	活跃	较活跃	不太活跃	Doris社区刚刚起步，目前核心用户只有Baidu；	较活跃	活跃	活跃	较活跃	较活跃
存储能力	shared nothing	shared nothing	纯计算	shared nothing	无	计算+存储	列式存储	计算+存储	计算+存储	计算+存储	存储到HDFS	计算+存储	shared	noting
成本	中	中	中（CDH据说要收费收费以后可能会提高）	中	低	中	中	高	中	中	低	未知	高	中
易用性	安装简单快捷，轻量级，简单，选择维度表和度量即可构建Cube	安装简单，基于内存，查询代价较大	部署简单，基于内存，查询代价较大	部署简单，基于内存	部署简单	部署较简单，但是难用目前发展趋向于专人专岗	部署简单，需要开发门槛较高，基于磁盘	简单易用	按装复杂	安装部署较为复杂	部署较简单	未知	未知	部署比较复杂
监控成本	自带监控组件、运维成本低	有公共web监控管理	自带监控组件，运维成本低	自带监控可配置，有web页面	自带监控	可以使用Kibana实现，成本较高	已经集成到CDH中，便于监控	自身具有简单的监控组件，可以联合其他的监控工具进行监控	监控的集中到Prometheus	使用开源的 metric 分析及可视化系统Grafana 进行监控	没有自带的监控，但是在阿里云有配合hive的监控，成本高	未知	运维成本高	支持多种工具监控

五、选型的一些建设

上面给出了常用的一些OLAP引擎，它们各自有各自的特点，我们将其分组：

Hive，Hawq，Impala - 基于SQL on Hadoop；
Presto和Spark SQL类似 - 基于内存解析SQL生成执行计划；
Kylin 用空间换时间，预计算；
Druid 一个支持数据的实时摄入；
ClickHouse OLAP领域的Hbase，单表查询性能优势巨大；
Greenpulm OLAP领域的Postgresql。

如果你的场景是基于HDFS的离线计算任务，那么Hive，Hawq和Imapla就是你的调研目标；
如果你的场景解决分布式查询问题，有一定的实时性要求，那么Presto和Spark SQL可能更符合你的期望；
如果你的汇总维度比较固定，实时性要求较高，可以通过用户配置的维度+指标进行预计算，那么不妨尝试Kylin和Druid；
ClickHouse则在单表查询性能上独领风骚，远超过其他的OLAP数据库；
Greenpulm作为关系型数据库产品，性能可以随着集群的扩展线性增长，更加适合进行数据分析。

就像美团在调研Kylin的报告中所说的：

目前还没有一个OLAP系统能够满足各种场景的查询需求。
其本质原因是，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。