full outer改写left anti join实践( 二 )

原来的full outer jionleft anti join初始化原来的full outer jionleft anti join第二天以后时间消耗8h30min38s1h4min48s7h32min30s32min30scpu消耗29666.02 Core * Min65705.30 Core * Min31126.86 Core * Min30589.29 Core * Minmem消耗109640.80 GB * Min133922.25 GB * Min114764.80 GB * Min65509.28 GB * Min
可以发现hash cluster分桶操作在初始化有额外的开销，主要是按主键进行散列和排序，但是这是值得的，可一劳永逸，后续的读取速度非常快。以前每天跑需要8小时，现在除了分桶初始化需要1小时，以后每天实际只需要30分钟。
初始化执行图
图1：

本文插图

M2是读全量表。
M4是读取增量表,在场景2的模型中增量表被读取了两次，其中：R5_4是对主键去重（row_number）后用于后面的union all ，里面包含了所有的增量数据；R1_4是对主键去重（row_number）后用于left anti join ，里面只包含了主键。
J3_1_2是left anti join,将它展开后看到这里还是有mergJoin ，但是这只是初始化的操作，后面每天就不会有了。展开后如图2 。
R6_3_5是将增量和全量进行union all ，展开后如图3 。
R7_6则是将索引信息写入元数据，如图3的MetaCollector1会在R7_6中sink 。因此：图1中除了R5_4和R1_4是去重必须的，有shuffle 。还有J3_1_2和R6_3_5这两个地方有shuffle 。

图2：

本文插图
图3：

本文插图
第二天以后的执行图
图1：

本文插图
同上，图1中的R3_2和R1_2是对增量去重必要对操作，有shuffle ，这里忽略。
初始化执行图的J3_1_2和R6_3_5已经被合并到了M4_1_3 ，将其展开后如图2 。即left anti join 和 union all这两步操作在一个阶段完成了，且这个阶段是Map 任务（M4_1_3），而不是Join任务或Reduce任务。而且全量表不在单独占用一个Map任务，也被合并到了M4_1_3 ，因此整个过程下来没有shuffle操作，速度提升非常明显。也就是说只需要一个M4_1_3就能完成所有到操作，直接sink到表。
R5_4则是将索引信息写入元数据，如图2的MetaCollector1会在R5_4中sink 。
图2：

本文插图
作者：阿里菜鸟 - 数据鹤方
本文为阿里云原创内容，未经允许不得转载。