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

发表于:2013-11-05来源:DataScientist作者:DataScientist点击数: 标签:sql
关于ORCFile的压缩效果,使用情况和性能可以参考hortonworks的博客 http://hortonworks.com/blog/orcfile-in-hdp-2-better-compression-better-performance/ 未来ORCFile还会支持轻量级

  关于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