• Hadoop本地库介绍及相关问题解决方法汇总


    1.hadoop本地库的作用是什么?
    2.哪两个压缩编码器必须使用hadoop本地库才能运行?
    3.hadoop的使用方法?
    4.hadoop本地库与系统版本不一致会引起什么错误?
    5.$ export HADOOP_ROOT_LOGGER=DEBUG,console有什么作

    本帖最后由 pig2 于 2014-3-20 20:46 编辑
    目的


    鉴于性能问题以及某些Java类库的缺失,对于某些组件,Hadoop提供了自己的本地实现。 这些组件保存在Hadoop的一个独立的动态链接的库里。这个库在*nix平台上叫libhadoop.so. 本文主要介绍本地库的使用方法以及如何构建本地库。


    组件
    Hadoop现在已经有以下 compression codecs本地组件:
    在以上组件中,lzo和gzip压缩编解码器必须使用hadoop本地库才能运行。
     
    使用方法
    hadoop本地库的用法很简单:
    • 看一下 支持的平台.
    • 下载 预构建的32位i386架构的Linux本地hadoop库(可以在hadoop发行版的lib/native目录下找到)或者自己 构建 这些库。
    • 确保你的平台已经安装了zlib-1.2以上版本或者lzo2.0以上版本的软件包或者两者均已安装(根据你的需要)。
    bin/hadoop 脚本通过系统属性 -Djava.library.path=<path>来确认hadoop本地库是否包含在库路径里。
    检查hadoop日志文件可以查看hadoop库是否正常,正常情况下会看到:
    DEBUG util.NativeCodeLoader - Trying to load the custom-built native-hadoop library... 
    INFO util.NativeCodeLoader - Loaded the native-hadoop library
    如果出错,会看到:
    INFO util.NativeCodeLoader - Unable to load native-hadoop library for your platform... using builtin-java classes where applicable

    支持的平台
    Hadoop本地库只支持*nix平台,已经广泛使用在GNU/Linux平台上,但是不支持 Cygwin 和 Mac OS X
    已经测试过的GNU/Linux发行版本:
    在上述平台上,32/64位Hadoop本地库分别能和32/64位的jvm一起正常运行。

    构建Hadoop本地库
    Hadoop本地库使用 ANSI C 编写,使用GNU autotools工具链 (autoconf, autoheader, automake, autoscan, libtool)构建。也就是说构建hadoop库的平台需要有标准C的编译器和GNU autotools工具链。请参看 支持的平台
    你的目标平台上可能会需要的软件包:
    如果已经满足了上述先决条件,可以使用build.xml 文件,并把其中的compile.native置为 true,这样就可以生成hadoop本地库:
    $ ant -Dcompile.native=true <target>
    因为不是所有用户都需要Hadoop本地库,所以默认情况下hadoop不生成该库。
    你可以在下面的路径查看新生成的hadoop本地库:
    $ build/native/<platform>/lib
    其中<platform>是下列系统属性的组合 ${os.name}-${os.arch}-${sun.arch.data.model};例如 Linux-i386-32。
     
     
    注意
    • 在生成hadoop本地库的目标平台上必须 安装了zlib和lzo开发包;但是如果你只希望使用其中一个的话,在部署时,安装其中任何一个都是足够的。
    • 在目标平台上生成以及部署hadoop本地库时,都需要根据32/64位jvm选取对应的32/64位zlib/lzo软件包。

    使用DistributedCache 加载本地库
    用户可以通过 DistributedCache 加载本地共享库,并分发和建立库文件的符号链接。
    这个例子描述了如何分发库文件并在从map/reduce任务中装载库文件。
    • 首先拷贝库文件到HDFS。
      bin/hadoop fs -copyFromLocal mylib.so.1 /libraries/mylib.so.1
    • 启动作业时包含以下代码:
      DistributedCache.createSymlink(conf); 
      DistributedCache.addCacheFile("hdfs://host:port/libraries/mylib.so.1#mylib.so", conf);
    • map/reduce任务中包含以下代码:
      System.loadLibrary("mylib.so");


    这里要注意:DistributedCache是用来分发应用特定的只读文件和一个jar包的,以供Map-Reduce框架在启动任务和运行的时候使用这些缓冲的文件或者是把第三方jar包添加到其classpath路径中去,要注意的是DistributedCache的使用是有一个前提的,就它会认为这些通过urls来表示的文件已经在hdfs文件系统里面。

    下面给出一个具体示例:
    1. 配置应用程序的cache,把需要使用的文件上传到DFS中去:

    1.     $ bin/hadoop fs -copyFromLocal lookup.dat /myapp/ 
    2.     $ bin/hadoop fs -copyFromLocal map.zip /myapp/ 
    3.     $ bin/hadoop fs -copyFromLocal mylib.jar /myapp/
    4.     $ bin/hadoop fs -copyFromLocal mytar.tar /myapp/
    5.     $ bin/hadoop fs -copyFromLocal mytgz.tgz /myapp/
    6.     $ bin/hadoop fs -copyFromLocal mytargz.tar.gz /myapp/
    复制代码
    此时Hadoop框架会把这些应用所需要的文件复制到每个准备启动的节点上去,它会把这些复制到mapred.temp.dir配置的目录中去,以供相应的Task节点使用。

    这里要注意的DistriubtedCache分发的文件分成公有与私有文件,公有文件可以给HDFS中的所有用户使用,而私有文件只能被特定的用户所使用,用户可以配置上传文件的访问权限来达到这种效果。

    2. 配置JobConf:


    1.      JobConf job = new JobConf();
    2.      DistributedCache.addCacheFile(new URI("/myapp/lookup.dat#lookup.dat"),job); // 这里的lookup.dat加了一个符号连接
    3.      DistributedCache.addCacheArchive(new URI("/myapp/map.zip", job);
    4.      DistributedCache.addFileToClassPath(new Path("/myapp/mylib.jar"), job); // 这里是把相应的jar包加到Task的启动路径上去
    5.      DistributedCache.addCacheArchive(new URI("/myapp/mytar.tar", job);
    6.      DistributedCache.addCacheArchive(new URI("/myapp/mytgz.tgz", job);
    7.      DistributedCache.addCacheArchive(new URI("/myapp/mytargz.tar.gz", job);
    复制代码

    3. 在Mapper或者Reducer任务中使用这些文件:

    1. public static class MapClass extends MapReduceBase  
    2.      implements Mapper<K, V, K, V> {
    3.      
    4.        private Path[] localArchives;
    5.        private Path[] localFiles;
    6.        
    7.        public void configure(JobConf job) {
    8.          // Get the cached archives/files
    9.          localArchives = DistributedCache.getLocalCacheArchives(job);  // 得到本地打包的文件,一般是数据文件,如字典文件
    10.          localFiles = DistributedCache.getLocalCacheFiles(job);        // 得到本地缓冲的文件,一般是配置文件等
    11.        }
    12.        
    13.        public void map(K key, V value, 
    14.                        OutputCollector<K, V> output, Reporter reporter) 
    15.        throws IOException {
    16.          // Use data from the cached archives/files here
    17.          // ...
    18.          // ...
    19.          output.collect(k, v);
    20.        }
    21.      }
    复制代码
    另外,使用新的MP接口要注意的地方:

    1. 我们知道,新的MP接口使用了Job这个类来对MP任务进行配置,这里使用的时候要注意一点
    1.    Configuration conf = new Configuration();
    2.    // 对conf加入配置信息  - 正确方法
    3.    Job job = new Job(conf,"word count");
    4.    // 对conf加入配置信息 - 这是有问题的,这些配置不会生效,因为这里生成Job的时候它会对conf进行复制,这个看一下Job的源代码就知道。
    5.    // 这里可以用job.getConfiguration()来得到其内部的conf对象,这样就不会有问题。
    复制代码
    2. 如果你在启动MP任务之前调用了第三方jar包的类,那这就会有问题,会在启动任务的时候找不到这个类。这个问题我还没有找到好的解决办法,一个办法就是把这些类想办法移到MP任务中,如果有朋友知道更加好的办法,请告诉我一下,多谢了。我感觉Nutch中也会有同样的问题,什么时候研究一下Nutch的代码,说不定会有很多关于Hadoop方面的收获。



    --------------------------------------------------------------------------------------------------------------------------
    hadoop本地库与系统版本不一致引起的错误解决方法

     




    部署hadoop的集群环境为  


    操作系统 centos 5.8    


    hadoop版本为cloudera   hadoop-0.20.2-cdh3u3


    集群中设置支持gzip lzo压缩后,在对压缩文件进行读取或者对输入文件压缩的时候要使用到hadoop的本地库,本地库的默认位置在


    $HADOOP_HOME/lib/native/Linux-amd64-64   (64位操作系统)


    $HADOOP_HOME/lib/native/Linux-i386-32   (32位操作系统)




    文件夹中的libhadoop.so文件,就是hadoop的本地库。


    如果本地库不存在,或者本地库与当前操作系统的版本不一致的时候,会报下面的错误:


    11/09/20 17:29:49 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform… using builtin-java classes where applicable


    增加调试信息设置


    $ export HADOOP_ROOT_LOGGER=DEBUG,console
    $ hadoop fs -text /test/data/origz/access.log.gz


    2012-04-24 15:55:43,269 WARN org.apache.hadoop.util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable


    error libhadoop.so  /lib64/libc.so.6 required (libc 2.6)    /usr/local/hadoop/lib/native/Linux-amd64-64  


    说明系统中的glibc的版本和libhadoop.so需要的版本不一致导致


    查看系统的libc版本  


    # ll /lib64/libc.so.6


    lrwxrwxrwx 1 root root 11 Apr 24 16:49 /lib64/libc.so.6 -> libc-2.5.so


    系统中的版本为2.5


    将系统中的glibc升级为2.9


    下载glibc
    wget  http://ftp.gnu.org/gnu/glibc/glibc-2.9.tar.bz2


    下载glibc-linuxthreads
    wget http://ftp.gnu.org/gnu/glibc/glibc-linuxthreads-2.5.tar.bz2


    解压
    $tar -jxvf glibc-2.9.tar.bz2
    $cd glibc-2.9
    $tar -jxvf ../glibc-linuxthreads-2.5.tar.bz2
    $cd ..
    $export CFLAGS="-g -O2"
    $./glibc-2.9/configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
    $make
    #make install


    安装编译过程中需要注意三点:
    1、要将glibc-linuxthreads解压到glibc目录下。
    2、不能在glibc当前目录下运行configure。
    3、加上优化开关,export CFLAGS="-g -O2",否则会出现错误




    安装完后,可以查看ls -l /lib/libc.so.6已升级


    lrwxrwxrwx 1 root root 11 Apr 24 16:49 /lib64/libc.so.6 -> libc-2.9.so


    测试本地库是否升级




    $ export HADOOP_ROOT_LOGGER=DEBUG,console
    $ hadoop fs -text /test/data/origz/access.log.gz


    12/04/25 08:54:47 INFO lzo.LzoCodec: Successfully loaded & initialized native-lzo library [hadoop-lzo rev 6bb1b7f8b9044d8df9b4d2b6641db7658aab3cf8]
    12/04/25 08:54:47 DEBUG util.NativeCodeLoader: Trying to load the custom-built native-hadoop library...
    12/04/25 08:54:47 INFO util.NativeCodeLoader: Loaded the native-hadoop library
    12/04/25 08:54:47 INFO zlib.ZlibFactory: Successfully loaded & initialized native-zlib library
    12/04/25 08:54:47 DEBUG fs.FSInputChecker: DFSClient readChunk got seqno 0 offsetInBlock 0 lastPacketInBlock false packetLen 132100
    可以看到将glibc升级后不再报错,已经成功加载本地库


    -------------------------------------------------------------------------------------------------------------------------------------------------另外一例:错误都是一样,可以从中学到解决问题的方法

    用官方的Hadoop 2.1.0-beta安装后,每次hadoop命令进去都会抛出这样一个Warning

    WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable

    设置logger级别,看下具体原因


    export HADOOP_ROOT_LOGGER=DEBUG,console​
    1. 13/08/29 13:59:38 DEBUG util.NativeCodeLoader: Trying to load the custom-built native-hadoop library...  
    2. 13/08/29 13:59:38 DEBUG util.NativeCodeLoader: Failed to load native-hadoop with error: java.lang.UnsatisfiedLinkError: /usr/local/hadoop/hadoop-2.1.0-beta/lib/native/libhadoop.so.1.0.0: /usr/local/hadoop/hadoop-2.1.0-beta/lib/native/libhadoop.so.1.0.0: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)  
    3. 13/08/29 13:59:38 DEBUG util.NativeCodeLoader: java.library.path=/usr/local/hadoop/hadoop-2.1.0-beta/lib/native/Linux-amd64-64:/usr/local/hadoop/hadoop-2.1.0-beta/lib/native  
    4. 13/08/29 13:59:38 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable  
    复制代码
    wrong ELFCLASS32,难道是加载的so文件系统版本不对

    执行命令file libhadoop.so.1.0.0
    libhadoop.so.1.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
    果然是80386,是32位的系统版本,而我的hadoop环境是64位OS
    原来直接从apache镜像中下载的编译好的Hadoop版本native library都是32版本的,如果要支持64位版本,必须自己重新编译,这就有点坑爹了,要知道几乎所有的生产环境都是64位的OS

    YARN官方对于native library的一段话验证了这一点
    “The pre-built 32-bit i386-Linux native hadoop library is available as part of the hadoop distribution and is located in the lib/native directory​”

    重新checkout source code
    svn checkout http://svn.apache.org/repos/asf/ ... release-2.1.0-beta/
    加上编译native的选项,编译时会根据当前的操作系统架构来生产相应的native库
    mvn package -Pdist,native -DskipTests -Dtar
    再去native文件下查看所有的file type,已经都是64位版的了,替换线上文件,WARNING消除
    1. file *  
    2. libhadoop.a:        current ar archive  
    3. libhadooppipes.a:   current ar archive  
    4. libhadoop.so:       symbolic link to `libhadoop.so.1.0.0'  
    5. libhadoop.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped  
    6. libhadooputils.a:   current ar archive  
    7. libhdfs.a:          current ar archive  
    8. libhdfs.so:         symbolic link to `libhdfs.so.0.0.0'  
    9. libhdfs.so.0.0.0:   ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped  
    复制代码
  • 相关阅读:
    第四章 开始Unity Shader学习之旅(3)
    第四章 开始Unity Shader学习之旅(2)
    第四章 开始Unity Shader学习之旅(1)
    堆中的变量、对象的使用
    goto语句 switch语句
    C/C++走过的坑(基础问题篇)
    EOF 与 getchar()
    char与 int 类型转化问题汇总
    运算符优先级记忆口诀及列表(转)
    SQL基础篇---函数及其函数配套使用的关键字
  • 原文地址:https://www.cnblogs.com/ilinuxer/p/5037346.html
Copyright © 2020-2023  润新知