使用Snappy 压缩方式报错“java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path”...

阅读量：4960 次

发布时间：2019-06-12

本文共 8581 字，大约阅读时间需要 28 分钟。

情况描述

其实这个问题已经困扰我很久了，最近在公司Linux上搭建hadoop 和 spark环境的时候，我就遇到 spark提交作业到yarn 集群就报错这个错，当时已经安装snappy环境了，任何关于snappy静态库都编译了，这是我提交到spark mail list上的

后来也没人给我回复，就有一个人这样给我回复的“chef if hadoop distribution doesn’t come with other version of snappy jar, if you have 2 snappies in classpath it may cause your problem

”

而最近我在macox下搭建一个spark伪分布式模式，我在idea上启动spark任务时候，也报这个错了

“java.lang.reflect.InvocationTargetException

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:317)

at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:219)

at org.xerial.snappy.Snappy.(Snappy.java:44)

at org.apache.spark.io.SnappyCompressionCodec.(CompressionCodec.scala:150)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:526)

at org.apache.spark.io.CompressionCodec

.createCodec(CompressionCodec.scala:68)atorg.apache.spark.io.CompressionCodec.createCodec(CompressionCodec.scala:60)

at org.apache.spark.scheduler.EventLoggingListener.(EventLoggingListener.scala:69)

at org.apache.spark.SparkContext.(SparkContext.scala:513)

at org.apache.spark.examples.SparkPi

.main(SparkPi.scala:28)atorg.apache.spark.examples.SparkPi.main(SparkPi.scala)atsun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod)atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)atjava.lang.reflect.Method.invoke(Method.java:606)atorg.apache.spark.deploy.yarn.ApplicationMaster

anon2.run(ApplicationMaster.scala:483)

Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path

at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)

at java.lang.Runtime.loadLibrary0(Runtime.java:849)

at java.lang.System.loadLibrary(System.java:1088)

at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)

… 23 more ”

后来我在谷歌上搜索 “java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path”关键字，我看到github 上 snappy的issue，

发现这就是jdk1.7.X on mac ，但我想貌似Linux 也应该有问题吧，但又不敢确定，因为我之前把我们测试环境集群所有关于hadoop 和spark的压缩包都在我本地的ubutun环境搭建了（jdk，scala，hadoop，spark都是一样），NND 我的ubutun上就没有任何问题，我的神呀

然后呢？

我想既然这个问题不是hadoop和spark上的问题，那我就先使用snappy压缩和解压一段java String

我在github上找到snappy源码中的README.md有使用snappy 示例

依赖：        
                 
      
       org.xerial.snappy
                  
      
       snappy-java
                  
      
       1.1.1.4
                  
      
       jar
                  
      
       compile
              
        源码：        public class TestSnappy {    public static void main(String[] args) throws Exception{        String input = "Hello snappy-java! Snappy-java is a JNI-based wrapper of "                + "Snappy, a fast compresser/decompresser.";        byte[] compressed = Snappy.compress(input.getBytes("UTF-8"));        byte[] uncompressed = Snappy.uncompress(compressed);        String result = new String(uncompressed, "UTF-8");        System.out.println(result);    }}

使用snappy 1.1.1.4版本是因为 spark源码的pom.xml文件都使用这个版本的snappy

当我运行这个程序后，报错如下：

java.lang.reflect.InvocationTargetException    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)    at java.lang.reflect.Method.invoke(Method.java:606)    at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:317)    at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:219)    at org.xerial.snappy.Snappy.
     
      (Snappy.java:44)    at test.TestSnappy.main(TestSnappy.java:12)    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)    at java.lang.reflect.Method.invoke(Method.java:606)    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)    at java.lang.Runtime.loadLibrary0(Runtime.java:849)    at java.lang.System.loadLibrary(System.java:1088)    at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)    ... 13 moreException in thread "main" org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] null    at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)    at org.xerial.snappy.Snappy.
      
       (Snappy.java:44)    at test.TestSnappy.main(TestSnappy.java:12)    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)    at java.lang.reflect.Method.invoke(Method.java:606)    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)Process finished with exit code 1

后来我就继续看

dgerges commented on 5 Feb 2014An easy fix if you want to continue to use 1.4.0.1 on MacOSX with JDK 1.7unzip snappy-java-1.0.4.1.jarcd org/xerial/snappy/native/Mac/x86_64/copy libsnappyjava.jnilib libsnappyjava.dylibcd ../../../../../..cp snappy-java-1.0.4.1.jar snappy-java-1.0.4.1.jar.oldjar cf snappy-java-1.0.4.1.jar org

进入到 ~/.m2/repository/ 然后按照上述描述尝试了下，

当我再次运行TestSnappy程序后，果然不报错了

Hello snappy-java! Snappy-java is a JNI-based wrapper of Snappy, a fast compresser/decompresser.Process finished with exit code 0

看来 macox下要需要识别 ”libsnappyjava.dylib“ 这个文件

写到这，我突然想说下我最近关于mac发生的事情：

我现在在使用的这台电脑是mac book air,是公司给我配置的，而我自己有个mac book pro 840 中配，就关于“no snappyjava in java.library.path”这个问题，我有天晚上突然想在自己的pro上再试一次，然后就用同样的hadoop和spark等包都在pro上安装了，后来启动hadoop时候就报错无法加载 hadoop相关的.so 静态文件，后来我就把$HADOOP_HOME/lib/native/*.so 文件cp 到/usr/local/lib/ 还有 /usr/lib/,但是还是没效果，后来我合计既然不好用，那我就把/usr/local/lib/ 还有 /usr/lib/ 下得.so文件删除吧，

1. 先/usr/local/lib/下所有hadoop相关的.so文件删除了

2. 然后删除/usr/lib/下相关文件，因为我们项目也使用了lzma,当时我也是SB了，直接就rm -rf /usr/lib/liblzma* ，然后呢？执行 sudo 任何命令，都提示“can not initialized PAM”，后来也不能上网了，当时还SB的认为，mac怎么也能抽风呢？重启电脑吧，后来竟然无法启动了，进度条在50%后，就不动了，后来进入单用户模式，看/var/log/才知道，原来缺少 /usr/lib/liblzma.5.dylib /usr/lib/liblzma.dylib 这个两个文件

当时就想着从别的mac 上copy这两个文件就OK了。但是U盘不能挂载了（是我单用户进去的），我也拦着弄了，我就合计线上升级了，发现试了几次，家里网络也不行，我就放弃了，次日去公司，用同事做得macox U盘镜像安装系统，发现他得版本没我的高，后来我同事让我自己做个，我又懒着做了，我就去三里屯苹果店了，10分钟重新在线安装了。哎我是SB呀

spark解决办法

macox
既然macox下要识别 ”libsnappyjava.dylib“ 这个文件，那我就把这个文件 copy到/usr/local/lib/下，执行命令：cp libsnappyjava.dylib /usr/local/lib/
执行命令：ls /usr/local/lib/libsnappy*
当我再次在idea上运行spark程序，也没有再报错了，问题也解决了

公司测试集群
由于这问题有点影响整体进度了，所以我就把这个问题跳过了，但还是没有解决
目前解决方案是：
在 $SPARK_HOME/conf/spark-defaults.conf中增加 spark.io.compression.codec lzf
因为spark默认是使用snappy压缩方式在处理日志聚合和 driver与executor通信等