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、明智的復制和緩存層次結構使您能夠保持「熱」快速,「溫暖」可用,「冷」便宜且安全。