Ubuntu环境下的HDFS数据压缩策略
一 压缩算法与适用场景
- Snappy：压缩/解压速度极快、压缩率适中；适合高吞吐的ETL、流式处理与Map中间结果。一般不支持split（需结合容器/分片策略）。
- LZO：速度与压缩率均衡，支持split（需索引/建索引）；适合大文件、需要快速随机访问与分片的场景。
- Gzip：压缩率较高、通用性强；但压缩/解压较慢且不支持split；适合归档、冷数据。
- Bzip2：压缩率最高、可split；但速度很慢；适合对空间极度敏感、可接受长处理时间的离线场景。
- Zstandard（zstd）：兼顾压缩率与速度，资源占用相对友好；适合在存储与计算间寻求平衡的业务。
- LZ4：极快的解压速度、较低CPU开销；适合低延迟/高QPS路径的压缩/解压。
以上算法在Hadoop生态均可使用，选择时以“速度/压缩率/是否可split/CPU与Native库支持”为权衡维度。
二 存储层与列式格式的压缩策略
- 在HDFS上优先采用列式存储并结合压缩：如Parquet或ORC。二者内置多种编码器（如SNAPPY、ZSTD、GZIP、LZO），可在保持高效列式剪枝的同时显著降低存储与I/O。
- 典型实践：离线数仓/批处理选ORC+ZSTD/SNAPPY，交互式查询选Parquet+ZSTD/SNAPPY；结合合理的**块大小（如128MB–256MB）**与副本策略，获得更好的扫描与网络传输效率。
三 MapReduce与Hive等计算阶段的压缩配置
- 输入端：若源数据已压缩，Hadoop可据扩展名自动选择解码器；也可显式开启输入压缩。
- Map端输出（中间结果）：开启中间压缩可显著降低Shuffle网络与磁盘压力，常用Snappy或LZO。
- Reduce端输出：对最终落盘结果启用压缩（如Snappy/Gzip/Zstd），在存储与后续读取性能间平衡。
- 常用配置示例（MapReduce/作业级）：
- 开启Map输出压缩：mapreduce.map.output.compress=true；mapreduce.map.output.compress.codec=org.apache.hadoop.io.compress.SnappyCodec
- 开启Reduce输出压缩：mapreduce.output.fileoutputformat.compress=true；mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.SnappyCodec
这些配置可直接写入作业配置或客户端配置文件，以统一作业压缩策略。
四 集群与传输层压缩配置
- 在core-site.xml注册可用编解码器：io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec,DefaultCodec,BZip2Codec,LzoCodec,SnappyCodec,ZstdCodec（确保集群节点具备相应编解码库/Native库）。
- 在hdfs-site.xml可按需设置与压缩相关的I/O与块参数（如dfs.blocksize、io.file.buffer.size），以配合不同压缩算法的吞吐与I/O特性。
- 确保集群各节点启用并支持所选压缩编解码器，避免“能写不能读/解码失败”的不一致问题。
五 策略选择与落地建议
- 高吞吐与低延迟（实时/近实时）：选Snappy/LZ4；列式存储优先Parquet/ORC+Snappy。
- 高压缩比与成本优先（冷数据/归档）：选Gzip/Bzip2；若需分片与较好解压速度，可考虑LZO/Zstd。
- 大文件与可随机访问：选LZO（建索引）或Zstd；结合较大的HDFS块大小减少NameNode压力。
- 小文件治理：优先在采集/计算侧合并；确需归档可用HAR，但对NameNode仍有一定索引压力，建议与列式压缩结合使用。
- 持续评估：结合监控与基准测试（吞吐、CPU、I/O、作业耗时）在不同算法与参数间做权衡与迭代。