ClickHouse存储成本降一半？手把手教你用ZSTD和列编码优化实战

ClickHouse存储优化实战：ZSTD压缩与列编码的黄金组合

当数据量以每天TB级的速度增长时，存储成本就像个无底洞。我们团队曾经管理着一个超过200TB的ClickHouse集群，每月仅存储费用就高达数万美元。直到我们发现，通过合理的压缩策略和列编码组合，竟然能在不影响查询性能的前提下，将存储占用直接砍半。这不是理论上的数字游戏，而是经过生产环境验证的真实案例。本文将带你一步步实现这个目标，从全局压缩算法选择到列级别的精细调优，每个环节都有可落地的配置示例和效果对比。

1. 压缩算法选型：LZ4与ZSTD的实战对决

在ClickHouse的战场上，LZ4和ZSTD是两大主力压缩算法。LZ4以速度著称，而ZSTD则在压缩率上更胜一筹。但具体到你的业务场景，该如何选择？

先看一个真实案例：我们有一个存储用户行为事件的MergeTree表，原始大小约1.2TB。使用默认的LZ4压缩后，体积降至420GB。而切换到ZSTD(level=3)后，神奇的事情发生了——存储空间直接降到了280GB，节省了33%的空间，而查询延迟仅增加了8%。

配置方法很简单，在config.xml中添加：

<clickhouse> <compression> <case> <method>zstd</method> <level>3</level> </case> </compression> </clickhouse>

提示：ZSTD的压缩级别(1-22)需要权衡，级别越高压缩率越好但CPU消耗越大。生产环境建议从3开始逐步测试。

下表展示了我们在不同业务场景下的测试结果：

有趣的是，时序数据的压缩效果最好，这正是ZSTD的强项。如果你的业务中有大量时间序列数据（如监控指标、IoT传感器数据），ZSTD会给你惊喜。

2. 列编码：针对数据特性的精准打击

全局压缩只是第一道防线，真正的存储优化大师都在玩列编码(Column Codec)。ClickHouse提供了多种针对特定数据特性的编码方式：

• DoubleDelta：时序数据的黄金搭档
• Gorilla：缓慢变化浮点数的克星
• T64：整数类型的空间魔术师
• Delta：有序数据的压缩利器

以我们处理的一个物联网场景为例，设备温度读数表原始结构如下：

CREATE TABLE temperatures ( device_id UInt32, timestamp DateTime, temperature Float32 ) ENGINE = MergeTree() ORDER BY (device_id, timestamp)

应用列编码后的优化版本：

CREATE TABLE temperatures_optimized ( device_id UInt32 CODEC(T64, ZSTD), timestamp DateTime CODEC(DoubleDelta, ZSTD), temperature Float32 CODEC(Gorilla, ZSTD) ) ENGINE = MergeTree() ORDER BY (device_id, timestamp)

优化前后的存储对比令人震惊：

注意：修改已有表的编码需要使用ALTER TABLE MODIFY COLUMN，这会导致重写数据，建议在低峰期操作。

3. 组合拳实战：从理论到落地

纸上得来终觉浅，让我们通过一个完整的案例，展示如何系统性地优化一个生产环境中的大表。

假设我们有一个电商用户行为表：

CREATE TABLE user_events ( event_date Date, event_time DateTime, user_id UInt64, page_id UInt32, action_type Enum8('click'=1, 'view'=2, 'purchase'=3), device String, location_city UInt32, duration_sec UInt32, price Float32 ) ENGINE = MergeTree() PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, user_id)

优化步骤：

1. 分析列特性：

   • 时间序列：event_date, event_time
   • 枚举/低基数：action_type, location_city
   • 单调递增：user_id, page_id
   • 浮点数：price

