简介
default pipeline与final pipeline实际上都是普通的ingest pipeline，只是和一般的pipeline执行时机不同；default pipeline的执行时机是当前写入请求没有指定pipeline时，final pipeline的执行时机是在所有pipeline执行完毕后，具体如图所示：
如果当前bulk或者index请求指定了pipeline参数，则会先执行自定义的普通pipeline，所有的pipelie执行完毕后在执行final pipeline(如果索引的显式的设置了index.final_pipeline)；如果当前bulk或者index请求没有指定pipeline，当索引显式的设置了index.default_pipeline参数时，则会先执行default pipeline，然后再执行final pipeline。
索引重定向
使用set ingest processor可以对当前写入的索引名称_index字段进行重新赋值, 因此我们可以创建一个pipeline， 将其配置为当前正在写入的索引的default pipeline，从而实现把所以重定向写入到另外一个索引中：
1.定义pipeline
代码语言：javascript复制PUT _ingest/pipeline/redirect
{
"description": "_description",
"processors": [
{
"set": {
"field": "_index",
"value": "my_newpipeline" // 新索引名
}
}
]
}2.设置default_pipeline
代码语言：javascript复制PUT my_pipeline/_settings
{
"index.default_pipeline": "redirect"
}
设置前：
"default_pipeline": "_none"
设置后：
"settings": {
"index": {
"number_of_shards": "5",
"provided_name": "my_pipeline",
"default_pipeline": "redirect",
"creation_date": "1609225725978",
"number_of_replicas": "1",
"uuid": "Hp8KuokbTbe2suqK09ZDlQ",
"version": {
"created": "6070299"
}
}
}经过上述设置后，可以发现，向my_pipeline索引写入的数据已经全部写入到了my_newpipeline索引。
3.索引数据
代码语言：javascript复制PUT my_pipeline/_doc/1
{
"name": "pipeline",
"message": "this is so cool!"
}
为什么不用final pipeline呢？因为final pipeline强制要求不能进行索引的重新命名(可能因为需要避免出现循环)。
存在的问题
使用default pipeline，使得在业务端不用做任何变更的情况下，将数据写入到一个新的索引中去，但是该方式还存在以下问题：
- 性能问题：使用ingest pipeline是会带来一定的性能损耗的，pipeline的处理过程中需要遍历每个document，节点的cpu使用率势必会上升，在集群资源充足的情况下或者索引本身写入速率不高的情况下可以使用该方式解决索引切换的问题。
- 查询方式的问题：虽然解决了写入索引切换的问题，但是数据存储到新的索引中去了，查询时就必须去查询新的索引；如果业务使用的是通配符的方式去查询，则非常好解决，只需要把新索引命名为老的索引名称再增加一个后缀即可，不能使用通配符的方式查询索引的话，就不能使用该方式切换写入的索引了。
