使用阿里云DataWorks进行数据处理的时候，有时候会遇到一个sql或pyodps（本质上还是转化为sql）执行很长的情况，这个时候有必要对代码进行性能优化。
一、打开ODPS运行评估报告
一个sql脚本执行完毕后，在运维中心的周期实例中右击该任务"查看运行日志"。
然后再找到如下链接即可打开日志的检测报告：
点击后显示如下：
可以看到该任务从13:33运行到16:04，运行了2个半小时左右，性能堪忧。
二、分析LogView的信息
我们对LogView的各部分信息分别进行说明。
1、运行DAG图
显示了整个SQL任务切分为MapReduce任务后的DAG图。
【名称含义】
M：map操作
R：reduce操作
J：join操作
【链路】
链路上比较粗的表示数据量比较大，比较细的表示数据量比较小。
2、任务节点详细信息
该部分展示了Map、Reduce、Join节点任务的详细信息。
IO Records：数据的条数
IO Bytes：数据的大小
Latency：节点运行时长
Failed/Terminated/ALL：节点的分区执行情况
3、某节点的各分区(partition)的任务执行情况
在这里可以查看下start_time：如果差异很大说明计算资源紧缺，依次抢占了计算资源。
三、优化方案
1、资源切换
如果之前使用的是公共资源，那么可以切换为独享资源
2、Hash clustering
将数据提前进行shuffle和排序，在使用数据的过程中，读取数据后直接参与计算。这种模式非常适合产出后 后续节点多次按照相同key进行join或聚合的场景。
当然生成hash clustering table本身也是有代价的，在生辰阶段会进行一次额外的shuffle。
执行方法示例：
alter table s_auction_auctions CLUSTERED by (acution_id) SORTED by (auction_id) into 1200 buckets;
3、设置任务执行时的map、reduce、join实例数
'odps.stage.mapper.num' : 1024
'odps.stage.joiner.num' : 2048
'odps.stage.reducer.num' : 2048
4、提早过滤不必要的数据
DAG中输入较多数据的节点（线较粗的），提早过滤没用的数据，让输入数据变少点。
