【Elasticsearch】冷热集群架构

原创已于 2025-07-24 22:42:49 修改 · 1.2k 阅读

31 ·

CC 4.0 BY-SA版权

文章标签：

#elasticsearch #大数据 #搜索引擎 #全文检索 #集群架构 #冷热节点 #集群

于 2025-07-20 09:45:48 首次发布

Elastic 专栏收录该内容

47 篇文章

订阅专栏

《Elasticsearch 集群》系列，共包含以下文章：

😊 如果您觉得这篇文章有用 ✔️ 的话，请给博主一个一键三连 🚀🚀🚀 吧（点赞 🧡、关注 💛、收藏 💚）！！！您的支持 💖💖💖 将激励 🔥 博主输出更多优质内容！！！

冷热集群架构

1.核心层级定义
2.行业级应用案例
3.冷热集群架构的优势
4.架构优势深度剖析
5.专业级搭建指南
6.为什么必须采用分层架构？—— 本质矛盾解析

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 × C_i^{hardware} + Q_i × 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 $CP U$ 单位）

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 深度历史分析
- 解决方案：热层维持原始数据结构，温层预聚合，冷层采用列存

📊 某金融客户实践效果：

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