记2018最后一次问题诊断-Spark on Yarn所有任务运行失败

　　2018的最后一个工作日，是在调式和诊断问题的过程中度过，原本可以按时下班，毕竟最后一天了，然鹅，确是一直苦苦挣扎。

　　废话不多说，先描述一下问题：有一套大数据环境，是CDH版本的，总共4台机子，我们的应用程序与大数据集群之前已经集成完毕，调试没有问题，可以运行Spark任务。而与这个集群集成是17年下半年的事了，这次升级后，发现无法正确的执行任务，不管是程序提交的还是用示例程序SparkPi，或者手动用spark-submit提交，都是执行失败，且Yarn框架调度执行两次。主要错误提示如下：

Diagnostics: java.lang.NoSuchMethodError: org.apache.commons.io.FileUtils.isSymlink(Ljava/io/File;)Z

截图如下：

sprak-submit提交客户端日志截图

yarn:8088任务监控页面任务（与上图不是一个任务，但错误信息一致）

　　其实，从任务日志错误提示，可以看出，肯定是加载了低版本的包，用了高版本的方法，NoSuchMethod异常再也熟悉不过了，这一点确信后，就需要找这个包在哪里？FileUtils类属于commons-io包，目前有1.4和2.4版本的，其中，1，4中的FileUtils类确实没有isSymlink方法。好了，基本可以确认，程序在使用了这个commons-io-1.4.jar包。

　　虽然问题确认，但是还是让人很头疼，因为我可以确认，我们自己的应用程序中，只用了2.4的包。为了排序一些常规影响，我们分别使用cdh自带的sparka提交、使用最简单的SparkPi来运行，但都运行失败，并且我还写了一个搜索类所在的包的工具，来运行排查问题。

package com.meritdata.search.tool;

import java.io.PrintStream;
import java.security.CodeSource;
import java.security.ProtectionDomain;

public class Utils
{
  public static void search(String name)
  {
    try
    {
      Class clazz = Class.forName(name);
      ProtectionDomain pd = clazz.getProtectionDomain();
      CodeSource cs = pd.getCodeSource();
      System.out.println(name + " location: " + cs.getLocation());
    }
    catch (Throwable e) {
      e.printStackTrace();
    }
  }
}

package com.meritdata.search.tool;

public class Search
{
  public static void main(String[] args)
  {
    String name = args[0];
    Utils.search(name);
  }
}

这是最先开始使用的代码，想验证当前任务加载的包是不是有其他的版本，使用提交命令：

%SPARK_HOME%>.inspark-submit.cmd --master --deploy cluster --files hive-site.xml --class com.meritdata.search.tool.Search search.tool-0.0.1-SNAPSHOT.jar org.apache.commons.io.FileUtils

这个任务运行的结果，打印的是commons-io-2.4.jar。确认后再想，是不是其他地方引用，而这个demo比较简单，没有使用到，因为加载顺序不一样，可能会影响。所以，又完善了一下程序：

package com.meritdata.search.tool;

import java.util.Collections;
import org.apache.spark.sql.Dataset;
import org.apache.spark.sql.Encoders;
import org.apache.spark.sql.SparkSession;
import org.apache.spark.sql.SparkSession.Builder;

public class SparkDemo
{
  public static void main(String[] args)
  {
    try
    {
      SparkSession spark = SparkSession.builder().appName("SparkDemo").enableHiveSupport().getOrCreate();
      Dataset dataset = spark.createDataset(Collections.singletonList("test"), Encoders.STRING());
      dataset.show();
      spark.sql("SELECT explode(Array("a", "b", "c")) as v ").show();
    } catch (Throwable e) {
      e.printStackTrace();
    }

    String name = args[0];
    Utils.search(name);
  }
}

　　因为实际中，要使用spark，必须初始化SparkSession，这样运行完成spark的代码后，再看看打印的包名称。但是结果令人意外，在初始化SparkSession的时候，任务就异常了，错误信息如开头提示。这下，我终于确认，是Yarn服务加载了不该加载的jar包，这下，就要排查yarn加载的包了，除过应用自己，yarn还要加载默认的包，hadoop的，hdfs的，yarn的包，配置项为 yarn.application.classpath, 在CDH的配置界面可以搜索到，有默认配置，会加载hadoop的一些基础程序包。首先想到的是，肯定是这个路径下面加载了低版本的包，想清空试试运行，结果还不行，因为有默认值，不填写每用，后来才想到的，因为当时已经调试的懵逼了。

　　发现不过后，想着去服务器上面，看看那些地方都有1.4的包，使用搜索命令：

find / -name commons-io-*.jar -type f

　　搜索结果如图：

在大数据集群的某个节点搜索到的结果

　　从搜索结果来看，在cdn的jars下面有个1.4的包，我想，会不会是这样包引起的呢？但是，我在其他的环境中也发现这个包，不可能是这个包引起的，要不然，都得有问题。既然这个包没有影响，任务加载的包也是正确的，哪到底是哪里的影响了任务的执行？

　　此时，这个问题已经搞得人头疼，尝试了却没有发现问题，明明很简单，就包冲突，却无法解决。在领导的提示下，替换1.4中的FileUtils类，看看到底是不是这个包的问题，也不管了，只能试试了，司马当活马医。修改完成，打包，在四个节点搜索所有的1.4包，准备替换。

　　突然，发现了一个让人惊喜的意外，在大数据集群的某个节点，在Hadoop的子目录，搜索到了一个1.4的包，而且不是软链接。

　　从搜索结果可以看出来，在执行的时候，每个任务下临时目录会复制jar包，hadoop/lib/commons-io-1.4.jar就是这个原因，查看其他节点，均为有类似情况。毫无疑问，删除这个包，重启集群，执行demo，成功，终于松了一口气。不知道是什么原因导致，现场环境复杂，所以也没办法追究，也没有必要，问题出现，就得解决。其实，很早之前，就应该检查四个节点，这样的话，就不会在那瞎想，可以尽早的发现异常包。

　　由于是客户现场，调试不方便，同事也比较辛苦，在现场的滋味，我深有体会。问题虽然简单，但是对整理的了解和调试方法也是很重要的，否则，会做很多无用功。

　　仅此来纪念和告别2018的辛勤工作，2019继续奋发前行，让自己更强。

本文地址：https://www.cnblogs.com/flowerbirds/p/10205185.html