问题
早上巡检一个800节点的CDH集群，版本为5.13发现集群很多报错如下
而且还在增加，遇到文件描述符问题，一般都是yarn的job问题，于是登到相关报错的几台机器上执行top命令查看对应的pid
再执行ps -ef｜grep 那个pid号，然后查看appellation信息，分别在几台机器上查找，定位在这些机器上共同运行的job
结果定位如下job，并通知数据开发整改。
下面列举了部分问题与解决方案
reduce task数目不合适
shuffle磁盘IO时间长
map|reduce数量大，造成shuffle小文件数目多
序列化时间长、结果大
单条记录消耗大
collect输出大量结果时速度慢
任务执行速度倾斜
通过多步骤的RDD操作后有很多空任务或者小任务产生
Spark Streaming吞吐量不高
Spark Streaming 运行速度突然下降了，经常会有任务延迟和阻塞
1、reduce task数目不合适
解决方案：
需要根据实际情况调整默认配置，调整方式是修改参数spark.default.parallelism。通常的，reduce数目设置为core数目的2-3倍。数量太大，造成很多小任务，增加启动任务的开销；数目太小，任务运行缓慢。所以要合理修改reduce的task数目即spark.default.parallelism
2、shuffle磁盘IO时间长
解决方案：
设置spark.local.dir为多个磁盘，并设置磁盘的IO速度快的磁盘，通过增加IO来优化shuffle性能；
3、map|reduce数量大，造成shuffle小文件数目多
解决方案：
通过设置spark.shuffle.consolidateFiles为true，来合并shuffle中间文件，此时文件数为reduce tasks数目；
4、序列化时间长、结果大
解决方案：
spark默认使用JDK 自带的ObjectOutputStream，这种方式产生的结果大、CPU处理时间长，可以通过设置spark.serializer为org.apache.spark.serializer.KeyoSerializer。
另外如果结果已经很大，那就最好使用广播变量方式了，结果你懂得。
5、单条记录消耗大
解决方案：
使用mapPartition替换map，mapPartition是对每个Partition进行计算，而map是对partition中的每条记录进行计算；
6、collect输出大量结果时速度慢
解决方案：
collect源码中是把所有的结果以一个Array的方式放在内存中，可以直接输出到分布式的文件系统，然后查看文件系统中的内容；
7、任务执行速度倾斜
解决方案：
如果数据倾斜，一般是partition key取得不好，可以考虑其他的并行处理方式，并在中间加上aggregation操作；如果是Worker倾斜，例如在某些Worker上的executor执行缓慢，可以通过设置spark.speculation=true 把那些持续慢的节点去掉；
8、通过多步骤的RDD操作后有很多空任务或者小任务产生
解决方案：
使用coalesce或者repartition去减少RDD中partition数量；
9、Spark Streaming吞吐量不高
解决方案：
可以设置spark.streaming.concurrentJobs
10、Spark Streaming 运行速度突然下降了，经常会有任务延迟和阻塞
解决方案：
这是因为我们设置job启动interval时间间隔太短了，导致每次job在指定时间无法正常执行完成，换句话说就是创建的windows窗口时间间隔太密集了；
