摘要：Hadoop已在各行业广泛使用，例如互联网、金融、教育等，Hadoop的核心是存储、分析、挖掘海量的数据，并通过这些数据来解决实际的问题。对于一个工程师或者分析师来说，如何查询和分析TB/PB级别的数据是在大数据时代不可回避的问题。和编程相比，SQL更具易用性，这种易用性的需求使SQL on Hadoop技术成为Hadoop生态系统中最活跃的领域之一，各种各样的SQL on Hadoop引擎大量涌现，本文将介绍几个流行的开源SQL on Hadoop引擎以及每种引擎的应用场景。

SQL：结构化查询语言(Structured Query Language)，是一种数据库查询和程序设计语言，相比其他编程语言，SQL的一个显著特点是简洁、易用，不管是开发工程师、数据分析师还是没有编程基础的人员，都能迅速的掌握和使用。随着大数据的兴起，用户更希望通过SQL来操作Hadoop，而不是通过编程的方式，由于这种急迫的需求，SQL on Hadoop引擎大量涌现。

目前SQL on Hadoop引擎的地位争夺战大体分几类阵营，第一类是在计算引擎（如MapReduce/Spark）之上覆盖SQL层，由SQL层负责SQL的解析、优化，最终转换成计算引擎的任务进行分布式处理，这类引擎如Hive、Spark SQL等；第二类是抛开了计算引擎，采用类MPP架构，自己做分布式计算，这类引擎更似一种专用引擎，如Impala、HAWQ、Presto、Drill等；第三类是专用SQL引擎，如Phoenix，专门为HBase提供SQL支持，正是这种专一的目标，使其成为查询HBase性能最好的SQL引擎；第四类是多维分析引擎，如Apache Kylin，数据分析之前先进行多维建模（创建数据立方体），以空间换取时间的方式加速数据查询；第五类则是最近兴起的流式SQL，使用SQL来处理流数据。

一、几种SQL on Hadoop引擎概览

1. Apache Hive

Hive是Hadoop上出现的第一个SQL引擎，由Facebook开源，并迅速得到了广泛的应用，至今Hive仍然是使用最广泛的SQL on Hadoop引擎，虽然Hive的性能不及一些新兴的SQL引擎，但其稳定性是最佳的。由于Hive已得到了广泛的使用，各个Hadoop的发行版厂商都会支持Hive，大部分支持Hadoop的工具（如ETL、BI等）也都支持Hive。Hive 的数据存储在HDFS中（也支持Amazon S3），所有的查询转化为MapReduce的任务在Hadoop集群上执行，其架构如图1所示。

图1. Hive体系架构

Hortonworks将Hive底层的执行引擎切换为TEZ（类似MapReduce的一种分布式计算引擎），使Hive的性能得到了大幅度的提升。随着Spark的快速发展，Hive目前也可以将底层引擎切换为Spark，借助Spark，Hive的性能得到进一步提升。Hive定义了简单的类SQL查询语言，称为HQL，熟悉SQL的人员很容易掌握HQL。Hive可通过CLI客户端进行查询，也可通过JDBC/ODBC接口进行访问。

Hive2.x将HPL/SQL纳入，自此，Hive开始支持存储过程（HPL/SQL兼容部分PL/SQL），不过目前还处于初级阶段，使用HPL/SQL只能通过脚本的方式（相当于客户端的存储过程），无法像使用传统数据库那样调用数据库中的存储过程。不过Hive社区正努力将HPL/SQL深度融合到Hive中，届时，存储过程将会被编译优化后存储在Hive服务器端，应用程序可以通过JDBC/ODBC等方式调用。

2. Apache Spark SQL

SparkSQL是Spark生态圈中的重要一员，SparkSQL的前身是Shark，Shark对于Hive有太多依赖（如采用Hive的语法解析器、查询优化器等），Spark社区认为这种强依赖将会阻塞Spark SQL的发展（社区意在开发自己的优化器），因此SparkSQL抛弃原有Shark的代码，汲取了Shark的一些优点，如内存列存储（In-Memory Columnar Storage）、Hive兼容性等，重新开发了SparkSQL代码。由于摆脱了对Hive的依赖性，SparkSQL在数据兼容、性能优化、组件扩展方面都得到了极大的方便。在性能方面比Hive有了10-100倍的提高。Spark2.0版本中的SparkSQL对SQL的支持程度已有了很大程度的提升，完全支持TPC-DS（一种测试SQL兼容程度的标准测试）的99个用例，性能也有了大幅度提升，并且在易用程度及展示层面有了很大的改进。

