genshengxiao 2013-12-01
以前只用过Hive与impala两个类SQL查询系统,最近又将Hortonworks开源的Stinger与Apache的Drill做了些调研。累死累活搞了一天的资料,头都大了。为了纪念我那逝去的脑细胞,特将这些信息整理出来。
由于调查时间比较短(一天的时间都头晕眼花了,再长点估计我就要过劳死了),所写之处难免会有差错,欢迎大家指正
总体来说虽然impala、stinger、drill三个系统都是类SQL实时查询系统,但是它们的侧重点完全不同。而且它们也不是为了替换Hive而生,hive在做数据仓库时还是很有价值的。
目前来说只有impala比较成熟(人家标称要使用CDH版本Hadoop,如果要使用apache的,要做好测试的心里准备)。
其它两个系统还都处理孵化状态,但是前景非常不错。
这个系统是Cloudera开源的,时间大约是在12年下半年。虽然到现在才一年的时间但是已经有很多人在使用。社区也比较活跃,大家可以在github上面看到项目的开发人员与代码提交情况(地址:https://github.com/cloudera/impala)。个人感觉开发者虽然有其它几个公司,但是还是以cloudera为主。这样也造就了impala开发的比较快速,虽然到现在才一年左右的时间,但是impala已经可以很稳定的运行。
impala主要是为hdfs与hbase数据提供实时SQL查询。它是根据google的dremel论文实现的一套分布式系统,自用户提交的SQL开始都是基于自身的分析器与执行器。下图是其架构图
(图片来源自impala安装使用说明书)
由 于完全脱离了M/R技术,自身根据HDFS的文件分布来调整计算,所以速度较Hive有很大提升。根据我个人使用部分TPC基准测(为什么是部分?没理 由,我只选了一部分SQL来跑),impala虽然性能提升不像Cloudera标称的达到hive的一百倍,但是在比较复杂的情况下达到40-70倍性 能提高还是有的。
就日常使用来说,标称是支持大部分SQL-92标准(我也不清楚这个标准到底有多少,专业的童鞋给点解读呗!!)。根据我 是测试,日常用的SQL都没有问题。并且impala支持JDBC与ODBC的连接,这对于我们的使用也是很必要的,基于此特点我们可以开发对应业务系统 的UI部分,从而不用要求业务人员自己下SQL了(这是为数不多的展现工作成果的时候了)。
其次就是impala支持的文件格式,我们存取 数据的时候肯定要应景的选择压缩与否以及文件的存储格式。impala支持常用的Text、Sequence、avro格式,压缩方面支持Snappy、 bzip、gzip以及deflate压缩应该可以满足我们大部分的使用场景了。
而最棒的是它的UDF功能可以直接使用hive的udf库,而不需要修改任何代码,使用hive的童鞋可以庆祝了,很多任务不需要任何改变即可平滑切换impala。不过因为impala使用的是C开发的,所以impala还是鼓励大家写一个c下面的udf来提高性能。
开源时间跟impala差不多,只不过属于Apache,。这个系统的目标很宏大--抽象所有数据源,做成统一接口。底层支持hbase、mongoDB、HDFS、Cassandra等数据源。
它的数据接口都是插件化,理论上支持各种查询语言,SQL自然也不例外,不过目前这个系统还是Apache的一个孵化项目,很多功能尚未完成与稳定。但是可以预见,这个系统如果完成是很有影响力的。下图为drill的架构图。
(图片来源https://cwiki.apache.org/confluence/display/DRILL/High-level+Architecture)
Hortonworks开源的一个实时类SQL查询系统,也是声称可以提升较hive 100倍的速度(悲崔的hive,都拿它来当反面教材)。目前处于其计划中三个阶段的最后一个阶段。
综合来看Hortonwork做的事是在hive等分析系统的现有基上加了一个优化层,所有的事都要经过它的优化层Tez(此框架是基于Yarn)来处理,以减少不必要的工作以及资源开销。虽然它也对HIVE进行了很多的优化与加强,但是这个效果就要看子系统Tez的表现的了。Tez目前也是apache的孵化项目,Stringer如果要稳定可以商用依然还有很多路要走。
从下面的示意图大家可以了解Tez所处的位置。
相关阅读: