Hot/Warm/Cold存储

1）为什么要在Hot/Warm/Cold上共享数据

• 优化成本：仅适用于热工作集的快速且昂贵的层。
• 遵守SLO： p95/throughput用于在线,为故事提供更长的截止日期。
• 简化缩放：水平堆积廉价层而不过热"前端"。
• 降低风险：不同的故障/复制域、独立的保护策略。

• 热门-最新，最频繁的阅读/写入，最小的潜伏期。
• Warm-不太可能改变,有大量的阅读时间范围.
• 冷是存档，便宜的存储，高的TTFB，恢复缓慢。

2）按级别划分的配置文件和SLO

Hot

访问：毫秒（KV/索引的 p95 5-20毫秒；复杂查询的100-300毫秒）。
操作：频繁的upsert/append，索引，OLTP/stream ingest。
介质：NVMe/SSD、内存、快速网络。
复制：RPO≈0分钟的RTO的增强（例如RF=3）。

Warm

访问：数十到数百毫秒/秒。
手术：阅读"窗口"，batchi，新鲜历史OLAP（7-90天）。
介质：具有本地缓存的SATA SSD/快速 HDD/对象存储。
复制：中等（RF=2），包括压缩。

Cold

访问：秒钟；频繁的离线访问，"retrieve-and-scan"。
操作：稀有阅读，法规遵从性（夏季重生）。
媒体：对象/存档（S3 Glacier/Deep Archive，Azure Archive，GCS Coldline）。
复制：区域/区域间,WORM/Legal Hold。

3）按层划分的典型技术

Hot: PostgreSQL (OLTP, partitions), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-nodes, ClickHouse горячие партиции, Kafka local log.

Warm： ClickHouse Colonic Storage、BigQuery/Snowflake最近分期付款、Elasticsearch warm-nodes, S3+Presto/Trino with cash、Tiered storage （Kafka/Pulsar）。
Cold：S3/Glacier，GCS Nearline/Coldline/Archive，Azure Cool/Archive，HDFS存档，长期备份。

4）生命周期策略（ILM）和自动化

4.1个概念

时间分期（每天/每周/每月）是分层之间转移的主要杠杆。
ILM规则：滚动（按体积/年龄），shrink/merge，freeze，delete。
重复数据消除和压缩：在warm/cold上启用,避免热点处的CPU瓶颈。

4.2个示例

Elasticsearch ILM (hot→warm→cold→delete)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "allocate": { "require": { "box_type": "warm" } }, "forcemerge": { "max_num_segments": 1 } } },
"cold": { "min_age": "30d", "actions": { "allocate": { "require": { "box_type": "cold" } }, "freeze": {} } },
"delete":{ "min_age": "365d", "actions": { "delete": {} } }
}
}
}

S3 Lifecycle (Standard→Infrequent→Glacier→Expire)

json
{
"Rules": [{
"ID": "logs-lifecycle",
"Filter": { "Prefix": "logs/" },
"Status": "Enabled",
"Transitions": [
{ "Days": 7, "StorageClass": "STANDARD_IA" },
{ "Days": 30, "StorageClass": "GLACIER" }
],
"Expiration": { "Days": 365 }
}]
}

Kafka Tiered Storage（草图）

properties log. segment. bytes=1073741824 log. retention. ms=259200000 tiered. storage. enable=true remote. log. storage. system=s3 remote. log. storage. bucket=topic-archive

PostgreSQL分期付款

sql
CREATE TABLE events (
id bigserial, at timestamptz NOT NULL, payload jsonb
) PARTITION BY RANGE (at);

CREATE TABLE events_2025_10 PARTITION OF events
FOR VALUES FROM ('2025-10-01') TO ('2025-11-01')
TABLESPACE ts_hot; -- further ALTER TABLE... SET TABLESPACE ts_warm по ILM

5）成本和性能建模

5.1简单的TCO模型

"TCO=CapEx/OpEx媒体+网络（egress）+每个压缩/扫描+控制+DR/复制的 CPU"。

5.2潜伏期与价格平衡

热集≈ 5-20%的数据提供80-95%的查询。
目标是在热缓存（CPU/RAM/NVMe）中保留工作套件，其余的则转移到Warm/Cold。

5.3个指标

hit_ratio_hot, pct_hot_of_total_bytes, cost_per_TB_month{tier}, scan_cost_per_TB, time_to_first_byte{tier}, promotion_rate (cold→warm), demotion_rate (hot→warm/cold).

6）分配、索引和缓存

时间分期付款+"新鲜"切片的二级索引。
黄金查询规则：时间过滤器第一，然后选择键。
缓存是分层的：proc → Redis → edge；热键/聚合的pin缓存。
Bloom 过滤器/skip索引（ClickHouse, Parquet）,用于减少在warm/cold上的读数。

7）复制、容错和DR

Hot：同步复制（multizon），RPO≈0，快速捕获器。
Warm：异步区域间/区域间副本；RPO分钟。
冷落：与WORM（Write Once Read Many）进行区域间合作，法律保持合规性。
DR计划：用于恢复"冷"档案（时钟）的运行书，偶尔发生火灾。

8）安全性和合规性

PII/PCI：静止加密（KMS），每个阶段的关键策略，向下传输时的掩码。
重建和删除：每个冷的自动截止日期，可证明的擦除（erase报告）。
司法管辖区：在该地区的存储（EU-only，RU-only，BY-region等），地质隔离桶。

9）使用模式

9.1徽标和遥测

Hot：NVMe上Elasticsearch/ClickHouse的最后24-72小时。
Warm：在S3的SSD/HDD+Parquet上运行30-180天。
冷：>180天在冰川；通过Trino/Presto"按需"查询。

9.2交易/认股权证

Hot：具有简短历史的OLTP DB（PostgreSQL/MySQL）。
Warm：BI的非正规狙击手。
冷：法律存档,导出到对象存储。

9.3个ML-fichestore

Hot：Redis/low-latency DB中的在线照片。
Warm：柱子/对象中的离线字体。
冷气：经过（Delta/Iceberg/Hudi）的原始日期。

10）与群集和Kubernetes的互动

StorageClass按等级标记："gold-nvme"（hot），"silver-ssd"（warm），"bronze-object"（cold）。
在hot/warm/cold worcloads下规划池节点（taints/labels）。
在向对象存储请求之前先进行侧缓存（例如本地SSD缓存）。

PVC示例

yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: { name: db-hot }
spec:
storageClassName: gold-nvme accessModes: [ ReadWriteOnce ]
resources: { requests: { storage: 500Gi } }

11）可观察性

Dashbords：按等级分配字节/查询，按等级递减，在warm/cold上加载，成本/月。
Alerts：热量下降,推广率上升（是否足够热量）,TTFB增加warm,冷恢复缓慢（SLO断裂）。

12）反模式

"一切都热"：超额成本，IO过热。
"没有指数的深冷"：便宜的存储，昂贵的阅读；没有快速切片的路径。
"没有ILM"：手动携带，人为错误。
所有级别的"统一复制策略"：多付和不均匀的RPO。
在单个计算池中"混合prod/存档查询"：相互影响。
冷云中的"未计数的egress"：帐户中的惊喜。

13）实施支票

• 对数据集进行分类：SLA、访问频率、存储要求。
• 选择每层介质和引擎（NVMe/SSD/HDD/Object/Archive）。
• 设计批次（时间/密钥）、索引和格式（Parquet/ORC/Delta）。
• 定义ILM规则（rollover/transition/expire）并实现自动化。
• 启用压缩/编码（ZSTD/LZ4；在冷中-更强）。
• 定义复制/RPO/RTO和DR过程。
• 为热聚合配置缓存层次结构和pin。
• 按等级划分的价值/潜伏期和异常度量。
• 安全政策（KMS、法律重组、地理隔离）。
• 定期审查翻译门槛（seasonality，成长）。

14) FAQ

Q： 如何定义热和热之间的界限?

答：根据实际查询分布："热工作集"=前5-20%的密钥/批次,提供80-95%的查询。任何没有击中的都是战争的候选人。

Q：可以直接从冷中读取吗？
答：是的,但计划在分钟/小时内进行SLA；在分析之前将碎片还原为warm （staging）更为有利可图。

Q： 30-180天分析师选择什么?

A：具有缓存的对象+查询引擎（Trino/Presto/ClickHouse）上的柱状格式（Parquet/ORC）；索引/跳过数据以节省IO。

问：如何避免冷选举中的"热风暴"？
A：使用prefetch/prepare-jobs、限制查询、时间紧缩、在战争中应用请求缓存和派恩缓存。

15）结果

Hot/Warm/Cold体系结构是访问配置文件的成本匹配加上自动生命周期管理。清晰的层级SLO、分组和ILM、明智的复制和缓存层次结构使您能够保持"热"快速,"温暖"可用,"冷"便宜且安全。