SQL on Hadoop系统的最新进展(3)

　　Cloudera Manager 4.6以后会有slow query的分析功能

　　Runtime Code Generation http://blog.cloudera.com/blog/2013/02/inside-cloudera-impala-runtime-code-generation/

　　impala可以直接使用硬盘上的数据而不经过hdfs

　　缺点：

　　impala不会按照group by的列排序

　　目前不支持UDF，impala 1.2即将支持Hive UDFs(Java写的)和Impala native UDFs and UDAs(接口类似PosgreSQL)

　　不支持像Hive的Serializer/Deserializer，从而使得它做从非结构化到结构化数据的ETL工作比较麻烦。所以本质上讲Impala适合MR配合做ETL之后的查询工作。

　　由于Impala的设计初衷是short query，所以不支持fault tolerance。如果参与查询的某个node出错，Impala将会丢弃本次查询。

　　安全方面的支持还比较差。impalad之间传输的数据没有加密，不支持表或者列级别的授权。

　　每个PlanFragment执行尽量并行化，但是有的时候并不是很容易。例如Hash Join需要等到其中一个表完全Scan结束才能开始。

　　虽然有这么多缺点，但是很多公司还是开始尝试Impala了。以百度为例，百度尝试把MySQL接入Impala的后端作为存储引擎，同时实现相应操作对应的PlanFragment，那么用户来的query还是按照原来的解析方法解析成各种PlanFragment，然后直接调度到对应的节点(HDFS DataNode/HBase RegionServer/MySQL)上执行。会把某些源数据或者中间数据放到MySQL中，用户的query涉及到使用这部分数据时直接去MySQL里面拿。

　　Shark/Spark

　　由于数据能放到内存尽量放到内存，使用内存非常aggressive。优点是做JOIN时会比较快，缺点是占用内存太大，且自行管理内存，占用内存后不会释放。

　　由于Shark借用了Hive的codebase，所以在SQL，SerDes，UDF支持方面和Hive是完全兼容的。

　　支持fault tolerance

　　性能：

　　特别简单的select…where查询，shark性能的提升不明显。(因为hive也不怎么费时间)

　　但是如果查询比较复杂select…join…where…group by，hive的job数目会比较多，读写HDFS次数增多，时间自然会变长。当内存还足够大的时候shark性能是最好的，如果内存不够装下所有的数据时性能会下降，但还是会比Hive好很多。

　　SQL on Hadoop产品需要向传统数据仓库学习的地方

　　以开源数据仓库brighthouse(基于MySQL的数据仓库存储引擎)为例。

　　VLDB 2008 论文 <>

　　brighthouse的SQL解析用的是MySQL的代码，开发了brighthouse专用的optimizer,executor以及storage engine

　　brighthouse的数据存储通过三层来组织：Data Pack, Data Pack Node, Knowledge Node

　　DP(Data Pack):brighthouse是列存储的，每个DP存储一列中64K个单元的数据。

　　DPN(Data Pack Node):DPN和DP是一对一的关系，DPN中记录每个DP数据对应的一些统计值(max,min,count,sum)

　　KN(Knowledge Node):DP的更详细的数据信息和DP之间关系的信息

　　KN又分为一下三个部分：

　　HISTs(Histograms):数值类型列的统计直方图，能够快速判断这个DP是否符合查询条件。

　　CMAPs(Character Maps):文本类型的位图，用于快速查找字符。(优化关键字like)

　　Pack-To-Pack:等值JOIN操作时产生的两个列(DP)之间关系的位图。

　　DPN和KN相当于DP的一些统计信息，占整个DP的1%的存储空间，所以可以轻松装入内存。他们是为了快速定位哪些DP是跟这个query相关(relevant)的，哪些是不相关(irrelevant)的，哪些是可能相关(suspect)的。从而减小IO读取的数据量，提高性能。

　　性能测试：http://www.fuchaoqun.com/tag/brighthouse/

　　从这个性能测试中可以看出：

　　1，压缩率：infobright比MyISAM/tar.gz的压缩率都要高很多

　　2，查询性能：跟建了索引的MyISAM表相比，查询速度也要快3-6倍

　　总之，大家都缺少的是：

　　1，workload management or query optimization

　　多个表的JOIN如何执行，例如3个表的JOIN会有6种执行策略，那么哪一种才是效率最高的呢。显然要通过计算每种执行顺序的开销来获得。在传统数据库或者数据仓库领域(Oracle/Teradata/PostgreSQL)都有非常好的查询优化器，而在分布式系统中该如何衡量这些指标(磁盘IO，网络带宽，内存)与最后查询效率之间的关系是个需要认真研究的问题。

　　2，关联子查询correlated sub-queries还是没有谁能够实现。

　　在TPC-H中又很多关联子查询的例子，但是现在的SQL on Hadoop产品都不支持。听Impala的人说，他们客户对这个的需求不是很强烈，大部分关联子查询可以转化成JOIN操作。但是目前的商业产品像Hawq/Greenplum都是支持关联子查询的。

原文转自：http://yanbohappy.sinaapp.com/?p=381