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集群在资源有限的情况下可最大化平衡性能与成本，是处理海量时序数据的标准实践。