南京某客户Spark序列化问题解决

问题描述

南京**银行项目，客户需要将现在星环计算好的结果数据通过魔镜进行展现，现在需要做POC测试，往来了N次都没有搞定。

1. 第一次，对方客户给的centos7.2系统，ambari2.7部署失败，缺各种依赖包。
2. 第二次，云鹏在河南机电做好了一个操作系统镜像，然后成功部署ambari2.2版本。
3. 第三次，以为客户只是需要将星环数据导入，开始方案是希望魔镜建好表，然后由国通将写星环大数据平台的ETL任务同样配置到魔镜这边一份，所以需要新版本的魔镜的数据开发功能，所以建议云鹏去掉之前的ambari2.2，换成ambari2.7新版。
4. 第三次，建表，导入，load功能都测试完成，但是客户又说需要之前的拖拽分析功能，而新版本的拖拽分析暂时去掉了，所以只能换回之前的ambari2.2版本。
5. 第四次 ，建议云鹏使用旧版本的魔镜+新版本的ambari功能，提示jdk版本不对，因为hadoop3是基于jdk1.8的，而最早的魔镜7.3.1.6版本是基于jdk1.7的，重新打包1.8jdk，启动、基础功能都ok,但是关联之后筛选、超过100列、保存等功能有点异常，怀疑是ambari2.7导致的。
6. 第五次，换回ambari2.2版本，然而问题依旧...
7. 我今天来现场排查问题，首先查看错误日志，显示

Caused by: java.io.InvalidClassException: org.apache.spark.sql.catalyst.catalog.CatalogTable; local class incompatible: stream classdesc serialVersionUID = 1731605485048471233, local class serialVersionUID = -7734630329307796844
    at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:616)
    at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1630)
    at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1521)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1781)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1353)
    at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2018)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1942)

问题显示是某个类反序列化的时候serialVersionUID不对，初步还是感觉是jar包版本问题，开始尝试排查

• 首先查看出错的类org.apache.spark.sql.catalyst.catalog.CatalogTable存在于spark-catalystjar包中，而错误上看，是从exectuor中反序列化出错，所以将问题核心定位再hdfs上的jar包版本

• 通过docker exec -it mojing_mojing_1 bash中查看tomcat 中spark相关jar包版本，发现是hadoop*-2.7.2版本。

• ssh到集群的某台机器上，hdfs dfs -ls /spark_yarn_achvie_2.1 查看hdfs上的spark版本，发现是：hadoop*-2.7.3版本，spark对应的也不一样

• 根据猜测，想办法替换掉jar包版本尝试，先从docker中将相关的jar包拷贝出来 docker cp mojing_mojing_1:/tomcat/webapps/mojing-server/WEB-INF/lib ./

• 然后scp到集群机器上：scp -r lib root@node1:/home/hdfs

• 将hdfs上的jar包拷贝下来，hdfs dfs -get /spark_yarn_archive_2.1 ./

• 合并，我是先删除spark_yarn_archive_2.1 ，在将lib下拷贝过来：rm -rf spark_yarn_archive_2.1/hadoop-,rm -rf spark_yarn_archive_2.1/spark-,cp lib/hadoop- spark_yarn_archive_2.1/,cp lib/spark- spark_yarn_archive_2.1/

• 因为是测试，所以先将jar包上传到hdfs上，重新命名，将旧的先保留下来：hdfs dfs -put spark- spark_yarn_archive_2.1 /spark- spark_yarn_archive_2.1_new

• 修改魔镜的docker-compose.yml ，将jar包目录指向新的地址。

• docker-compose up -d启动，验证新功能，发现预览、筛选、等功能已经ok

  因为客户是需要测试关联，保存之后的分析功能，所以继续进行保存，然而，等了好久....没动静了，始终没有保存成功，继续排查吧。

  1. 首先查看AM上job运行情况，登录ambari ,点击 yarn -> resource managerUI,找到魔镜的常驻进程，spark-yarn-Moojnn
  2. 点击application Master 进去，查看job执行情况。
  3. 进去发现有个stage总是失败，查看task运行情况，发现失败的task 数据倾斜比较严重，报了timed out exception异常，出现在shuffle之后的stages上，谷歌，应该是exectutor数据的数据量有点大？但是又比较奇怪，其他有几个G的数据也没有报错过。不过由于在现场，一切从简，先尝试修改patitions个数，从10个改为20个尝试将每个task处理的数据量降低。然而发现还是没用，但是修改memory overhead 又需要从新编译打包，换一张表试试吧，碰巧换了之后数据非常均为，都是在几十兆的级别，数据运算也非常快。
  4. 至此，问题算是结束，测试分析，出图，仪表盘都没有问题，让云鹏验证poc流程是否可以，验证没问题你收工回家。

本文固定链接：杨晨辉的个人博客 » 南京某客户Spark序列化问题解决
本站内容除特别标注外均为原创，欢迎转载，但请保留出处！