Hive学习之连接查询优化（二）

星型连接增强功能

        Hive-0.11.0中优化器的增强功能专注于星型模式配置中连接的有效处理。星型模式连接的初始化工作是受限制的，在该模式中所有维度表在过滤和投影后在同一时间装入内存。一部分维度表装入内存的场景还未实现。连接查询优化可以被分为三部分：

当使用MAPJOIN时，在只有map的一个作业中执行操作符树中的map连接链。
 自动转换情况的扩展优化（在优化时生成合适的备份计划）。
完全在任务端产生内存中的哈希表（将来工作）。
       下面分别描述这些优化器的增强功能。

Map连接链的优化

       下面的查询在执行时将产生两个只有map的作业：

select /*+ MAPJOIN(time_dim, date_dim) */ count(*) from
store_sales
join time_dim on (ss_sold_time_sk = t_time_sk)
join date_dim on (ss_sold_date_sk = d_date_sk)
where t_hour = 8 and d_year = 2002

       对于小的维度表来说，很可能两个表需要同时装入内存，这样会显著地降低执行该查询的时间，因为事实表只被读取一次而不是读取两次然后写入HDFS以用于作业之间的通信。目前已经实现和将来要实现的优化有：

合并M*-MR模式到一个MR中。对于小的维度表来说，很可能两个表需要同时装入内存，这样会显著地降低执行该查询的时间，因为事实表只被读取一次而不是读取两次然后写入HDFS以用于作业之间的通信。目前已经实现和将来要实现的优化有：
当可能时，合并MJ->MJ模式到一个MJ中。
 合并MJ*模式到一个map阶段，做为MJ操作符的一个链（目前还未实现）。
       如果hive.auto.convert.join为true（默认为true），优化器不仅将连接转换为map连接，还会尽可能地合并MJ*模式。

自动连接转换的优化

       当启用自动连接后，就不再需要MAPJOIN提示了。自动连接选项可以使用下面的参数配置：

set hive.auto.convert.join.noconditionaltask = true;
set hive.auto.convert.join.noconditionaltask.size = 10000000;

       第一个参数的默认值为true，意味着自动转换已经启动。第二个参数控制多大的表可以放进内存，默认值为10000000L（10M），该值表示可以被转换为哈希映射的表大小的总和。目前，连接中的n-1表必须放进内存以使map连接优化生效，没有检查来确认表是否被压缩为一个和表的可能大小是多少。该假设在结果集上的影响将在下一节讨论。例如上面的查询改为：

select count(*) from
store_sales
join time_dim on (ss_sold_time_sk = t_time_sk)
join date_dim on (ss_sold_date_sk = d_date_sk)
where t_hour = 8 and d_year = 2002

       如果表time_dim和date_dim的大小符合上面参数配置的值，两个连接转换为map连接。如果两个表大小之和符合上面参数的值，连个map连接合并为一个map连接。这减少了MR作业的数量，并显著地增加了该查询的速度。

       外连接提供了更多的挑战。由于map连接操作符只能流过一个表，被流过的表需要是所有的行都被要求的表。对于左外连接，是join左侧的表；对右外连接，是join右侧的表。这意味虽然内连接可以被转换为一个map连接，但外连接不可以。如果除了被流过的表，其它表满足配置参数设置的大小的话外连接可以被转换。全外连接不能被转换为map连接，因为所有的表都需要以流的方式读取。

       对于条件连接，如果一个小的别名的输入流可以直接应用于join操作符而不需要过滤或者投影，那么不需要通过MapReduce的本地任务在分布式缓存中提前执行。可以设置hive.auto.convert.join.use.nonstaged为true避免提前执行。

       目前自动连接转换的优化为：尽可能多的将MJ操作符分到一个MJ中。如果不同map连接操作符中的表大小的总和在hive.auto.convert.join.noconditionaltask.size参数的限制内，这些MJ操作符合并在一起，这将确保这些查询的更大加速。

       Sort-Merge-Bucket(SMB)连接也可以转换为SMB map连接，SMB连接在表是排序和分桶的情况下使用。连接归结为仅合并已经排序的表，导致该操作比普通的map连接更为迅速。然而如果表是分区的，将会减速因为每个mapper需要某个分区的非常小的块。下面的配置启用了将SMB转换为map连接的SMB：

set hive.auto.convert.sortmerge.join=true;
set hive.optimize.bucketmapjoin = true;
set hive.optimize.bucketmapjoin.sortedmerge = true;
set hive.auto.convert.sortmerge.join.noconditionaltask=true;

       下面的参数用于设置大表的选择策略：

set hive.auto.convert.sortmerge.join.bigtable.selection.policy= org.apache.hadoop.hive.ql.optimizer.TableSizeBasedBigTableSelectorForAutoSMJ;

       默认情况下，选择策略为平分分区大小。相对于哈希和流，大表的选择策略有助于决定选择哪个表仅用于流。可用的选择策略有：

org.apache.hadoop.hive.ql.optimizer.AvgPartitionSizeBasedBigTableSelectorForAutoSMJ (default)
org.apache.hadoop.hive.ql.optimizer.LeftmostBigTableSelectorForAutoSMJ
org.apache.hadoop.hive.ql.optimizer.TableSizeBasedBigTableSelectorForAutoSMJ

在任务端生成哈希表

       未来的工作将使完全在任务端生成内存中的哈希表成为可能。在客户端生成哈希表（或者为多个连接生成多个哈希表）是有缺点的（客户端指运行Hive客户端并提交作业的主机）：

数据局部性：客户端通常不是DataNode，所有被访问的数据都是远程且必须通过网络读取。
技术参数：运行该进程的主机的技术参数是不明确的，可能存在内存、硬盘或者CPU限制。
 HDFS上传：数据必须通过任务节点使用的分布式缓存传回到集群并被复制。
       在客户端机器上预处理哈希表也有一些优点：

存储在分布式缓存中数据很可能比原表小（过滤和投影）。
使用分布式缓存在任务节点上直接加在哈希表意味着缓存中的大对象可能降低使用MAPJOIN的机会。
       当哈希表完全在任务端生成时，所有的任务节点都必须访问原有数据源以生成哈希表。虽然在正常情况下将会并行处理并不会影响延迟，但是Hive有存储处理器的概念并且可以让许多任务访问相同的外部数据源（HBase，数据库等），这可能压垮或降低数据源。