一些MaxCompute日常优化案例分享

原创开七阿里云开发者

阿里妹导读

MaxCompute优化是一个多样而又重要的过程，优化过程需要能够深入理解ODPS的工作原理和内部机制，本文总结了以下几个日常优化案例，最终优化手段可能非常简单，但其中的分析过程较为重要，希望对大家有所启发。

前言

MaxCompute优化是一个多样而又重要的过程，优化过程中若能够深入理解ODPS的工作原理和内部机制，才能够更明确的发现运行过程中存在的问题，这样才能更有针对性地进行优化，优化需要不断思考和尝试不同的想法和方法，适当的时候我们可以寻求平台技术人员帮助，以找到最适合的优化方案。

以下通过日常几个优化案例，最终优化手段可能非常简单，但其中的分析过程较为重要，希望对他人有所启发。

一、dmj针对多union的一种优化

任务内容：多个表union all 后对其中的一些表进行distmapjoin关联。

任务线上经常报内存不够，以往处理基本是增加内存，内存到8192后则增加shard_count数量来减少内存使用，此种治标不治本的手段无法根治问题，仔细分析执行任务图发现，其中对应的加工逻辑有多个union all +distmapjoin，导致不合理的执行图如下:

图中可以看出一份数据对应4次分发（主表有union all四份数据），个人分析一个distmapjoin对应多路分发不合理，合理应该分发一份，但个人无法处理，寻求平台人员：

经测试此参数无效，平台人员给出另一参数。

关键参数：

set odps.optimizer.union.split.enable=false;

效果：执行图变的更加清爽，相对原来30步变为21步。

修改前资源消耗：

修改后资源消耗：

小结

由于消除了union all对应同一表多个distmap分发，最终运行cu及内存都减少一大半，整体运行稳定性提高。但我们开发任务时还是尽量不要加各种参数，去参数化也是平台人员的优化方向。

btw:关于参数设置带来收益问题可能很多人会有疑问，为什么平台不直接默认这些参数的合理设置，因为很多坏例子平台人员看到了而我们没有感知。当把这些坏例子消除则参数就不需要设置。

二、一个json解析参数的优化

前几天在针对一些计算资源较大任务排查时发现一任务曝光任务，任务整体执行一个小时，执行计划较简洁。

一千四百亿数据量运行一小时也问题不大，但当点击执行图中M5的详细内容如后

发现除读写外，project1算子占比64%(时间都花在这了)，而且发现里面内容get_json_object调用9次，时间应该就是花在此处，记得多个get_json_object现在平台会自动转化为GET_JSON_OBJECT_TUPLE，但此处的确没有。因此任务增加参数

set odps.sql.udf.getjsonobj.new =true;

查看第二天任务运行情况，已转为GET_JSON_OBJECT_TUPLE批量取数，且project1算子占比出变成34%。

效果：

执行时间对比：

加参数前：

加参数后：

整体可以看出，加参数前平均实例由15分钟变成7分钟，计算cu及内存将近下降一半，效果非常显著。

小结

优化的过程往往都不是什么高大上，建议正确的技能认知、有意识的发现及定位问题，解决问题可能就非常简单。

三、一个去group by 操作的优化

一位同学咨询一个问题，由于数据量特别大，里面涉及数据膨胀且最终group by做汇总，整体消耗非常大，但发现group by前后数据量只有微小变化，因此沟通是否可以剔除group by操作。

而且此数据是先膨胀后，里面有非常多的字段行间是相同的，因此增加重排可能会有较好效果，因此建议同学对sql进行改写

最终结果：

存储：

此处数据量由600亿变900亿不是因为剔除了group by操作，是因为当天业务量增长的变成造成，但可以看到，由于增加了局部重排，存储减少非常多。

时间：

小结

很多时候group by 操作是否必要有业务要求，但也应该关注数据量的变化，一般情况需要考虑指数级别的数量减少，另外优化需要结合着多种手段，此处增加事中重排，存储减少带来收益的同时，下游读表的资源也将大大减少。最后的最后，若表只是简单map操作，那就变成简单加工，就应该考虑干掉这个任务或者视图替代了。

总结

odps性能优化是数据开发人员的必备技能，降低成本同时也能让乏味的工作有一丝丝乐趣。

继续滑动看下一个