【Elasticsearch】冷热集群架构

1.核心层级定义

冷热集群架构（Hot-Warm Architecture）是 Elasticsearch 的一种部署模式，将集群节点划分为不同类型，针对不同阶段的数据采用不同的硬件配置和存储策略。

层级	数据特征	硬件配置	访问频率	典型保留周期
热（Hot）	最新写入数据	高性能 SSD、高 CPU / 内存	实时访问	0 - 3 天
温（Warm）	近期不再写入但常查询的数据	中等性能 SSD / 高速 HDD	高频查询	3 - 30 天
冷（Cold）	极少访问的归档数据	高密度 HDD / 对象存储	偶尔访问	30+ 天

2.行业级应用案例

• 电商订单系统（日增量 TB 级）
  • 热层：处理实时订单写入（NVMe SSD，32 核 + 128GB 内存）
  • 温层：支撑用户订单查询（SATA SSD，16 核 + 64GB 内存）
  • 冷层：存储合规数据（HDD + 可搜索快照，8 核 + 32GB 内存）
• 物联网监控系统
  • 热层：实时设备状态写入（5s 粒度数据）
  • 温层：近 7 天故障分析（1min 粒度聚合数据）
  • 冷层：年度运行报告（1hour 粒度汇总数据）

3.冷热集群架构的优势

• 成本效益
  • 热节点数量少但配置高，冷节点数量多但配置低。
  • 示例：10 个热节点（SSD，64GB RAM） + 50 个冷节点（HDD，16GB RAM）比 60 个统一配置节点成本低 40%。
• 性能优化
  • 热数据获得最佳硬件资源，确保关键业务查询性能。
  • 冷查询不影响热数据操作的响应时间。
• 资源利用率
  • 避免为不常访问的数据分配昂贵资源。
  • 可根据数据生命周期自动迁移数据。
• 扩展灵活性
  • 可独立扩展热层或冷层。
  • 热节点不足时只需增加热节点，不影响冷层。
• 数据保留策略
  • 更容易实现基于时间的数据保留和归档。
  • 冷节点可配置不同的副本策略进一步节省空间。

4.架构优势深度剖析

4.1 性能与成本平衡原理

$$\text{总成本}=\sum _{i=hot}^{cold}(N_i\times C_i^{hardware}+Q_i\times C_i^{query})$$

其中：

• $N_i$ = 节点数量
• $C_i^{hardware}$ = 单节点硬件成本
• $Q_i$ = 层级查询量
• $C_i^{query}$ = 单次查询资源消耗

🚀 详细分析可以参考我的另一篇博文《【Elasticsearch】合适的锅炒合适的菜：性能与成本平衡原理公式解析》。

4.2 分层存储的经济学效应

• 硬件成本指数级降低
  • 每 TB 存储月成本
    • 热层（SSD）： 300
    • 温层（混合）： 120
    • 冷层（HDD）： 40
• 查询资源消耗优化
  • 热层查询：10ms 级响应（消耗 $1000$ CPU 单位）
  • 温层查询：100ms 级响应（消耗 $200$ CPU 单位）
  • 冷层查询：1s+ 响应（消耗 50 $CPU$ 单位）

4.3 不可替代的核心价值

• 写入 / 查询资源隔离
  • 热层专注处理高并发写入
  • 温层承载批量历史查询
  • 避免慢查询阻塞实时写入（如：某车企实时车辆数据写入因历史报表查询阻塞）
• 数据生命周期自动化

  // ILM策略示例（含温层）
  "warm": {"min_age": "3d","actions": {"allocate": { "include": { "tier": "warm" } },"shrink": { "number_of_shards": 2 },  // 分片收缩减少开销"forcemerge": { "max_num_segments": 1 }}
  },
  "cold": {"min_age": "30d","actions": {"searchable_snapshot": {  // 冷层专属优化"snapshot_repository": "s3-repo" }}
  }
  

• 故障域隔离
  • 热层节点故障：影响实时业务（需优先保障）
  • 冷层节点故障：不影响核心业务（可延迟修复）

5.专业级搭建指南

5.1 硬件规划建议

层级	节点数量	存储	CPU	内存	网络
Hot	3+	NVMe SSD	32核+	128GB+	25GbE+
Warm	5+	SATA SSD	16核	64GB	10GbE
Cold	N+	RAID HDD	8核	32GB	1GbE

5.2 关键配置步骤

• 节点角色标记（elasticsearch.yml）

  # 热节点
  node.roles: [data_hot, data, ingest, master]# 温节点
  node.roles: [data_warm, data]# 冷节点
  node.roles: [data_cold, data]
  

• 分层存储策略

  PUT _ilm/policy/enterprise_tier_policy
  {"policy": {"phases": {"hot": {"min_age": "0ms","actions": {"rollover": { "max_primary_shard_size": "50gb" },"set_priority": { "priority": 100 }}},"warm": {"min_age": "3d","actions": {"allocate": { "number_of_replicas": 1,"include": { "_tier_preference": "data_warm" } },"shrink": { "number_of_shards": 1 },  // 温层核心优化"forcemerge": { "max_num_segments": 1 }}},"cold": {"min_age": "30d","actions": {"allocate": { "include": { "_tier_preference": "data_cold" },"number_of_replicas": 0  // 冷层可取消副本},"searchable_snapshot": {"snapshot_repository": "s3_backup"}}},"delete": { "min_age": "365d" }}}
  }
  

• 分片布局优化

  # 禁止冷层分配新索引
  PUT _cluster/settings
  {"persistent": {"cluster.routing.allocation.exclude._tier_preference": "data_cold"}
  }
  

5.3 运维监控要点

• 通过 Cat API 监控数据分布：

  GET _cat/allocation?v&h=node,shards,disk.*,tier
  

• 使用 Tier 监控看板：

  Stack Monitoring -> Index Management -> Index Lifecycle Management
  

• 冷层特别优化：

  // 启用冻结索引（冷层专属）
  POST /my_cold_index/_freeze  // 查询时解冻
  POST /my_cold_index/_unfreeze?wait_for_active_shards=1
  

6.为什么必须采用分层架构 ？—— 本质矛盾解析

• 资源争用矛盾
  • 实时写入吞吐量 vs 历史数据扫描资源
  • 解决方案：物理隔离热层（写入）与温/冷层（查询）
• 存储成本矛盾
  • 数据量随时间指数增长 vs 存储预算线性增长
  • 解决方案：冷层使用 HDD + 可搜索快照，存储成本降至热层的 $1/8$
• 查询性能矛盾
  • 毫秒级实时查询 vs 深度历史分析
  • 解决方案：热层维持原始数据结构，温层预聚合，冷层采用列存

📊 某金融客户实践效果：

• 写入延迟：从 $2s$ 降至 $200ms$
• 存储成本：降低 $62\%$
• 历史查询对实时业务影响：下降 $90\%$