- 如何来判断是否发生了数据倾斜问题：
可以根据Spark 的webUI 中的相关指标来判断
spark webUI中的stages 页面的中就是stage数量 ： 宽依赖数（shuffle 数量）导致宽依赖的算子数 +n（读取表的数量）
点击不同的stage 可以跳转到对应的task中的
查看每一个task的执行时间如何有明显的和其他的task的执行时间相差很大，以及一个查询任务一致卡在某个点跑了很久都没出结果就是数据倾斜了
数据倾斜的场景： 一个key对应了多个值 的情况
解决1设置配置：
set hive.groupby.skewindata=true
它使得计算变为了二个mr的过程
-
第一次mr第一个shuffle过程中partition时随机给key 进行标记， 使每一个key随机均匀分布到各个reduce 中去计算（预shuffle）
目的是为了将一个key对应很多值的情况解决掉
-
第二次mr做正常的shuffle
数据分布不均匀的问题再第一次mr中已经有很大的改善了
解决2：
1. AQE Skewedjoin
2. 广播join 加随机数打散
解决3：
hive中的小文件存储过多的危害
-
在计算时会对 每一个小文件启动一个map ， 很影响计算的性能， 以及磁盘的寻址时间
多个小文件情况处理：
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
-- 再map执行前合并小文件，减少map的数量
set hive.merge.mapfiles=true;
-- 在map-only 任务结束后合并小文件， 该参数的默认值也是true
set hive.merge.mapredfiles=true;
-- mr 任务结束后合并小文件，默认为false
set hive.merge.size.per.task=268435456;
单位byte -- 设置合并文件的大小
set hive.merge.smallfiles.avgsize=1677216;
单位字节 -- 当输出的文件平均大小 -> 小于我们设定的阈值时，程序就会单独启动一个独立的reduce task 进行文件的merge
顺便简单说一下广播变量的目的： 就是让集群的消耗降到最低
且其中的每一个executor 中有一个blockmanager （区块管理器）
