Elasticsearch 的冷熱架構（Hot-Warm-Cold Architecture）是一種針對時序數據（如日志、指標等）的成本與性能優化方案，通過將數據在不同生命周期的存儲需求分層處理，兼顧性能、容量和成本。其核心思想是：讓最新、最頻繁訪問的數據（熱數據）存儲在高速硬件上，較舊、較少訪問的數據（溫/冷數據）遷移到廉價大容量硬件上。
核心架構分層
| 層級 | 數據特征 | 硬件配置 | 使用場景 |
|---|---|---|---|
| Hot | 最新寫入，高頻訪問 | 高性能節點（SSD、高CPU/內存） | 實時寫入、快速查詢 |
| Warm | 近期數據，中低頻訪問 | 中等性能節點（SSD/HDD混合） | 歷史數據分析 |
| Cold | 舊數據，極少訪問（歸檔） | 高容量低成本節點（大容量HDD） | 長期歸檔，偶爾查詢 |
| Optional: Frozen | 極舊數據（只讀） | 對象存儲（如S3） | 極少訪問，解凍才能查詢 |
關鍵實現步驟
1. 節點角色劃分
- 為不同層級配置專屬節點，在
elasticsearch.yml中標記節點角色：# Hot 節點 node.roles: ["data_hot"]# Warm 節點 node.roles: ["data_warm"]# Cold 節點 node.roles: ["data_cold"]
2. 配置索引生命周期管理 (ILM)
- 策略示例（將數據按時間自動遷移）：
PUT _ilm/policy/hot_warm_cold_policy {"policy": {"phases": {"hot": {"min_age": "0ms","actions": {"rollover": { "max_size": "50gb", "max_age": "1d" }, // 滾動創建新索引"set_priority": { "priority": 100 } // 高查詢優先級}},"warm": {"min_age": "1d", // 1天后進入溫層"actions": {"set_priority": { "priority": 50 },"allocate": { "require": { "data_type": "warm" } // 遷移到 Warm 節點},"forcemerge": { "max_num_segments": 1 } // 合并段減少資源占用}},"cold": {"min_age": "7d", // 7天后進入冷層"actions": {"set_priority": { "priority": 0 },"allocate": { "require": { "data_type": "cold" } // 遷移到 Cold 節點}}},"delete": {"min_age": "30d", // 30天后刪除"actions": { "delete": {} }}}} }
3. 應用ILM策略到索引模板
PUT _index_template/logs_template
{"index_patterns": ["logs-*"], "template": {"settings": {"index.lifecycle.name": "hot_warm_cold_policy","index.routing.allocation.require.data_type": "hot" // 初始寫入 Hot 節點}}
}
核心優勢
- 成本優化
- 冷數據用廉價HDD存儲，降低50%+存儲成本。
- 性能保障
- 熱數據獨占SSD資源，確保寫入/查詢速度。
- 擴展靈活
- 按需擴展不同層級節點（如單獨擴容Cold層）。
- 自動化管理
- ILM自動處理數據流轉，無需人工干預。
注意事項
- 硬件差異：確保Hot節點使用SSD，Cold節點使用大容量HDD。
- 分片分配：Cold層可減少分片副本數（如從2副本降為1副本）。
- 凍結層（Frozen）：對極少訪問數據使用
searchable snapshots，從對象存儲加載數據（查詢慢但成本極低）。 - 版本兼容：ILM功能需ES 6.6+，完整冷熱架構建議7.10+。
實際應用場景
- 日志分析系統：新日志寫入Hot節點實時分析，舊日志移至Cold層歸檔。
- 電商指標：當天訂單數據在Hot層快速聚合，上月數據存Cold層備份。
- 安全審計：近期審計記錄在Warm層可查，歷史數據存Frozen層合規保留。
通過冷熱分離，ES集群在資源有限的情況下可最大化平衡性能與成本，是處理海量時序數據的標準實踐。
