Cost-based optimization in Hive

Cost-based optimization in Hive

Abstraction

已有的大多数hive优化是减少shuffle的开销。这种情况下， 用户必须向hive提交正确的join顺序，执行效率才更高。Hive中的逻辑优化仅限于过滤条件下推、投影修剪（针对于select的列）和分区修剪。

**Cost based logical optimizations(CBO)**会自己选择最合适的join顺序和join算法（待测试，把mapjoin的参数调大，但不手动开启mapjoin为true，观察是否启动了mapjoin）

Calcite是一个开源的查询优化框架。Calcite有50多种优化规则可以重写查询树，和一个有效的查询计划修剪器可以使得查询句话最高效。这篇文章介绍Calcite怎样在hive中实现CBO。

Introduce

在过去，Hadoop job往往具有高延迟，并在作业提交和调度方面产生大量开销。在使用Hadoop2和Tez后，作业提交和调度的开销显著下降。

MR需要把中间结果落盘，Tez不需要，可以大幅度提升性能。

查询优化可以分为逻辑查询优化和物理查询优化。包括以下几个方面：

1. 逻辑查询优化：
   • 投影修剪
   • Deducing Transitive Predicates
   • 谓词下推
   • 把Select-Select，Filter-Filter合并
   • 多路join
   • 查询重写以适应某些列值上的连接倾斜
2. 物理查询优化：
   • 分区修剪
   • 基于分区和分桶的查询修剪
   • 在某些情况下，在map端实现group by
   • 在map端实现join
   • 优化union，使得union只在map端实现-
   • 删掉不必要的reduce sink operator
   • 对于limit，减少扫描表读取的文件
   • 对于limit，通过限制Reduce Sink operator的生成来限制mapper的输出
   • 在简单的 fetch 查询的情况下避免 Map-Reduce 作业
   • 重写 group by 查询以使用索引表而不是原始表
   • 当表扫描之上的谓词是相等谓词并且谓词中的列上有索引时，使用索引扫描。

在hive里面，大多数优化不是基于查询成本的优化，除了过滤器下推和运算符合并外，大多数优化不会重新排列operator tree。大多数operator tree的修剪是移除reduce-sink和reducer算子。但是利用CBO优化，可以获得以下收益：

1. 得到争取的join顺序
2. 选择合适的join算法
3. 确定中间结果是要落盘还是在失败时重新计算
4. 得到合适的算子的并行度

Calcite是一个开源的，遵循Apache协议的查询计划和执行框架。Calcite有JDBC server，查询解析器和校验器，查询优化器：

Calcite现在具有50多种优化规则。一些突出的优化规则如下：

1. Push Join through Union
2. Push Filter past Table Function
3. join 重排序
4. Push Aggregate through Union
5. Pull Aggregate through Union
6. Pull Constants through Aggregate
7. Merge Unions

本篇论文，我们提出使用 Calcite 的基于成本的优化器，Volcano，在hive中实现基于成本的优化。我们建议分阶段实施。

1. 阶段一：join重排序和join算法的选择

   • Table cardinality and boundary statistics will be used to compute operator cardinality
   • Hive Operator Tree被转化为 Calcite Operator Tree
   • Calcite 中的 Volcano 优化器将 join重排序并且选择合适的 join 算法
   • 优化后的Calcite Operator Tree在执行前被转成 Hive AST。所以，所有的hive的优化将是基于Calcite优化后的sql

2. 阶段二：添加直方图的支持，在Calcite中国呢使用其他优化算法

   • 引入节省空间的直方图
   • Change operator cardinality computation to use histograms
   • 注册其他的优化规则

3. 阶段三：代码重组以便 Calcite 生成优化的Hive Operator树

   • 不同于第一阶段，使得 Hive AST 可以直接转成 Calcite Operator Tree
   • 使用 Volcano 优化 Calcite Operator Tree
   • 将 Calcite Operator Tree 直接转回 Hive Operator Tree。不同于第一阶段的 Calcite Operator Tree 转成 Hive AST

相关论文

1. Query Optimization for Massively Parallel Data Processing
2. Profiling, What-if Analysis, and Cost-based Optimization of MapReduce Programs
3. Optimizing Joins in a Map-Reduce Environment
4. Efficient and scalable statistics gathering for large databases in Oracle 11g
5. Estimating Distinct (Postgress SQL)
6. The History of Histograms

背景

Hive 优化的问题

Hive 将用户的Sql语句转化成AST，然后用于生成物理Operator Tree。所有查询优化都基于物理 Operator Tree。Hive将语义信息与Operator Tree分开。在计划生成期间提取语义信息，然后在下游优化期间经常查找这些信息。由于缺乏适当的逻辑查询计划以及语义信息和查询树分离，通常很难将新的优化添加到Hive。

Tez

Tez将MR范式推广到执行复杂的DAG任务。

Hive中的 Join 优化

Multi way Join

如果多个连接共享同一个连接key（即连接的主表是一个），那么这些连接都可以在一个任务中完成。

Common Join

就是最普通的join，相同的key会被发到一个reducer。

Map Join

在星型模型中使用，把所有的小表换存在内存中，小表会被存在hash表中，连接的key作为hash表的key，然后大表作为流。可以避免shuffle。

Bucket Map Join

如果map join的key是分桶的，那么在join的时候，就不会把整个小表换存在内存中，仅是对应的分桶会被缓存。

SMB Join

SMB Join是对Bucket Map Join的优化，如果参加join的key已经排好序了，那么就不用hash表了， 而是使用 sort merge join算法来替代。

Skew Join

如果数据有倾斜，那么hive会把倾斜的key分离出来做join，然后和其他的union在一起。

实现

CBO会分阶段引入hive

阶段一

优化：

• Join的顺序
• Join的算法

限制：

• Calcite CBO 仅用于 select 表达式

• 当有以下算子的时候，Calcite CBO 会失效：

  • Sort By

    局部排序不能用关系代数和 SQL 来表示。以后可能将 Sort By 作为一个表函数。

  • Map/Reduce/Transform

    不能直接将 Transform 转为关系代数。以后可能会将其作为表函数。

  • Cluster By/Distribute By

  • Table Sample

  • Lateral Views

  • UDTF

  • PTF

Caocite 相关的加强：

• 引入 Operators 来表示 hive 相关的 operator。包括 Table Scan，Join，Union，Select，Filter，Group By，Distinct，Order By。这些算子将实现一个具有物理成本的调用约定。
• 引入了将 CommonJoin 转为 MapJoin，MapJoin 转为 BucketJoin，BucketJoin 转为 SMBJoin，CommonJoin 转为 SkewJoin的规则。
• 引入了用单个 Join 来替代多路 Join 的规则。
• Hive 中的 Merged-Join 将被转化成 Calcite 中的 MultiJoinRel。

阶段二

Calcite 相关的加强：

• Join 的顺序基于直方图
• Join 的算法选择基于直方图的估算

阶段三