spark添加二方包导致依赖冲突排查

问题描述

近期发现了一个线上问题，本地启动byzer服务是正常的，但打好的docker镜像就是抛异常跑不起来，而前几天构建的镜像是正常的，初步定位到时新的发布导致的！于是经过了一系列痛苦的排查。

错误堆栈

看byzer-lang最近的提交记录都在30天前，显示不会是它的问题，于是根据日志研究。

7bafdda4df93] __MMMMMM__ Total jobs: 1 current job:1 job script:load modelList.`` as __output__ 
22/02/09 14:58:32  ERROR Executor: Exception in task 0.0 in stage 2.0 (TID 2)
java.lang.IllegalArgumentException: Illegal pattern component: XXX
at org.apache.commons.lang3.time.FastDatePrinter.parsePattern(FastDatePrinter.java:282)
at org.apache.commons.lang3.time.FastDatePrinter.init(FastDatePrinter.java:149)
at org.apache.commons.lang3.time.FastDatePrinter.(FastDatePrinter.java:142)
at org.apache.commons.lang3.time.FastDateFormat.(FastDateFormat.java:384)
at org.apache.commons.lang3.time.FastDateFormat.(FastDateFormat.java:369)
at org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:91)
at org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:88)
at org.apache.commons.lang3.time.FormatCache.getInstance(FormatCache.java:82)

报错xxx令人不知所措，一开始怀疑是modelList这个脚本在RestController执行的时候，携带了这个xxx错误参数，但因为是镜像中不好debug，定位堆栈抛异常的是如下代码：

val jsonDF = limitOrNot {
  df.limit(outputSize)
}.toJSON
val scriptJsonStringResult = fetchType match {
  case "collect" => jsonDF.collect().mkString(",")

看代码得知是jsonDF.collect().mkString(",")这行的问题，outputSize数据有问题，但我并没有在启动服务的时候请求任何脚本，于是陷入了死胡同。

google后发现是一个spark2普遍的问题，找到如下文章：

https://www.codetd.com/en/article/12490356

https://stackoverflow.com/questions/46429616/spark-2-2-illegal-pattern-component-xxx-java-lang-illegalargumentexception-ill

描述很清晰，是commons-lang3依赖冲突导致的，需要保证commons-lang3依赖在3.5以上。于是顺着这个方向，排了工程里面相关的依赖，本地启动正常，docker中启动报错。。。

于是怀疑是docker环境问题导致，拉取了最新的docker构建脚本，发现大量新增代码，果然是新增代码的锅，新增逻辑比较多，于是直接拉上相关同事一起看。发现最近docker的lib文件夹下增加了很多jar，spark提交任务的脚本增加了很多插件类：

COPY lib/ansj_seg-5.1.6.jar 
  lib/nlp-lang-1.7.8.jar 
  lib/${AZURE_BLOB_NAME} 
  lib/mlsql-assert-${MLSQL_SPARK_VERSION}_${SCALA_BINARY_VERSION}-0.1.0-SNAPSHOT.jar 
  lib/mlsql-excel-${MLSQL_SPARK_VERSION}_${SCALA_BINARY_VERSION}-0.1.0-SNAPSHOT.jar 
  lib/mlsql-ext-ets-${MLSQL_SPARK_VERSION}_${SCALA_BINARY_VERSION}-0.1.0-SNAPSHOT.jar 
  lib/mlsql-shell-${MLSQL_SPARK_VERSION}_${SCALA_BINARY_VERSION}-0.1.0-SNAPSHOT.jar 
  lib/mlsql-mllib-${MLSQL_SPARK_VERSION}_${SCALA_BINARY_VERSION}-0.1.0-SNAPSHOT.jar 
  ${MLSQL_HOME}/libs/

spark-submit 任务启动脚本：

$SPARK_HOME/bin/spark-submit --class streaming.core.StreamingApp  --driver-memory ${DRIVER_MEMORY} 
               ...
-streaming.plugin.clzznames "tech.mlsql.plugins.ds.MLSQLExcelApp,tech.mlsql.plugins.assert.app.MLSQLAssert,tech.mlsql.plugins.shell.app.MLSQLShell,tech.mlsql.plugins.ext.ets.app.MLSQLETApp"

显然是二方包导致的依赖冲突，而之前花了大量时间改byzer的依赖，打包，部署，重新构建docker都是无用功！

但jar还是比较多，只能穷举的在docker环境中一个一个的删掉，测试是否有启动异常，在排查到AZURE这个jar的时候发现了问题，该jar是我们为了支持AZURE添加的，已经经过冲突依赖shade处理的，shade重构建的项目在这个REPO下：

GitHub - byzer-org/byzer-objectstore-dep

于是clone项目，使用maven Dependency Analyzer分析：

并没有commons-lang3这个依赖，于是怀疑是其他依赖导致的冲突，把azure相关的依赖直接引入到byzer的项目中（为了做依赖冲突分析），于是惊奇的发现commons-lang3又有了：

是因为打包项目为了满足不同的hadoop版本打包，设置了profiles，导致分析工具失效了：

修复问题

对azure-store项目中的依赖做shade处理：


    shade
    
        
            
                org.apache.maven.plugins
                maven-shade-plugin
                3.2.0
                
                    
                        
                            *:*
                            
                                meta-INF/*.SF
                                meta-INF/*.DSA
                                meta-INF/*.RSA
                            
                        
                    
                    false
                    
                     
                        
                            org.apache.commons
                            shadeio.azure.org.apache.commons
                        
                        
                            commons-lang
                            shadeio.azure.commons-lang
                        
                    
                

                
                    
                        package
                        
                            shade

在byzer-lang中添加统一的版本约束：


    
        
            org.apache.commons
            commons-lang3
            3.10

在启动byzer的子pom中显式声明依赖：


    org.apache.commons
    commons-lang3

问题得到解决，另外发现一个问题，虽然dependencyManagement定义版本这种定义方式有如下规范：

如果子pom中显式设置了version则以子pom的version为主

需要使用父pom依赖时需要声明依赖并且不设置version

但我测试发现在azure这个依赖中携带的commons-lang3即使不在子pom声明使用dependencyManagement定义后，其版本也会被约束成3.10而不是以前的3.3。笔者建议声明一下避免打包解析树的时候出现问题。

spark添加二方包导致依赖冲突排查

大数据系统相关栏目本月热门文章