Question

没有-Djava.library.path = / opt / mapr / hadoop / hadoop-0.20.2 / lib / native / Linux-amd64-64 /作为运行Java的参数，我收到以下错误，

2013-11-13 15:23:29,414 WARN    pool-3-thread-3 org.apache.hadoop.util.NativeCodeLoader Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
2013-11-13 15:23:29,414 INFO    pool-3-thread-3 org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback        Falling back to shell based

这是什么意思？使用基于shell的速度较慢吗？我该解决这个问题吗？我应该关心这个警告吗？

FYI此错误（或UnspecifiedLinkError）可以通过以下任一方式修复，

有关设置java.library.path - rhive.connect() issues with MapR distribution
向文件hadoop-env.sh添加以下行

export HADOOP_CLIENT_OPTS = -Djava.library.path = $ HADOOP_HOME / lib / native / Linux-amd64-64 /

感谢您的帮助。

Answer 1

对于你得到的WARN消息，我假设你已经弄清楚了，但这只是意味着你没有使用Hadoop的本机库，这可能会更慢或者只是不能正常工作gzip。 / p>

但是对于来自JniBasedUnixGroupsMappingWithFallback的第二条消息，它有点复杂。如果你看一下这个来源，你会看到这样的东西：

if (NativeCodeLoader.isNativeCodeLoaded()) {
    this.impl = new JniBasedUnixGroupsMapping();
} else {
    LOG.info("Falling back to shell based");
    this.impl = new ShellBasedUnixGroupsMapping();
}

ShellBasedUnixGroupsMapping和JniBasedUnixGroupsMapping之间的唯一区别是ShellBasedUnixGroupsMapping只会通过bash -c groups执行ProcessBuilder来确定用户属于哪个群组，JniBasedUnixGroupsMapping将使用JNI与libC通信以获取组列表。

我没有运行任何基准测试，但我认为与{lib}实现相比，ProcessBuilder的开销不会太大，因为它只是为了获得组，因此影响很小。话虽这么说，因为看起来你已经弄明白了，但在Hadoop的其他领域使用本机库来提高性能肯定不会受到影响。

无法加载native-hadoop库

1 个答案: