Apache Doris 压缩算法怎么选：ZSTD、LZ4、Snappy 配置指南-开发者社区

Apache Doris 压缩算法怎么选：ZSTD、LZ4、Snappy 配置指南

【免费下载链接】dorisApache Doris is a real-time analytics and hybrid search database for AI agents.项目地址: https://gitcode.com/GitHub_Trending/doris/doris

在 Apache Doris 中，压缩算法的选择直接决定两个数字：数据落到磁盘占多少空间，以及查询读回时多花多少毫秒。生产上可选的其实是三选一——ZSTD、LZ4、Snappy，一句话原则是：为存储成本选 ZSTD，为查询速度选 LZ4。下文先给出三者的定位，再按"集群默认 → 单表覆盖 → 效果验证"讲配置路径，最后给两条可执行的判断规则。

Doris 压缩算法对比：三种定位各占一席

Doris 的列存按数据块粒度压缩：一列数据先编码，再经过压缩编解码器写入磁盘，底层接口在 be/src/util/block_compression.h。三种算法的差异在于压缩率与 CPU 开销的取舍：

算法	压缩率档位	压缩速度	解压速度	典型定位
ZSTD	高（约 1.5～3 倍）	中	中快	大体积、少更新的数据
LZ4	中（约 1.2～1.8 倍）	快	快	热数据、高频查询
Snappy	低（约 1.1～1.5 倍）	快	快	低压缩性的日志类数据

ZSTD 是省存储的主力。压缩率明显高于另外两者，且数据量越大优势越明显；代价是压缩时 CPU 开销最高，不适合毫秒敏感的实时写入链路，更适合历史分区、离线报表这类"一次写入、多次读取"的位置。

LZ4 是查询速度的均衡解。压缩和解压都快，解压开销在多数场景可忽略。点查 QPS 高、延迟敏感、写入端 CPU 已经吃紧时，LZ4 是热数据分区的首选。

Snappy 是低压缩性数据的兜底。压缩率三者最低，但速度不输 LZ4，工程上最省心。日志、文本、随机序列这类本身可压缩性差的数据，硬上 ZSTD 不会多省多少空间，只会多烧 CPU，Snappy 更合适。

storage_compression_method 配置：默认值、单表覆盖、验证

配置分三层，后者覆盖前者，按顺序做：

集群默认：在 conf/be.conf 中指定新数据的全局默认算法，不配置时默认为 LZ4。

# conf/be.conf，可选 ZSTD / LZ4 / SNAPPY storage_compression_method = ZSTD

单表覆盖：建表时用PROPERTIES里的compression指定单表算法，优先级高于集群默认；可选枚举可对照 gensrc/proto/segment_v2.proto（含 ZSTD、LZ4、LZ4F、ZLIB、SNAPPY、LZ4HC 等）。

CREATE TABLE user_behavior ( user_id BIGINT, action STRING, event_time DATETIME ) PROPERTIES ("compression" = "LZ4");

效果验证：数据落盘后，用information_schema.partitions_meta算实际压缩比，用数字代替感觉。

SELECT table_name, ROUND(SUM(data_size) / SUM(data_size_compressed), 2) AS ratio FROM information_schema.partitions_meta GROUP BY table_name ORDER BY ratio DESC;

⚠️ 压缩算法只作用于新写入的数据。存量数据不会自动重压，需要重建分区或备份恢复后重写。

Doris 压缩率选型：只看两个变量

不用画流程图，按顺序问两个问题：

更新频率：同一分区是否每天被反复修改？
- 一次写入、基本不再更新 →ZSTD，用 CPU 换空间。
- 频繁 update/delete，数据长期"半热" →LZ4，重写 segment 的开销要尽量低。
查询压力：这张表的读 QPS 是否上千且延迟敏感？
- 是 →LZ4，解压几乎不占 CPU，读路径上限更稳。
- 否（报表、离线分析） →ZSTD，解压多花几毫秒，省下的空间更值。
- 数据本身可压缩性差（日志、随机串） →Snappy，ZSTD 在这里烧 CPU 也换不来空间。

拿不准就用 LZ4：它贴近 Doris 的默认方向，两边都不会错得太远。

真实场景与上线前避坑

案例（示例数据）：某电商的用户行为日志表，约 20TB，Snappy 下实测压缩比 1.3 倍；切 ZSTD 并重建分区后升到约 2.7 倍，存储占用减少约一半，夜间报表窗口 CPU 占用上升，但整体耗时反而缩短约 15%（IO 减少所致）。这组数字仅供量级参考，实际比率完全取决于你的数据可压缩性。

避坑清单：