【Elasticsearch】Elasticsearch 字段膨胀不要怕，Flattened 类型解千愁

1.概述

转载：Elasticsearch 字段膨胀不要怕，Flattened 类型解千愁

2.线上真实案例

球友问题：我记得您写过一篇关于建模字段膨胀的问题，对于比如request header response这种动态的对象，是怎么处理来着？

进一步反馈：决定升级es高版本了，Flattened 解千愁！主要我们这需求要把接口所有信息都保留，只能这样了。

3.Elasticsarch 字段膨胀

Elasticsearch Mapping 如果不做特殊设置，默认为 dynamic。dynamic 的本质就是：不加约束的动态添加字段。这样对某些日志场景，可能会产生大量的未知字段。字段如果持续激增，就会达到 Elasticsearch Mapping 层面的默认上限，对应设置和默认大小为：index.mapping.total_fields.limit：1000。

我们把这种非预期字段激增的现象或结果称为：字段膨胀。

拿自己线上环境示例，说一下 dynamic 的副作用。在一个实际业务环境，混淆了检索和写入的语法，会导致将检索语句动态认定为新增 Mapping 字段。

当然，如果是非常复杂的大 bool 检索语句，会导致 Mapping 变得非常复杂甚至会出现字段膨胀的情况。

当然，可行的解决方案就是：dynamic 设置为 false，甚至更为严谨的推荐方式：将 dynamic 设置为 strict。

3.1 解决字段膨胀方案一：dynamic 设置为 false

dynamic 设置为 false 后，新来的非 mapping 预设字段数据可以写入，但是：不能被检索，仅支持 Get 获取文档的方式通过 _source 查看详情内容。

举例如下：

3.2 解决字段膨胀方案二：dynamic 设置为 strict

dynamic 一旦设置为：strict，会“阻止一切来犯之敌”，一切索引创建阶段指定的 Mapping 字段之外的字段名称都将会报错。

设置为 strict 后，再动态插入数据，会报错如下：

{
  "error" : {
    "root_cause" : [
      {
        "type" : "strict_dynamic_mapping_exception",
        "reason" : "mapping set to strict, dynamic introduction of [cont] within [_doc] is not allowed"
      }
    ],
    "type" : "strict_dynamic_mapping_exception",
    "reason" : "mapping set to strict, dynamic introduction of [cont] within [_doc] is not allowed"
  },
  "status" : 400
}

4、Flattened 类型产生的背景

如前分析，将 dynamic 设置为 false 或者 strict 不是普适的解决方案 ，如日志场景需求如下：

一方面：期望能动态添加字段。strict 过于严谨会导致新字段数据拒绝写入，dynamic 过于松散会字段膨胀。

另一方面：不期望索引字段膨胀。

这就导致同时满足上述两个方面的 Flattend 字段的诞生。

Flattened 中文释义：“压扁、弄平”，实际就是字段扁平化的意思。

当面临处理包含大量不可预测字段的文档时，使用 Flattend 类型可以通过将整个 JSON 对象及其嵌套 Nested 字段索引为单个关键字 keyword 类型字段来帮助减少字段总数。

Flattened 类型的最早发布在：7.3 版本。

5、Flattened 类型解决的根本问题

特定日志场景、电商场景，Elasticsearch Mapping 字段数有时是无法预知的。如果随着新写入数据激增，字段也激增，可能带来的后果是什么呢？

Elasticsearch 必须为每个新字段更新集群状态，并且必须将此集群状态传递给所有节点。由于跨节点的集群状态传输是单线程操作，因此需要更新的字段映射越多，完成更新所需的时间就越长。这种延迟通常大大降低集群性能，有时会导致整个集群宕机。这被称为“ Mapping 爆炸”（mapping explosion）。

这也是 Elasticsearch 从 5.x 及更高版本将索引中的字段数限制为 1000 的原因之一。如果实战业务场景字段数超过 1000，我们必须手动更改默认索引字段限制或者重新考虑架构重构。

修改默认值的方式如下：

PUT record_infos
{
  "settings": {
    "index.mapping.total_fields.limit": 2000
  }
}

Flattened 扁平化字段就是解决：“Mapping 爆炸”问题的。

6.Flattened 类型实战解读

6.1 Flattened 类型真容

千呼万唤始出来，Flattend 真容如下：

这和 Integer、long、nested、join 等都属于字段类型的范畴。

Flattened 本质是：将原来一个复杂的 Object 或者 Nested 嵌套多字段类型统一映射为偏平的单字段类型。

这里要强调的，不管原来内嵌多少个字段，内嵌多少层，有了 Flattend，一下都打平！！

6.2 基于 Flattened 类型插入数据

基于上面的 Mapping，写入一条数据如下：

PUT demo-flattened/_doc/1
{
  "message": "[5592:1:0309/123054.737712:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.",
  "fileset": {
    "name": "syslog"
  },
  "process": {
    "name": "org.gnome.Shell.desktop",
    "pid": 3383
  },
  "@timestamp": "2020-03-09T18:00:54.000+05:30",
  "host": {
    "hostname": "bionic",
    "name": "bionic"
  }
}

这时候再查看 Mapping， 如下：

由于 host 字段设置为：Flattened，其下的：hostname、name 字段都不再映射为特定嵌套子字段。

6.3 更新 Flattened 字段，添加数据

POST demo-flattened/_update/1
{
  "doc": {
    "host": {
      "osVersion": "Bionic Beaver",
      "osArchitecture": "x86_64"
    }
  }
}

再次查看 Mapping，依然“岿然不动”。继续 Flattened 拉平，没有字段扩增，也就不会再有 “Mapping 爆炸”出现。

6.4 Flattened 类型检索

以下两种检索都会召回数据：

GET demo-flattened/_search
{
  "query": {
    "term": {
      "host": "Bionic Beaver"
    }
  }
}
GET demo-flattened/_search
{
  "query": {
    "term": {
      "host.osVersion": "Bionic Beaver"
    }
  }
}

而，如下的检索，则返回结果为空。

GET demo-flattened/_search
{
  "query": {
    "match": {
      "host.osVersion": "bionic beaver"
    }
  }
}

GET demo-flattened/_search
{
  "query": {
    "match": {
      "host.osVersion": "Beaver"
    }
  }
}

为什么呢？

由于使用 Flattened 扁平化类型，Elasticsearch 未对该字段进行分析，因此它只会返回匹配字母大小写且完全一致的结果。

如上检索结果和 keyword 类型检索结果一致。

这也初步暴露出：Flattened 类型的部分缺陷。

6.5 Flattend 类型的不足

每当面临 Flattened 扁平化对象的决定时，在选型 Elasticsearch 扁平化数据类型时，我们需要考虑以下几个关键限制：
Flattened 类型支持的查询类型目前仅限于以下几种：

term
terms
terms_set
prefix
range
match and multi_match
query_string and simple_query_string
exists

Flattened 不支持的查询类型如下：

1. 无法执行涉及数字计算的查询，例如：range query。
2. 无法支持高亮查询。
3. 尽管支持诸如 term 聚合之类的聚合，但不支持处理诸如“histograms”或“date_histograms”之类的数值数据的聚合。

7、小结

Flattened 类型的出现，解决了字段膨胀引起的 Mapping 爆炸问题，如果您的生产环境高于7.3版本，有文章开头类似问题，可以小心求证、大胆尝试这种新类型。

您生产环境使用 Flattened 类型了吗？您有没有遇到过字段膨胀或“Mapping 爆炸”问题，是如何解决的？

欢迎留言说一下您的实战思考！