无需murmur3插件的ElasticSearch基数聚合预计算哈希相关问题

针对你在高基数string/keyword字段基数聚合场景下，关于预计算哈希方案的三个疑问，解答如下：

1. 预计算哈希值的数据类型要求 #

预计算的哈希值必须存储为数值类型（比如long），不能用字符串类型的keyword字段。因为基数聚合（cardinality）在处理预计算哈希时，依赖数值类型的二进制表示直接参与HyperLogLog算法计算，字符串类型无法被识别为预计算哈希值，ES仍会对其重新计算哈希。

2. 字符串类型keyword无法被识别为预计算哈希 #

ES不会自动识别字符串类型的keyword字段是预计算哈希——从字段结构上看，它和普通keyword没有区别。只有当字段是数值类型，且聚合时触发ES对数值类型的默认优化（或指定execution_hint: "map"），才会直接使用存储的数值作为哈希值，跳过重新计算步骤。如果用字符串存储哈希，ES只会把它当成普通字符串处理，依然会执行murmur3哈希计算，达不到预计算的目的。

3. 预计算哈希的性能与内存影响 #

你的推测基本正确：预计算哈希主要提升聚合速度，对内存占用的优化非常有限。
底层原理是：基数聚合依赖HyperLogLog算法，该算法的内存消耗由精度参数（precision_threshold）决定，和输入值的类型无关——不管是原字符串还是预计算的哈希值，最终都会被映射到HyperLogLog的桶中，内存占用是固定的。预计算哈希只是省去了ES在聚合时对每个字符串执行murmur3哈希的CPU开销，尤其是高基数场景下，大量字符串的哈希计算会消耗可观的CPU，预计算后能显著降低这部分耗时，但内存占用不会有明显变化。

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