2. 设计编码方案：

   CREATE TABLE user_events_optimized ( event_date Date CODEC(Delta, ZSTD), event_time DateTime CODEC(DoubleDelta, ZSTD), user_id UInt64 CODEC(T64, ZSTD), page_id UInt32 CODEC(Delta, ZSTD), action_type Enum8('click'=1, 'view'=2, 'purchase'=3) CODEC(T64, ZSTD), device String CODEC(ZSTD), location_city UInt32 CODEC(T64, ZSTD), duration_sec UInt32 CODEC(ZSTD), price Float32 CODEC(Gorilla, ZSTD) ) ENGINE = MergeTree() PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, user_id)

3. 实施效果验证： 我们对比了三个月数据的存储情况：

   指标	原始表	优化表	节省
   存储空间	14.7TB	6.2TB	58%
   平均查询延迟	342ms	365ms	+6.7%
   导入吞吐量	12GB/s	9GB/s	-25%

虽然写入吞吐有所下降，但考虑到存储成本减半和查询性能影响有限，这个trade-off完全值得。

4. 避坑指南：那些年我们踩过的坑

在实施压缩优化过程中，我们积累了一些血泪教训：

1. 不要过度追求压缩率： ZSTD级别超过5后，压缩率提升曲线明显平缓，而CPU消耗却直线上升。有一次我们将级别设为10，结果导入速度下降了60%，完全无法满足实时性要求。

2. 注意编码兼容性： Delta系列编码要求数据必须有序。我们曾对一个随机生成的ID列使用Delta编码，结果存储空间反而增大了30%。

3. 监控资源使用： 压缩和解压都需要CPU资源。建议在优化后监控以下指标：

   • system.metrics中的CompressedReadBufferBytes和CompressedWriteBufferBytes
   • system.processes中的CPU使用率变化

4. 测试，测试，再测试： 不同数据特征对压缩效果影响巨大。我们开发了一套自动化测试流程：

   # 采样1%的生产数据 clickhouse-client --query "SELECT * FROM prod_table SAMPLE 0.01" > sample_data.tsv # 创建测试表 clickhouse-client --query "CREATE TABLE test_table AS prod_table ENGINE = MergeTree() ORDER BY tuple()" # 导入数据 cat sample_data.tsv | clickhouse-client --query "INSERT INTO test_table FORMAT TSV" # 测试不同编码组合 ALTER TABLE test_table MODIFY COLUMN column1 CODEC(ZSTD, Delta)

5. 考虑冷热数据分离： 我们对超过3个月的冷数据使用ZSTD(level=5)，热数据使用ZSTD(level=1)，在存储和性能间取得了更好的平衡。

5. 进阶技巧：超越基础压缩

当标准压缩方案仍不能满足需求时，可以考虑这些进阶策略：

按列类型分组存储：

CREATE TABLE events_grouped ( -- 时间相关列 event_date Date CODEC(Delta, ZSTD), event_time DateTime CODEC(DoubleDelta, ZSTD), -- ID类列 user_id UInt64 CODEC(T64, ZSTD), device_id UInt32 CODEC(T64, ZSTD), -- 枚举/低基数列 country_code Enum16(...) CODEC(T64, ZSTD), event_type Enum8(...) CODEC(T64, ZSTD), -- 高基数字符串 url String CODEC(ZSTD), user_agent String CODEC(ZSTD), -- 度量值 duration Float32 CODEC(Gorilla, ZSTD), price Float64 CODEC(Gorilla, ZSTD) ) ENGINE = MergeTree() ORDER BY (event_date, user_id)

使用自定义压缩字典： 对于特定领域的高基数字符串（如药品名称、设备型号），可以预先生成字典：

CREATE TABLE medical_records ( drug_name String CODEC(ZSTD(3), LZ4HC(9, 'custom_dictionary.bin')), ... )

利用物化视图预聚合： 有时最好的压缩是存储更少的数据。我们对一些高频查询创建了物化视图：

CREATE MATERIALIZED VIEW metrics_daily ENGINE = MergeTree() ORDER BY (date, metric_name) AS SELECT toDate(timestamp) AS date, metric_name, avg(value) AS avg_value, quantile(0.95)(value) AS p95_value FROM raw_metrics GROUP BY date, metric_name

这个简单的改变，将我们的存储需求从50TB降到了800GB，同时使常用查询快了100倍。