企业官网建设流程全解析

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_configuration：

<yandex> <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> <type>s3</type> <endpoint>https://s3.cn-hangzhou.oss.aliyuncs.com/ch-cold-bucket/data/</endpoint> <access_key_id>AKIA_PROD_CH_TIER</access_key_id> <secret_access_key>SECRET_KEY_MASKED</secret_access_key> <metadata_path>/data/clickhouse/s3_metadata/</metadata_path> <cache_enabled>true</cache_enabled> <cache_path>/data/clickhouse/s3_cache/</cache_path> <cache_max_size>64424509440</cache_max_size> <!-- 60GB 读缓存 --> </cold_s3> </disks> <!-- 定义名为 tiered_three_level 的分层策略 --> <policies> <tiered_three_level> <volumes> <hot_volume> <disk>hot_nvme</disk> </hot_volume> <warm_volume> <disk>warm_ebs</disk> </warm_volume> <cold_volume> <disk>cold_s3</disk> </cold_volume> </volumes> <move_factor>0.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 内核在后台是如何处理数据块流转的：

1. 数据写入瞬间：所有新的 Part 目录严格默认写入hot_nvme物理磁盘，确保极速写入吞吐；
2. 后台自动合并检测：当后台background_processing_pool执行 Compaction 时，内核检查每个 Part 内部所有记录的最大时间戳（max_date）；
3. 分卷物理转移（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%）；
• 实现了“热层快如闪电、冷层便宜如水、全局透明分析”的顶级海量存储治理境界。