第二篇一次查询

问题：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,最后运行结果还正确么？