聊到 Hadoop 生态大家关注点通常集中在分布式存储、计算引擎、资源调度这些“大件”上但有一样东西经常被忽略却直接影响集群成本和任务效率——数据压缩。它贯穿 HDFS 的落盘、MapReduce/Spark 的 Shuffle、Hive 数仓的存储格式甚至决定你的任务是几十个 Map 并行跑完还是一个 Map 孤军奋战跑到天黑。这篇文章从实际运维和调优的角度把 Hadoop 数据压缩的关键机制、主流格式差异、选型逻辑和生产配置完整梳理一遍刚接触大数据的朋友能拿来避坑正在压存储成本、优化离线任务的人也可以当一份选型清单来用。1. 先搞懂Hadoop 里压缩到底在解决什么问题1.1 一笔真实的存储成本账HDFS 默认三副本意味着 1TB 原始数据落进去实际占用集群空间是 3TB。这一点很多新人都知道但很少换算成成本去感受。假设一个日志系统每天产生 1TB 原始数据保留 30 天那就是 30TB 原始数据、90TB 实际占用。如果对这批数据做一次 gzip 压缩压缩率按 30% 算压缩后只有 9TB 原始体积三副本是 27TB。也就是说同样保留一个月集群空间从 90TB 降到 27TB省下 63TB。这还只是存储侧的收益不含后续读取时节省的磁盘 IO、网络传输和机架带宽。压缩对性能的影响更直接。很多大数据任务的瓶颈不在 CPU而在 IO。一个需要 Shuffle 的 Join 或聚合任务中间结果从 Map 端写到本地磁盘、再通过网络拉到 Reduce 端如果中间数据能压缩到原来的三分之一甚至四分之一传输量大幅下降整个作业的完成时间肉眼可见地缩短。这也是为什么我在评估集群上某个任务“是不是该优化”时第一件事就去看它的 Shuffle 数据量而不是急着调并行度。1.2 天下没有免费的压缩CPU 和 IO 的博弈压缩不是白拿的。压缩要耗 CPU解压也要耗 CPU如果场景选错压缩非但不会提速反而会把任务拖慢。IO 密集型任务比如全表扫描、大表 Join、Shuffle 重操作压缩收益非常明显因为磁盘和网络通常是瓶颈但 CPU 密集型任务比如复杂正则解析、大量特征计算压缩带来的 IO 节省可能不足以抵消 CPU 的额外开销。举个生活化的类比。你给朋友传一张 2GB 的工程文件如果网速很慢先把文件压成 500MB 再传省下的传输时间远比压缩消耗的时间多这是划算的如果你们在同一个内网、网速极快那直接传反而更快因为压缩和解压消耗的时间超过了传输节省的时间。大数据场景也是一样的道理判断要不要压缩、选哪种压缩本质是在“CPU 成本”和“IO 成本”之间寻找平衡点。这个平衡点又跟集群的 CPU 资源是否充裕、磁盘是机械盘还是 SSD、网络是万兆还是千兆都有关系所以我从来不相信有“一套配置走天下”的答案。2. 压缩格式核心机制为什么“能不能切分”是生死线2.1 可切片性的真实含义HDFS 文件默认按 128MB 切成 Block 存储MapReduce 和 Spark 在读取文件时会尽量按照 Block 的边界来生成输入分片每个分片交给一个 Map 或一个 Partition 去处理。这样并行度才能上去。这里就冒出一个关键问题如果文件是整块压缩的比如一个 1GB 的 gzip 文件HDFS 底层虽然还是把它切成多个 Block但计算引擎从 Block 中间位置开始解压时根本没有办法独立解出数据因为 gzip 是一个连续的压缩流后面的数据依赖前面的解压上下文。结果就是1GB 的 gzip 文件即使底层占了 8 个 Block计算引擎也只能把它当作一个整体交给一个 Map 去处理。其他节点只能围观。这就是典型的“压缩导致数据倾斜”不是数据本身倾斜而是切分能力被压缩格式废掉了。相反lzo、bzip2、zstd 这类支持切片或自带独立块结构的格式可以按 Block 边界切分并行度不受影响。我习惯把可切片性理解成“切西瓜”gzip 是一个没切过的整瓜不管它多大你只能抱起来整个啃lzo 是切好的西瓜盒拿出一块就能吃不需要先还原成完整的瓜。对分布式计算来说能不能切开直接决定了并行度的上限。2.2 从算法层面看为什么 gzip 不能切片这里值得稍微往下挖一层。gzip 用的 DEFLATE 算法是一连串有状态依赖的压缩块压缩器维护一个滑动窗口字典后面的数据压缩时会引用前面出现过的字符串。解压器必须从文件开头依次处理前面的块才能正确还原后面的内容。所以你在文件中间随便挑一个位置开始解压根本拿不到有效的输出。相比之下bzip2 的底层是多个独立的 BWT 变换块每个块可以单独解压天然支持按块切分。lzo 和 LZ4 同样采用独立块或带可分割索引的流式结构所以它们能更好地配合分布式计算引擎。很多人在选压缩格式时只盯着“压缩率”和“速度”两个指标忽略了可切片性结果把 gzip 用在了每天被大量扫描的明细表上查询性能惨不忍睹。这个教训在 Hadoop 生态里反复出现值得每个新人记住。2.3 压缩格式和容器格式Snappy 的“可切”是有条件的还有一个经常被绕进去的细节Snappy 本身并不保证文件级别的可切分。很多人看到“Snappy 速度快”就直接把纯文本文件用 snappy 压了存进 HDFS然后发现扫描该表的 Map 数只有一个任务跑了两个小时还没结束。问题不在于 Snappy 算法而在于你把它用在了裸文本文件上裸 Snappy 流没有块索引引擎无法从中间切入。Snappy 的优势要在“容器格式”里才能完全发挥。比如 Parquet 或 ORC 文件内部有行组Row Group或 Stripe 结构每个行组内部的数据可以独立被 Snappy 压缩计算引擎知道行组的边界就能在任意行组处切片读取。这也是为什么数据仓库领域形成了“Parquet/ORC Snappy”这种黄金组合列式存储负责裁剪列和切分Snappy 负责压缩和解压速度两者搭配后既有高压缩率又有高并行度。如果只是想把文本日志压缩存放又不想失去并行度优先考虑 lzo 加索引文件或者直接换 Parquet 这类带自描述结构的容器格式。3. 主流压缩 Codec 横向对比与选型指南3.1 一张表看全所有参数Hadoop 生态常见的压缩格式就那么几种我把它们的关键参数放在一起做个对比方便大家对照选择。Codec扩展名平均压缩比压缩速度解压速度是否支持切片典型适用场景gzip / deflate.gz较高一般一般否冷数据归档、不常读的备份bzip2.bz2最高很慢慢是极冷归档、追求极限压缩率lzo.lzo中等快快是需索引高频读取且需要切分的裸文本snappy.snappy较低极快极快容器格式内可切Parquet/ORC 内嵌压缩、中间数据lz4.lz4较低极快极快容器格式内可切需要极致速度的临时数据zstd.zst高快快是流式/容器既想省空间又想速度快的新项目看这张表时注意一点压缩比数字不是固定值具体取决于数据特征。日志文本里有大量的重复字段和固定模式压缩效果就很好如果是随机数、加密数据或已经压缩过的图片视频再压也压不出多少空间。所以上面说“平均压缩比”是在文本型数据的典型情况。真正做选型时一定要拿自己的数据样本实测不要照搬别人的结论。3.2 按场景选型给出一套决策规则我每次给团队建议压缩格式时都会按场景来分而不是直接指定一个“最好”的格式。数据仓库的 Hive 表走 Parquet Snappy 基本上是默认答案。Parquet 的列式裁剪和谓词下推能省掉大量 IOSnappy 的解压速度足够快查询引擎不会在解压上卡脖子。如果集群 CPU 资源比较宽裕、存储压力又大可以试试 Parquet Zstd压缩率明显优于 Snappy解压速度也没落后太多。原始日志文件的归档如果保留后会偶尔被读取、但不需要频繁做全表扫描lzo 加索引是不错的选择兼顾了压缩率和并行读。真正的冷数据比如超过一年的历史明细几乎不会被读直接用 gzip 或 bzip2 压到极限空间优先读取慢一点也无所谓因为一年也不会有几次人去看它。MapReduce 或 Spark 任务的中间结果也就是 Shuffle 阶段的数据选 Snappy 或 LZ4。这个场景的特点是数据只在一个作业内部流动生命周期极短压缩率没那么重要速度才是第一位。用高压缩率格式压缩 Shuffle 数据往往得不偿失——压缩时间变长了网络省下的那点时间还不够还债。3.3 值得重点关注的 Zstd最近几年 Zstd 在大数据生态里的存在感越来越强。它在高压缩级别下能达到接近 bzip2 的压缩率同时速度和 LZ4 处于同一量级比 gzip 快得多。更关键的是它支持预设字典对于一批结构高度相似的数据训练一个小字典后压缩率还能进一步提升。Hadoop 3.3 之后的发行版对 Zstd 的原生支持已经比较完善Hive 和 Spark 侧也都能透传配置。我在一个模拟项目里对比过 Zstd level 3 和 Snappy同样的 100GB 文本日志Zstd 压缩后体积比 Snappy 少了约 35%解压速度大概是 Snappy 的八成左右。也就是说在 CPU 没有明显瓶颈的集群上Zstd 是一个“多花一点 CPU、省下三分之一存储和大量 IO”的划算买卖。如果集群还在用 Hadoop 2.x接入 Zstd 需要额外编译 native 库稍微麻烦一点但如果你已经开始用 Hadoop 3.x 系列我建议把 Zstd 放进选型测试列表它在很多场景里会给你惊喜。4. 生产环境实操从配置到验证4.1 全局配置core-site.xml 与 mapred-site.xmlHadoop 使用压缩能力的第一步是把用到的 Codec 注册到运行时环境。在 core-site.xml 的 io.compression.codecs 属性里把需要的 Codec 类全部列上逗号分隔。少了这一步任务执行时可能抛 “Codec not found” 或直接退化为不压缩输出。基础配置如下property nameio.compression.codecs/name valueorg.apache.hadoop.io.compress.GzipCodec, org.apache.hadoop.io.compress.BZip2Codec, org.apache.hadoop.io.compress.SnappyCodec, org.apache.hadoop.io.compress.Lz4Codec, org.apache.hadoop.io.compress.ZStandardCodec /value /propertyMapReduce 的输出压缩在 mapred-site.xml 里控制。开启最终输出压缩和中间结果压缩两组开关并指定各自使用的 Codecproperty namemapreduce.output.fileoutputformat.compress/name valuetrue/value /property property namemapreduce.output.fileoutputformat.compress.codec/name valueorg.apache.hadoop.io.compress.SnappyCodec/value /property property namemapreduce.map.output.compress/name valuetrue/value /property property namemapreduce.map.output.compress.codec/name valueorg.apache.hadoop.io.compress.SnappyCodec/value /property注意这里我特意把最终输出和中间结果都设置了。分不清这两个概念是常见的配置误区mapreduce.map.output.compress 控制的是 Map 端写到本地磁盘、再通过网络传给 Reduce 的那部分数据也就是 Shuffle 中间数据mapreduce.output.fileoutputformat.compress 控制的是作业最终落盘在 HDFS 上的输出文件。两者独立生效很多任务慢在 Shuffle但你只改了最终输出压缩自然看不到效果。4.2 Hive 与 Spark 侧的压缩设置Hive 在跑 MapReduce 引擎时同样需要打开输出压缩和中间压缩。直接在 Hive 会话里执行即可SET hive.exec.compress.outputtrue; SET hive.exec.compress.intermediatetrue; SET hive.intermediate.compression.codecorg.apache.hadoop.io.compress.SnappyCodec;这里有个容易被忽略的问题如果 Hive 表的存储格式是 Parquet 或 ORC压缩其实是由表本身的存储格式决定的。你在会话里打开输出压缩指的是 MapReduce 结果文件的压缩而 Parquet 表内部的列压缩由表属性控制。建表时直接指定CREATE TABLE ods_xxx ( id bigint, name string ) STORED AS PARQUET TBLPROPERTIES (parquet.compressionSNAPPY);Spark 侧的配置类似在 SparkSession 里设置spark.conf.set(spark.sql.parquet.compression.codec, snappy) spark.conf.set(spark.io.compression.codec, lz4)spark.sql.parquet.compression.codec 控制 Parquet 文件的压缩spark.io.compression.codec 控制内部数据如 RDD 序列化数据的压缩。注意 Spark 3.x 里 Parquet 压缩默认值通常是 snappy但如果你用的是高版本默认可能变成了 uncompressed 或 zstd最好在项目初始化时显式设置避免不同环境行为不一致。4.3 命令与 API快速验证压缩是否生效配置改完最怕的是“看着改了实际没生效”。我习惯用几个命令快速验证。先确认 native 库是否加载正常hadoop checknative正常输出里会列出 gzip、bzip2、snappy、zstd 等对应的是 true 还是 false。如果 Snappy 是 false说明用的是 Java 实现性能大打折扣。再看 HDFS 上文件的压缩前后体积hadoop fs -du -h /data/raw hadoop fs -du -h /data/compressed如果一个 10GB 的文件压缩后变成 3GB说明压缩确实生效了。验证文件内部是否真的可切片可以查看文件的物理 Block 分布和计算引擎切出的分片数量。在 MapReduce 的 Counter 里能看到 Input Split 数量如果一个大 gzip 文件只有一个 Input Split那就是不可切分的典型表现。Java API 层面MapReduce 作业里可以用 FileOutputFormat 直接设置压缩输出job.setOutputFormatClass(TextOutputFormat.class); FileOutputFormat.setCompressOutput(job, true); FileOutputFormat.setOutputCompressorClass(job, SnappyCodec.class);4.4 一次日志目录压缩的完整试验有一次我接手一个日志平台的存储优化任务现状是 HDFS 上按天分目录存原始 JSON 日志三副本后占用了大量空间。我的处理步骤是先挑一个非核心的日期目录做小规模验证不直接动全量数据。先统计目录原始体积hadoop fs -du -h /logs/2024/06/01然后写一个临时 MapReduce 任务或直接用 Hive CTAS把该日期数据转成 Parquet Snappy 存储到新目录。完成后对比新旧目录的体积并跑一个典型查询对比耗时。确认存储节省比例和查询耗时都可接受后再批量处理其他日期目录。最后一步才是切换上层应用的表路径并观察一段时间的稳定性。整个过程遵循“先测试、再小范围试点、最后全量推广”的节奏。压缩格式的改动涉及所有下游任务一旦全量切换后才发现查询性能下降回滚成本远高于事前多花一两天做验证。5. 最容易踩的坑Codec 缺失、索引与格式嵌套5.1 LZO 的 native 库困境Apache Hadoop 官方发行版默认不包含 LZO 的 native 实现因为它涉及的底层库授权方式比较特殊。你配置了 LzopCodec 后直接跑任务大概率会碰到异常提示无法找到对应的 native 库。解决方案是自行编译安装 lzo 相关依赖并把编译好的 so 文件部署到所有节点同时修改 core-site.xml 注册 LzopCodec。这个坑在第一次接触 LZO 时几乎人人都会踩。很多人以为配置项写对就行结果忽略了 native 库的部署。一个可用的检查手段是 hadoop checknative输出里如果没有 lzo 对应的 true说明它压根没加载成功。若团队里没有人愿意折腾编译部署又需要可切分的裸文本压缩其实可以考虑 Zstd它同样能切片且在新版本 Hadoop 里支持度更好部署成本低不少。5.2 索引文件丢失导致任务打回“单 Map”LZO 支持切片的前提是存在索引文件通常是 .lzo.index。如果只有 .lzo 数据文件而索引文件缺失计算引擎不知道每个块从哪里开始独立解压只能把整个文件当成一个分片处理。之前某数据团队在做跨集群数据迁移时用 distcp 拷贝了一批 lzo 文件结果索引没复制过去下游跑批任务突然从几百个 Map 降到一个 Map作业时间从半小时拉长到十几个小时。这个坑的教训很明确lzo 索引文件是数据的一部分迁移、备份时必须一并保留。在迁移脚本里明确写出对所有 .lzo 及 .lzo.index 文件一并处理事后检查文件数量是否成对出现。如果索引真的丢了可以用工具重新扫描原文件生成索引但这会消耗大量 IO 资源最好选在业务低峰期操作。5.3 重复压缩白白损耗 CPU还有一种情况是“压了个寂寞”。有次我排查一个数据链路发现上层已经把 Parquet Snappy 文件写好了下层任务读取后又做了一次 gzip 压缩输出到归档目录。Parquet 内部的 Snappy 已经把数据压过一遍再套一层 gzip几乎压不动反而白白增加了整条链路的 CPU 消耗。碰到这种问题检查文件后缀和配置就能发现一个文件同时带 .parquet 和 .gz 后缀或者 Hive 表属性是 PARQUET 但会话又打开了 text 输出的 gzip 压缩都是重复压缩的迹象。重复压缩的另一个常见字体是“对人畜无害对系统有害”单看每个任务耗时不多但全集群任务叠加起来浪费的 CPU 相当可观。建议在开发规范里明确列式存储表用表属性控制压缩不要额外打开文件输出压缩归档链路只保留一层压缩不用对已有压缩格式二次包装。5.4 小文件加 gzip调度灾难的隐藏源头如果把大量小文件分别用 gzip 压缩后存放而每个文件又是不可切分的那么每个文件都对应一个 Map 任务。文件数量一多任务调度、启动、清理的开销会淹没真正的计算时间集群会出现大量短命 Map 任务NameNode 的 RPC 压力也随之暴涨。这种问题通常不会立刻报警但你会发现集群整体吞吐越来越差、队列积压越来越多。正确的处理方式是把小文件合并成大文件后再压缩。比如日志类小文件可以先合并成 SequenceFile 或直接写入 Parquet 表再启用压缩。Parquet 本身有行组结构一个文件可以做得很大且保持可切分性配合 Snappy 或 Zstd既解决了小文件问题又保住了并行度和压缩率。6. 压箱底经验先测再选、参数与监控6.1 动手前先做一个最小可对比的压缩测试我强烈建议所有团队在引入新压缩格式前先用真实数据样本做一次压缩测试不要直接信网上的经验值。方法很简单取真实业务数据的一个小目录比如 20GB 左右的文本日志用不同 Codec 分别压缩一遍记录压缩时间、压缩后体积和一次典型查询的耗时。测试后做成一张自己的对比表。某次我用 Hadoop 自带工具压缩一份 25GB 的日志样本结果是gzip 压到约 7.5GB用时约 6 分钟lzo 压到约 10GB用时约 2 分钟snappy 压到约 11GB用时不到 1 分钟zstd 压到约 8.5GB用时约 3 分钟。当然这个结果只对当时那份数据有效不同数据分布下数字会变化但这类测试能帮团队建立“自己的数据到底适合什么”的判断。测试时别用 core-site 的全局配置直接在命令行或任务配置里指定要测的 Codec 即可。6.2 三个容易被忽略的调优点第一个是压缩级别。gzip 和 zstd 都支持调节压缩级别gzip 从 1 到 9数字越大压缩率越高但耗时越长zstd 也有类似级别选项。很多人默认用级别 6 或默认值但日志归档场景下其实可以试试更高级别看能省多少空间因为这是低频读取的数据压缩时间稍长问题不大。第二个是 IO buffer 大小。io.file.buffer.size 默认通常是 4KB 或 128KB取决于版本。调大这个值可以提高大文件顺序读写的效率对压缩数据的读写也有正向影响。我在一次调优中把 buffer 从 4KB 调到 128KB 后压缩文件读取任务的整体耗时下降了大约 10%。第三个是 HDFS 块大小与数据量的匹配。当一个压缩文件解压后的大小远大于一个 Block 时可切分格式的优势才体现得出来如果文件本身就小于 128MB可不可切其实无所谓因为本来也只能一个 Map 处理。所以不要盲目追求“所有文件都可切”小文件该合并先合并再来谈压缩格式。6.3 用集群指标确认压缩收益配置上线后要用监控数据确认收益而不是只看“任务跑完了”。我一般关注三个指标HDFS 实际存储量变化、典型作业的 Shuffle 数据量变化、任务完成时间变化。HDFS 侧用 hadoop fs -du 按目录对比即可Shuffle 数据量可以在 YARN 的 Counter 或 Spark UI 里看到作业时间对比最好是相同数据、相同资源配置、相同时间段的多次采样避免偶然波动。还有一个容易忽略的收益指标是磁盘 IO 压力。如果集群之前频繁出现 DataNode 磁盘繁忙压缩生效后这一指标通常会明显缓解。这不是压缩格式本身的功劳而是因为读写的数据量变少了。反过来如果你发现压缩后 CPU 使用率明显上升、任务反而变慢就要考虑降低压缩级别或改选速度更快的格式。7. 收尾的几句实在话压缩格式没有绝对的“最好”只有“当前场景下最合适”。我的习惯是每半年或每换一批硬件后重新做一轮压缩测试因为集群的 CPU 算力、网络带宽、磁盘类型都会影响最优选择。曾经觉得不可用的方案可能在资源充裕后变得非常划算。最后一个小技巧在做选型对比时把“解压速度”和“压缩率”放在同等重要的位置很多团队的失败不是压缩率不够而是解压太慢导致查询越来越卡。数据压缩是省钱的杠杆也是性能的隐形开关花一两天认真测一次后面一整年都会感谢当时的自己。