笔记：Hive的主要技术改进（Major Technical Advancements in Apache Hive）

http://web.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-14-2.pdf 

(辅助参考：https://cwiki.apache.org/confluence/display/Hive/Correlation+Optimizer ）

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. 查询执行
   
   

来自为知笔记(Wiz)