共计 2325 个字符，预计需要花费 6 分钟才能阅读完成。
作者：开七 蚂蚁团体数据技术专家
本文围绕 hash cluster 表使用及 Shuffle 过程原理进行探讨，欢送各位开发者退出大数据计算 MaxCompute 社区：https://developer.aliyun.com/group/maxcompute
概述
蚂蚁的转化归因在初期运行两个多小时的状况下，进行了一系列优化，其中建设 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 进行收缩，收缩后的数据关联拜访和点击日志数据失去日志中的其它一些补充字段。
以上步骤按单用户数据处理过程流程大抵如下：
以支付宝领取线来讲，最后总计运行两个来小时，加工逻辑步骤有近十来个工作。后续进行了 udf 优化并逻辑合并为一个 script，图 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
整体运行图如下，相比原来十来个工作，无论是日常运行、历史回刷都变的绝对简洁。
在此过程中集体剖析若事件输出表能在运行过程中变 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 后整体执行图如下：
以上执行图曾经相当简略，运行速度相比原来工作及减少的上游整体也有肯定的晋升，然而发现两主 task 中，m3 和 m4 同样都是 4096 实例，都是按用户分桶进行的散发，按理此两 M 应该是能够 Shuffle remove 进行合并的，问及 MaxCompute 开发人员大抵是一些简单操作后属性失落后不能打消 Shuffle。
最终状态
尽管图 5 的执行打算相对来说曾经十分简洁，但一些理论后果与认知不同时总想找到问题出在哪里。因而，我对工作中的一些 sql 嵌套进行档次缩小，对一些关联先拆解再缓缓减少，在此过程中发现减少了一个小表的 mapjoin 会导致上游须要进行 Shuffle（实践上小表 mapjoin 不影响主表散发），其中一个黑名单列表，数据量少且近三年都无减少数据，因而间接革新为固定值传入，另外一个小表在最初再进行 mapjoin 关联，最终执行图如下，只有一个主的 task，十分简洁。
以下为 m2 中的算子，非常复杂，但无需 Shuffle 执行效率十分高。
执行后果
最终执行时长不到 20 分钟，绝对原先缩小一半，而且耗费的 cu 及内存都有所升高，转化归因整体链路产出提前 20 分钟 +。
总结
1、本文的一些优化整体是基于 Hash Clustering Table 的建设，在创立 Hash 表时须要思考分桶键的设定，并不是说肯定要所有的关联键设置为分桶键，在思考 Hash 的一些工作性能的同时，也须要思考表的存储压缩大小。
2、针对 MaxCompute 平台的一些策略原理，首先须要有本人的一些本身认知，很多时候不肯定是一两个文档可能说分明，更须要一些实际的测试来加深知识点的了解。
3、MaxCompute 很多方面曾经十分智能及高效，心愿在主动的优化方面能够更加智能 。
【 MaxCompute 公布收费试用打算，为数仓建设提速 】新用户可 0 元支付 5000CU* 小时计算资源与 100GB 存储，有效期 3 个月。 立刻支付 >>