Elasticsearch 高基数聚合性能提升3倍，改动了什么？

1、上问题

这是来自球友实战问题。

 

大致需求介绍如下：

 

约 3600 万的数据，其中关键字段如下所示：

用 cardinality 聚合统计，creator 的个数有约 1300 万。

 

问题：但在高基数（high cardinality）的情形下，性能不理想。

 

2、概念解读：什么是高基数？

为了更精确解读，这里直接拿：Elastic 官方博客只字不差的翻译。

terms 聚合的性能可能会受到所聚合字段的基数的极大影响。

 

基数（Cardinality）是指存储在特定字段中的值的唯一性。

 

 •  高基数：意味着一个字段包含很大比例的唯一值。

举例：电子邮件地址可能会有数千万+唯一值，属于高基数。（换了举例）

 

 •  低基数：意味着一个字段包含很多重复的值。

举例：因为世界上少于200个国家，国家名称就是低基数。

 

3、问题本质

经反复讨论，本质问题：高基数业务场景下，聚合慢，达不到预期。

 

我记得刚入职场，我向导师的导师（辈分应该是：师爷）当面请教一个问题，我说了很长，他实在听不下去了，就说了一句：“你的问题是什么？”，一语惊醒梦中人，我一直记到今天。

 

后面当我再向别人请教问题的时候，我都提前打好草稿、列好提纲，快速且直接说出重点、交流效率提升不少。

 

毫不夸张的说，能用简短的话描述清楚问题，问题就能基本解决了一大半。

 

4、怎么改进呢？

经反复讨论，结合球友之前的实践，思路如下：

 

 •  第一 ：对于字段值，存储Hash值（写入时处理）。

 •  第二 ：基于Hash 做聚合和统计分析操作。

5、Elasticsearch 有 Hash 值类型吗？

早期版本（7.X 之前）没有，但是 7.X 之后有。

 

如下借助 mapper-murmur3 插件实现：

 

插件地址：

 

https://www.elastic.co/guide/en/elasticsearch/plugins/7.2/mapper-murmur3.html

 

murmur3 需要着重介绍一下：

 

维基百科解读：MurmurHash 是一种非加密型哈希函数，适用于一般的哈希检索操作。

 

由 Austin Appleby 在 2008年发明， 并出现了多个变种，都已经发布到了公有领域(public domain)。

 

与其它流行的哈希函数相比，对于规律性较强的 key，MurmurHash的随机分布特征表现更良好。

 

Redis 在实现字典时用到了两种不同的哈希算法，MurmurHash 便是其中一种（另一种是djb），在 Redis 中应用十分广泛，包括数据库、集群、哈希键、阻塞操作等功能都用到了这个算法。

 

发明算法的作者被邀到 google 工作，该算法最新版本是 MurmurHash3 ， 基于MurmurHash2改进了一些小瑕疵，使得速度更快，实现了 32 位（低延时）、128 位 HashKey，尤其对大块的数据，具有较高的平衡性与低碰撞率。

 

6、mapper-murmur3 插件实践一把

第一步：插件安装

第二步：导入Demo测试

聚合结果如下：

这时候，就能比较清晰的看出murmur3的作用：

 

 •  属于 Mapping的特定字段类型。

 •  可以和keyword类型组合当做复合类型使用。

 •  _source  不存储结果值。

 •  只在聚合后才能看到结果。

7、加了 mapper-murmur3 Hash 后效果如何呢？

球友实践反馈如下：

8、在相对低基数聚合性能如何呢？

实战一把。

8.1 模拟生成 1000W+数据。

文本文件输入了 39415 name信息（随机生成）。通过 python-dsl 随机生成写入 ES集群。

 

写入结果如下所示：

索引1：

索引2：

8.2 低基数有多低？

 •  去重后的结果：39415。

 •  原始数据量：11509010。

 •  占比：0.342%

虽然高、低基数没有明确数据量多少的定义，但，这明显是低基数。

 

8.2 聚合结果对比

如上所示 ，未加Hash的索引聚合要被加了Hash 的快一倍！

 

这也初步说明：Hash 在低基数聚合没有效果。

9、小结

以上验证和测试仅供参考，实际选型需要结合业务场景实际，进行充分验证后再做定夺。

 

类似高基数聚合业务场景，你实践中的优化点是什么？欢迎留言交流。