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

把一份日志表的落盘体积再压低 10%~30%，查询延迟基本不动——在 Apache Doris 里，这件事只需要在建表语句里改一行属性。这个实时分析数据库内置了 7 种压缩算法（SNAPPY、LZ4、LZ4F、LZ4HC、ZLIB、ZSTD、NO_COMPRESSION），集群默认走 LZ4；热数据保持它、冷数据切 ZSTD，存储成本就能降一档，而亚秒级查询不受影响。

7 种算法的适用边界：默认值为什么是 LZ4

Doris 的列存按块压缩：数据写入时每个块独立编码，读取时按页解压，所以选算法本质是在"落盘字节数"和"CPU 时间"之间做交换。可选集合定义在 gensrc/thrift/AgentService.thrift 的TCompressionType枚举里，BE 侧的编解码实现在 be/src/storage/ 目录下。

默认值是 LZ4：FE 侧表属性的初始定义见 TableProperty.java（compressionType = TCompressionType.LZ4F），与 Thrift 接口的默认值一致。选它做默认是合理的——实时分析数据库的读写都在延迟敏感路径上，LZ4 的解压吞吐在 GB/s 级，几乎不占查询时间。📉

表级压缩属性怎么写：PROPERTIES 里的 compression 一行

集群默认之外，每张表可以用compression表属性覆盖，属性键定义在 PropertyAnalyzer.java。新建表时直接写进PROPERTIES：

CREATE TABLE user_behavior ( user_id BIGINT, action STRING, event_time DATETIME ) DUPLICATE KEY(user_id, event_time) DISTRIBUTED BY HASH(user_id) BUCKETS 8 PROPERTIES ( "compression" = "zstd" -- 覆盖集群默认 LZ4，全表块级压缩 );

取值就是枚举名（zstd / lz4 / snappy 等），改一行即完成覆盖。注意集群级默认另由 FE 配置default_compression_type控制，表属性优先级高于它——这一点可以从 Env.java 中"表压缩类型与默认值不一致才输出到 SHOW CREATE"的检查逻辑看出来。

选型决策图：按查询模式选，不按习惯选

直觉常常是"哪个快用哪个"，但压缩算法的收益不对称：写路径吃压缩速度，读路径吃解压速度，存储账单吃压缩率。三个维度拆开看：

三句话版结论：

• 热表（分钟级写入、秒级查询）：保持默认 LZ4，别动。
• 冷表（天级以上分区、报表归档）：切 ZSTD，收益直接体现在账单上。
• 低配环境跑临时表：SNAPPY 的资源占用最低。

换算法的完整动作：改属性、重写旧数据、验证收益

以一张月度日志表从 LZ4 切 ZSTD 为例，完整动作只有三步，缺一不可：

1. 属性生效面：新算法只作用于之后写入的数据，已落盘的旧数据不会自动重压缩——这是换算法最容易漏的一环。
2. 重写旧数据：对历史分区重新导入或重建分区，让存量数据按 ZSTD 重新编码。
3. 验证收益：对比切换前后的磁盘占用，并确认查询 Profile 里解压耗时没有回退：

-- 对比切换前后该库各表的数据大小 SHOW DATA FROM analytics_db;

文本、日志、行为序列这类数据可压缩性好，切换后单分区体积通常下降 10%~30%；数值宽表收益小一些，随机二进制几乎无收益。收益是"通常"而不是"必然"，所以第三步的验证不能省。

避坑清单：4 个换压缩算法前必查的误区

1. 以为压缩率人人相同：数据特征决定一切。已经压缩过的字段（gzip 后再 base64 的附件、二进制列）再压一次，收益接近 0 甚至变大。
2. 改完属性就等收益：旧数据不重压，等于白改。
3. 拿 ZSTD 追解压速度：方向反了。ZSTD 的价值在压缩率，解压速度依然远快于 ZLIB；追解压速度请留在 LZ4。
4. 纠结 LZ4 与 SNAPPY 的速度：两者同处 GB/s 级，差距不构成选型理由，LZ4 还是默认值。

⚠️ 警告：切换压缩算法只影响新写入与重写的数据，存量分区的收益必须靠重写兑现；生产表建议在低峰期执行，并先做 backup 快照。

关键结论就一句：热数据 LZ4、冷数据 ZSTD，用compression表属性落地，用SHOW DATA验证——存储成本降一档，查询延迟不动。

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