SQL-on-Hadoop摘要

原始文章传送门 http://www.gruter.com/blog/?p=391

General Feature
数据往往以RC & ORC & Parquet等格式存放在HDFS 以及在分布式环境上执行SQL

SQL-on-Hadoop solutions
1.  Hive: 将SQL转成MapReduce Job,继承了MR的稳定可靠,同时也带来了Shuffle过程的额外消耗
2.  Stinger: 将计算框架迁移到Tez上, 因此并不算是一个独立的新解决方案,但可以解决Hive一部分不足
3.  Apache Iajo: 在HDFS上使用了自己的分布式执行引擎
4.  Impala: 使用了自己的分布式计算框架,在Shuffer阶段会将所有数据保存在内存中,因此避免了shuffling overheads,  但是不能处理超过内存限制的数据量
5.  Apache Drill: Google Dremel的开源实现,目前还在开发中,而且还没实现其主要的分布式处理模块

Key SQL-on-Hadoop performance factors
1.  磁盘扫描速度,因为数据通常是存放在HDFS;此外中间数据的传输效率也是个重要因素,因为像Group By或者Order By之类的算子往往会以多步来执行
2.  Query Execution启动时间,对于短查询而言,启动时间会成为较大的OverHeads,而在长查询中,启动时间往往占比很小
3. 文件格式,目前有 RC & ORC & Parquet等,往往这些文件格式有不同的特性,往往需要根据实际的应用场景来选择合适的文件。Query往往会生成大量的结果文件,文件格式和文件写效率是一个关键的因素,比如ORC文件格式有较好的读性能,但是写性能较差。此外合适的压缩机制也是一个关键因素在SQL-on-Hadoop系统中

The absolute performance limits of SQL-on-Hadoop
1.  除了上面的因素之外,还有一些限制是不能超出的:处理性能会小于或者等于在HDFS上的磁盘带宽
2.  对于像Select count(*) from table这样的查询而言,由于没有shuffle消耗,因此磁盘读取速度,Query启动时间和文件格式成为关键因素,当使用相同的文件格式和大量的数据场景下,各个解决方案的时间相差不远
3. 对于across a range of natural field queries,  Stinger这些只是比Hive快1.5-3倍左右

Frequently-used performance comparison queries
1.  对于短查询而言,Stinger由于省去了启动时间,因此可能会比Hive快上百倍,但是并不意味着在长查询中也有同样的效果
2.  而对于Order By这类操作,Hive只用单机来执行,对于能够分布式Order By方案而言,查询效率是能够比Hive高上千倍的,只要节点数足够多。但是并不能就宣称比Hive快上上千倍

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s