CentOS HDFS压缩技术有哪些
小樊
38
2026-01-08 06:59:49
CentOS上HDFS常用压缩技术与选型
一、常用压缩格式与特性
- Gzip(DEFLATE):压缩率较高、速度适中;Hadoop内置;文件扩展名**.gz**;不支持分片。适合压缩后每个文件不超过约130MB的场景(如小时级日志归档)。
- Snappy:压缩/解压速度很快、压缩率中等;通常需安装本地库;扩展名**.snappy**;不支持分片。适合MapReduce/Shuffle中间结果与实时计算链路。
- LZO:速度较快、压缩率中等;需安装(许可原因常与lzop一起使用);扩展名**.lzo**;支持分片(需建索引)。适合压缩后仍大于约200MB的大文件,利于并行处理。
- Bzip2:压缩率很高;Hadoop内置;扩展名**.bz2**;支持分片。适合对压缩率要求高、对时延不敏感的场景(如冷数据归档)。
- LZ4:极致的解压/压缩速度、压缩率较低;适合实时/低延迟数据流与高吞吐场景。
- Zstandard(Zstd):压缩速度与压缩率兼顾,提供多级压缩级别;适合在速度与压缩率之间平衡的业务。
- 补充:列式格式如Parquet/ORC天然支持压缩与编码(如SNAPPY/ZSTD),可进一步降低I/O与存储占用。
二、在HDFS与计算框架中的启用方式
- 全局编解码器注册(core-site.xml 或 hadoop-common 配置):
- 设置 io.compression.codecs,例如包含:GzipCodec、BZip2Codec、SnappyCodec、Lz4Codec、ZstdCodec。
- MapReduce关键参数(mapred-site.xml 或作业配置):
- 开启Map输出压缩:mapreduce.map.output.compress=true;设置编解码器:mapreduce.map.output.compress.codec=org.apache.hadoop.io.compress.SnappyCodec(或Lz4Codec/ZstdCodec)。
- 开启Reduce输出压缩:mapreduce.output.fileoutputformat.compress=true;设置编解码器:mapreduce.output.fileoutputformat.compress.codec=…
- 编程式使用 CompressionCodec:通过 CompressionCodecFactory 按扩展名推断编解码器,或使用 CompressionOutputStream/CompressionInputStream 对流进行压缩/解压。
- 注意:部分编解码器(如Snappy/LZO/Zstd)需要集群节点安装对应本地库(native library),否则只能走Java实现、性能会受影响。
三、选型建议与典型场景
- 日志/近实时链路:优先 Snappy/LZ4(速度优先,Shuffle/网络带宽敏感)。
- 大文件长期存储:优先 LZO(建索引)/Zstd(并行与压缩率平衡);若极致压缩且可接受慢速,选 Bzip2。
- Map中间结果:选 Snappy/LZ4,显著降低Shuffle与落盘I/O。
- 归档/冷数据:选 Bzip2/Zstd,节省存储成本。
- 列式数据(Parquet/ORC):结合查询性能与压缩率选择 SNAPPY/ZSTD 等内置编码。
四、实践注意事项
- 可分割性影响并行度:Gzip/Bzip2/Snappy 对单个压缩文件通常不可分片;Bzip2 天然可分片;LZO 需为索引文件(.lzo.index)后才可分片。为提升并行处理,尽量使用可分片格式或对不可分片文件进行合理切分/合并。
- CPU与延迟权衡:压缩能减少I/O与网络,但增加CPU开销;I/O密集作业更建议启用压缩,计算密集作业需谨慎评估。
- 本地库与兼容性:Snappy/LZO/Zstd 等需在各节点部署匹配版本的本地库(.so),避免 JNI UnsatisfiedLinkError;不同Hadoop版本对编解码器的内置支持与类名可能有差异,部署前请核对版本说明。
- 存储与容错:压缩节省的是“原始字节”,但副本数仍按“压缩后大小”计算;在 HDFS 3.x 可考虑对冷数据使用**纠删码(EC)**替代多副本以进一步降本。