SQL on Hadoop技术分析(一)

阅读更多
 
2016-07-12  王森  hadoop技术学习

SQL on Hadoop技术分析(一)_第1张图片

 背景

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的技术发展越来越快,各个厂家的竞争也是越来越激烈,到底哪种技术性能更加的好,查询时延更加的低,这个还是要从业务使用场景上来针对性分析选择。

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

 

 


 

 

 

 

 
 
SQL on Hadoop技术分析(一)_第2张图片

微信扫一扫
关注该公众号

你可能感兴趣的:(SQL on Hadoop技术分析(一))