Elastic存储动态键值对 基于Kibana 7.11.2实现可视化的方案咨询

核心问题定位 #

首先明确两个核心认知边界：

• 当前将动态键值对嵌套在单文档对象下的存储结构，本身和Elastic面向分析场景的设计逻辑不匹配
• Kibana 7.11.2 不支持通过“字段位置、父对象名称”这类规则动态匹配聚合字段，所有可视化配置的聚合逻辑，都需要基于索引映射中已明确注册的固定字段名运行，没有内置的通配抓取嵌套对象下不定名子字段的能力

当前存储方案的具体缺陷 #

你目前把动态语言键作为嵌套对象的属性、单文档存入Elastic的方式，存在两个不可持续的问题：

• 索引映射会持续膨胀：每次API返回新的键（比如新增zh_CN、ja_JP这类语言），Elastic的自动映射机制就会新增一个value.xxx类型的字段，时间长了很容易触发字段数量上限，也会让Kibana的字段列表变得杂乱无章
• 可视化配置完全依赖静态字段：哪怕手动配置能跑通，只要API返回的键集合发生变化，就必须手动修改可视化的字段选择规则，完全没法做到动态适配，和自动化展示的需求完全相悖

可落地的改造方案（零额外版本升级要求） #

完全不需要依赖Kibana的动态字段能力，只要在数据写入Elastic前调整文档结构，把“动态键的差异”从“文档结构的差异”转成“维度取值的差异”，就能从根本上解决动态适配的问题。

改造后的文档结构规范 #

不管API返回多少个动态键，最终写入Elastic的文档结构是完全固定的，不存在随API返回内容变化的字段：
原来你可能存的单条聚合文档长这样：

{
  "business_id": "biz_001",
  "collect_time": "2024-05-20T12:00:00Z",
  "other_business_attrs": "xxx",
  "value": {
    "en_GB": 181,
    "en_US": 86,
    "es_ES": 20,
    "fr_FR": 10
  }
}

改造后需要把上面的单个嵌套对象，拆成和键数量一致的多条独立文档，每条文档的结构完全固定：

// 文档1
{
  "business_id": "biz_001",
  "collect_time": "2024-05-20T12:00:00Z",
  "other_business_attrs": "xxx",
  "dimension_key": "en_GB",
  "metric_value": 181
}
// 文档2
{
  "business_id": "biz_001",
  "collect_time": "2024-05-20T12:00:00Z",
  "other_business_attrs": "xxx",
  "dimension_key": "en_US",
  "metric_value": 86
}
// 文档3
{
  "business_id": "biz_001",
  "collect_time": "2024-05-20T12:00:00Z",
  "other_business_attrs": "xxx",
  "dimension_key": "es_ES",
  "metric_value": 20
}
// 文档4
{
  "business_id": "biz_001",
  "collect_time": "2024-05-20T12:00:00Z",
  "other_business_attrs": "xxx",
  "dimension_key": "fr_FR",
  "metric_value": 10
}

对应的Kibana可视化配置逻辑 #

不管后续API返回多少个新的语言键，你都只需要在Kibana里做一次固定配置，就可以自动适配所有动态变化的维度：

• 做饼图时，桶聚合选择Terms类型，字段选固定的dimension_key，设置合适的桶数量上限
• 指标聚合选择Sum类型，字段选固定的metric_value
  配置完成后，图表会自动统计所有dimension_key的取值对应的指标总和，生成对应的扇区，不需要每次新增键就去调整可视化配置。

落地注意事项 #

• 不需要提前计算每个键的占比存入文档，Kibana的饼图会自动根据指标值计算每个扇区的占比，减少ETL流程的冗余计算
• 提前给dimension_key字段设置keyword类型的映射，避免Elastic自动把它识别成text类型，影响聚合性能
• 拆分成细粒度文档带来的存储成本增长非常有限，7.11版本的Elastic对同结构文档的压缩比很高，配合基础的索引生命周期管理，存储压力基本可以忽略
• 如果需要保留原始的嵌套值结构作为留档，可以在写入时同时存一份原始的value对象字段，但用于可视化聚合的部分一定要用固定结构的细粒度文档

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