问题：sparksql用GROUPPING SETS同时做不同维度组合的聚合，原先刚刚好危险的在一个小时内跑完，又新加了两个维度，维度组合翻倍（大致30个组合），结果要聚合的数据量也翻倍了。。。每次数据量大于2T，导致倾斜严重，运行慢的问题。(注，图的笔记利用了两个很相同的查询，只是为了说明一下情况) 尝试改进1：用mr跑会不会更快？没有，mr跑了2小时，spark跑了1个半小时（参数相同，只是把sql语句在两个平台换了一下而已） 尝试改进2：加了很多参数，其实我也不是怎么理解，重点的如把小文件合并，结果并没有明显的改善： 加的参数： set yarn.app.mapreduce.am.command-opts=”-Xmx6000m”; set yarn.app.mapreduce.am.resource.mb=9000; set hive.merge.mapredfiles=true; set hive.merge.smallfiles.avgsize=64000000; set hive.exec.parallel=true; 尝试改进3：将grouppingset的多个聚合组分开计算，一个短sql算一部分，发现一个很奇怪的现象：短sql执行完应该就聚合好一个短sql查询数据的，但是似乎spark还是hive优化，把所有的groupping sets的分发数据都分发完，然后每有一个groupping set的sql,加200个worker。可是当某个短sql查询数据量大时，200个worker不够用，而且本意的优化也不能进行。 本来是想每小部分聚合完只剩20万条，再最后聚合很方便。 但事实是所有groupping set产出的不同key的数据全都产出，最后每次对groupping set的聚合有200个worker。 这里底层到底发生了什么？怎么搞清楚？ 尝试看hive的explain,但没什么进展。 groupping set的原理是把不同的聚合组拼不同的key,所以多一个聚合组，就多一倍数据，所以维度多，维度组合多，数据就膨胀的严重。（还可以确认一下） 尝试改进4：在短sql自己聚合外面再聚合一次，会完成每次短sql的聚合么？也没有。。。
所以，至此这个问题又引出了更多的问题。 然后，把这个代码打包运行，发现突然又运行的较快了。。。应该不是集群的问题，因为在同样的时间点试验过，两个表现不同。这件事不是第一次发生，这又是一个问题。
其他： 1、！！！一定根据业务需要对表裁剪查询： 不裁剪： 裁剪： 2、spark运行阶段的skip是因为之前运行成功了，所以skip. 3、spark有fail的task,最后运行结果还正确么？