SparkSQL架构类似Hive，SQL层负责将SQL语句解析优化后生成Spark任务，其架构图2所示。SparkSQL支持HQL，熟悉Hive的用户也可以很快掌握SparkSQL。另外SparkSQL支持和Hive集成，即和Hive共用一个元数据库，Hive中的表在SparkSQL中也可以查询，无需创建外部表进行映射。

图2. Spark SQL体系架构

Spark支持DataFrame，用户可以通过DataFrame API在Spark程序中加载数据并注册成SparkSQL的临时表，在程序中使用SQL语句进行数据操作，降低了编程难度，编码量也大幅度减少，最大的优点在于SparkSQL处理的数据可以直接交给Spark的批处理、流处理或机器学习模块，无需数据落盘，减少了磁盘IO，提升了应用程序整体的性能，Spark用户无需投入时间去学习另外一种SQL引擎，降低了学习成本和运维成本。

另外，随着Spark的快速发展，SparkSQL支持的数据源越来越多，除了Hive外，还支持HBase、HDFS、JSON文件、各种传统关系型数据库（如Oracle、MySQL等）。

国内有些商业公司基于Spark进行二次开发优化，增强SQL的支持程度、增加对PL/SQL的支持，包装成自己的SQL引擎，提升自己发行版Hadoop的竞争力，也有厂商开源了Spark SQL对HBase的本地化处理引擎（Astro），使SparkSQL可以本地化处理存储在HBase中的数据。

3. Apache Impala

Impala是Cloudera公司开源的一款SQL引擎，随着Cloudera CDH的广泛应用，Impala也被广泛使用，Impala是受到Google的Dremel启发下开发的实时交互SQL大数据查询工具，它可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的结合体，其架构如图3所示。

图3. Impala体系架构

Impala的元数据存储在Hive中，Hive中的表也可以通过Impala进行查询。另外Impala也支持多种数据源，如HDFS、HBase等。Cloudera公司开源的Kudu存储引擎（kudu兼顾了吞吐量和实时性）也可以和Impala配合使用。

4. Facebook Presto

Presto是FaceBook继Hive之后开源的第二款SQL on Hadoop引擎，其架构和Hive完全不同，采用 Master-Slave的架构，如图4所示。Presto由一个Coordinator节点，一个Discovery Server节点，多个Worker节点组成，Discovery Server通常内嵌于Coordinator节点中。Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。Worker节点负责执行查询任务。

图4. Presto体系架构

国内有些互联网公司对Presto进行了实践应用，如京东和美团。京东对Presto进行了二次开发、应用，并和FaceBook合作，组成了Presto中国社区，并且开源了二次开发后的代码JD-Presto。

Presto有多种连接器，如Cassandra、Hive、Kafka、MongoDB、MySQL、PostreSQL、Redis等，通过配置可以很方便的使用存储在这些数据源中的数据。但是Presto并没有提供HBase的连接器。另外Presto支持近似查询，类似Spark中的BlinkDB。

5. Apache Drill

Apache Drill是是一个低延迟的分布式海量数据（涵盖结构化、半结构化以及嵌套数据）交互式查询引擎，使用ANSI SQL兼容语法，支持本地文件、HDFS、HBase、MongoDB等后端存储，支持Parquet、JSON、CSV、TSV、PSV等数据格式。Drill目前主要有MapR公司进行推动，相比其他SQL引擎，Drill不要求一个集中的元数据（Schema free），不需要创建一个元数据库来存储表和视图，Drill的元数据来源于数据源插件。Drill架构如图5所示，核心是DrillBit服务，接收客户端的请求，处理查询后返回给客户端。

图5. Drill体系架构

正是因为Drill的Scheme free架构和广泛的数据源支持，Drill可用于异构数据源直接的关联查询，如对存储在Oracle中的维度表和存储在HBase中的数据表进行JOIN查询。此外Drill提供了数据源配置的界面和查询界面，这一点比Presto更易用。

6. Apache HAWQ

Apache HAWQ是Pivotal公司在2015年开源的一款SQL on Hadoop引擎，HAWQ底层基于PostgreSQL，因此HAWQ语法大部分和PostgreSQL的语法一致。相比其他SQL on Hadoop引擎，HAWQ是支持SQL语句最完整的一个，并且支持存储过程。HAWQ是Master-Slave架构，如图6所示，Master节点为管理节点，Segment节点为计算节点。

图6. HAWQ体系架构

