作者：开七

一、前言

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 性能优化是数据开发人员的必备技能，降低成本同时也能让乏味的工作有一丝丝乐趣。