使用Elastic Ingest Pipeline拆分聚合字段构建可聚合嵌套结构

你之前通过kv处理器拆分字段遇到的两个卡点，本质是三个流程节点没有适配动态键值对的场景：

• kv处理器默认输出平铺键值对对象，没有提前锁定存储结构，ES动态映射会把每个动态key拆成独立字段，造成映射爆炸，出现delays.62、delays.86.keyword这类零散字段
• 键值对数量、key内容完全未知的情况下，没法提前为每个可能出现的key配置字符串转整型的规则
• dot_expander这类处理器依赖固定的字段路径展开规则，根本适配不了无固定key的场景，自然走不通

1. 提前定义索引映射，从根源避免映射爆炸 #

创建索引时直接锁定delays字段的存储结构，不依赖ES动态映射：

PUT /your_target_index
{
  "mappings": {
    "properties": {
      "delays": {
        "type": "nested",
        "properties": {
          "process_code": {
            "type": "keyword"
          },
          "duration_min": {
            "type": "integer"
          }
        }
      }
    }
  }
}

这里的嵌套结构有两个核心作用：

• 无论后续pipeline拆出多少组键值对，都会严格按照process_code（存原key，也就是流程编号）、duration_min（存原value，也就是超时时长）的统一结构存储，不会生成零散的动态字段
• 每个嵌套元素是独立存储的，不会出现普通object类型常见的键值对串值问题（比如同一文档下多组键值对的key、value打散交叉匹配）

2. 调整ingest pipeline配置 #

整个pipeline只需要两个处理器，完全适配动态键值对的处理需求：

第一步：kv处理器拆分原始字段 #

把拆分后的结果输出到临时中间字段，避免拆分出的平铺对象触发动态映射、留下垃圾字段：

{
  "kv": {
    "field": "IncomingField",
    "field_split": ";",
    "value_split": "/",
    "target_field": "_temp_kv",
    "ignore_missing": true,
    "trim_key": "\\s",
    "trim_value": "\\s",
    "ignore_failure": true,
    "remove_if_empty": true
  }
}

第二步：脚本处理器转结构、批量做类型转换 #

用painless脚本遍历临时拆分出来的所有键值对，转成之前定义的嵌套数组结构，过程中直接把字符串类型的超时时长转成整数，根本不需要提前知道有多少个key、key是什么内容：

{
  "script": {
    "lang": "painless",
    "source": """
      // 原始字段为空时，初始化delays为空数组，对应无延迟场景
      if (ctx._temp_kv == null) {
        ctx.delays = [];
        return;
      }
      // 遍历所有键值对，转成嵌套结构元素
      ctx.delays = [];
      for (entry in ctx._temp_kv.entrySet()) {
        // 跳过值非数字的脏数据
        try {
          int duration = Integer.parseInt(entry.getValue());
          ctx.delays.add([
            "process_code": entry.getKey(),
            "duration_min": duration
          ]);
        } catch (err) {
          continue;
        }
      }
      // 处理完成后删除临时字段，不残留到最终文档
      ctx.remove("_temp_kv");
    """,
    "ignore_failure": true
  }
}

这个环节直接解决你之前遇到的两个核心问题：

• 不管有1组还是n组键值对，脚本都会自动遍历处理，不需要提前预知键值对的数量和内容
• 遍历过程中直接完成字符串到整数的类型转换，不需要为每个未知的key单独配置转换规则

3. 业务场景适配 #

这套结构可以直接支撑你提到的两个核心业务需求：

• 筛选指定类别的延迟值：通过nested查询定位对应流程的延迟值，示例查询：

  GET /your_target_index/_search
  {
    "query": {
      "nested": {
        "path": "delays",
        "query": {
          "bool": {
            "must": [
              { "term": { "delays.process_code": "62" } },
              { "range": { "delays.duration_min": { "gte": 5, "lte": 15 } } }
            ]
          }
        }
      }
    }
  }
  

• 按日统计延迟区间分布：配合date_histogram按天分组，对嵌套字段的duration_min值做range聚合，直接统计无延迟（delays为空数组）、0-5分钟延迟、5-15分钟延迟的文档量级。

• 不要把delays映射为普通object类型，必须用nested类型，否则多组键值对会出现串值问题，导致查询结果不准
• pipeline配置里保留ignore_failure: true，避免单条脏数据导致整个文档处理失败，配合on_failure配置把失败文档投递到死信队列排查即可
• 临时字段用下划线开头命名，处理完即时删除，不会对最终的文档结构造成干扰

内容的提问来源于stack exchange，提问作者Chibisuketyan