温馨提示×

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)**替代多副本以进一步降本。

0