【Elasticsearch】冷热集群架构

冷热集群架构

• 1.核心层级定义
• 2.行业级应用案例
• 3.冷热集群架构的优势
• 4.架构优势深度剖析
• • [4.1 性能与成本平衡原理](#4.1 性能与成本平衡原理)
  • [4.2 分层存储的经济学效应](#4.2 分层存储的经济学效应)
  • [4.3 不可替代的核心价值](#4.3 不可替代的核心价值)
• 5.专业级搭建指南
• • [5.1 硬件规划建议](#5.1 硬件规划建议)
  • [5.2 关键配置步骤](#5.2 关键配置步骤)
  • [5.3 运维监控要点](#5.3 运维监控要点)
• [6.为什么必须采用分层架构 ？------ 本质矛盾解析](#6.为什么必须采用分层架构 ？—— 本质矛盾解析)

1.核心层级定义

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

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

2.行业级应用案例

• 电商订单系统（日增量 TB 级）
  实时订单处理 T+1迁移 用户订单查询 T+30迁移 年度审计 热层 订单创建/支付/退款 温层 近30天订单检索 冷层 历史订单归档
  • 热层：处理实时订单写入（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 性能与成本平衡原理

总成本 = ∑ i = h o t c o l d ( N i × C i h a r d w a r e + Q i × C i q u e r y ) \text{总成本} = \sum_{i=hot}^{cold} (N_i × C_i^{hardware} + Q_i × C_i^{query}) 总成本=i=hot∑cold(Ni×Cihardware+Qi×Ciquery)

其中：

• N i N_i Ni = 节点数量
• C i h a r d w a r e C_i^{hardware} Cihardware = 单节点硬件成本
• Q i Q_i Qi = 层级查询量
• C i q u e r y C_i^{query} Ciquery = 单次查询资源消耗

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

4.2 分层存储的经济学效应

• 硬件成本指数级降低
  • 每 TB 存储月成本
    • 热层（SSD）： 300
    • 温层（混合）： 120
    • 冷层（HDD）： 40
• 查询资源消耗优化
  • 热层查询：10ms 级响应（消耗 1000 1000 1000 CPU 单位）
  • 温层查询：100ms 级响应（消耗 200 200 200 CPU 单位）
  • 冷层查询：1s+ 响应（消耗 50 C P U CPU 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 1/8 1/8
• 查询性能矛盾
  • 毫秒级实时查询 vs 深度历史分析
  • 解决方案：热层维持原始数据结构，温层预聚合，冷层采用列存

📊 某金融客户实践效果：

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