文章转载自：
一、问题引出
node
来自星球同窗的提问：redis
“Ingest node什么场景会遇到它？ 一直没搜到它是在什么场景工做的？”
的确咱们比较关心集群的节点角色的划分。包括：数据库
集群应该几个节点？ 几个节点用于数据存储？ 要不要独立Master节点、协调节点？
可是Ingest node的场景用的比较少。
二、集群节点角色划分梳理
数组
以前的文章：刨根问底 | Elasticsearch 5.X集群多节点角色配置深刻详解有过解读。本文再参考7.1版本官方文档总结一下：
2.1 主节点
架构
主节点负责集群相关的操做，例如建立或删除索引，跟踪哪些节点是集群的一部分，以及决定将哪些分片分配给哪些节点。app
拥有稳定的主节点是衡量集群健康的重要标志。elasticsearch
注意：性能
一、因为索引和搜索数据都是CPU、内存、IO密集型的，可能会对数据节点的资源形成较大压力。 所以，在较大规模的集群里，最好要设置单独的仅主节点角色。（这点PB级集群调优时重点关注） 二、不要将主节点同时充当协调节点的角色，由于：对于稳定的集群来讲，主节点的角色功能越单一越好。
2.2 数据节点学习
数据节点：保存包含索引文档的分片数据，执行CRUD、搜索、聚合相关的操做。属于：内存、CPU、IO密集型，对硬件资源要求高。
2.3 协调节点
fetch
搜索请求在两个阶段中执行（query 和 fetch），这两个阶段由接收客户端请求的节点 - 协调节点协调。
在请求阶段，协调节点将请求转发到保存数据的数据节点。 每一个数据节点在本地执行请求并将其结果返回给协调节点。 在收集fetch阶段，协调节点将每一个数据节点的结果聚集为单个全局结果集。
2.4 Ingest节点
ingest 节点能够看做是数据前置处理转换的节点，支持 pipeline管道 设置，可使用 ingest 对数据进行过滤、转换等操做，相似于 logstash 中 filter 的做用，功能至关强大。
我把Ingest节点的功能抽象为：大数据处理环节的“ETL”——抽取、转换、加载。
前Elastic中国架构师吴斌的文章中对Ingest节点的评价很高，他指出
“2018这一年来拜访了不少用户，其中有至关一部分在数据摄取时遇到包括性能在内的各类各样的问题，那么大多数在咱们作了ingest节点的调整后获得了很好的解决。Ingest节点不是万能的，可是使用起来简单，并且抛开后面数据节点来看性能提高趋于线性。因此我一直本着能用ingest节点解决的问题，毫不麻烦其余组件的大致原则”。
三、Ingest 节点能解决什么问题？
上面的Ingest节点介绍太官方，看不大懂怎么办？来个实战场景例子吧。
思考问题1：线上写入数据改字段需求
如何在数据写入阶段修改字段名（不是修改字段值）？
思考问题2：线上业务数据添加特定字段需求
如何在批量写入数据的时候，每条document插入实时时间戳？
这时，脑海里开始对已有的知识点进行搜索。
针对思考问题1：字段值的修改无非：update,updatebyquery？可是字段名呢？貌似没有相关接口或实现。
针对思考问题2：插入的时候，业务层面处理，读取当前时间并写入貌似能够，有没有不动业务层面的字段的方法呢？
答案是有的，这就是Ingest节点的妙处。
四、Ingest实践一把
针对问题1：
PUT _ingest/pipeline/rename_hostname
{
"processors": [
{
"field": "hostname",
"target_field": "host",
"ignore_missing": true
}
}
]
}
PUT server
POST server/values/?pipeline=rename_hostname
{
"hostname": "myserver"
}
如上，借助Ingest节点的 rename_hostname管道的预处理功能，实现了字段名称的变动：由hostname改为host。
针对问题2：6.5版本ES验证ok以下。
PUT _ingest/pipeline/indexed_at
{
"description": "Adds indexed_at timestamp to documents",
"processors": [
{
"set": {
"field": "_source.indexed_at",
"value": "{{_ingest.timestamp}}"
}
}
]
}
PUT ms-test
{
"settings": {
"index.default_pipeline": "indexed_at"
}
}
POST ms-test/_doc/1
{"title":"just testing"}
如上，经过indexedat管道的set处理器与ms-test的索引层面关联操做，
ms-test索引每插入一篇document，都会自动添加一个字段indexat=最新时间戳。
五、Ingest节点基本概念
在实际文档索引起生以前，使用Ingest节点预处理文档。Ingest节点拦截批量和索引请求，它应用转换，而后将文档传递回索引或Bulk API。
强调一下： Ingest节点处理时机——在数据被索引以前，经过预约义好的处理管道对数据进行预处理。
默认状况下，全部节点都启用Ingest，所以任何节点均可以处理Ingest任务。咱们也能够建立专用的Ingest节点。
要禁用节点的Ingest功能，须要在elasticsearch.yml 设置以下：
node.ingest：false
这里就涉及几个知识点：
一、预处理 pre-process 要在数据索引化(indexing)以前预处理文档。 二、管道 pipeline 每一个预处理过程能够指定包含一个或多个处理器的管道。
管道的实际组成：
{
"description" : "...",
"processors" : [ ... ]
}
description：管道功能描述。
processors：注意是数组，能够指定1个或多个处理器。
三、处理器 processors 每一个处理器以某种特定方式转换文档。 例如，管道可能有一个从文档中删除字段的处理器，而后是另外一个重命名字段的处理器。 这样，再反过来看第4部分就很好理解了。
六、Ingest API
Ingest API共分为4种操做，分别对应：
PUT（新增）、 GET（获取）、 DELETE（删除）、 Simulate （仿真模拟）。
模拟管道AP Simulate 针对请求正文中提供的文档集执行特定管道。
除此以外，高阶操做包括：
一、支持复杂条件的Nested类型的操做； 二、限定条件的管道操做； 三、限定条件的正则操做等。
详细内容，参见官网便可。
常见的处理器有以下28种，举例：
append处理器：添加1个或1组字段值； convert处理器：支持类型转换。
建议：不必都过一遍，根据业务需求，反查文档便可。
七、Ingest节点和Logstash Filter 啥区别？
业务选型中，确定会问到这个问题。
区别一：支持的数据源不一样。 Logstash：大量的输入和输出插件（好比：kafka，redis等）可供使用，还可用来支持一系列不一样的架构。 Ingest节点：不能从外部来源（例如消息队列或数据库）提取数据，必须批量bulk或索引index请求将数据推送到 Elasticsearch. 区别二：应对数据激增的能力不一样。 Logstash：Logstash 可在本地对数据进行缓冲以应对采集骤升状况。如前所述，Logstash 同时还支持与大量不一样的消息队列类型进行集成。 Ingest节点：极限状况下会出现：在长时间没法联系上 Elasticsearch 或者 Elasticsearch 没法接受数据的状况下，均有可能会丢失数据。 区别三：处理能力不一样。 Logstash：支持的插件和功能点较Ingest节点多不少。 Ingest节点：支持28类处理器操做。Ingest节点管道只能在单一事件的上下文中运行。Ingest一般不能调用其余系统或者从磁盘中读取数据。 区别四：排他式功能支持不一样。 Ingest节点：支持采集附件处理器插件，此插件可用来处理和索引常见格式（例如 PPT、XLS 和 PDF）的附件。 Logstash：不支持如上文件附件类型。
选型小结：
一、两种方式各有利弊，建议小数据规模，建议使用Ingest节点。缘由：架构模型简单，不须要额外的硬件设备支撑。
二、数据规模大以后，除了建议独立Ingest节点，同时建议架构中使用Logstash结合消息队列如Kafka的架构选型。
三、将Logstash和Ingest节点结合，也是架构选型参考方案之一。
八、小结
Ingest是5.X版本就有的特性，不算是新知识点。
实践很重要！当咱们对不熟悉的概念学习的时候，能够先查一下别人的应用场景，大体理解一下，再动手跟着官方文档敲一遍、理解一遍，加深认知。
基于Ingest实现的PDF文档预处理和索引，甚至基于Ingest自定义插件开发能够实现更多复杂的功能，你均可以尝试一下！
