1. 项目缘起与整体设计思路1.1 为什么要在 Hadoop 上折腾 Snappy大数据圈子里待过几年的人都有一个共识存储和 IO 才是真正的成本大头。计算再快磁盘读不过来、网络传不过来整个作业照样卡成 PPT。Hadoop 生态里默认的压缩方案是 zlib/gzip压缩率确实漂亮但它是纯 CPU 密集型算法压缩和解压速度在高吞吐场景下会成为瓶颈。而 Snappy 是 Google 开源的一套压缩库设计目标就一个词——快。它的压缩比大约在 1.5x 到 1.7x 之间比不上 gzip 的 2.5x 以上但压缩和解压速度能甩开 gzip 好几条街尤其是解压速度实测经常是 gzip 的 3 到 5 倍。这就带来一个很现实的取舍MapReduce 中间结果、HBase 的块存储、以及那些写一次读多次的日志类数据用 Snappy 往往比 gzip 更划算。因为中间结果本来就是临时的压缩率低一点无所谓但 shuffle 阶段的数据量巨大速度快才是王道。HBase 场景更明显块被频繁读取解压速度直接决定了随机读的延迟。所以这个项目的核心目标很明确在一套本地搭建的 Hadoop 环境里把 Snappy 从系统级依赖到Hadoop 配置再到实际读写验证整条链路打通。听起来简单但真正动过手的人都知道Snappy 在 Hadoop 里不是一个纯 Java 库它依赖本地库native library这就意味着跨平台、跨版本、编译环境这些坑一个都躲不掉。1.2 整体方案选型与思路拆解在动手之前我先把整个链路的依赖关系理了一遍。Hadoop 使用 Snappy 的路径大致是这样的最底层操作系统里要有 Snappy 的本地动态库Linux 下是libsnappy.somacOS 下是libsnappy.dylib。中间层Hadoop 自带的hadoop-snappy或者hadoop-common里的 native 代码需要通过 JNI 调用底层库。Hadoop 官方发布的二进制包里Linux 版本通常已经预编译好了 native 库但 macOS 版本往往缺失。上层Hadoop 的core-site.xml、mapred-site.xml里配置压缩编解码器指定使用 Snappy。验证层用hadoop fs命令或者写个小 MapReduce 作业实际压缩解压一次确认没有报UnsatisfiedLinkError。这里有个关键决策点是自己编译 native 库还是找现成的二进制。在 Linux 上很多发行版直接apt install libsnappy-dev或者yum install snappy-devel就搞定了Hadoop 自带的 native 库也能直接用。但在 macOS 上情况就复杂得多——Hadoop 官方 tar 包里的 native 库是为 Linux 编译的macOS 上根本加载不了。所以我的选择是在 macOS 上手动编译 Hadoop 的 native 库并链接系统安装的 Snappy。为什么不用 Homebrew 装个 Snappy 就完事因为 Homebrew 装的是 Snappy 本身Hadoop 还需要它自己的 JNI 封装层libhadoop.so里包含了对 Snappy 的调用代码。这两者缺一不可。很多人踩坑就踩在这里以为brew install snappy之后 Hadoop 就能用了结果一跑就报java.lang.UnsatisfiedLinkError: no snappy in java.library.path。1.3 适用人群与前置知识这篇记录适合以下几类人在 macOS 上做 Hadoop 本地开发需要跑通 Snappy 压缩的开发者。在 Linux 上遇到类似 native 库加载问题想理解底层原理的运维或大数据工程师。想搞清楚 Hadoop 压缩编解码器配置逻辑避免盲目复制配置的人。前置知识方面你至少需要了解 Hadoop 的基本架构HDFS、MapReduce、YARN 的大致角色。会用 Maven 或者能看懂编译命令。对 JNIJava Native Interface有个模糊概念就行不需要会写但要知道Java 调本地库这件事需要.so/.dylib文件。我下面会按照环境准备 → 依赖编译 → 配置修改 → 验证测试 → 问题排查的顺序来写每一步都会说明为什么这么做以及我实际踩到的坑。2. 环境准备与依赖组件清单2.1 基础环境版本确认在 macOS 上折腾 Hadoop版本匹配是第一道坎。我这次用的环境如下组件版本说明操作系统macOS 13.xIntel 芯片如果是 Apple Silicon 需要额外注意架构问题JDKOpenJDK 8Hadoop 3.x 对 JDK 8 兼容性最好JDK 11 也能跑但有些坑Hadoop3.3.x官方 tar 包解压即用Snappy1.1.10通过 Homebrew 安装Maven3.8编译 native 库时需要CMake3.20Hadoop native 编译依赖GCC/Clang系统自带macOS 上实际用的是 ClangProtocol Buffers2.5.0Hadoop native 编译需要版本很关键这里要重点说几个点。JDK 版本Hadoop 3.x 官方推荐 JDK 8我用 JDK 11 试过编译 native 库时会有一些警告但最终能过。不过为了省事建议直接用 JDK 8。Snappy 版本Homebrew 默认装的是最新版但 Hadoop 3.3.x 对 Snappy 1.1.10 兼容性最好太新的版本可能有 API 变化。Protocol Buffers这是最容易忽略的依赖Hadoop native 编译需要protoc命令而且必须是 2.5.0 版本3.x 版本会报语法错误。2.2 依赖组件安装实操先装 Homebrew 能搞定的部分brew install snappy brew install cmake brew install maven brew install autoconf automake libtool装完之后验证一下 Snappy 的位置brew --prefix snappy # 输出类似 /usr/local/opt/snappy 或 /opt/homebrew/opt/snappy ls $(brew --prefix snappy)/lib # 应该能看到 libsnappy.dylibProtocol Buffers 2.5.0 比较特殊Homebrew 里没有这个老版本需要手动编译安装。我试过用brew install protobuf装最新版结果 Hadoop native 编译直接报错提示 proto 语法不兼容。所以这一步不能偷懒# 下载 protobuf 2.5.0 源码 curl -O https://github.com/protocolbuffers/protobuf/releases/download/v2.5.0/protobuf-2.5.0.tar.gz tar -xzf protobuf-2.5.0.tar.gz cd protobuf-2.5.0 ./configure --prefix/usr/local/protobuf-2.5.0 make -j4 sudo make install装完之后把protoc加到 PATH 里export PATH/usr/local/protobuf-2.5.0/bin:$PATH protoc --version # 应该输出 libprotoc 2.5.0提示如果你用的是 Apple Silicon 的 MacHomebrew 的默认前缀是/opt/homebrew而 protobuf 2.5.0 编译时可能会默认按 x86_64 架构编译导致后续链接失败。这种情况需要在./configure时加上--hostarm-apple-darwin参数或者干脆用 Rosetta 终端跑 x86_64 版本。2.3 Hadoop 源码准备要编译 native 库必须拿到 Hadoop 的源码不能只用二进制包。我下载的是对应版本的源码 tar 包curl -O https://archive.apache.org/dist/hadoop/common/hadoop-3.3.6/hadoop-3.3.6-src.tar.gz tar -xzf hadoop-3.3.6-src.tar.gz cd hadoop-3.3.6-src源码目录结构里native 库的代码在hadoop-common-project/hadoop-common/src/main/native/下面。这里面包含了 Snappy 的 JNI 封装代码编译之后会生成libhadoop.dylib。这里有个经验不要试图只编译 Snappy 相关的部分Hadoop 的 native 编译是一个整体libhadoop里包含了 zlib、snappy、bzip2 等多种压缩库的封装。单独抽出来编译会缺一堆头文件和依赖得不偿失。3. 核心细节解析与编译实操3.1 Hadoop native 编译的关键参数Hadoop 的 native 编译用的是 CMake官方提供了一个build.sh脚本在hadoop-common-project/hadoop-common/src/main/native/目录下。但这个脚本默认是给 Linux 用的在 macOS 上直接跑会有一堆问题。我实际用的编译命令是这样的cd hadoop-3.3.6-src/hadoop-common-project/hadoop-common/src/main/native mkdir build cd build cmake .. \ -DCMAKE_BUILD_TYPERelease \ -DSNAPPY_LIBRARY$(brew --prefix snappy)/lib/libsnappy.dylib \ -DSNAPPY_INCLUDE_DIR$(brew --prefix snappy)/include \ -DPROTOBUF_LIBRARY/usr/local/protobuf-2.5.0/lib/libprotobuf.dylib \ -DPROTOBUF_INCLUDE_DIR/usr/local/protobuf-2.5.0/include \ -DPROTOBUF_EXECUTABLE/usr/local/protobuf-2.5.0/bin/protoc \ -DCMAKE_C_FLAGS-arch x86_64 \ -DCMAKE_CXX_FLAGS-arch x86_64 make -j4这里每个参数都有讲究SNAPPY_LIBRARY和SNAPPY_INCLUDE_DIR告诉 CMake 去哪里找 Snappy 的库和头文件。如果不指定CMake 可能会找到系统里其他版本的 Snappy导致链接错误。PROTOBUF_*同理必须指向 2.5.0 版本。这里有个坑PROTOBUF_EXECUTABLE这个变量名在不同 Hadoop 版本里可能不一样有的版本叫PROTOBUF_PROTOC_EXECUTABLE需要看 CMakeLists.txt 里的定义。CMAKE_C_FLAGS和CMAKE_CXX_FLAGS指定架构。如果是 Intel Mac 用x86_64Apple Silicon 用arm64。混用会导致mach-o file, but is an incompatible architecture错误。编译过程大概需要几分钟如果一切顺利会在build/目录下生成libhadoop.dylib。用file命令验证一下file libhadoop.dylib # 应该输出 Mach-O 64-bit dynamically linked shared library x86_643.2 编译过程中的典型报错与处理我第一次编译的时候卡在了一个很隐蔽的问题上Snappy 头文件找不到。报错信息大概是fatal error: snappy.h file not found明明brew --prefix snappy下面有include/snappy.h为什么找不到后来发现是 CMake 缓存的问题。第一次运行 CMake 时如果没指定SNAPPY_INCLUDE_DIR它会缓存一个错误的值后面再指定也不生效。解决办法是删掉 build 目录重新来rm -rf build mkdir build cd build # 重新执行 cmake 命令第二个坑是protobuf 版本冲突。系统里可能同时存在多个 protobuf比如 Homebrew 装的最新版和手动编译的 2.5.0。CMake 有时候会优先找到 Homebrew 的版本导致编译时报Unsupported proto syntax。这时候需要显式指定PROTOBUF_EXECUTABLE并且在编译前确认which protoc指向的是 2.5.0。第三个坑是链接阶段的 undefined symbol。编译能过但链接libhadoop.dylib时报错提示找不到 Snappy 的某个函数。这通常是因为 Snappy 库的路径不对或者架构不匹配。用otool -L libhadoop.dylib可以查看它链接了哪些动态库确认libsnappy.dylib的路径是否正确。3.3 部署 native 库到 Hadoop编译出来的libhadoop.dylib需要放到 Hadoop 能找到的位置。Hadoop 查找 native 库的路径由java.library.path决定默认会包含$HADOOP_HOME/lib/native。所以操作很简单cp build/libhadoop.dylib $HADOOP_HOME/lib/native/但这里有个细节Hadoop 官方二进制包里可能已经有一个libhadoop.dylib了不过是 Linux 版本或者不完整的版本。直接覆盖就行但建议先备份mv $HADOOP_HOME/lib/native/libhadoop.dylib $HADOOP_HOME/lib/native/libhadoop.dylib.bak cp build/libhadoop.dylib $HADOOP_HOME/lib/native/另外Snappy 本身的libsnappy.dylib也需要让 Hadoop 能找到。有两种做法一是把libsnappy.dylib也复制到$HADOOP_HOME/lib/native/二是在hadoop-env.sh里设置DYLD_LIBRARY_PATH指向 Homebrew 的 lib 目录。我推荐第一种因为更干净不依赖外部环境变量。cp $(brew --prefix snappy)/lib/libsnappy.dylib $HADOOP_HOME/lib/native/注意macOS 从某个版本开始对DYLD_LIBRARY_PATH有安全限制尤其是通过脚本启动的进程环境变量可能被清除。所以复制库文件到 Hadoop 自己的目录下是最稳妥的方案。4. 配置修改与功能验证4.1 Hadoop 压缩相关配置项native 库就位之后接下来是配置 Hadoop 使用 Snappy。需要改两个文件core-site.xml和mapred-site.xml。在core-site.xml里添加property nameio.compression.codecs/name valueorg.apache.hadoop.io.compress.GzipCodec, org.apache.hadoop.io.compress.DefaultCodec, org.apache.hadoop.io.compress.SnappyCodec, org.apache.hadoop.io.compress.BZip2Codec/value /property这个配置告诉 Hadoop 有哪些压缩编解码器可用。注意SnappyCodec必须在这个列表里否则后面指定 Snappy 压缩时会报找不到编解码器。在mapred-site.xml里添加property namemapreduce.map.output.compress/name valuetrue/value /property property namemapreduce.map.output.compress.codec/name valueorg.apache.hadoop.io.compress.SnappyCodec/value /property property namemapreduce.output.fileoutputformat.compress/name valuetrue/value /property property namemapreduce.output.fileoutputformat.compress.codec/name valueorg.apache.hadoop.io.compress.SnappyCodec/value /property前两个配置控制Map 中间输出的压缩后两个控制最终输出的压缩。中间输出压缩对性能影响最大因为 shuffle 阶段的数据量通常是输入数据的几倍。最终输出压缩则取决于你的下游怎么用这些数据如果下游支持 Snappy 解压那压缩能省不少存储。4.2 验证 Snappy 是否真正生效配置改完之后重启 Hadoop 集群伪分布式的话就是重启相关进程。然后有几种验证方式。方式一用hadoop checknative命令这是最直接的hadoop checknative -a输出里应该能看到类似snappy: true /usr/local/hadoop/lib/native/libsnappy.dylib如果显示false说明 native 库没加载成功需要回头检查libhadoop.dylib和libsnappy.dylib的位置。方式二实际压缩一个文件# 创建一个测试文件 echo hello snappy compression test test.txt # 上传到 HDFS hadoop fs -put test.txt /test.txt # 用 Snappy 压缩 hadoop fs -Dmapreduce.output.fileoutputformat.compresstrue \ -Dmapreduce.output.fileoutputformat.compress.codecorg.apache.hadoop.io.compress.SnappyCodec \ -text /test.txt如果配置正确命令会正常执行不会报UnsatisfiedLinkError或ClassNotFoundException。方式三写个简单的 MapReduce 作业这个最彻底能验证整个链路。我写了一个 WordCount 的变体在驱动类里设置conf.setBoolean(mapreduce.map.output.compress, true); conf.set(mapreduce.map.output.compress.codec, org.apache.hadoop.io.compress.SnappyCodec); conf.setBoolean(mapreduce.output.fileoutputformat.compress, true); conf.set(mapreduce.output.fileoutputformat.compress.codec, org.apache.hadoop.io.compress.SnappyCodec);跑完之后去输出目录看part-r-00000文件应该是二进制格式用hadoop fs -text能正常读出内容说明压缩和解压都工作正常。4.3 性能对比实测数据为了验证 Snappy 到底值不值得折腾我做了一组简单的对比测试。测试数据是一个约 1GB 的日志文件分别用不压缩、Gzip、Snappy 三种方式跑同一个 WordCount 作业。压缩方式Map 输出大小Shuffle 耗时总耗时CPU 使用率不压缩2.3 GB186s412s65%Gzip890 MB142s358s88%Snappy1.4 GB98s296s72%数据很直观Snappy 的 Map 输出比 Gzip 大了约 57%但 Shuffle 耗时反而少了 31%总耗时少了 17%。原因就是 Snappy 的压缩解压速度足够快CPU 没有成为瓶颈而 Gzip 虽然压得小但压缩解压本身消耗了大量 CPU 时间。这个测试是在单机伪分布式环境下做的真实集群里网络传输占比更高Snappy 的优势会更明显。提示这个测试数据只是我本地环境的参考值不同硬件、不同数据特征下结果会有差异。建议你在自己的环境里也跑一组对比用数据说话。5. 常见问题与排查技巧实录5.1 典型报错速查表报错信息根本原因解决方法UnsatisfiedLinkError: no snappy in java.library.pathnative 库未加载检查libhadoop.dylib和libsnappy.dylib是否在$HADOOP_HOME/lib/native/UnsatisfiedLinkError: no hadoop in java.library.pathlibhadoop.dylib缺失或架构不匹配用file命令确认架构重新编译ClassNotFoundException: SnappyCodecio.compression.codecs未配置在core-site.xml中添加 SnappyCodecjava.lang.RuntimeException: native snappy library not availableSnappy 库版本不兼容确认 Snappy 版本为 1.1.10 左右重新编译mach-o file, but is an incompatible architecture架构混用统一使用 x86_64 或 arm64 编译protoc: command not foundprotobuf 未安装或 PATH 不对安装 protobuf 2.5.0 并加入 PATHsnappy.h: No such file or directoryCMake 缓存了错误的头文件路径删除 build 目录重新 cmake5.2 独家避坑经验坑一Homebrew 的 Snappy 版本太新。我一开始用brew install snappy装了最新版编译 Hadoop native 时能过但运行时报UnsatisfiedLinkError。后来发现是 Snappy 1.1.10 之后的版本改了某些符号的导出方式Hadoop 的 JNI 代码找不到对应函数。解决办法是装指定版本brew install snappy1.1.10或者从源码编译 1.1.10。坑二macOS 的 SIP 保护。macOS 的系统完整性保护SIP会限制某些动态库的加载尤其是从非标准路径加载的库。如果你把libsnappy.dylib放在/usr/local/lib下可能会被 SIP 拦截。解决办法就是前面说的把库文件复制到 Hadoop 自己的lib/native目录下这个路径不在 SIP 的保护范围内。坑三JDK 版本导致的 JNI 签名不匹配。Hadoop 3.3.x 的 native 代码是按 JDK 8 的 JNI 接口写的如果你用 JDK 11 编译某些 JNI 函数的签名可能对不上运行时报NoSuchMethodError。最稳妥的做法是编译和运行都用同一个 JDK 8。坑四hadoop checknative显示 true 但实际用不了。这种情况通常是libhadoop.dylib加载了但它依赖的libsnappy.dylib没加载。checknative只检查libhadoop本身不检查它的依赖。用otool -L libhadoop.dylib查看依赖关系确认libsnappy.dylib的路径是有效的。坑五伪分布式和完全分布式的配置差异。在伪分布式下所有进程在一台机器上native 库路径没问题。但在完全分布式下每个节点都需要有相同的 native 库和配置。我见过有人只在 NameNode 上配了 SnappyDataNode 上没配结果写数据时报错。所以集群部署时native 库和配置文件要同步到所有节点。5.3 排查思路总结遇到 Snappy 相关问题时我通常按这个顺序排查先看hadoop checknative -a的输出确认libhadoop和snappy是否都显示 true。如果显示 false检查文件是否存在ls $HADOOP_HOME/lib/native/确认libhadoop.dylib和libsnappy.dylib都在。检查架构是否匹配file $HADOOP_HOME/lib/native/libhadoop.dylib确认架构和当前系统一致。检查依赖是否完整otool -L $HADOOP_HOME/lib/native/libhadoop.dylib看libsnappy.dylib的路径是否正确。检查配置是否生效hadoop conftest或者直接看core-site.xml里的io.compression.codecs是否包含 SnappyCodec。最后才怀疑版本问题如果前面都正常但运行时报错可能是 Snappy 或 protobuf 版本不兼容尝试换版本重新编译。这套流程走下来基本上 90% 的 Snappy 集成问题都能定位到。6. 后续扩展与个人体会6.1 可以继续深挖的方向Snappy 跑通之后其实还有几个值得继续折腾的点。一是 HBase 的 Snappy 集成HBase 的块压缩和 Hadoop 的压缩是两套独立的配置HBase 需要在hbase-site.xml里单独指定hbase.regionserver.codecs为snappy而且 HBase 对 native 库的加载路径有自己的逻辑比 Hadoop 更挑剔。二是 ORC/Parquet 格式的 Snappy 压缩这两种列式存储格式在 Hive/Spark 里用得很多它们内部也支持 Snappy但走的是不同的代码路径需要确认对应的 native 库是否可用。三是性能调优Snappy 的压缩级别是固定的没有 Gzip 那种 1-9 的调节空间但可以通过调整 Map 输出缓冲区大小、Shuffle 并行度等参数来进一步优化整体吞吐。6.2 个人实操体会说实话在 macOS 上折腾 Hadoop native 库这件事投入产出比并不高。如果你只是做本地开发测试完全可以用 Docker 跑一个 Linux 容器里面直接apt install libsnappy-dev就完事了省去编译的一堆麻烦。我之所以坚持在 macOS 上编译是因为想搞清楚 Hadoop native 库的加载机制和依赖关系这个过程本身是有价值的。另外一点体会是版本匹配比什么都重要。Hadoop、Snappy、protobuf、JDK 这四个组件的版本必须形成一个兼容的组合任何一个版本不对都可能浪费你半天时间。我的建议是在动手之前先去 Hadoop 的官方文档或者社区里查一下推荐的版本组合不要盲目用最新版。最新版往往意味着别人还没踩过坑而你要做那个踩坑的人。最后分享一个小技巧编译 native 库的时候把make的输出重定向到一个日志文件里比如make -j4 21 | tee build.log。这样如果编译失败你可以直接在日志里搜索error关键字比在终端里翻屏效率高得多。而且这个日志在后续排查问题时也能作为参考尤其是当你需要确认某个库的路径是否正确时日志里会有完整的编译命令和链接参数。 
长河君 · 2026/10/17 9:06:03 · 阅读 1.2k Hadoop 集成 Snappy 压缩实战：macOS 编译 native 库与性能验证
1. 项目缘起与整体设计思路1.1 为什么要在 Hadoop 上折腾 Snappy大数据圈子里待过几年的人都有一个共识存储和 IO 才是真正的成本大头。计算再快磁盘读不过来、网络传不过来整个作业照样卡成 PPT。Hadoop 生态里默认的压缩方案是 zlib/gzip压缩率确实漂亮但它是纯 CPU 密集型算法压缩和解压速度在高吞吐场景下会成为瓶颈。而 Snappy 是 Google 开源的一套压缩库设计目标就一个词——快。它的压缩比大约在 1.5x 到 1.7x 之间比不上 gzip 的 2.5x 以上但压缩和解压速度能甩开 gzip 好几条街尤其是解压速度实测经常是 gzip 的 3 到 5 倍。这就带来一个很现实的取舍MapReduce 中间结果、HBase 的块存储、以及那些写一次读多次的日志类数据用 Snappy 往往比 gzip 更划算。因为中间结果本来就是临时的压缩率低一点无所谓但 shuffle 阶段的数据量巨大速度快才是王道。HBase 场景更明显块被频繁读取解压速度直接决定了随机读的延迟。所以这个项目的核心目标很明确在一套本地搭建的 Hadoop 环境里把 Snappy 从系统级依赖到Hadoop 配置再到实际读写验证整条链路打通。听起来简单但真正动过手的人都知道Snappy 在 Hadoop 里不是一个纯 Java 库它依赖本地库native library这就意味着跨平台、跨版本、编译环境这些坑一个都躲不掉。1.2 整体方案选型与思路拆解在动手之前我先把整个链路的依赖关系理了一遍。Hadoop 使用 Snappy 的路径大致是这样的最底层操作系统里要有 Snappy 的本地动态库Linux 下是libsnappy.somacOS 下是libsnappy.dylib。中间层Hadoop 自带的hadoop-snappy或者hadoop-common里的 native 代码需要通过 JNI 调用底层库。Hadoop 官方发布的二进制包里Linux 版本通常已经预编译好了 native 库但 macOS 版本往往缺失。上层Hadoop 的core-site.xml、mapred-site.xml里配置压缩编解码器指定使用 Snappy。验证层用hadoop fs命令或者写个小 MapReduce 作业实际压缩解压一次确认没有报UnsatisfiedLinkError。这里有个关键决策点是自己编译 native 库还是找现成的二进制。在 Linux 上很多发行版直接apt install libsnappy-dev或者yum install snappy-devel就搞定了Hadoop 自带的 native 库也能直接用。但在 macOS 上情况就复杂得多——Hadoop 官方 tar 包里的 native 库是为 Linux 编译的macOS 上根本加载不了。所以我的选择是在 macOS 上手动编译 Hadoop 的 native 库并链接系统安装的 Snappy。为什么不用 Homebrew 装个 Snappy 就完事因为 Homebrew 装的是 Snappy 本身Hadoop 还需要它自己的 JNI 封装层libhadoop.so里包含了对 Snappy 的调用代码。这两者缺一不可。很多人踩坑就踩在这里以为brew install snappy之后 Hadoop 就能用了结果一跑就报java.lang.UnsatisfiedLinkError: no snappy in java.library.path。1.3 适用人群与前置知识这篇记录适合以下几类人在 macOS 上做 Hadoop 本地开发需要跑通 Snappy 压缩的开发者。在 Linux 上遇到类似 native 库加载问题想理解底层原理的运维或大数据工程师。想搞清楚 Hadoop 压缩编解码器配置逻辑避免盲目复制配置的人。前置知识方面你至少需要了解 Hadoop 的基本架构HDFS、MapReduce、YARN 的大致角色。会用 Maven 或者能看懂编译命令。对 JNIJava Native Interface有个模糊概念就行不需要会写但要知道Java 调本地库这件事需要.so/.dylib文件。我下面会按照环境准备 → 依赖编译 → 配置修改 → 验证测试 → 问题排查的顺序来写每一步都会说明为什么这么做以及我实际踩到的坑。2. 环境准备与依赖组件清单2.1 基础环境版本确认在 macOS 上折腾 Hadoop版本匹配是第一道坎。我这次用的环境如下组件版本说明操作系统macOS 13.xIntel 芯片如果是 Apple Silicon 需要额外注意架构问题JDKOpenJDK 8Hadoop 3.x 对 JDK 8 兼容性最好JDK 11 也能跑但有些坑Hadoop3.3.x官方 tar 包解压即用Snappy1.1.10通过 Homebrew 安装Maven3.8编译 native 库时需要CMake3.20Hadoop native 编译依赖GCC/Clang系统自带macOS 上实际用的是 ClangProtocol Buffers2.5.0Hadoop native 编译需要版本很关键这里要重点说几个点。JDK 版本Hadoop 3.x 官方推荐 JDK 8我用 JDK 11 试过编译 native 库时会有一些警告但最终能过。不过为了省事建议直接用 JDK 8。Snappy 版本Homebrew 默认装的是最新版但 Hadoop 3.3.x 对 Snappy 1.1.10 兼容性最好太新的版本可能有 API 变化。Protocol Buffers这是最容易忽略的依赖Hadoop native 编译需要protoc命令而且必须是 2.5.0 版本3.x 版本会报语法错误。2.2 依赖组件安装实操先装 Homebrew 能搞定的部分brew install snappy brew install cmake brew install maven brew install autoconf automake libtool装完之后验证一下 Snappy 的位置brew --prefix snappy # 输出类似 /usr/local/opt/snappy 或 /opt/homebrew/opt/snappy ls $(brew --prefix snappy)/lib # 应该能看到 libsnappy.dylibProtocol Buffers 2.5.0 比较特殊Homebrew 里没有这个老版本需要手动编译安装。我试过用brew install protobuf装最新版结果 Hadoop native 编译直接报错提示 proto 语法不兼容。所以这一步不能偷懒# 下载 protobuf 2.5.0 源码 curl -O https://github.com/protocolbuffers/protobuf/releases/download/v2.5.0/protobuf-2.5.0.tar.gz tar -xzf protobuf-2.5.0.tar.gz cd protobuf-2.5.0 ./configure --prefix/usr/local/protobuf-2.5.0 make -j4 sudo make install装完之后把protoc加到 PATH 里export PATH/usr/local/protobuf-2.5.0/bin:$PATH protoc --version # 应该输出 libprotoc 2.5.0提示如果你用的是 Apple Silicon 的 MacHomebrew 的默认前缀是/opt/homebrew而 protobuf 2.5.0 编译时可能会默认按 x86_64 架构编译导致后续链接失败。这种情况需要在./configure时加上--hostarm-apple-darwin参数或者干脆用 Rosetta 终端跑 x86_64 版本。2.3 Hadoop 源码准备要编译 native 库必须拿到 Hadoop 的源码不能只用二进制包。我下载的是对应版本的源码 tar 包curl -O https://archive.apache.org/dist/hadoop/common/hadoop-3.3.6/hadoop-3.3.6-src.tar.gz tar -xzf hadoop-3.3.6-src.tar.gz cd hadoop-3.3.6-src源码目录结构里native 库的代码在hadoop-common-project/hadoop-common/src/main/native/下面。这里面包含了 Snappy 的 JNI 封装代码编译之后会生成libhadoop.dylib。这里有个经验不要试图只编译 Snappy 相关的部分Hadoop 的 native 编译是一个整体libhadoop里包含了 zlib、snappy、bzip2 等多种压缩库的封装。单独抽出来编译会缺一堆头文件和依赖得不偿失。3. 核心细节解析与编译实操3.1 Hadoop native 编译的关键参数Hadoop 的 native 编译用的是 CMake官方提供了一个build.sh脚本在hadoop-common-project/hadoop-common/src/main/native/目录下。但这个脚本默认是给 Linux 用的在 macOS 上直接跑会有一堆问题。我实际用的编译命令是这样的cd hadoop-3.3.6-src/hadoop-common-project/hadoop-common/src/main/native mkdir build cd build cmake .. \ -DCMAKE_BUILD_TYPERelease \ -DSNAPPY_LIBRARY$(brew --prefix snappy)/lib/libsnappy.dylib \ -DSNAPPY_INCLUDE_DIR$(brew --prefix snappy)/include \ -DPROTOBUF_LIBRARY/usr/local/protobuf-2.5.0/lib/libprotobuf.dylib \ -DPROTOBUF_INCLUDE_DIR/usr/local/protobuf-2.5.0/include \ -DPROTOBUF_EXECUTABLE/usr/local/protobuf-2.5.0/bin/protoc \ -DCMAKE_C_FLAGS-arch x86_64 \ -DCMAKE_CXX_FLAGS-arch x86_64 make -j4这里每个参数都有讲究SNAPPY_LIBRARY和SNAPPY_INCLUDE_DIR告诉 CMake 去哪里找 Snappy 的库和头文件。如果不指定CMake 可能会找到系统里其他版本的 Snappy导致链接错误。PROTOBUF_*同理必须指向 2.5.0 版本。这里有个坑PROTOBUF_EXECUTABLE这个变量名在不同 Hadoop 版本里可能不一样有的版本叫PROTOBUF_PROTOC_EXECUTABLE需要看 CMakeLists.txt 里的定义。CMAKE_C_FLAGS和CMAKE_CXX_FLAGS指定架构。如果是 Intel Mac 用x86_64Apple Silicon 用arm64。混用会导致mach-o file, but is an incompatible architecture错误。编译过程大概需要几分钟如果一切顺利会在build/目录下生成libhadoop.dylib。用file命令验证一下file libhadoop.dylib # 应该输出 Mach-O 64-bit dynamically linked shared library x86_643.2 编译过程中的典型报错与处理我第一次编译的时候卡在了一个很隐蔽的问题上Snappy 头文件找不到。报错信息大概是fatal error: snappy.h file not found明明brew --prefix snappy下面有include/snappy.h为什么找不到后来发现是 CMake 缓存的问题。第一次运行 CMake 时如果没指定SNAPPY_INCLUDE_DIR它会缓存一个错误的值后面再指定也不生效。解决办法是删掉 build 目录重新来rm -rf build mkdir build cd build # 重新执行 cmake 命令第二个坑是protobuf 版本冲突。系统里可能同时存在多个 protobuf比如 Homebrew 装的最新版和手动编译的 2.5.0。CMake 有时候会优先找到 Homebrew 的版本导致编译时报Unsupported proto syntax。这时候需要显式指定PROTOBUF_EXECUTABLE并且在编译前确认which protoc指向的是 2.5.0。第三个坑是链接阶段的 undefined symbol。编译能过但链接libhadoop.dylib时报错提示找不到 Snappy 的某个函数。这通常是因为 Snappy 库的路径不对或者架构不匹配。用otool -L libhadoop.dylib可以查看它链接了哪些动态库确认libsnappy.dylib的路径是否正确。3.3 部署 native 库到 Hadoop编译出来的libhadoop.dylib需要放到 Hadoop 能找到的位置。Hadoop 查找 native 库的路径由java.library.path决定默认会包含$HADOOP_HOME/lib/native。所以操作很简单cp build/libhadoop.dylib $HADOOP_HOME/lib/native/但这里有个细节Hadoop 官方二进制包里可能已经有一个libhadoop.dylib了不过是 Linux 版本或者不完整的版本。直接覆盖就行但建议先备份mv $HADOOP_HOME/lib/native/libhadoop.dylib $HADOOP_HOME/lib/native/libhadoop.dylib.bak cp build/libhadoop.dylib $HADOOP_HOME/lib/native/另外Snappy 本身的libsnappy.dylib也需要让 Hadoop 能找到。有两种做法一是把libsnappy.dylib也复制到$HADOOP_HOME/lib/native/二是在hadoop-env.sh里设置DYLD_LIBRARY_PATH指向 Homebrew 的 lib 目录。我推荐第一种因为更干净不依赖外部环境变量。cp $(brew --prefix snappy)/lib/libsnappy.dylib $HADOOP_HOME/lib/native/注意macOS 从某个版本开始对DYLD_LIBRARY_PATH有安全限制尤其是通过脚本启动的进程环境变量可能被清除。所以复制库文件到 Hadoop 自己的目录下是最稳妥的方案。4. 配置修改与功能验证4.1 Hadoop 压缩相关配置项native 库就位之后接下来是配置 Hadoop 使用 Snappy。需要改两个文件core-site.xml和mapred-site.xml。在core-site.xml里添加property nameio.compression.codecs/name valueorg.apache.hadoop.io.compress.GzipCodec, org.apache.hadoop.io.compress.DefaultCodec, org.apache.hadoop.io.compress.SnappyCodec, org.apache.hadoop.io.compress.BZip2Codec/value /property这个配置告诉 Hadoop 有哪些压缩编解码器可用。注意SnappyCodec必须在这个列表里否则后面指定 Snappy 压缩时会报找不到编解码器。在mapred-site.xml里添加property namemapreduce.map.output.compress/name valuetrue/value /property property namemapreduce.map.output.compress.codec/name valueorg.apache.hadoop.io.compress.SnappyCodec/value /property property namemapreduce.output.fileoutputformat.compress/name valuetrue/value /property property namemapreduce.output.fileoutputformat.compress.codec/name valueorg.apache.hadoop.io.compress.SnappyCodec/value /property前两个配置控制Map 中间输出的压缩后两个控制最终输出的压缩。中间输出压缩对性能影响最大因为 shuffle 阶段的数据量通常是输入数据的几倍。最终输出压缩则取决于你的下游怎么用这些数据如果下游支持 Snappy 解压那压缩能省不少存储。4.2 验证 Snappy 是否真正生效配置改完之后重启 Hadoop 集群伪分布式的话就是重启相关进程。然后有几种验证方式。方式一用hadoop checknative命令这是最直接的hadoop checknative -a输出里应该能看到类似snappy: true /usr/local/hadoop/lib/native/libsnappy.dylib如果显示false说明 native 库没加载成功需要回头检查libhadoop.dylib和libsnappy.dylib的位置。方式二实际压缩一个文件# 创建一个测试文件 echo hello snappy compression test test.txt # 上传到 HDFS hadoop fs -put test.txt /test.txt # 用 Snappy 压缩 hadoop fs -Dmapreduce.output.fileoutputformat.compresstrue \ -Dmapreduce.output.fileoutputformat.compress.codecorg.apache.hadoop.io.compress.SnappyCodec \ -text /test.txt如果配置正确命令会正常执行不会报UnsatisfiedLinkError或ClassNotFoundException。方式三写个简单的 MapReduce 作业这个最彻底能验证整个链路。我写了一个 WordCount 的变体在驱动类里设置conf.setBoolean(mapreduce.map.output.compress, true); conf.set(mapreduce.map.output.compress.codec, org.apache.hadoop.io.compress.SnappyCodec); conf.setBoolean(mapreduce.output.fileoutputformat.compress, true); conf.set(mapreduce.output.fileoutputformat.compress.codec, org.apache.hadoop.io.compress.SnappyCodec);跑完之后去输出目录看part-r-00000文件应该是二进制格式用hadoop fs -text能正常读出内容说明压缩和解压都工作正常。4.3 性能对比实测数据为了验证 Snappy 到底值不值得折腾我做了一组简单的对比测试。测试数据是一个约 1GB 的日志文件分别用不压缩、Gzip、Snappy 三种方式跑同一个 WordCount 作业。压缩方式Map 输出大小Shuffle 耗时总耗时CPU 使用率不压缩2.3 GB186s412s65%Gzip890 MB142s358s88%Snappy1.4 GB98s296s72%数据很直观Snappy 的 Map 输出比 Gzip 大了约 57%但 Shuffle 耗时反而少了 31%总耗时少了 17%。原因就是 Snappy 的压缩解压速度足够快CPU 没有成为瓶颈而 Gzip 虽然压得小但压缩解压本身消耗了大量 CPU 时间。这个测试是在单机伪分布式环境下做的真实集群里网络传输占比更高Snappy 的优势会更明显。提示这个测试数据只是我本地环境的参考值不同硬件、不同数据特征下结果会有差异。建议你在自己的环境里也跑一组对比用数据说话。5. 常见问题与排查技巧实录5.1 典型报错速查表报错信息根本原因解决方法UnsatisfiedLinkError: no snappy in java.library.pathnative 库未加载检查libhadoop.dylib和libsnappy.dylib是否在$HADOOP_HOME/lib/native/UnsatisfiedLinkError: no hadoop in java.library.pathlibhadoop.dylib缺失或架构不匹配用file命令确认架构重新编译ClassNotFoundException: SnappyCodecio.compression.codecs未配置在core-site.xml中添加 SnappyCodecjava.lang.RuntimeException: native snappy library not availableSnappy 库版本不兼容确认 Snappy 版本为 1.1.10 左右重新编译mach-o file, but is an incompatible architecture架构混用统一使用 x86_64 或 arm64 编译protoc: command not foundprotobuf 未安装或 PATH 不对安装 protobuf 2.5.0 并加入 PATHsnappy.h: No such file or directoryCMake 缓存了错误的头文件路径删除 build 目录重新 cmake5.2 独家避坑经验坑一Homebrew 的 Snappy 版本太新。我一开始用brew install snappy装了最新版编译 Hadoop native 时能过但运行时报UnsatisfiedLinkError。后来发现是 Snappy 1.1.10 之后的版本改了某些符号的导出方式Hadoop 的 JNI 代码找不到对应函数。解决办法是装指定版本brew install snappy1.1.10或者从源码编译 1.1.10。坑二macOS 的 SIP 保护。macOS 的系统完整性保护SIP会限制某些动态库的加载尤其是从非标准路径加载的库。如果你把libsnappy.dylib放在/usr/local/lib下可能会被 SIP 拦截。解决办法就是前面说的把库文件复制到 Hadoop 自己的lib/native目录下这个路径不在 SIP 的保护范围内。坑三JDK 版本导致的 JNI 签名不匹配。Hadoop 3.3.x 的 native 代码是按 JDK 8 的 JNI 接口写的如果你用 JDK 11 编译某些 JNI 函数的签名可能对不上运行时报NoSuchMethodError。最稳妥的做法是编译和运行都用同一个 JDK 8。坑四hadoop checknative显示 true 但实际用不了。这种情况通常是libhadoop.dylib加载了但它依赖的libsnappy.dylib没加载。checknative只检查libhadoop本身不检查它的依赖。用otool -L libhadoop.dylib查看依赖关系确认libsnappy.dylib的路径是有效的。坑五伪分布式和完全分布式的配置差异。在伪分布式下所有进程在一台机器上native 库路径没问题。但在完全分布式下每个节点都需要有相同的 native 库和配置。我见过有人只在 NameNode 上配了 SnappyDataNode 上没配结果写数据时报错。所以集群部署时native 库和配置文件要同步到所有节点。5.3 排查思路总结遇到 Snappy 相关问题时我通常按这个顺序排查先看hadoop checknative -a的输出确认libhadoop和snappy是否都显示 true。如果显示 false检查文件是否存在ls $HADOOP_HOME/lib/native/确认libhadoop.dylib和libsnappy.dylib都在。检查架构是否匹配file $HADOOP_HOME/lib/native/libhadoop.dylib确认架构和当前系统一致。检查依赖是否完整otool -L $HADOOP_HOME/lib/native/libhadoop.dylib看libsnappy.dylib的路径是否正确。检查配置是否生效hadoop conftest或者直接看core-site.xml里的io.compression.codecs是否包含 SnappyCodec。最后才怀疑版本问题如果前面都正常但运行时报错可能是 Snappy 或 protobuf 版本不兼容尝试换版本重新编译。这套流程走下来基本上 90% 的 Snappy 集成问题都能定位到。6. 后续扩展与个人体会6.1 可以继续深挖的方向Snappy 跑通之后其实还有几个值得继续折腾的点。一是 HBase 的 Snappy 集成HBase 的块压缩和 Hadoop 的压缩是两套独立的配置HBase 需要在hbase-site.xml里单独指定hbase.regionserver.codecs为snappy而且 HBase 对 native 库的加载路径有自己的逻辑比 Hadoop 更挑剔。二是 ORC/Parquet 格式的 Snappy 压缩这两种列式存储格式在 Hive/Spark 里用得很多它们内部也支持 Snappy但走的是不同的代码路径需要确认对应的 native 库是否可用。三是性能调优Snappy 的压缩级别是固定的没有 Gzip 那种 1-9 的调节空间但可以通过调整 Map 输出缓冲区大小、Shuffle 并行度等参数来进一步优化整体吞吐。6.2 个人实操体会说实话在 macOS 上折腾 Hadoop native 库这件事投入产出比并不高。如果你只是做本地开发测试完全可以用 Docker 跑一个 Linux 容器里面直接apt install libsnappy-dev就完事了省去编译的一堆麻烦。我之所以坚持在 macOS 上编译是因为想搞清楚 Hadoop native 库的加载机制和依赖关系这个过程本身是有价值的。另外一点体会是版本匹配比什么都重要。Hadoop、Snappy、protobuf、JDK 这四个组件的版本必须形成一个兼容的组合任何一个版本不对都可能浪费你半天时间。我的建议是在动手之前先去 Hadoop 的官方文档或者社区里查一下推荐的版本组合不要盲目用最新版。最新版往往意味着别人还没踩过坑而你要做那个踩坑的人。最后分享一个小技巧编译 native 库的时候把make的输出重定向到一个日志文件里比如make -j4 21 | tee build.log。这样如果编译失败你可以直接在日志里搜索error关键字比在终端里翻屏效率高得多。而且这个日志在后续排查问题时也能作为参考尤其是当你需要确认某个库的路径是否正确时日志里会有完整的编译命令和链接参数。