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/dorisApache Doris 内置 ZSTD、LZ4、Snappy 三种存储压缩算法写数据时按块自动压缩。选对算法同样一份数据在磁盘上能省出 30%~50% 的空间选错了写入变慢、查询也跟着变差。本文从成本痛点出发讲清三个算法的差异、按场景选型的判断方法并给出可直接复制的配置。一个真实场景账单上的数字先于性能出问题假设你负责一个用户行为分析库每天通过 Stream Load 写入 100GB 日志一年下来原始数据超过 36TB。这时会出现两个矛盾的信号运维发现磁盘水位涨得快扩容预算批不下来但历史报表查询也不快怀疑是磁盘 IO 瓶颈。其实两者往往是同一个原因数据以较低的压缩比落在磁盘上读写的数据量偏大。Doris 的列存引擎在写入时按块执行压缩底层编解码见 be/src/util/block_compression.cpp 与 be/src/util/decompressor.cpp压缩比直接决定了磁盘占用而解压速度影响查询耗时。所以选哪种压缩算法不是玄学是一道可计算的题。三种算法画像先看懂各自的脾气Doris 支持的压缩类型定义在 gensrc/thrift/AgentService.thrift 和 gensrc/proto/segment_v2.proto 中。三个算法可以这样理解维度ZSTDLZ4Snappy压得有多小最好同数据下体积最小中等最差压缩速度最慢吃 CPU快快解压速度较快最快快运行内存中等低很低典型用途冷数据、归档、报表底表实时接入、高频查询Doris 默认值日志类、临时中间结果一句话总结ZSTD 拿 CPU 换空间LZ4 两头均衡Snappy 几乎不占 CPU 但空间省得少。三者没有绝对优劣只匹配不匹配的问题。按场景选型四个问题定算法不需要做复杂测试按下面顺序问自己四个问题数据多久动一次写完基本不查的归档、历史报表分区选 ZSTD把空间省到极致是不是实时链路Kafka 接入、分钟级刷新的表优先 LZ4压缩解压都快不会拖慢导入机器 CPU 富余吗如果 BE 节点 CPU 长期吃紧、又是高并发小查询Snappy 的解压开销最小能不能分区对待同一张表往往冷热共存这时用分区级覆盖而不是全表一刀切。对照下来场景推荐算法历史归档、冷分区、降本优先ZSTD实时流接入、高频点查LZ4默认即可CPU 紧张、日志流水Snappy冷热混合表热分区 LZ4 冷分区 ZSTD落地实操两处配置五分钟生效1. 全局默认改 conf/be.conf编辑 conf/be.conf设置集群默认压缩算法# 可选值LZ4 / ZSTD / SNAPPY默认 LZ4 storage_compression_method LZ42. 表级覆盖建表时指定全局设置改完要重启 BE影响面大更常用的做法是建表时用PROPERTIES精确控制冷热分区各用各的CREATE TABLE user_behavior ( user_id BIGINT, action STRING, event_time DATETIME ) PARTITION BY RANGE(event_time) ( PARTITION p_hot VALUES [(2026-01-01), (2026-03-01)), PARTITION p_cold VALUES [(2026-03-01), (2026-09-01)) ) PROPERTIES ( compression LZ4 -- 热分区保持快速读写 );对已建好的冷分区把compression改成ZSTD重建即可。块大小page_size相关参数一般用默认值如果单页数据偏大、压缩收益不明显再考虑调整页大小。效果验证与避坑别改完就不管了怎么确认压缩生效、省了多少两步就够-- 1. 看表的磁盘占用压缩后的真实体积 SELECT table_name, data_size FROM information_schema.tables WHERE database_name analytics_db; -- 2. 和未压缩或旧算法时期的体积对比算出压缩收益对比前后两次data_size再结合SHOW PARTITIONS里各分区的压缩类型就能确认冷分区确实按 ZSTD 落盘了。三个常见坑改算法不等于原地生效。压缩属性是写入时决定的已落盘的数据不会被自动重压。变更算法需要重建对应分区如重建表或重建分区别指望改个配置旧数据就变小重建选在低峰期。重建分区期间该部分数据不可查或查询变慢业务高峰期操作容易触发超时动手前先备份。用 Doris 的 backup/restore 能力给库做快照重建出问题可以回滚这是最便宜的保险。另外提醒一句版本问题ZSTD 在不同版本上可用的压缩级别不同1.2.0 之后的版本对 ZSTD 支持更完整老集群升级后再切 ZSTD 更稳妥。快速清单照着做一遍盘一遍存量表哪些是冷归档、哪些是实时热表各占多少磁盘确认 BE 版本 ≥ 1.2.0再对冷数据启用 ZSTD全局storage_compression_method保持 LZ4 作为默认表级按需覆盖冷热混合表热分区 LZ4冷分区 ZSTD分别验证data_size下降变更算法安排在业务低峰操作前先做 backup 快照上线后用information_schema.tables复查磁盘占用记录压缩收益压缩这件事在 Doris 里没有最强大盘只有最合适的那块。把冷数据交给 ZSTD 省空间把热数据留给 LZ4 保速度账单和查询时间会一起变好看。【免费下载链接】dorisApache Doris is a real-time analytics and hybrid search database for AI agents.项目地址: https://gitcode.com/GitHub_Trending/doris/doris创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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/dorisApache Doris 内置 ZSTD、LZ4、Snappy 三种存储压缩算法写数据时按块自动压缩。选对算法同样一份数据在磁盘上能省出 30%~50% 的空间选错了写入变慢、查询也跟着变差。本文从成本痛点出发讲清三个算法的差异、按场景选型的判断方法并给出可直接复制的配置。一个真实场景账单上的数字先于性能出问题假设你负责一个用户行为分析库每天通过 Stream Load 写入 100GB 日志一年下来原始数据超过 36TB。这时会出现两个矛盾的信号运维发现磁盘水位涨得快扩容预算批不下来但历史报表查询也不快怀疑是磁盘 IO 瓶颈。其实两者往往是同一个原因数据以较低的压缩比落在磁盘上读写的数据量偏大。Doris 的列存引擎在写入时按块执行压缩底层编解码见 be/src/util/block_compression.cpp 与 be/src/util/decompressor.cpp压缩比直接决定了磁盘占用而解压速度影响查询耗时。所以选哪种压缩算法不是玄学是一道可计算的题。三种算法画像先看懂各自的脾气Doris 支持的压缩类型定义在 gensrc/thrift/AgentService.thrift 和 gensrc/proto/segment_v2.proto 中。三个算法可以这样理解维度ZSTDLZ4Snappy压得有多小最好同数据下体积最小中等最差压缩速度最慢吃 CPU快快解压速度较快最快快运行内存中等低很低典型用途冷数据、归档、报表底表实时接入、高频查询Doris 默认值日志类、临时中间结果一句话总结ZSTD 拿 CPU 换空间LZ4 两头均衡Snappy 几乎不占 CPU 但空间省得少。三者没有绝对优劣只匹配不匹配的问题。按场景选型四个问题定算法不需要做复杂测试按下面顺序问自己四个问题数据多久动一次写完基本不查的归档、历史报表分区选 ZSTD把空间省到极致是不是实时链路Kafka 接入、分钟级刷新的表优先 LZ4压缩解压都快不会拖慢导入机器 CPU 富余吗如果 BE 节点 CPU 长期吃紧、又是高并发小查询Snappy 的解压开销最小能不能分区对待同一张表往往冷热共存这时用分区级覆盖而不是全表一刀切。对照下来场景推荐算法历史归档、冷分区、降本优先ZSTD实时流接入、高频点查LZ4默认即可CPU 紧张、日志流水Snappy冷热混合表热分区 LZ4 冷分区 ZSTD落地实操两处配置五分钟生效1. 全局默认改 conf/be.conf编辑 conf/be.conf设置集群默认压缩算法# 可选值LZ4 / ZSTD / SNAPPY默认 LZ4 storage_compression_method LZ42. 表级覆盖建表时指定全局设置改完要重启 BE影响面大更常用的做法是建表时用PROPERTIES精确控制冷热分区各用各的CREATE TABLE user_behavior ( user_id BIGINT, action STRING, event_time DATETIME ) PARTITION BY RANGE(event_time) ( PARTITION p_hot VALUES [(2026-01-01), (2026-03-01)), PARTITION p_cold VALUES [(2026-03-01), (2026-09-01)) ) PROPERTIES ( compression LZ4 -- 热分区保持快速读写 );对已建好的冷分区把compression改成ZSTD重建即可。块大小page_size相关参数一般用默认值如果单页数据偏大、压缩收益不明显再考虑调整页大小。效果验证与避坑别改完就不管了怎么确认压缩生效、省了多少两步就够-- 1. 看表的磁盘占用压缩后的真实体积 SELECT table_name, data_size FROM information_schema.tables WHERE database_name analytics_db; -- 2. 和未压缩或旧算法时期的体积对比算出压缩收益对比前后两次data_size再结合SHOW PARTITIONS里各分区的压缩类型就能确认冷分区确实按 ZSTD 落盘了。三个常见坑改算法不等于原地生效。压缩属性是写入时决定的已落盘的数据不会被自动重压。变更算法需要重建对应分区如重建表或重建分区别指望改个配置旧数据就变小重建选在低峰期。重建分区期间该部分数据不可查或查询变慢业务高峰期操作容易触发超时动手前先备份。用 Doris 的 backup/restore 能力给库做快照重建出问题可以回滚这是最便宜的保险。另外提醒一句版本问题ZSTD 在不同版本上可用的压缩级别不同1.2.0 之后的版本对 ZSTD 支持更完整老集群升级后再切 ZSTD 更稳妥。快速清单照着做一遍盘一遍存量表哪些是冷归档、哪些是实时热表各占多少磁盘确认 BE 版本 ≥ 1.2.0再对冷数据启用 ZSTD全局storage_compression_method保持 LZ4 作为默认表级按需覆盖冷热混合表热分区 LZ4冷分区 ZSTD分别验证data_size下降变更算法安排在业务低峰操作前先做 backup 快照上线后用information_schema.tables复查磁盘占用记录压缩收益压缩这件事在 Doris 里没有最强大盘只有最合适的那块。把冷数据交给 ZSTD 省空间把热数据留给 LZ4 保速度账单和查询时间会一起变好看。【免费下载链接】dorisApache Doris is a real-time analytics and hybrid search database for AI agents.项目地址: https://gitcode.com/GitHub_Trending/doris/doris创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
