sqoop抽取数据到hive，mapreduce任务卡主问题解决

问题现象：

sqoop任务调度起来后没有关注运行结果，5天后发现这个任务没有报错信息并且在yarnui上可以看到任务还在运行，查看详细信息发现map任务已经运行到100%，reduce任务0%，map任务运行状态是running；

处理过程：

查看mapreduce任务日志
- 首先通yarnui上查看application的日志，发现日志还没有聚合，看不到有用信息
- 然后到后台通过yarn logs命令查看applicationId的日志，发现和ui的日志信息是一样的。
- 看不到日志就没法定位问题，于是继续到ui上查看任务运行的container信息，找到containerid和container运行所在的节点信息，然后到这个节点上查看nodemanager的日志，在nodemanager的日志中搜索containerid，发现这个container有这样一行日志信息:Skipping monitoring container container_xxx since CPU usage is not yet available打眼一看，这不是没有获取到资源吗，为什么会没有获取到资源呢，yarn队列满了吗？去yarnui上看下，发现资源很充足。
- 这不是让人犯难了吗，去问问度娘，度娘说需要配置yarn-site.xml，感觉这不适用于我，因为集群中其他任务运行的好好的呀。于是继续问度娘，问了好久没有发现有用答案，于是开始掉头发了。

重启大法
- 搞了半天没有头绪，基于CPU usage is not yet available这个信息，我决定运用重启大法。生产环境重启yarn集群有什么影响？
  - 目前集群上正在运行的任务大概有20多个，yarn重启完成后任务会自动拉起运行，这个影响不大。
  - 万一yarn重启失败怎么办？相信光，相信电，相信yarn,重启！
- yarn顺利重启，于是乎跟客户说运行任务的时候没有获取到资源导致的任务卡住，你看日志：“since CPU usage is not yet available”。客户欣然接受。然后重跑一下任务。我心想都用重启大法了，应该没啥问题，毕竟其他任务都在顺利运行着。
- 但是心里并不踏实，于是时刻盯着yarnui，发现任务提交上来之后，立刻去看nodemanager的日志，发现重跑的container还是有CPU usage is not yet available的日志打出。FUC~K！

埋头苦干：

重大局出发，着眼于细节；
- 首先分析一下sqoop任务，sqoop抽取关系型数据库到hive中，整个流程应该是通过jdbc拉取数据库中的数据，然后把数据临时存放到--target-dir目录下，最终将数据同步到hive中；
- 看下sqoop任务配置，没有啥问题，但是-m设置的是1，也就是只启动一个map任务，嗯~~~，会不会是数据量比较大，一个map任务受不了导致的；于是到yarnui上看下目前正在运行的container在哪个节点上，然后通过ps -es | grep attemp_xxx找到这个map进程id；
- 找到map进程后，首先看下是不是GC导致的任务卡住，使用jmap -heap pid命令发现输出信息中年轻代占用75v%，老年代45%，看来堆内存是没有问题的;
- 是不是线程死锁导致的呢？于是切换用户，执行jstack pid查看map任务的线程信息，发现写hdfs文件的进程是waiting状态，读取关系型数据库的进程也是waiting状态，嗯~~~是不是边从关系型数据库拉取数据边写入hdfs数据呀；
- 到yarnui上查看task任务的counter，发现counter页面上，map input record一直在增大，每秒钟大概三四百条的样子，hdfs写入字节也一直在增加，于是执行hdfs dfs -tail 命令看下hdfs正在写入的文件，发现确实是在一条一条的写入数据；
于是乎告诉客户，数据正在写入，每秒钟xxx条，大概需要xxx时间写完，如果想快点，可以通过-m指定并行度，当前并行度是1。

总结：

头发掉了不少，问题也不明不白的解决了，从头到尾只有两步操作，重启yarn集群，重跑任务；是重启yarn集群起作用了还是重跑任务起作用了？重启之前没有静下心分析任务卡住的点，导致本次问题处理不够完美。