网站导航
> 技术文档 > 【Elasticsearch】冷热集群架构

【Elasticsearch】冷热集群架构

网友: 技术文档 2025-07-30 12:46:31

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

  • 1️⃣ 冷热集群架构
  • 2️⃣ 合适的锅炒合适的菜：性能与成本平衡原理公式解析
  • 3️⃣ ILM（Index Lifecycle Management）策略详解
  • 4️⃣ Elasticsearch 跨机房部署
  • 5️⃣ 快照与恢复功能详解
  • 6️⃣ Elasticsearch 快照恢复 API 参数详解
  • 7️⃣ 安全地删除快照仓库、快照
  • 8️⃣ 快照生命周期管理 SLM（理论篇）
  • 9️⃣ 快照生命周期管理 SLM（实战篇）
  • 🔟 跨集群检索（Cross-Cluster Search）

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

冷热集群架构

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

1.核心层级定义

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

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

2.行业级应用案例

  • 电商订单系统（日增量 TB 级） #mermaid-svg-mKN5imZvRO7HPgGh {font-family:\"trebuchet ms\",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-mKN5imZvRO7HPgGh .error-icon{fill:#552222;}#mermaid-svg-mKN5imZvRO7HPgGh .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-mKN5imZvRO7HPgGh .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-mKN5imZvRO7HPgGh .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-mKN5imZvRO7HPgGh .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-mKN5imZvRO7HPgGh .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-mKN5imZvRO7HPgGh .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-mKN5imZvRO7HPgGh .marker{fill:#333333;stroke:#333333;}#mermaid-svg-mKN5imZvRO7HPgGh .marker.cross{stroke:#333333;}#mermaid-svg-mKN5imZvRO7HPgGh svg{font-family:\"trebuchet ms\",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-mKN5imZvRO7HPgGh .label{font-family:\"trebuchet ms\",verdana,arial,sans-serif;color:#333;}#mermaid-svg-mKN5imZvRO7HPgGh .cluster-label text{fill:#333;}#mermaid-svg-mKN5imZvRO7HPgGh .cluster-label span{color:#333;}#mermaid-svg-mKN5imZvRO7HPgGh .label text,#mermaid-svg-mKN5imZvRO7HPgGh span{fill:#333;color:#333;}#mermaid-svg-mKN5imZvRO7HPgGh .node rect,#mermaid-svg-mKN5imZvRO7HPgGh .node circle,#mermaid-svg-mKN5imZvRO7HPgGh .node ellipse,#mermaid-svg-mKN5imZvRO7HPgGh .node polygon,#mermaid-svg-mKN5imZvRO7HPgGh .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-mKN5imZvRO7HPgGh .node .label{text-align:center;}#mermaid-svg-mKN5imZvRO7HPgGh .node.clickable{cursor:pointer;}#mermaid-svg-mKN5imZvRO7HPgGh .arrowheadPath{fill:#333333;}#mermaid-svg-mKN5imZvRO7HPgGh .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-mKN5imZvRO7HPgGh .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-mKN5imZvRO7HPgGh .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-mKN5imZvRO7HPgGh .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-mKN5imZvRO7HPgGh .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-mKN5imZvRO7HPgGh .cluster text{fill:#333;}#mermaid-svg-mKN5imZvRO7HPgGh .cluster span{color:#333;}#mermaid-svg-mKN5imZvRO7HPgGh div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\"trebuchet ms\",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-mKN5imZvRO7HPgGh :root{--mermaid-font-family:\"trebuchet ms\",verdana,arial,sans-serif;} 实时订单处理 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%
网络标签：

相关问题