近期HAWQ发布了2.0版本，新版本增加了对YARN的支持，可以和Hadoop其他组件进行统一资源调度，并且增加了与Hive HCatalog的集成，无需通过创建外部表即可访问Hive中的数据，在性能方面也有较大的提升。另外HAWQ提供了扩展插件PXF，通过PXF，HAWQ可访问外部数据源，如HBase等，同时PXF提供扩展接口，用户可以根据自己的需要对特定数据源开发访问插件。

7. Apache Phoenix

HBase提供了海量数据的毫秒级查询功能，但是HBase是一个非常原始的数据库，并不支持SQL，用户需要通过HBase提供的查询命令或API进行HBase查询，使用非常不方便。而Phoenix则为HBase提供了SQL支持，用户可以使用标准的SQL去创建表、插入记录、查询数据。Phoenix的查询语句会转化为HBase的API操作，由此，Phoenix也成为HBase的本地化SQL引擎。

Phoenix支持Hadoop上的OLTP业务和运营分析业务，提供HBase的二级索引功能。Phoenix可以和Hive集成，通过HiveQL查询Phoenix，Phoenix还支持和Spark集成，通过Spark DataFrame查询HBase数据。

8. Apache Kylin

Apache Kylin提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay开发并贡献至开源社区。它能在亚秒内查询巨大的表，号称终极OLAP引擎。Kylin架构如图7所示，核心思想是对数据源进行多维度预处理（创建数据立方体），以空间来换取查询性能。据社区测试数据显示，一个近280亿条原始数据的cube（26TB）上，90%的查询在5秒内完成。国内一些互联网公司已经开始在线上使用Kylin来支撑业务，如百度地图等。

图7. Kylin体系架构

9. 流式SQL引擎

在大数据处理场景中，流数据处理是很大的一块，目前流式数据的处理大部分还是需要通过编写代码来做。国内有一些互联网公司，为了简化这部分工作，对流处理进行了封装，提供类似DSL语言来描述，并提供一些模板，这对于单个公司内部使用尚可满足，但是对于提供企业版大数据平台的厂商还是倾向于提供SQL来处理流式数据，有Hadoop发行版厂商提供基于Spark Streaming的StreamSQL、也有厂商提供基于Storm的CQL等。开源社区中，Apache Flink同样开始不断的完善SQL的支持。基于SQL来操作流数据能大大降低复杂程度，使BI人员、运维人员也可以处理流式数据。

10. 综合对比

二、SQL on Hadoop引擎应用场景

1. OLAP场景

联机分析处理OLAP（On-Line Analytical Processing）支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。典型的应用就是复杂的动态的报表系统。OLAP的应用场景有如下特点：

1）数据更新实时性要求不高；

2）数据量大；

3）动态查询。

这类场景是分析类场景不涉及到数据的insert、update、delete操作，可选的SQL引擎有Hive、SparkSQL、Impala、Presto、Drill、HAWQ、Kylin。

若数据来源于Spark（批处理、流处理、机器学习），推荐使用Spark SQL，这样数据无需落盘，并且无需去学习另外一款SQL引擎；

若需要用到异构数据源之间的关联查询，推荐使用Drill或Presto（注意：Presto暂时没有提供HBase连接器）；

若用户需要存储过程，推荐使用HAWQ；

若用户对查询性能要求极高，推荐使用Kylin预先对数据进行多维建模；

其他一般的即席查询需求，可选的SQL引擎有SparkSQL、Impala、Presto、Drill、HAWQ，鉴于Hive的性能偏弱，即席查询不推荐使用Hive。

2. OLTP场景

联机事务处理OLTP（on-line transaction processing）主要是执行基本的、日常的事务处理，比如数据库记录的增、删、改、查，如在线内容推荐系统等。OLTP应用有如下特点：

1）实时性要求高；

2）确定的SQL操作；

3）较高的事务要求。

这类场景涉及到对数据频繁的insert、update、delete操作，推荐HBase和Phoenix配合使用。

三、结束语

尽管现在SQL on Hadoop引擎已经很多，但是都不是很完善，目前还没有一个能提供全量的功能，毕竟相比较成熟的关系数据库，分布式环境下需要解决的问题更多，在实践中大浪淘沙，最终将会有几个SQL引擎会脱颖而出。

目前新华三集团大数据平台DataEngine支持Hive、SparkSQL、HAWQ、Phoenix、Kylin，并对这些SQL引擎进行了bug修复及性能优化。我们正在将这几种SQL引擎进行功能及架构上的融合，后面的版本将给用户提供统一的SQL访问接口，同时支持OLTP和OLAP场景、异构数据源之间的关联查询、流数据的SQL操作，大大降低用户的选型难度及使用难度。