SQL on Hadoop技术分析（一）

Hadoop的诞生是划时代的数据变革，但关系型数据库时代的存留也为Hadoop真正占领数据库领域埋下了许多的障碍。对SQL（尤其是PL/SQL）的支持一直是Hadoop大数据平台在替代旧数据时代亟待解决的问题。Hadoop对SQL数据库的支持度一直是企业用户最关心的诉求点之一，也是他们选择的Hadoop平台的重要标准。

自打Hive出现之后，SQL onHadoop相关系统已经百花齐放，速度越来越快，功能也越来越齐全。目前比较主流的有Impala，Spark SQL，HAWQ，Tez，Drill，Presto，Tajo等。下面从技术层面梳理下一个技术统一的视角，来为后续在技术方案上选择做参考。

系统架构：Runtime Framework vs MPP

在SQL on Hadoop系统中，有两种主流的架构，一种是基于某个运行时框架来构建查询引擎，典型的案例就是Hive，另一种是仿照MPP数据库架构，典型的如Impala，HAWQ。前者现有运行时框架，然后套上SQL层，后者则是一个一体化的查询引擎，有时我们能听到一种声音，说后者的架构优于前者，至少在性能上。那么是否果真如此？

一般来说，对于SQL on Hadoop系统很重要的一个评价指标就是:快，低时延。在Hive逐渐普及后，就逐渐有了所谓交互式的查询需求，因为无论是BI系统，还是Ad-hoc，都不能按照离线的方式来处理。很多厂商都试图去解决这个问题，于是就有了Impala，HAWQ等，同时经过不断的发展，Hive也能跑在DAG框架上了，不仅有Tez，还有Spark。从任务的运行角度来看，MPP类引擎的执行方式其实跟DAG模型是类似的，主要的特点如下：

·        DAG v.s. MR：最主要的优势，中间结果不写磁盘（除非内存不够）。

·        流水线计算：上游stage一出结果马上推送或者拉到下一个stage处理，比如多表join时前两个表有结果直接给第三个表，不像MR要等两个表完全join完再给第三个表join。

·        高效的IO：本地查询没有多余的消耗，充分利用磁盘。

·        线程级别的并发：相比之下MR每个task要启动JVM，本身就有很大延迟，占用资源也多。

当然MPP模式也有其劣势，一个是扩展性不是很高，这在关系数据库时代就已经有过结论；另一个是容错性差，对于Impala来说一旦运行过程中出点问题，整个查询就挂了。

主流的存储格式有，ORC，Parquet，最近华为大数据团队研发的CarbonData数据格式，从原型测试数据，CarbonData性能上比Parquet要快，这主要得益于在构建Carbon数据格式中，创建了很多的索引，从整个查询扫描过程中，利用索引快速过滤掉数据，减少扫描的数据量，类似这样的系统，有腾讯的Hermes等。另外Impala使用的Parquet格式存储，现在又有了一种新的解决方案，kudu+Impala的方案，Cloudera宣称查询分析非常快，并且能支持数据的更新等操作。

在SQL on Hadoop方案中，另外一个客户关注的方面是资源控制，在Hadoop体系中，与Yarn的集成。比如目前的Impala版本就不支持通过Yarn来管理分布使用资源，不过从Impala的版本路标中，与Yarn的数据集成已经是Impala的一个重要的目标。目前能与Yarn集成的有Spark SQL，HAWQ等.

SQL on Hadoop的技术发展越来越快，各个厂家的竞争也是越来越激烈，到底哪种技术性能更加的好，查询时延更加的低，这个还是要从业务使用场景上来针对性分析选择。

任何一种技术，都有其适合的场景，然后结合技术上分析，如何减少扫描的数据量，是提升查询性能的关键。