压缩格式选型与权衡
压缩本质是在 CPU 与 IO 之间做兑换：Snappy 压缩与解压都快、压缩比中等，Zstd 压缩比高且解压快，Gzip 压缩比高但压缩过程吃 CPU。列式格式（ORC、Parquet）自带压缩编码，通常只需选内部编码；中间过程数据与长期落地数据可以分别选择，不必统一。
基本信息
| Snappy | 速度快，压缩比中等 |
|---|---|
| Zstd | 压缩比高，解压快 |
| Gzip | 压缩比高，压缩耗 CPU |
| 列式文件 | ORC / Parquet 内部编码可选 |
| 选择依据 | IO 与 CPU 哪个更紧张 |
典型使用场景
- 中间过程数据：用 Snappy 换取更短的任务耗时
- 长期存储的表：用 Zstd 降低存储成本，解压开销尚可接受
- 低频归档数据：可用 Gzip 追求更高的压缩比
- 列式表按需要选择编码：数值列可考虑压缩比更高的编码
- 成本评估：把压缩带来的 CPU 增量与 IO 节省放在一起比较再决定
参数设置
参数设置
-- 中间结果压缩：优先降低 IO 与任务耗时
set hive.exec.compress.intermediate=true;
set mapreduce.map.output.compress.codec=org.apache.hadoop.io.compress.SnappyCodec;
set mapreduce.output.fileoutputformat.compress=true;
set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.SnappyCodec;
-- 落地表在 DDL 中指定格式与内部编码（ORC 示例）
-- CREATE TABLE t (...) STORED AS ORC TBLPROPERTIES ('orc.compress' = 'SNAPPY');压缩格式对照
| 格式 | 压缩比 | CPU 开销 | 适用 |
|---|---|---|---|
| Snappy | 中等 | 低 | 中间过程数据 |
| Zstd | 高 | 解压低、压缩中等 | 长期存储 |
| Gzip | 高 | 高 | 低频归档 |
| 不压缩 | 无 | 无 | 极热的小数据集 |
压缩格式对上层 SQL 基本透明，可以在不改语句的前提下按表调整，属于成本低、可回退的优化手段。
对已经是列式压缩的 ORC 或 Parquet 文件再整体包一层 Gzip，既浪费 CPU，又让引擎无法按列裁剪与跳读，查询会退化成整文件解压。
选压缩不看单次测试：同一份数据在写入一次、读取多次的场景里，读取端的解压开销会被放大很多倍；评估时以「写入加多次读取」的总成本为准，而不是只看写入耗时。
压缩与文件布局是配套的两件事：单文件过小的时候，压缩比再高也挡不住文件数带来的元数据与打开开销，先把文件大小收敛到目标区间，再谈压缩编码选择。