loader任务运行时间长

版本：C70SPC200
问题背景：太保那边有一个loader任务，从hive导出数据到mysql中的，运行了一周，还是没有完成

查看AM日志中，一直有认证的输出打印，太保就怀疑有可能是不是一直重复认证导致任务运行时间长。

首先否定是重复认证导致任务运行时间长的问题。AM日志中认证代表任务一直在运行，是正常的，任务的运行时间与实际的数据量和GC时间有关系。
然后收集loader的json任务文件，将loader任务跑到我们本地，复现下，我这边测试没有问题。
然后就需要收集他们那边的loader日志了，首先进入loader，点入日志进入yarn相关的页面，查询到这个loader任务起了100个map任务，大多数map任务都是很快就变为success了，但是还有7个map任务一直在运行



查看这7个map任务，一直处于running状态，查看还在不断read数据，说明任务还在运行，之后点进去查看该map任务的日志，发现如下报错：



查看貌似是mysql连接时间过长，报错了，导致loader的map任务一直处于运行中。
发现了可能是mysql的问题之后，就让他们替换mysql的驱动，替换驱动之后还是运行慢。
于是kill掉这个loader任务，重新执行了这个loader任务，然后打印这个map进程的jstack，查看一直是在运行中的，然后过一两天后又重复上面的错误。



然后观察这些map任务的运行数据量，最开始这个map任务读取的数据量是61347515行


过几天，这几个单独的map任务还在运行，查看还在继续读取数据行，目前是122350318行，任务是没有停止的


排查数据倾斜的原因，是hive表中，hdfs的路径下，有许多空文件，导致有些map任务处理的数据比较小，有些map任务处理的数据比较多，导致任务数据倾斜。
1.针对分区表，loader任务会根据分区的数量来划分map的数目。
2. 对于非分区表，loader任务通过hive分片数目进行划分map，当分片数目大于设置的map数目，会进行取模的操作。
3. 查看hive表目录下文件的大小，数据文件大小分配不均，大多数文件大小为0，且文件大小之间存在量级的差距。确认loader任务数据倾斜的原因为hive表下数据文件大小不均，导致map任务处理数据不均。
然后建议他们调整hive表目录下文件大小，文件大小分配均匀，避免出现数据倾斜，对于大小为0的文件建议删除。

创建hive2sftp的作业，执行任务，55s内所有的数据导出完成，可以确认数据读取正常，排除hive表的问题，怀疑mysql数据导出存在异常。


在集群内部ping mysql服务器所在的节点，网络存在很大延迟，可以确认确实是由于网络延迟到最后数据导出慢。

1：先排查是否是数据倾斜

2：创建中间任务来排查是源头还是目标端有问题

3：排查相关链接的网络情况