摘要：在MaxCompute中，Join操作符的实现算法之一名为"Hash Join"，其实现原理是，把小表的数据全部读入内存中，并拷贝多份分发到大表数据所在机器，在 map 阶段直接扫描大表数据与内存中的小表数据进行匹配。

        这是MaxCompute有关SQL优化器原理的系列文章之一。我们会陆续推出SQL优化器有关优化规则和框架的其他文章。

       本文主要描述MaxCompute优化器实现的Auto Hash Join的功能。

简介

       在MaxCompute中，Join操作符的实现算法之一名为"Hash Join"，其实现原理是，把小表的数据全部读入内存中，并拷贝多份分发到大表数据所在机器，在 map 阶段直接扫描大表数据与内存中的小表数据进行匹配。Hash join执行方式效率很高，但是要求小表数据足够小以便放到内存中，假如小表数据太大，则任务在执行过程中会报OutOfMemory错误。

      在MapCompute中，可以使用MapJoin关键字来实现Hash join，如下所示：

       但是这种通过使用hint的方式还是不够智能。另外对于query复杂的情况，用户很可能因为无法确定join的某一路数据量大小而放弃使用mapjoin。在最新的MaxCompute SQL 2.0中，基于代价的优化器（Cost Based Optimizer，CBO）包含了一个自动优化join为hash join的优化规则。

实现原理

       在CBO中会对所有的operator的cost进行估计，这个cost包含rowcount、cpu、内存等等。有了各个operator的cost，就能估计其对应输出数据量的大小,公式可以简单的认为是：data_size = rowcount * averageRowSize。有了dataSize之后，就可以很容易知道这个任务是否适合使用HashJoin，其判定方法就是计算各个parent operator的data size之和是否小于某个阈值。假如估算出的data size在阈值范围之内，则会产生一个包含HashJoin的计划。同时对于Join，CBO也会产生一个普通的包含MergeJoin的计划，最后在这两个计划中选择cost最小的作为最优计划。

简单说来，在CBO中是否选择HashJoin作为最优计划的步骤有两个：

1. Step1：估算join的输入数据量大小，判定是否产生一个包含HashJoin的计划

2. Step2：对比HashJoin、MergeJoin相关计划的cost，选择cost最小的计划作为最优计划

       举例，对如下sql进行优化：

       上述sql在CBO中会翻译生成如下operator tree:

       从上可以看到，join的parent operator有两个：

       其中id为1的project其输出记录数是4行，且其输出列只有1列（bad_tpch_customer表中有5列），估算其输出数据量，认为其适合使用HashJoin，因此其产生的计划中包含两种：

1. 计划1：HashJoin

===

2. 计划2：MergeJoin

       比较上述两个计划的cost，明显计划1的cost更小，因此选择包含HashJoin的计划1作为最优计划。

总结

       AutoHashJoin的一个很大的好处是能让用户免参与的进行这个优化，同时对于一些复杂的query也更有可能使用HashJoin。但是，因为CBO无法完美估计数据量，会出现误判从而导致任务OOM的情况。针对这种情况，MaxCompute也进行了相应的调整，对于CBO误判导致HashJoin OOM的任务会关闭HashJoin rule来重试。

       目前CBO中使用HashJoin的阈值比较保守，默认是25MB。主要原因是CBO对于数据量的估计有偏差，无法完美估计数据量，而估计不准的原因有两个：

1. 数据是压缩存储的，CBO拿到的statistics不准

2. CBO的估计算法有偏差

       这两个问题也是CBO致力解决的问题。

       作者：勿凡，阿里计算平台事业部数据研发工程师