2.1 Elasticsearch-节点角色：master、data、ingest、coordinating、ml、transform

原创已于 2025-11-05 21:36:51 修改 · 901 阅读

9 ·

CC 4.0 BY-SA版权

CC BY-NC-SA 3.0

文章标签：

#elasticsearch #大数据 #搜索引擎

于 2025-11-05 21:35:07 首次发布

elasticsearch 专栏收录该内容

25 篇文章

订阅专栏

在这里插入图片描述
2.1 Elasticsearch-节点角色：master、data、ingest、coordinating、ml、transform
——把集群拆成“专业化战队”而不是“全能兵”

上一篇我们把 8.x 的默认配置跑通后，集群里 3 个节点自动都成了“万能选手”：既投票选主，又存数据，还能跑管道预处理。这种“all-in-one”在笔记本上玩 demo 很香，但放到生产就是灾难：

选主卡顿会拖慢整个索引；
跑大聚合把 data 节点内存打满，master 可能直接失联；
想做冷热分层，结果热节点被 ML 作业抢占 CPU；
想水平扩展，却不知道到底该加哪一类节点。

Elasticsearch 从 5.x 开始把“职能”拆成可插拔的节点角色（node roles），8.x 进一步把“万能”拆成 6 张专业身份证。理解每一张身份证的权责，是后续做容量规划、故障域隔离、冷热分层、机器学习调优的前提。下面直接给出 6 种角色的“一句话定位 + 真实场景坑点 + 配置模板”，拿来即可落地。

master 角色——“议会”
职责

只负责集群级元数据变更：创建/删除索引、分片分配、节点上下线。
不参与文档级写、也不负责查询，因此不需要大堆内存（默认 1 GB 足够）。

生产坑点

“脑裂”：discovery.seed_hosts 只给 3 个稳定低延迟 IP，避免让数据节点混进 master 选举。
负载漂移：master 节点如果同时是 data 节点，full GC 时可能让集群无主；独立 master 后，集群稳定性提升一个量级。

配置模板

node.roles: [ master ]
discovery.seed_hosts: ["10.0.0.11","10.0.0.12","10.0.0.13"]
cluster.initial_master_nodes: ["es-master-1","es-master-2","es-master-3"]

data 角色——“仓库”
职责

真正存储分片数据、倒排索引、段文件；负责 CRUD、聚合、排序。
8.x 进一步细分为 data_hot / data_warm / data_cold / data_frozen，对应 ILM 的“温度”阶段。

生产坑点

磁盘热点：SSD 机器如果同时承担冷数据，寿命被无谓消耗；用 attribute 把冷热节点打上 box_type 标签，让 ILM 自动搬迁。
堆内存 > 32 GB 会踩 OOP 禁区；给 data 节点 64 GB 物理机时，堆设 31 GB，剩下留给 Lucene 系统缓存。

配置模板（热节点）

node.roles: [ data_hot ]
node.attr.box_type: hot

ingest 角色——“预处理车间”
职责

接收单条写入请求，按 pipeline 里定义的 processors 做字段拆分、IP 解析、Geo 定位、script 计算，再把文档转给目标 data 节点。
属于 CPU 密集型，对内存要求不高。

生产坑点

高吞吐场景（日志 200 k doc/s）若把 ingest 跟 data 混部，CPU 抢占会让搜索延迟抖动；独立 2~3 台 ingest 节点，配合负载均衡器轮询，CPU 利用率可拉到 80% 而不会影响查询。
pipeline 里用 script 处理器时，记得打开“compiled script cache”监控，避免每次动态编译把节点打挂。

配置模板

node.roles: [ ingest ]

coordinating 角色——“前台接待”
职责

接收客户端任何请求，把搜索/聚合 scatter 到 data 节点，再 gather 结果做排序、分页、聚合合并，最后返回。
本质上是无状态的“聚合路由器”，负责合并段、收集全局桶，内存消耗与聚合复杂度成正比。

生产坑点

深分页（from + size > 1 万）+ 高并发，会把 coordinating 节点堆内存瞬间打满；独立 coordinating 后，出现 OOM 只会掉查询，不会掉数据。
8.x 默认所有节点都自带 coordinating 功能，若已独立 coordinating，记得把 data/master 节点的 node.roles 显式写死，避免“兼职”。

配置模板

node.roles: [ ]
# 空列表即 coordinating only

ml 角色——“算法工程师”
职责

仅 8.x 的 Platinum+ 许可证生效，跑异常检测、数据帧分析、推理模型。
每节点可并发 job 数 = min(节点核数/2, 512)，内存按模型大小预留。

生产坑点

机器学习任务对 CPU 持续占用 90%+，与 data 节点混布会让搜索延迟暴涨；独立 ml 节点后，可把夜间低峰期的 CPU 全部让给模型。
模型快照默认存在 _ml 索引，若该索引分片落在冷节点，恢复速度极慢；给 ml 节点额外打上 node.attr.ml: true，在 _ml 索引设置里用 allocation filtering 固定到本地 SSD。

配置模板

node.roles: [ ml ]
node.attr.ml: true

transform 角色——“ETL 小秘书”
职责

持续把原始索引 roll up 成指标汇总表，或把大宽表 pivot 成窄表，供 Kibana Lens 秒级出图。
底层是 persistent task，会记录 checkpoint，失败可续跑。

生产坑点

transform 任务写目标索引时，如果目标分片正被 relocation，会无限重试；给 transform 节点独立角色后，可让目标索引分片只分配到 data_warm，避免热节点抖动。
8.x 支持 max_page_search_size 动态调，默认 500 太小，聚合场景可拉到 2000，减少 round-trip。

配置模板

node.roles: [ transform ]

一张图总结角色分工

          ┌--------------┐
client -> │ coordinating │  scatter  ┌---------┐
          └------┬-------┘           │  data   │
                 │                   └----┬----┘
            ┌----┴----┐  ingestpipeline  │
            │ ingest  │<--(optional)------┘
            └----┬----┘
                 │  write
          ┌------┴------┐
          │ data_hot    │
          │ data_warm   │
          │ data_cold   │
          │ data_frozen │
          └------┬------┘
                 │  meta
          ┌------┴------┐
          │  master     │ (3~5 台低负载节点)
          └-------------┘

sidecar: ml, transform 节点按需水平扩展，与 coordinating 同级接入 LB。

最小生产模板（3 角色 5 节点）

master * 3：4 vCPU / 8 GB / 100 GB SSD
data_hot * 2：16 vCPU / 64 GB / 2 TB NVMe
coordinating * 2：8 vCPU / 16 GB / 100 GB SSD
ingest * 2：8 vCPU / 8 GB / 100 GB SSD
ml * 2：16 vCPU / 32 GB / 500 GB SSD

把以上节点池化后，通过

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "box_type,ml"
  }
}

即可让 ILM + ML 任务自动感知冷热与算法隔离。

更多技术文章见公众号: 大城市小农民