0 序
本文围绕【压缩算法】展开分析，并阐释【压缩格式】、【归档格式】，及各自的特点和应用场景。
1 概述：压缩算法
作为软件工程师，尤其是数据工程师，压缩算法是数据存储、传输和计算优化的核心技术之一，其选型直接影响存储成本、IO 性能和计算效率。
在数据压缩领域里，文本压缩的历史最久，从Morse到Huffman和算术编码(Arithmetic coding)，再到基于字典和上下文的压缩算法。
各种算法不断改进，从通用算法，到现在更具针对性的专用算法，结合应用场景的垂直化的趋势越来越明显。
综上，在选择或者评价压缩算法，一定要结合实际应用场景加以考虑，包括：字符集、内容的大小、压缩及解压的性能、以及各端支持情况(特别是操作系统、浏览器和应用软件中)。
数据压缩算法
一套完整的压缩算法，实际以下几个部分：
其中，除编码外的三项目的都是找到一个适于编码的表示方法，而【编码】则是以简化的方法进行输出。
最典型的建模方法是基于字符的概率统计，而基于上下文的建模方法(Context Modeling)则是从文本内容出发，它们追求的目标都是让字符的出现概率越不平均越好。
转换方法是最具代表性的是基于词典的转换，比如庞大的LZ族系。
Huffman和算术编码则是常见的【编码方法】。
因为语言本身的特性，基于上下文的建模方法(Context Modeling，如PPM*系列算法)可以得到更好的【压缩比】，但却由于它的【性能问题】却很难普及。
当前比较流行的压缩算法中其突破的核心只有两个:
ANS (FSE是它的一个实现): Facebook zStd, Apple的lzfse等。
Context Modeling + LZ77 (编码是Huffman): Brotli, bz2也应用了其中的BWT算法。
下图为六种算法的压缩比测试的结果，分别针对一本英文小说，一本中文小说，和一份较小(4KB+)的中文混合的JSON数据。
其中PPM是Context Modeling的代表算法。
可以看到算法对字符集(中文与英文)和大小都是敏感的，表现各不相同。
算法思想的简述
Huffman编码受到了Morse编码的影响，背后的思想就是将最高概率出现的字母以最短的编码表示。比如英文中字母e出现概率为12%，字母z的出现概率还不到1%（数据来源:Letter Frequency）。
算术编码以及区间编码，它们是利用字符概率分布，将字符组合转变为概率的层次划分，最终转换一个固定的数字(算术编码和区间编码最大差别就在于一个使用小数，另一个使用整数)。可以对应下图考虑下AAAA，以及AAB的编码输出 (在0-1的轴上找到一个数字来表示。)。
参考维基上的说明: 算术编码。 上面这两类算法一直霸占着算法编码领域，各自拥有大量的变形算法。
压缩算法核心分类（按原理 + 特性）
无损压缩算法（Lossless Compression）
定义：解压后数据与原始数据完全一致，无任何信息丢失，适用于可容忍压缩速度，但要求数据完整性的场景。
如: 数据库备份、日志存储、结构化数据等场景。
算法名称
核心原理
压缩比
压缩速度
解压速度
内存占用
典型应用场景
开源实现/工具支持
DEFLATE
LZ77 + 霍夫曼编码
中（~2.5x）
中
快
低
通用文件压缩（ZIP/GZIP）、HDFS
JDK内置、Apache Commons Compress
GZIP
DEFLATE的包装格式（带校验+头信息）
中（~2.5x）
中
快
低
日志文件、API响应压缩
Hadoop CompressionCodec、Flink内置
BZIP2
Burrows-Wheeler 变换 + 霍夫曼编码
高（~3.5x）
慢
中
中
归档数据、离线备份
Hadoop BZip2Codec、pbzip2（并行）
LZ4
LZ77变种（快速查找重复序列）
低-中（~2x）
极快
极快
低
实时计算、内存数据压缩
Flink状态后端、Redis、ClickHouse
Zstandard（ZSTD）
LZ77 + 熵编码（支持多级别）
高（~4x，可调）
快-中
快
中
通用场景、大数据存储
Hadoop 3.x+、Spark、ClickHouse
Snappy
LZ77变种（优化CPU效率）
低-中（~1.8x）
极快
极快
低
实时流处理、列式数据库
Kafka、Parquet、HBase、Flink
LZO
LZ77变种（分块压缩）
低-中（~2x）
快
快
低
分布式存储、HDFS块压缩
Hadoop LzoCodec、Cloudera推荐
Brotli
LZ77 + 霍夫曼编码（支持字典优化）
高（~4.5x）
中-慢
中
中-高
静态资源、HTTP/2传输
Nginx、CDN、Spark 3.x+
有损压缩算法（Lossy Compression）
定义：通过丢弃非关键信息提升【压缩比】，解压后数据与原始数据存在差异，适用于对【精度要求不高】的场景。
如: 音视频、图像、AI模型等场景。
算法名称
核心原理
压缩比
适用场景
大数据/AI领域应用
JPEG/JPEG 2000
离散余弦变换（DCT）+ 量化
极高（~10x-100x）
图像存储、传输
计算机视觉数据集预处理（如ImageNet）
MP3/AAC
心理声学模型（丢弃人耳不可闻频率）
高（~10x-20x）
音频存储、流式传输
语音识别数据集压缩、语音AI训练
VP9/AV1
帧内预测 + 运动估计/补偿
极高（~20x-50x）
视频流、直播
视频监控大数据存储、AI视频分析
FP16/FP8/INT8
数值精度截断（浮点转低精度）
2x-4x
AI模型存储、推理加速
TensorFlow/PyTorch模型压缩、GPU推理
Sparse Coding
稀疏化矩阵（置零非关键权重）
3x-10x
神经网络模型压缩
深度学习模型部署（如MobileNet）
PCA降维
特征维度压缩（保留主成分）
按需调整
高维数据预处理、特征存储
机器学习特征工程、推荐系统
大数据领域关键压缩算法对比
针对大数据场景（存储、计算、传输）的核心需求（高吞吐、低延迟、高压缩比平衡）。
以下是最常用算法的深度对比：
评估维度
Snappy
【LZ4】
【ZSTD】
GZIP
BZIP2
压缩比（文本数据）
~1.8x-2.0x
~2.0x-2.2x
~3.5x-4.0x（级别10）
~2.5x-3.0x
~3.5x-4.0x
压缩速度（MB/s）
300-500（单线程）
500-800（单线程）
100-300（级别10）
50-100
10-30
解压速度（MB/s）
1500-2000（单线程）
2000-3000（单线程）
800-1200（级别10）
300-500
50-100
并行压缩支持
支持（分块并行）
支持（LZ4 Frame格式）
支持（多线程API）
部分支持（如pigz）
支持（pbzip2）
Hadoop生态支持
原生支持（2.x+）
原生支持（3.x+）
原生支持（3.x+）
完全支持
完全支持
Flink支持
状态后端、Checkpoint
状态后端、流压缩
Checkpoint、结果输出
结果输出
离线计算输出
ClickHouse支持
表引擎压缩、导入导出
表引擎压缩、数据传输
表引擎压缩（推荐）
导入导出
离线导入
Kafka支持
消息压缩（推荐）
消息压缩
消息压缩（2.1.0+）
消息压缩
不推荐（速度慢）
内存占用
低（~几十MB）
极低（~几MB）
中（级别越高占用越大）
低
中（~100MB）
场景举例
实时流（Kafka/Flink）、列式存储（Parquet）
实时计算（Flink状态）、Redis缓存
通用存储（HDFS/OSS）、离线计算
日志归档、API传输
离线归档、备份数据
关键结论：
实时场景（Kafka/Flink/ClickHouse）优先选 Snappy/LZ4（速度第一，压缩比够用）；
存储优化场景（HDFS/OSS/数据湖）优先选 ZSTD（压缩比高，速度不弱于GZIP）；
离线归档场景可选 BZIP2（压缩比最高，但速度最慢）；
兼容性要求高（如老系统）选 GZIP（生态支持最广）。
大数据技术栈中的压缩算法选型实践
A. Hadoop生态（HDFS/MapReduce/YARN）
HDFS块压缩：
实时处理场景：Snappy/LZ4（通过 io.compression.codec 配置）；
存储优化场景：ZSTD（Hadoop 3.3+ 推荐，org.apache.hadoop.io.compress.ZStandardCodec）；
归档数据：BZIP2（适合冷数据，压缩比最高）。
MapReduce/Spark任务压缩：
中间结果压缩：Snappy/LZ4（减少Shuffle IO，提升吞吐）；
输出结果压缩：ZSTD/GZIP（平衡压缩比和可读性）。
B. 实时计算（Flink/Kafka）
Kafka消息压缩：
生产者压缩：Snappy（默认推荐）/LZ4（高吞吐场景），通过 compression.type 配置；
消费者解压：Kafka自动解压，无需额外配置，优先选与生产者一致的算法。
Flink压缩配置：
状态后端压缩：LZ4（RocksDB状态后端默认，state.backend.rocksdb.compression）；
Checkpoint压缩：ZSTD（高压缩比，execution.checkpointing.compression）；
流数据压缩：Snappy（pipeline.operator-chaining.compression）。
C. 列式数据库（ClickHouse/Parquet/HBase）
ClickHouse：
表引擎压缩：默认LZ4，存储优化选ZSTD（ENGINE = MergeTree() ORDER BY ... SETTINGS compression = 'zstd'）；
导入导出：Snappy（快速导入）、ZSTD（导出归档）。
Parquet/Orc文件格式：
Parquet默认Snappy，支持ZSTD/LZ4（通过 parquet.compression 配置，Spark/Flink均支持）；
Orc默认ZLIB，推荐切换为Snappy/ZSTD（提升读写速度）。
HBase：
列族压缩：Snappy（默认推荐）/LZ4（高吞吐场景），通过 COMPRESSION => 'SNAPPY' 配置。
D. AI领域（模型存储/数据预处理）
模型压缩：
无损压缩：ZSTD（模型文件归档，如PyTorch .pth 文件）；
有损压缩：INT8/FP16量化（TensorRT/TorchQuantizer）、稀疏编码（TensorFlow Model Optimization）。
数据集压缩：
图像数据集：JPEG 2000（平衡质量和压缩比）；
音频数据集：AAC（语音识别场景）；
文本数据集：GZIP/ZSTD（JSON/CSV文件归档）。
关键技术细节与避坑指南
压缩级别选择：
ZSTD支持1-22级（默认3级），级别越高压缩比越高但速度越慢，大数据场景建议5-10级；
Snappy/LZ4基本无需调级（速度优先，级别对压缩比影响小）。
并行压缩优化：
大文件压缩（如GB级日志）优先使用并行实现：pbzip2（BZIP2）、pigz（GZIP）、zstdmt（ZSTD多线程）；
Hadoop 3.x+ 原生支持ZSTD/Snappy的并行压缩（通过 mapreduce.map.output.compress.codec 配置多线程 codec）。
兼容性问题：
老系统（Hadoop 2.x）可能不支持ZSTD，需优先选Snappy/GZIP；
跨语言场景（如Java→Python）避免使用LZO（依赖系统库，兼容性差），优先选Snappy/ZSTD。
性能监控指标：
压缩效率：压缩后体积/原始体积（目标≤0.5）；
吞吐率：MB/s（实时场景需≥100MB/s）；
CPU占用：Snappy/LZ4的CPU使用率通常≤30%，ZSTD级别10约50-70%。
常见压缩格式、归档格式与对应压缩算法对照表
这是整理好的常见压缩格式与对应算法对照表，清晰区分压缩格式/归档格式（归档容器）和压缩算法（核心技术）：
压缩格式
类型
默认使用的压缩算法
支持的其他算法
典型文件扩展名
核心特点
ZIP
归档+压缩格式
DEFLATE
BZIP2、LZMA、ZSTD（新版）
.zip
通用、跨平台，支持分卷/加密
RAR
专有归档+压缩格式
RAR算法（LZ77变种）
-
.rar
高压缩比，支持分卷/恢复记录
GZIP
单文件压缩格式
DEFLATE
-
.gz
常与TAR配合（.tar.gz）
BZIP2
单文件压缩格式
BZIP2
-
.bz2
高压缩比，速度慢，常与TAR配合
TAR
纯归档格式（无压缩）
-（仅打包）
-
.tar
保留文件结构/权限，需配合压缩算法
TAR.GZ / TGZ
TAR+GZIP
DEFLATE
-
.tar.gz、.tgz
平衡压缩比与速度，Linux常用
TAR.BZ2
TAR+BZIP2
BZIP2
-
.tar.bz2
高压缩比，适合归档冷数据
TAR.XZ
TAR+XZ
LZMA2
-
.tar.xz
极高压缩比，速度慢
LZ4
单文件/流式压缩格式
LZ4
-
.lz4
极快速度，常与TAR配合（.tar.lz4）
Snappy
流式压缩格式
Snappy
-
.snappy
极快速度，大数据场景常用
ZSTD
单文件/流式压缩格式
ZSTD
-
.zst
高压缩比+高速度，新一代通用选择
7Z
归档+压缩格式
LZMA2
DEFLATE、BZIP2、ZSTD等
.7z
极高压缩比，支持多种算法
这个表格能帮你快速对应“格式-算法”的关系~要不要我再补充一份不同场景下格式的推荐清单？
不同应用场景的压缩格式与归档格式推荐清单
不同应用场景的压缩格式与归档格式推荐清单**，结合格式特性和实际使用场景给出最优选择：
1. 日常文件传输/分享（通用场景）
推荐格式：ZIP
理由：【跨平台兼容性】强（Windows/macOS/Linux均支持），支持分卷、加密，默认DEFLATE算法平衡【压缩比】与解压缩速度。
替代选项：7Z（压缩比更高，但部分设备默认不支持）。
2. Linux/macOS系统下的文件归档
日常归档（速度优先）： TAR.GZ（.tgz）
理由：DEFLATE算法速度快，压缩比够用，系统原生支持。
冷数据归档（压缩比优先）： TAR.XZ
理由：LZMA2算法压缩比极高，适合长期存储的大文件。
中等需求： TAR.BZ2
理由：压缩比高于TAR.GZ，速度略慢，兼容性较好。
3. 大数据/编程场景
实时计算（如Kafka/Flink）： Snappy、LZ4
理由：压缩/解压速度极快，对吞吐影响小，常作为流式数据压缩格式。
数据湖/存储优化：ZSTD（.zst）+ TAR
理由：高压缩比+高速度，是HDFS、对象存储的新一代优选。
日志/文本文件： GZIP（.gz）
理由：兼容性强，压缩比适中，适合日志归档。
4. 大文件分卷传输（如超过1GB）
推荐格式：RAR、ZIP（分卷模式）
理由：支持分卷（拆分多个小文件）+ 恢复记录（RAR），传输中断可续传/修复。
替代选项：7Z（分卷功能更灵活）。
5. 纯文件打包（不压缩）
推荐格式：TAR
理由：仅打包不压缩，完整保留文件权限、目录结构，适合Linux系统内的文件迁移。
6. 高压缩比需求（如备份老数据）
推荐格式：7Z（LZMA2算法）、TAR.XZ
理由：压缩比远高于ZIP/RAR，适合体积敏感的归档场景（但速度较慢）。
开源工具与推荐资源
算法/工具
官方文档/源码链接
Snappy
https://github.com/google/snappy
LZ4
https://github.com/lz4/lz4
ZSTD
https://github.com/facebook/zstd
Hadoop压缩支持
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Compression.html
Flink压缩配置
https://nightlies.apache.org/flink/flink-docs-stable/docs/deployment/config/#compression
ClickHouse压缩
https://clickhouse.com/docs/en/operations/table-engines/mergetree-family/mergetree/#compression
Kafka压缩配置
https://kafka.apache.org/documentation/#compression_config
ZSTD
Maven : com.github.luben:zstd-jni:1.4.3-1
com.github.luben.zstd.Zstd
public static byte [] decompress(byte[] src, int originalSize) throws ZstdException
2 常用压缩算法
压缩格式
算法
文件扩展名
是否可切分
压缩比
压缩速度
解压速度
DEFLATE
DEFLATE
.deflate
否
高
低
低
Gzip
DEFLATE
.gz
否
高
低
低
BZip2
BZip2
.bz2
是
高
低
低
LZO
LZO
.lzo
是（需建索引）
低
高
高
LZ4
LZ4
.lz4
否
低
高
高
Snappy
Snappy
.snappy
否
低
高
高
Zstd
Zstd
.zst
否
高
高
高
Gzip
名称： GNU Zip 压缩
Gzip压缩原理：
以Deflate压缩算法为基础，而Deflate算法是LZ77压缩算法的优化和Huffman编码的一个结合。
特点：
Gzip 是一种通用的压缩算法，被广泛应用于文件压缩和网络传输。
具有较高的压缩比，适用于文本数据。
压缩和解压速度相对较慢。
适用场景：
适用于需要高压缩比的场景，如文本文件。
LZ77压缩算法
LZ77压缩算法是由Jacob Ziv 和 Abraham Lempel 于1977年提出，以此得名。
LZ77相关术语：
滑动窗口：编码的过程类似算法中“滑动窗口”算法的逻辑过程，包含look ahead buffer和search buffer
look ahead buffer（待检区）：
search buffer（搜索区）：
为了编码待编码区， 编码器在滑动窗口的搜索缓冲区查找直到找到匹配的字符串。
匹配字符串的开始字符串与待编码缓冲区的距离称为“偏移值”，匹配字符串的长度称为“匹配长度”。编码器在编码时，会一直在搜索区中搜索，直到找到最大匹配字符串，并输出(o, l )，其中o是偏移值， l是匹配长度。然后窗口滑动l，继续开始编码。如果没有找到匹配字符串，则输出(0, 0, c)，c为待编码区下一个等待编码的字符，窗口滑动“1”。
LZ77压缩逻辑示例：
示例元素：ABCCABCAD
搜索区长度：5
待检区长度：3
搜索前，搜索区和待检区以及字符串状态，搜区区为空，待检区内进入了三个元素，如图所示
待检区检查第一个元素A，发现搜索区没有匹配项目，因此元素A按照原码记录，如下图
依次检查后面的元素B和C，发现搜索区没有与之相匹配的重复元素，因此按照源码记录
下面检查元素C，发现在搜索区有该元素，因此使用（offset，length）编码元素C，即（1，1），如图：
后面进行元素A匹配，发现匹配项，然后在继续一位元素B，即AB元素，也发现匹配，最后找到ABC在搜素区找到匹配项，因此使用（4，3）进行对ABC元素的编码，后续查找方式类似，知道遍历元素末尾
当所有元素遍历完毕之后，会得到一个新的经过编码的表示串，即：ABC(1,1)(4,3)(2,1)D
可以看出LZ77算法的中心思想就是利用数据的重复结构信息来进行数据压缩。
通过LZ77对数据进行初步的压缩之后，后续通过Huffman编码再次进行数据压缩，下面看下Huffman coding的原理。
Huffman coding
相信很多人对Huffman这个词并不陌生，因为它是大学里面数据结构课程的一个算法内容。
该算法依据元素出现概率来构造异字头的平均长度最短的码字，有时称之为最佳编码，一般就叫做Huffman编码（有时也称为霍夫曼编码）。
哈夫曼编码，核心逻辑是根据使用频率来最大化节省字符（编码）的存储空间。通过较大的字符串表示频率小的字符串，相应的通过较小字符串表示出现频率比较大的字符串，通过这个差值减少元素串的尺寸。
下面以元素串【emm tell me the truth】为例子，演示Huffman编码过程以及结果：
首先扫面原元素串，统计每个元素的出现频率信息
依据二叉树的规则，将元素信息以出现频率为权重，构造一个最优二叉树，示例树如图所示：
根据既定路径规则（左子树路径：0，右子树路径：1），得到每个元素的Huffman编码如下所示：
上图展示了元素串：【emm tell me the truth】，经过Huffman编码后用位串表示：【01 110 110 00 01 100 100 110 01 00 101 01 00 1110 1111 00 101】。可以看到Huffman编码占用比较少的位来描述元素信息，且频率高的元素使用的描述位比较少。
Snappy
特点：
Snappy 是由 Google 开发的压缩算法，具有较高的压缩和解压速度。
压缩比：较高效，适用于二进制数据。
压缩速度：快，通常用于对性能要求较高的场景。
适用场景：
适用于需要快速压缩和解压的场景，如 Avro、Parquet 格式的数据。
Snappy 是什么？一种压缩算法
Snappy 在大数据生态系统中扮演着极其关键的角色——它是一种快速压缩/解压算法，广泛用于 ORC / Avro / Parquet 等数据存储格式的数据压缩环节。
下面我们来深入探讨 Snappy 与这些格式的关系及其在大数据中的定位。
Snappy 是由 Google 开发的一种高速压缩算法，其设计目标不是追求极致压缩比，而是在保持合理压缩率的同时，极大提升压缩和解压速度。
特点：
压缩速度极快（通常 > 200 MB/s）；
解压速度更快（可达 500–1000 MB/s）；
压缩比中等（通常为原始数据的 20%–30%，不如 GZIP 或 Zstandard）；
无损压缩；
开源（BSD 许可），被广泛集成到 Hadoop 生态中。
Snappy 与 ORC / Avro / Parquet 数据存储格式的关系
这三种数据存储格式本身定义的是数据的组织结构（行式/列式、元数据布局等），而【压缩算法】是可插拔的组件。Snappy 就是它们最常用的压缩选项之一。
格式
是否支持 Snappy
典型使用场景说明
Parquet
✅ 支持
Spark 默认推荐使用 Snappy 压缩 Parquet 文件，兼顾速度与空间
ORC
✅ 支持
Hive 中常配置 orc.compress=SNAPPY，尤其在需要快速查询时
Avro
✅ 支持
Kafka + Avro 场景中，Snappy 是常用压缩方式（如 value.serializer=io.confluent.kafka.serializers.KafkaAvroSerializer + compression.type=snappy）
Snappy 的局限性
尽管 Snappy 非常高效，但它并非万能：
压缩比不如 Zstandard（zstd）或 GZIP：对于存储成本极度敏感的冷数据归档场景，可能选择 zstd（兼顾高压缩比与较快速度）；
不支持流式压缩的随机访问：不过这对列式存储影响不大，因为 Parquet/ORC 本身已通过分块（Row Group / Stripe）实现局部读取；
内存占用略高：但在现代服务器环境下通常不是问题。
实际配置示例
Spark 写入 Snappy 压缩的 Parquet
df.write \
.option("compression", "snappy") \
.parquet("hdfs:///data/events/")
Hive 创建 Snappy 压缩的 ORC 表
CREATE TABLE logs (
id BIGINT,
message STRING
)
STORED AS ORC
TBLPROPERTIES ("orc.compress"="SNAPPY");
Kafka Producer 使用 Snappy + Avro
compression.type=snappy
value.serializer=io.confluent.kafka.serializers.KafkaAvroSerializer
LZ4
特点：
LZ4 是一种无损压缩算法，具有极高的压缩和解压速度。
压缩比：较低，但适用于高吞吐量的场景，对 CPU 消耗较小。
压缩速度：非常快，适用于对性能要求极高的场景。
适用场景：
适用于需要极高性能的场景，如实时数据传输。
LZ4以其超高的吞吐量而出名，它的压缩和解压缩速度非常快，其底层压缩原理特使参考了LZ77算法，在其基础之上做了优化，可以粗暴的理解为是一个用16k大小哈希表储存字典并简化检索的LZ77。
在LZ77算法进行压缩时，耗时最多的部分是在字典中找到待搜索缓存中最长的匹配字符。若是字典和待搜索缓存过短，则能找到匹配的几率就会很小。所以LZ4对LZ77针对匹配算法进行了改动。
首先，LZ4算法的字典是一张哈希表。 字典的key是一个4字节的字符串，每个key只对应一个槽，槽里的value是这个字符串的位置。
LZ4没有待搜索缓存， 而是每次从输入文件读入四个字节， 然后在哈希表中查找这字符串对应的槽，下文称这个字符串为现在字符串。如果已经到最后12个字符时直接把这些字符放入输出文件。如果槽中没有赋值，那就说明这四个字节第一次出现， 将这四个字节和位置加入哈希表， 然后继续搜索。如果槽中有赋值，那就说明我们找到了一个匹配值。
LZ4压缩的数据结构：
Token：令牌长为1字节，其中前4个字为字面长度(literal length)，而其后4个字为匹配长度(match length)
Literal length：literal长度超长补充
literals：非编码元素
Offset：偏差，和LZ77中的offset一样的含义，表示距离重复串的index
Match length：match串长度超长补充
ZSTD
特点：
Zstandard 是一种先进的压缩算法，由 Facebook 开发。
具有较高的压缩比和解压速度，优于 Gzip。
支持多个压缩级别，可以根据需求调整性能和压缩比。
适用场景：
适用于需要较高压缩比和较快解压速度的场景，具有很好的通用性。
Zstd (Zstandard) 是由 Facebook 开源的快速无损压缩算法，主要应用于 zlib 级别的实时压缩场景，并且具有更好的压缩比。
Zstd 还可以以压缩速度为代价提供更强的压缩比，速度与压缩率的比重可通过增量进行配置。
Zstd 是一项性能优秀的压缩技术，与 zlib、lz4、xz 等压缩算法不同，Zstd 寻求的是压缩性能与压缩率通吃的方案。Zstd 还为小数据提供了一种特殊的压缩模式 “字典压缩”，支持以训练方式生成字典文件，以提高对小数据包的压缩率。
Z FAQ for 压缩算法
Q: 选择压缩算法的考虑因素?
数据特性
不同的数据类型可能更适合不同的压缩算法。文本数据可能适合 Gzip，而二进制数据可能更适合 Snappy 或 LZ4。
性能要求
不同的压缩算法在压缩和解压速度上有差异。选择适当的算法取决于对性能的具体要求。
压缩算法性能对比
压缩比
不同算法的压缩比也是一个重要的考虑因素。在一些场景中，更高的压缩比可能更重要。
(跨平台/跨环境)兼容性
其他
Q: .zip , .rar , .tar 属于压缩算法吗？为什么？
.zip、.rar、.tar 不属于压缩算法，它们是文件格式（或归档格式）。
.zip/.rar是“带压缩功能的归档格式”（依赖特定压缩算法），.tar是“纯归档格式”（无压缩）——它们都不是压缩算法，而是“封装压缩数据的容器”。
具体原因(如下)：
核心概念区分
压缩算法：是“减少数据体积的数学方法”（比如DEFLATE、LZ4、RAR算法），是压缩功能的技术核心。
文件格式：是“封装压缩后数据的容器”，包含文件元信息（文件名、目录结构）+ 压缩后的数据（由特定算法生成）。
逐一分析
（1）.zip
它是归档压缩格式：本身是一个“容器”，内部默认使用 DEFLATE压缩算法（也支持其他算法），同时包含文件目录、元数据等信息。
简单说：.zip = 文件结构 + DEFLATE（或其他算法）压缩后的数据。
（2）.rar
它是专有归档压缩格式：内部使用 RAR自有压缩算法（属于LZ77变种），同样包含文件结构、分卷/加密等功能。
简单说：.rar = 文件结构 + RAR算法压缩后的数据。
（3）.tar
它是纯归档格式：本身不包含压缩功能，只是将多个文件/目录“打包”成一个文件（保留权限、目录结构），体积与原始文件总和基本一致。
通常会配合压缩算法使用（比如.tar.gz = .tar打包 + GZIP（DEFLATE）压缩）。
Q: LZ4C 又是什么？
LZ4C是LZ4【压缩算法】对应的命令行工具（或旧版工具名称）**。
主要用于在终端中执行LZ4格式的压缩/解压操作**，具体说明如下：
1. 核心定位
LZ4C本质是LZ4算法的命令行实现工具。
功能是将【文件/数据流】通过LZ4压缩算法压缩为.lz4格式，或解压.lz4文件。
2. 常见场景与特点
功能：支持文件压缩、解压、校验（如lz4c compress 文件/lz4c decompress 文件.lz4），也可通过管道处理数据流（如cat 大文件 | lz4c > 大文件.lz4）。
现状：部分环境中，lz4c是LZ4工具的旧版名称，现在更常用简化后的lz4命令（比如lz4替代lz4c，功能完全一致），lz4c逐渐被标记为“已弃用”。
关联工具：在Go语言生态中，lz4c也可能是Go版LZ4库（如github.com/pierrec/lz4）附带的命令行工具，用于Go项目的LZ4压缩操作。
3. 简单用法示例
# 压缩文件（生成 file.lz4）
lz4c compress file.txt
# 解压文件
lz4c decompress file.lz4
# 管道压缩（适合大文件）
cat large_data.bin | lz4c > large_data.lz4
LZ4C是操作LZ4压缩格式的命令行工具，现在大多直接用lz4命令替代~要不要我帮你整理一份LZ4（含LZ4C）的常用命令清单？
y. 推荐文献
[数据压缩] LZ4 压缩算法 - 博客园/千千寰宇
Q:大数据系统的压缩算法倾向性选择？
在分布式计算环境中（如 Spark、MapReduce），CPU 通常不是瓶颈，I/O 和网络才是。
使用 合适的压缩算法 可显著减少磁盘读写量和网络传输量；
解压开销极低，不会拖慢计算任务；
需在“压缩收益”和“处理延迟”之间取得平衡。
举个例子（以选择 snappy 压缩算法为例）：
一个 10GB 的 CSV 日志文件：
GZIP 压缩后 ≈ 2GB（压缩率 80%），但解压需 30 秒；
Snappy 压缩后 ≈ 3.5GB（压缩率 65%），解压仅需 3 秒；
在 Spark 读取 100 个这样的文件时，总 I/O 减少 65%，且几乎无 CPU 瓶颈，整体作业时间反而更短。
Y 推荐文献
[数据存储] 浅谈大数据领域的数据存储格式：ORC / Avro / Parquet / Arrow - 博客园/千千寰宇
X 参考文献
文本压缩算法的对比和选择 - Zhihu/UC内核发布 【TODO/待续】
压缩算法分析(Gzip/Snappy/Lz4/ZSTD) - CSDN
Java使用apache-commons-compress对文件进行压缩(LZ4、Gzip、Snappy、Zip、Tar) - 华为云开发者联盟 【TODO】
Apache common-compress : https://commons.apache.org/proper/commons-compress/examples.html
GzipUtil、LZ4Util、SnappyUtil、ZipUtil、TarUtil、CompressUtil
深度解析Kafka中的消息奥秘 - CSDN 【推荐】
在 Kafka 生产者中，可以通过配置 compression.type 属性来启用消息的压缩。常见的压缩算法有 “gzip”、“snappy”、“lz4”、“zstd” 等。
大数据学习11之Hive优化篇 - CSDN
计算密集型作业少用压缩(计算密集需要大量CPU资源，解压需要CPU资源，加重CPU负载)
IO密集型作业多用压缩(CPU消耗少，IO操作多)