阿里云MaxCompute使用总结1

1、任务处理时间过长

发现是Calc2这个算子处理时间过长，初步判断为数据异常或者MC的集群负载过高导致
排查步骤
1、需要详细的运行日志，找到对应运行的logview
通过logview分析


Offline Job is running，该状态就是作业一直在运行中，如果运行中没资源，会一直是该状态，比如高优先级作业抢占资源，导致部分fuxi instance 起不来，状态是ready，从Parallel Running Fuxi Instances 这里看到咱们的作业一直是一个并行度在跑
所以咱们能否提供一个这个实例前几日调度的一个logview，我们对比看下
您也可以到MC的控制台看下，昨天晚上资源的使用率，是不是满了，导致任务申请不到资源导致的

然后这个任务的优先级是9，就是最小的，一旦有资源会优先运行其他任务
然后需要排查集群资源使用情况，发现确实很高，但不是导致任务运行变慢的根本原因，查看logview怀疑是数据膨胀
避免join引起的数据膨胀，方法如下
比如：两个表 join，左表是人口数据，数据量很大，但是由于并行度足够，效率可观。右表是个维表，记录每种性别对应的一些信息（比如每种性别可能的坏毛病），虽然只有两种性别，但是每种都包含数百行。那么如果直接按照性别来 join，可能会让左表膨胀数百倍。要解决这个问题，可以考虑先将右表的行做聚合，变成两行数据，这样 join 的结果就不会膨胀了
目前有一个优化方式，就是增加并发set odps.sql.mapper.split.size=64 ，这样就会增加instance使用更多的资源来处理任务
https://help.aliyun.com/zh/maxcompute/use-cases/optimize-sql-statements?spm=a2c4g.11186623.0.i4

2、Left join 变成了inner join导致数据变少

select * from xxma1 a left join xxma2 b on(a.a=b.a) where a.a=2; left join
select * from xxma1 a left join xxma2 b on(a.a=b.a) where b.a=2; inner join
select * from xxma1 a left join (select * from xxma2 where xxma2.a=2) b on(a.a=b.a); left join

总结：sql优化器在保证结果正确的前提下可以自由的选择执行计划
query中有where过滤条件，对join的结果右表做过滤 ，通过join之后，join type会转成inner join
需要把右表的过滤条件放在子查询里面