【SQL】MaxComputer中调试与问题排查技巧小结

1.分段调试

　　面对长的SQL，出错时一般直接看定位的行号，有时候不出错但是没数据时，应该尝试分段调试，很长的SQL嵌套很多的子查询时，一个一个子查询进行分别调试，看哪一步子查询出了问题，层层推进

　　通常情况下，日志都是很重要的指示。有时候一些莫名其妙的错误时，错误信息看得懂却始终调不通时，不妨尝试查看运行的日志（例如相关的设置项，系统解析出来运行的SQL等）

　　logview：ODPS的Debug工具

　　一般在运行节点时日志会打印出Logview：

　　当然，Logview其实是有规律的，通过参数分析也能得到instanceID等信息。如果有时候出现如下权限的现象：

　　使用命令wait instanceID即可！

　　Logview页面参数简介：

　　其他显而易见的就不赘述了，task字段比较容易理解，不再赘述：

　　Diagnosis就是诊断信息（包括资源诊断，长尾诊断）

　　我们重点关注的就是detail，task类型讲解参见本文第4点。

　　任意展开一个Instance：

需要关注的参数的介绍：

　　还有需要注意的是Logview系统只保留7天，7天之后还想分析需要先保存，再上传进行查看：

　　logview诊断方法：

　　　　（1）错误：这个通过控制台的日志或者Logview的result错误代码和错误提示，相对排查比较直观

　　　　（2）慢任务排队：这个可以通过logview的status查看排队状态，通过show p 查看所有Instance，通过top instance查看当前正在执行的作业信息

　　有时候比如一些表连接操作等一直连接不上，语法日志方面又没问题但就是没数据，那不如取出几条样本数据来比对，看到真实数据有时候可以比较直观的看到问题所在

常见MaxComputer错误：

　官方文档参考：https://help.aliyun.com/document_detail/51020.html?spm=5176.10695662.1996646101.searchclickresult.65ac2d43zPlfxk

　　　　　　　　https://help.aliyun.com/video_detail/91702.html?spm=5176.11065259.1996646101.searchclickresult.300e2edfH6w6qH

　1.切入点：logview

　　　　通过details可以定位长尾的位置：

// task类型：

在每个Task中，可以看到Task的名字，对于M1，表示这是一个Map task，R5_4中的4表示它依赖J4执行结束才能开始执行。同理，J4_1_2_3表示Join4这个阶段要依赖M1、M2、M3三个task完全成才能启动运行。

　　2.常见解决方案

　　·经典word_count的长尾：

SELECT a.key
    , COUNT(*) AS cnt
FROM  a
GROUP BY a.key

　　使用groupby参数，进行热点Key的打散：

set odps.sql.groupby.skewindata=true

　　此方法仅对长尾问题比较严重的有效！（分钟级内慎用！）

　　DISTINCT长尾：

　　　　DISTINCT不会再shuffer进行一次聚合操作，会全部传入给reduce进行处理！相对没有group by效率高！

　　　　采用去重统计的办法：

--原始SQL,不考虑Uid为空
SELECT COUNT(uid) AS Pv
    , COUNT(DISTINCT uid) AS Uv
FROM UserLog;

　　　　一个方式是改写，把DISTINCT改成普通的COUNT：

SELECT SUM(PV) AS Pv
    , COUNT(*) AS UV
FROM (
    SELECT COUNT(*) AS Pv
      , uid
    FROM UserLog
    GROUP BY uid
) a;

　　　　如果发现是特殊值引起的长尾（例如NULL特别多），则可以考虑先过滤再处理

　　动态分区长尾：

　　　　通过关闭reshuffer参数（默认开启的），来取消减少rudece的个数

　　JOIN长尾：

　　　　首先考虑能不能用mapjoin；

　　　　第二考虑分而治之，因为长尾原因就是热点KEY太多，把热点KEY通过GROUP BY 、ORDER BY找到后，将他们分开处理；

更多请参考社区文档与官方文档！