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

　　关于ORCFile的压缩效果，使用情况和性能可以参考hortonworks的博客

　　http://hortonworks.com/blog/orcfile-in-hdp-2-better-compression-better-performance/

　　未来ORCFile还会支持轻量级索引，就是每一列中以1W行作为一组的最大值和最小值。

　　通过对ORCFile的上述分析，我想大家已经看到了brighthouse的影子了吧。都是把列数据相应的索引、统计数据、词典等放到内存中参与查询条件的过滤，如果不符合直接略过不读，大量节省IO。关于brighthouse大家可以参考下面的分析。

　　4，HiveServer2的Security和Concurrency特性

　　http://blog.cloudera.com/blog/2013/07/how-hiveserver2-brings-security-and-concurrency-to-apache-hive/

　　HiveServer2能够支持并发客户端(JDBC/ODBC)的访问。

　　Cloudera还搞了个Sentry用于Hadoop生态系统的的安全性和授权管理方面的工作。

　　这两个特点是企业级应用Hadoop/Hive主要关心的。

　　5，HCatalog Hadoop的统一元数据管理平台

　　目前Hive存储的表格元数据和HDFS存储的表格数据之间在schema上没有一致性保证，也就是得靠管理员来保证。目前Hive对列的改变只会修改 Hive 的元数据，而不会改变实际数据。比如你要添加一个column，那么你用hive命令行只是修改了了Hive元数据，没有修改HDFS上存储的格式。还得通过修改导入HDFS的程序来改变HDFS上存储的文件的格式。而且还要重启Hive解析服务，累坏了系统管理员。

　　Hadoop系统目前对表的处理是’schema on read’，有了HCatlog就可以做到EDW的’schema on write’。

　　HCatlog提供REST接口提供元数据服务，有利于不同平台(HDFS/HBase/Oracle/MySQL)上的不同数据(unstructured/semi-structured/structured)共享。能够把Hadoop和EDW结合起来使用。

　　HCatlog对用户解耦了schema和storage format。举个例子吧，在写MR任务的时候，目前是把所有的行数据都当成Text来处理，Text一点点解析出各个Column需要编程人员来控制。有个HCatlog之后编程人员就不用管这事了，直接告诉它是哪个Database->Table，然后schema可以通过查询HCatlog来获得。也省得数据存储格式发生变化之后，原来的程序不能用的情况发生。

　　6，Windowing and Analytics Functions的支持。

　　支持Windowing functions : lead, lag, first_value, last_value

　　支持over clause : partition by, order by, window frame

　　支持analytics functions : rank, row_number, dense_rank, cume_dist, percent_rank, ntile

　　https://cwiki.apache.org/confluence/display/Hive/LanguageManual+WindowingAndAnalytics

　　https://issues.apache.org/jira/browse/HIVE-4197

　　Tez/Stinger(升级版的Hive)

　　Tez是一种新的基于YARN的DAG计算模型，主要是为了优化Hive而设计的。目前Tez/Stinger主要是Hortonworks在搞，他们希望以后把Hive SQL解析成能够在Tez上跑的DAG而不是MapReduce，从而解决计算实时性的问题。Tez的主要特点有：

　　底层执行引擎不再使用MR，而是使用基于YARN的更加通用的DAG执行引擎

　　MR是高度抽象的Map和Reduce两个操作，而Tez则是在这两个操作的基础上提供了更丰富的接口。把Map具体到Input, Processor, Sort, Merge, Output，而Reduce也具体化成Input, Shuffle, Sort, Merge, Processor, Output。在MR程序里，编程人员只需编写对应的Processor逻辑，其他的是通过指定几种具体实现来完成的;而在Tez里面给我们更大的自由度。其实这个跟Spark有点类似了，都是提供更丰富的可操作单元给用户。

　　传统的Reduce只能输出到HDFS，而Tez的Reduce Processor能够输出给下一个Reduce Processor作为输入。

　　Hot table也放到内存中cache起来

　　Tez service：预启动container和container重用，降低了每次Query执行计划生成之后Task启动的时间，从而提高实时性。

　　Tez本身只是YARN框架下得一个library，无需部署。只需指定mapreduce.framework.name=yarn-tez

　　http://dongxicheng.org/mapreduce-nextgen/apache-tez-newest-progress/

　　Tez/Stinger还有一个最重要的feature : Vectorized Query Execution (该feature在HDP 2.0 GA中会提供)

　　https://issues.apache.org/jira/browse/HIVE-4160

　　目前Hive中一行一行的处理数据，然后调用lazy deserialization解析出该列的Java对象，显然会严重影响效率。

　　多行数据同时读取并处理(基本的比较或者数值计算)，降低了一行一行处理中过多的函数调用的次数，提高了CPU利用率和cache命中率

　　需要实现基于向量的vectorized scan, filter, scalar aggregate, group-by-aggregate, hash join等基本操作单元。

　　未来工作方向：

　　Cost-based optimizer，基于统计选择执行策略，例如多表JOIN时按照怎样的顺序执行效率最高。

　　统计执行过程中每个中间表的Row/Column等数目，从而决定启动多少个MR执行

　　Impala

　　Impala可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的混合体。

　　https://github.com/cloudera/impala

　　Dremel论文： http://research.google.com/pubs/pub36632.html

　　优点：

　　目前支持两种类型的JOIN：broadcast join和partition join。对于大表JOIN时由于内存限制，装不下时就要dump部分数据到磁盘，那样就会比较慢

　　Impala各个任务之间传输数据采用的是push的方式(MR采用的是pull的方式)，也就是上游任务计算完就会push到下游，这样能够分散网络压力，提高job执行效率。

　　Parquet列存格式，同时能够处理嵌套数据。通过嵌套数据以及扩展的SQL查询语义，在某些特定的场景上避开了JOIN从而解决了一部分性能的bottleneck。(Impala目前支持LZO Text, Sequence, Avro, RCFile, Parquet, 不支持ORCFile。但是未来支持多种存储文件格式是个趋势，所以Impala读取文件这部分功能也需要尽快插件化。)

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