作者：开七 蚂蚁集团数据技术专家
本文围绕 hash cluster 表运用及 Shuffle 进程原理进行评论，欢迎各位开发者参加大数据核算 MaxCompute 社区：developer.aliyun.com/group/maxco…
概述
蚂蚁的转化归因在初期运转两个多小时的情况下，进行了一系列优化，其间树立hash cluster表及强制hash相关及Shuffle的手动干预进行remove操作此部分优化占了较大比重。本文则主要叙述hash cluster表的一些运用。
Hash cluster表具有两个效果：
-
存储预排序的重排紧缩。Hash cluster表选用分桶排序操作，若相同的值重复度高，则能够到达更好的紧缩效果。
-
下流使命的Shuffle Remove。Hash cluster表因为选用对指定字段分桶操作，下流若一些相关、聚合操作与分桶键战略相同，则会进行Shuffle Remove操作。MaxCompute操作中，Shuffle是贵重的，因而有必要在优化阶段尽可能移除不必要的Shuffle。什么情况下能够移除Shuffle？简略来说便是数据本身现已具有某些数据分布特性，刚好这个数据分布特性满足了上游算子对这份数据的分布要求，就不需求再做Shuffle，这个也是Hash cluster表的重要应用场景。
前语
转化归因使命加工相对较复杂，在此对其间关键过程做个说明：
1、源头分三部分，拜访日志数据A，点击日志数据B，接入的事情数据C，此三部分数据表已设置为4096分桶的hash表。
2、以上三部分数据以用户进行分组，分别传入用户的点击、拜访和事情数据，通过udf处理得到单用户的归因成果数据（以字条串返回）。
3、返回以用户粒度的成果数据进行字段拆分后以用户的事情id进行胀大，胀大后相关用户事情数据弥补事情数据后其它字段。
4、上一步相关后的成果数据以日志id进行胀大，胀大后的数据相关拜访和点击日志数据得到日志中的其它一些弥补字段。
以上过程按单用户数据处理进程流程大致如下：
图(1)
以付出宝付出线来讲，开始总计运转两个来小时，加工逻辑过程有近十来个使命。后续进行了udf优化并逻辑兼并为一个script，图2右部分。
图(2)
图(3)
优化进程
中间状况
以下使命是在通过多使命兼并为一script使命后内容，其间源头输入表点击(mid_log_clk_xxxx_di)和拜访(mid_log_vst_xxxx_di)表树立hash cluster，而事情表是以事情代码为二级分区的一般表（事情表是通过页面通过不同的事情码在线接入后生成不同的使命产出的表），以付出线为例，使命改造后稳定在半小时左右，但现在跟着事情添加有所添加。
点击拜访建表主要内容
CLUSTERED BY (user_id ASC) SORTED BY (user_id ASC,log_id ASC) INTO 4096 BUCKETS
全体运转图如下，比较原来十来个使命，无论是日常运转、历史回刷都变的相对简练。
图(4)
在此进程中个人剖析若事情输入表能在运转进程中变hash cluster的话，那下流按理可再削减一些Shuffle操作，测验对事情表添加 DISTRIBUTE BY user_id SORT BY scene_type,order_id 操作且设置参数set odps.sql.reducer.instances=4096，但测验发现下流对此无感知，联系MaxCompute 开发人员得知现在暂无此功用。
接入事情hash表不能在运转中得到那只能再添加一个使命把事情数据刺进一cluster表供使命运用，但因为在主链路上，添加的时刻影响全体产出时刻，但以付出线几个亿数据量为例，刺进cluster表全体3分钟左右，树立cluster后全体履行图如下：
图(5)
以上履行图现已相当简略，运转速度比较原来使命及添加的上游全体也有必定的提升，但是发现两主task中，m3和m4同样都是4096实例，都是按用户分桶进行的分发，按理此两M应该是能够Shuffle remove进行兼并的，问及MaxCompute开发人员大致是一些复杂操作后属性丢掉后不能消除Shuffle。
终究状况
虽然图5的履行方案相对来说现已十分简练，但一些实践成果与认知不同时总想找到问题出在哪里。因而，我对使命中的一些sql嵌套进行层次削减，对一些相关先拆解再渐渐添加，在此进程中发现添加了一个小表的mapjoin会导致下流需求进行Shuffle（理论上小表mapjoin不影响主表分发），其间一个黑名单列表，数据量少且近三年都无添加数据，因而直接改造为固定值传入，另外一个小表在终究再进行mapjoin相关，终究履行图如下，只有一个主的task，十分简练。
图(6)
以下为m2中的算子，十分复杂，但无需Shuffle履行效率十分高。
图(7)
履行成果
终究履行时长不到20分钟，相对原先削减一半，而且消耗的cu及内存都有所下降，转化归因全体链路产出提早20分钟+。
图(8)
图(9)
总结
1、本文的一些优化全体是基于 Hash Clustering Table的树立，在创建Hash表时需求考虑分桶键的设定，并不是说必定要所有的相关键设置为分桶键，在考虑Hash的一些使命功能的同时，也需求考虑表的存储紧缩巨细。
2、针对MaxCompute渠道的一些战略原理，首要需求有自己的一些本身认知，许多时候不必定是一两个文档能够说清楚，更需求一些实践的测验来加深知识点的了解。
3、MaxCompute许多方面现已十分智能及高效，期望在自动的优化方面能够愈加智能 。
【 MaxCompute发布免费试用方案，为数仓建设提速 】新用户可0元收取5000CU*小时核算资源与100GB存储，有效期3个月。 当即收取>>
