当前位置:   article > 正文

笔记:Hive的主要技术改进(Major Technical Advancements in Apache Hive)

hive的改进
  1. Introduction
    hive的主要不足: 存储和查询计划执行。文中提出了三个主要的改进点
    1. 新的文件格式 ORC
    2. 查询计划组件优化(关联优化器correlation optimizer
    3. 向量执行模型,以充分利用CPU CACHE
  2. Hive architecture

  3. 识别hive的不足
    1. 存储格式的不感知以及一次只能处理一行数据。在hive,存储效率由序列化和文件格式决定。以前支持的text和sequence格式,以及v0.4后支持的RCFile都是类型不感知的。RCFile每次只能处理一行数据。类型不感知意味着不能做有针对类型的优化;一次处理一行数据,意味着并行度低,并且序列化的压缩比低。
    2. 没有数据索引(包括统计汇总信息)以及不支持复杂数据类型。RCFile是为数据扫描设计的,并没有索引和提供其他语意以跳过无用的数据。不支持复杂类型的解析(如map、array),意味着访问该类型的任何一个成员,都要去读整个类型的数据。
    3. 忽略了数据操作之间的联系,导致出现很多的不必须shuffle。
    4. 每次处理一行数据也限制了对现代CPU缓存和并行处理的利用。
  4. 文件格式优化(ORC)
    类型识别;支持刚类型的数据索引;支持复杂数据类型分解
    1. 1 表的数据布局方式(The table placement method), 见上图。注意,ORC不支持将列放到列组里面。

      优点1: stripe的缺省大小为256m(RCFile为4M)
      优点2:支持复杂数据类型,见table1.

      有点3: stripe的边界与hdfs的边界对齐。通常,stripe大小会小于hdfs的block大小,使用这种对齐,可以确保一个stripe始终保存在同一个block内部。
    2. 数据索引(Indexes)
      处于加载速度的考虑,只使用稀疏索引。存在两种索引:
      1. 数据统计信息(data statistics)。包括counter/mix/max/sum/len
        数据统计信息分三个级别: 文件、stripe、逻辑数据块(缺省10000个value一个块,可配置)
      2. 位置指针(position pointer)。
    3. 压缩。
      有两个级别的压缩,
      1. 基于类型的压缩。(string类型的压缩,如果去重后数量除以总数量大于0.8使用字典压缩,否则使用byte类型压缩。

      2. 通用压缩方式(可选)(e.g., gzip,snappy等,默认压缩窗口256k)
    4. 内存管理。根据内存的限制自动调节实际使用的stripe的大小。(应该是指每次读取数据块的大小)
  5. 查询计划
    三个不足点:
    1. 不必要的Map阶段。由于一个MR job最多有一个shuffle,所以出现多个MR job很正常。MR的中间文件会回写到hdfs中的。如果一个map没有reduce,它就引入了一次没有必要的回写hdfs。

    2. 重复的数据加载。一个表被多次在不同MR中使用的情况下,这个表被多次加载。
    3. 不必要的数据重分片。
    4. 消除不必要的map phase.
      Map-only job产生是因为MR job 被转换成了Map job。存在集中情况,其中最有代表性的是较小的表和大表之间的hash join。为了减少map phase,每次将reduce join转化为map join之前,计算map-only job中参与hash join操作的较小的表是否小于某个阈值,如果是就将这个map-only jion到他的子job中去。

    5. 关联优化器(correlation optimizer)
      基于YSmart(http://web.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-11-7.pdf  )。
      存在两种关联:
      1. 输入关联(input correlation):意思是一个表在不同MR job中别使用多次。
      2. job flow correlation(工作流程关联):一个操作依赖于另一个操作,且这两种操作使用相同的数据分片方法。
        有三个条件决定一个上游RSOp是否与一个下游RSOp关联:
        1. 产生的行使用相同的排序方法;
        2. 使用相同的数据分片方法
        3. 没有reduce数量上的冲突(?)
      3. 操作树转换
        1. 必须有底层RSOp,用来产生行数据
        2. 添加DemuxOperator来减少不必要的RSOp。

      4. 操作协调。 
        因为MR是push数据的,导致很多不必要的数据也被传输。所以需要一个协调器实现“按需传输”的功能。
    6. 查询执行
      目的是充分利用现代cpu的特点。现代cpu的效率很大程度取决于并行度。为了实现多条流水线并行执行,需要减少指令分支。另外,数据的独立也有利于提高并行度。另外,一次执行一行导致cache性能低。
      1. 数据集代表批量的行(默认1024,可配置)。
      2. 单行模式下,一行数据被整棵查询树处理后才处理下一行;现在批量的行为单位执行了。


    7. 性能测试
      1. file format


      2. 查询计划
      3. 查询执行





posted on 2015-04-26 23:00 过雁 阅读( ...) 评论( ...) 编辑 收藏

转载于:https://www.cnblogs.com/zwCHAN/p/4458653.html

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/正经夜光杯/article/detail/962501
推荐阅读
相关标签
  

闽ICP备14008679号