ClickHouse 21.8.4.51版本TTL失效问题求助

使用Spark Streaming消费Kafka数据写入ClickHouse（版本21.8.4.51），表DDL如下：

CREATE TABLE dataplugin.ods_stb_boot_up_delay_all_local ON CLUSTER '{cluster}'(
`evtTime` Int64,
`evtCode` String,
`pVer` String,
`stbID` String,
`bootUpDelay` Int64,
`provinceCode` String,
`writeTime` DateTime,
INDEX pattern_match stbID TYPE ngrambf_v1(3,256,2,0) GRANULARITY 3
)
ENGINE=ReplicatedMergeTree('/clickhouse/ods_stb_boot_up_delay_all_local/{shard}','{replica}') 
PARTITION BY toYYYYMMDD(writeTime) 
ORDER BY (stbID,evtTime) 
TTL writeTime + INTERVAL 3 MONTH 
SETTINGS 
merge_with_ttl_timeout = 86400,
index_granularity = 8192,
use_minimalistic_part_header_in_zookeeper=1

2022年11月30日执行查询发现仍存在过期数据：

# Query:
select count(1) from dataplugin.ods_stb_boot_up_delay_all_local where writeTime <= '2022-07-01 00:00:00';
# Result:
_____count()______
|   37323403     |
|________________|

已尝试执行以下操作但无效：

• ALTER table #{tableName} MATERIALIZE TTL
• OPTIMIZE TABLE #{tableName} ON '{cluster}' FINAL
• system start TTL MERGES

当前因表数据量过大导致ZooKeeper副本节点znode数量激增，存在ClickHouse服务器重启失败风险。

1. 快速清理过期分区（紧急处理） #

由于表按toYYYYMMDD(writeTime)分区，过期数据对应2022年6月及更早的分区，直接删除这些分区是最高效的方式，且能同步清理ZK元数据：

ALTER TABLE dataplugin.ods_stb_boot_up_delay_all_local ON CLUSTER '{cluster}'
DROP PARTITION WHERE toYYYYMMDD(writeTime) <= 20220630;

说明：ReplicatedMergeTree的分区删除是集群级原子操作，会自动同步到所有副本，能快速降低ZK节点负载。

2. 排查TTL未自动触发的根因 #

（1）检查TTL任务与mutation状态 #

在每个集群副本上执行以下命令，确认TTL任务是否堆积：

-- 查看待处理的TTL任务
SELECT * FROM system.ttl_queue;
-- 查看未完成的mutation（包括TTL触发的合并）
SELECT * FROM system.mutations WHERE is_done = 0;

如果队列中有大量待处理任务，说明集群CPU/IO资源不足，导致TTL合并无法及时完成。

（2）临时调高TTL合并资源优先级 #

针对21.8.4.51版本，可通过动态配置提升TTL合并效率：

-- 提高每秒允许的TTL合并数（默认值较低）
SET GLOBAL max_merges_with_ttl_per_second = 10;
-- 缩短TTL合并检查间隔（从默认86400秒改为3600秒）
SET GLOBAL merge_with_ttl_timeout = 3600;

若需永久生效，可修改ClickHouse节点的config.xml配置并重启。

（3）校验writeTime字段有效性 #

确认writeTime字段无NULL或异常值，否则这类数据不会被TTL规则匹配：

SELECT min(writeTime), max(writeTime), count(*) FROM dataplugin.ods_stb_boot_up_delay_all_local WHERE writeTime IS NULL;

若存在NULL值，需单独清理：

ALTER TABLE dataplugin.ods_stb_boot_up_delay_all_local ON CLUSTER '{cluster}'
DELETE WHERE writeTime IS NULL;

3. 缓解ZK节点压力 #

（1）清理ZK无效元数据 #

登录ZK节点，手动清理已删除分区对应的无效znode（操作前需备份ZK数据）：

zkCli.sh
# 查看表对应的ZK路径下的分区节点
ls /clickhouse/ods_stb_boot_up_delay_all_local/{shard}/{replica}/parts
# 删除已确认失效的分区节点
rmr /clickhouse/ods_stb_boot_up_delay_all_local/{shard}/{replica}/parts/[失效分区名]

（2）保持ZK存储优化配置 #

当前表已设置use_minimalistic_part_header_in_zookeeper=1，该配置可大幅减少ZK存储的元数据体积，建议集群内所有ReplicatedMergeTree表统一启用。

4. 长期预防措施 #

• 优化Spark写入逻辑：调整批次大小，合并小文件，减少小分区数量，降低ZK元数据基数。
• 定时手动清理：通过定时任务（如Crond、Airflow）定期执行分区删除命令，作为TTL自动清理的补充。
• 升级ClickHouse版本：21.8版本较老旧，后续版本对TTL合并、ZK元数据管理的稳定性有明显提升，建议升级至22.3及以上版本。

内容的提问来源于stack exchange，提问作者minyan-xiao