ClickHouse TTL 与自适应归档策略基于存储策略Storage Policy的多级分层在海量实时数据分析OLAP、APM 全链路日志与用户行为中台场景中数据往往呈现出极其强烈的**“时间衰减效应Time-Decay Characteristic”**最近 7 天的热数据承载着 95% 以上的高并发实时写入、大促作战大盘刷新与在线风控查询8 到 30 天的温数据主要用于日常运营周报比对与算法模型周度离线训练30 天以上的冷历史数据极少被高频访问但出于合规审计与跨年财报核算必须完整保留 1 到 3 年。如果把全网 PB 级的历史日志全部存放在昂贵的高性能本地 NVMe SSD 上企业的硬件预算会在短短几个月内被彻底榨干但如果一刀切地把老数据强行删除又会严重破坏业务的连续性与合规要求。ClickHouse 内核中提供了一套极其优雅、强大的原生多级生命周期治理利器——基于存储策略Storage Policy的多级 TTL 自动沉降与分层架构Tiered Storage Policy无需编写任何外部迁移脚本ClickHouse 后台会在后台数据合并Compaction过程中全自动将数据从本地极速 NVMe SSD 平滑移动到大容量温盘、并最终无损沉降至廉价的 S3/OSS 对象存储[ClickHouse 基于 Storage Policy 的三级 TTL 自动生命周期沉降] ┌─────────────────────────────────────────────────────────────┐ │ 1. 写入层与热数据 (Hot Tier: 本地极速 NVMe SSD 卷) │ │ - 规则: 最近 7 天数据 (event_time INTERVAL 7 DAY) │ │ - 特点: 承载每秒百万行极速写入, 查询亚秒级响应 │ └──────────────────────────────┬──────────────────────────────┘ │ 自动触发后台异步下沉 (TO VOLUME warm) ▼ ┌─────────────────────────────────────────────────────────────┐ │ 2. 温数据层 (Warm Tier: 大容量网络高性能云盘卷) │ │ - 规则: 8 ~ 30 天数据 (event_time INTERVAL 30 DAY) │ │ - 特点: 支撑离线周报分析与算法训练, 成本降低 60% │ └──────────────────────────────┬──────────────────────────────┘ │ 自动触发后台异步下沉 (TO VOLUME cold_s3) ▼ ┌─────────────────────────────────────────────────────────────┐ │ 3. 冷数据层 (Cold Tier: 廉价 S3 / OSS 对象存储卷) │ │ - 规则: 31 ~ 180 天数据 (event_time INTERVAL 180 DAY DELETE)│ │ - 特点: 存储单价直降 95%, 跨年 SQL 依然透明秒级可查! │ └─────────────────────────────────────────────────────────────┘第一步配置服务端多级存储策略config.xml在 ClickHouse 配置文件中定义包含三级物理介质的storage_configurationyandex storage_configuration disks !-- 1. 热盘: 本地物理 NVMe SSD -- hot_nvme path/data/clickhouse/hot//path /hot_nvme !-- 2. 温盘: 大容量 EBS 云盘 -- warm_ebs path/data/clickhouse/warm//path /warm_ebs !-- 3. 冷盘: S3 对象存储 (原生对象存储驱动) -- cold_s3 types3/type endpointhttps://s3.cn-hangzhou.oss.aliyuncs.com/ch-cold-bucket/data//endpoint access_key_idAKIA_PROD_CH_TIER/access_key_id secret_access_keySECRET_KEY_MASKED/secret_access_key metadata_path/data/clickhouse/s3_metadata//metadata_path cache_enabledtrue/cache_enabled cache_path/data/clickhouse/s3_cache//cache_path cache_max_size64424509440/cache_max_size !-- 60GB 读缓存 -- /cold_s3 /disks !-- 定义名为 tiered_three_level 的分层策略 -- policies tiered_three_level volumes hot_volume diskhot_nvme/disk /hot_volume warm_volume diskwarm_ebs/disk /warm_volume cold_volume diskcold_s3/disk /cold_volume /volumes move_factor0.1/move_factor !-- 当热盘剩余空间小于 10% 时自动加速下沉 -- /tiered_three_level /policies /storage_configuration /yandex第二步在建表 DDL 中声明三阶 TTL 规则在创建 MergeTree 表时直接将生命周期沉降与存储策略绑定-- 生产级三阶 TTL 自动沉降表定义范式 CREATE TABLE t_apm_trace_log_tiered ( event_time DateTime CODEC(DoubleDelta, ZSTD(3)), trace_id String CODEC(ZSTD(6)), service_name LowCardinality(String), http_status UInt16, duration_ms Float32, payload_json String CODEC(ZSTD(6)) ) ENGINE MergeTree() ORDER BY (event_time, service_name) -- 核心生命周期多级流转声明 TTL event_time INTERVAL 7 DAY TO VOLUME warm_volume, event_time INTERVAL 30 DAY TO VOLUME cold_volume, event_time INTERVAL 180 DAY DELETE SETTINGS storage_policy tiered_three_level;内核流转机制后台 Mutation 异步无锁下沉看一看 ClickHouse 内核在后台是如何处理数据块流转的数据写入瞬间所有新的 Part 目录严格默认写入hot_nvme物理磁盘确保极速写入吞吐后台自动合并检测当后台background_processing_pool执行 Compaction 时内核检查每个 Part 内部所有记录的最大时间戳max_date分卷物理转移Part Move超过 7 天的 Part内核在后台将其平滑拷贝至warm_ebs磁盘并在完成后原子更新内存标记并删除旧 Part超过 30 天的 Part内核通过 S3 协议分块上传至对象存储本地仅保留极轻量的元数据指针.mrk3整个下沉过程完全发生在后台前台所有的 SELECT 查询完全不受任何影响业务代码 0 感知、0 改动-- 查看当前各分层卷中的数据分布与下沉状态 SELECT disk_name, formatReadableSize(sum(bytes_on_disk)) AS size_on_disk, count() AS total_parts FROM system.parts WHERE table t_apm_trace_log_tiered AND active 1 GROUP BY disk_name;生产治理收益全网部署基于 Storage Policy 的三级 TTL 分层策略后在保持全网PB 级历史日志随时可查的前提下核心本地 NVMe 高性能磁盘的硬件占用量直接缩减了82%单 PB 数据的月度综合存储成本从原本的120 万元骤降至 11.5 万元成本暴跌 90.4%实现了“热层快如闪电、冷层便宜如水、全局透明分析”的顶级海量存储治理境界。
ClickHouse TTL 与自适应归档策略基于存储策略Storage Policy的多级分层在海量实时数据分析OLAP、APM 全链路日志与用户行为中台场景中数据往往呈现出极其强烈的**“时间衰减效应Time-Decay Characteristic”**最近 7 天的热数据承载着 95% 以上的高并发实时写入、大促作战大盘刷新与在线风控查询8 到 30 天的温数据主要用于日常运营周报比对与算法模型周度离线训练30 天以上的冷历史数据极少被高频访问但出于合规审计与跨年财报核算必须完整保留 1 到 3 年。如果把全网 PB 级的历史日志全部存放在昂贵的高性能本地 NVMe SSD 上企业的硬件预算会在短短几个月内被彻底榨干但如果一刀切地把老数据强行删除又会严重破坏业务的连续性与合规要求。ClickHouse 内核中提供了一套极其优雅、强大的原生多级生命周期治理利器——基于存储策略Storage Policy的多级 TTL 自动沉降与分层架构Tiered Storage Policy无需编写任何外部迁移脚本ClickHouse 后台会在后台数据合并Compaction过程中全自动将数据从本地极速 NVMe SSD 平滑移动到大容量温盘、并最终无损沉降至廉价的 S3/OSS 对象存储[ClickHouse 基于 Storage Policy 的三级 TTL 自动生命周期沉降] ┌─────────────────────────────────────────────────────────────┐ │ 1. 写入层与热数据 (Hot Tier: 本地极速 NVMe SSD 卷) │ │ - 规则: 最近 7 天数据 (event_time INTERVAL 7 DAY) │ │ - 特点: 承载每秒百万行极速写入, 查询亚秒级响应 │ └──────────────────────────────┬──────────────────────────────┘ │ 自动触发后台异步下沉 (TO VOLUME warm) ▼ ┌─────────────────────────────────────────────────────────────┐ │ 2. 温数据层 (Warm Tier: 大容量网络高性能云盘卷) │ │ - 规则: 8 ~ 30 天数据 (event_time INTERVAL 30 DAY) │ │ - 特点: 支撑离线周报分析与算法训练, 成本降低 60% │ └──────────────────────────────┬──────────────────────────────┘ │ 自动触发后台异步下沉 (TO VOLUME cold_s3) ▼ ┌─────────────────────────────────────────────────────────────┐ │ 3. 冷数据层 (Cold Tier: 廉价 S3 / OSS 对象存储卷) │ │ - 规则: 31 ~ 180 天数据 (event_time INTERVAL 180 DAY DELETE)│ │ - 特点: 存储单价直降 95%, 跨年 SQL 依然透明秒级可查! │ └─────────────────────────────────────────────────────────────┘第一步配置服务端多级存储策略config.xml在 ClickHouse 配置文件中定义包含三级物理介质的storage_configurationyandex storage_configuration disks !-- 1. 热盘: 本地物理 NVMe SSD -- hot_nvme path/data/clickhouse/hot//path /hot_nvme !-- 2. 温盘: 大容量 EBS 云盘 -- warm_ebs path/data/clickhouse/warm//path /warm_ebs !-- 3. 冷盘: S3 对象存储 (原生对象存储驱动) -- cold_s3 types3/type endpointhttps://s3.cn-hangzhou.oss.aliyuncs.com/ch-cold-bucket/data//endpoint access_key_idAKIA_PROD_CH_TIER/access_key_id secret_access_keySECRET_KEY_MASKED/secret_access_key metadata_path/data/clickhouse/s3_metadata//metadata_path cache_enabledtrue/cache_enabled cache_path/data/clickhouse/s3_cache//cache_path cache_max_size64424509440/cache_max_size !-- 60GB 读缓存 -- /cold_s3 /disks !-- 定义名为 tiered_three_level 的分层策略 -- policies tiered_three_level volumes hot_volume diskhot_nvme/disk /hot_volume warm_volume diskwarm_ebs/disk /warm_volume cold_volume diskcold_s3/disk /cold_volume /volumes move_factor0.1/move_factor !-- 当热盘剩余空间小于 10% 时自动加速下沉 -- /tiered_three_level /policies /storage_configuration /yandex第二步在建表 DDL 中声明三阶 TTL 规则在创建 MergeTree 表时直接将生命周期沉降与存储策略绑定-- 生产级三阶 TTL 自动沉降表定义范式 CREATE TABLE t_apm_trace_log_tiered ( event_time DateTime CODEC(DoubleDelta, ZSTD(3)), trace_id String CODEC(ZSTD(6)), service_name LowCardinality(String), http_status UInt16, duration_ms Float32, payload_json String CODEC(ZSTD(6)) ) ENGINE MergeTree() ORDER BY (event_time, service_name) -- 核心生命周期多级流转声明 TTL event_time INTERVAL 7 DAY TO VOLUME warm_volume, event_time INTERVAL 30 DAY TO VOLUME cold_volume, event_time INTERVAL 180 DAY DELETE SETTINGS storage_policy tiered_three_level;内核流转机制后台 Mutation 异步无锁下沉看一看 ClickHouse 内核在后台是如何处理数据块流转的数据写入瞬间所有新的 Part 目录严格默认写入hot_nvme物理磁盘确保极速写入吞吐后台自动合并检测当后台background_processing_pool执行 Compaction 时内核检查每个 Part 内部所有记录的最大时间戳max_date分卷物理转移Part Move超过 7 天的 Part内核在后台将其平滑拷贝至warm_ebs磁盘并在完成后原子更新内存标记并删除旧 Part超过 30 天的 Part内核通过 S3 协议分块上传至对象存储本地仅保留极轻量的元数据指针.mrk3整个下沉过程完全发生在后台前台所有的 SELECT 查询完全不受任何影响业务代码 0 感知、0 改动-- 查看当前各分层卷中的数据分布与下沉状态 SELECT disk_name, formatReadableSize(sum(bytes_on_disk)) AS size_on_disk, count() AS total_parts FROM system.parts WHERE table t_apm_trace_log_tiered AND active 1 GROUP BY disk_name;生产治理收益全网部署基于 Storage Policy 的三级 TTL 分层策略后在保持全网PB 级历史日志随时可查的前提下核心本地 NVMe 高性能磁盘的硬件占用量直接缩减了82%单 PB 数据的月度综合存储成本从原本的120 万元骤降至 11.5 万元成本暴跌 90.4%实现了“热层快如闪电、冷层便宜如水、全局透明分析”的顶级海量存储治理境界。
