做地理空间数据这行十年了，最烦的就是客户拿着Excel过来问：“哎，你们系统怎么把同一个门店标了两遍？”我一看后台日志，血压瞬间就上来了。这帮人以为ES是万能的，其实很多时候是你自己把数据搞乱了。今天不整虚的，直接聊ES geo_point去重这个让人头秃的问题。

很多人第一反应是：哎呀，加个唯一索引呗。对，但是geo_point比较特殊。你存经纬度，精度稍微差一点，比如一个是116.4074,39.9042，另一个是116.4074000000001,39.9042000000001，在ES眼里这就是两个完全不同的点。虽然地图上看着重合，但底层数据就是没去重。这就是典型的“伪去重”。

我见过太多团队在这里栽跟头。之前有个做物流轨迹的客户，每天几百万条数据进来，结果发现同一个司机同一个时间段出现了多条记录。查了半天，发现是前端上报的GPS漂移，加上后端没做预处理，直接塞进ES了。这时候你再去搞去重，那查询压力直接爆表。

那怎么搞？别指望ES原生聚合能完美解决所有精度问题。你得在写入前做文章。我的建议是，先对经纬度做量化处理。比如保留小数点后6位，或者根据业务场景，把坐标映射到一个网格ID上。这个网格ID就是你去重的关键。

举个例子，你可以写个简单的脚本，在数据进入ES之前，把经纬度四舍五入到指定精度。这样，同一个地点的不同微小偏差就被抹平了。然后再把这个处理后的坐标作为唯一标识。这样再去重，效率杠杠的。

当然，如果你已经存进去了，数据量大得离谱，别想着全量扫描去重，那是找死。你得用滚动窗口或者定期清理的策略。比如，每天凌晨跑个任务，把前一天的数据拿出来，按“设备ID+时间窗口+量化坐标”分组，只保留最新的一条。这个逻辑虽然简单，但非常有效。

这里有个坑，千万别踩。别直接用文档ID去重，除非你严格控制ID生成逻辑。很多时候，业务系统生成的ID本身就带有随机性或者时间戳，导致同一个物理点在不同时间写入时，ID不一样，ES根本不会覆盖。这时候你就得用_update_by_query或者重新索引来清理脏数据。

说到价格，找外包做这种数据清洗，起步价都在几万块，因为涉及到底层数据架构的调整。自己搞虽然省钱，但得熬通宵调参。我上次帮朋友调这个，为了把精度从8位降到6位，测试环境跑了三天，生产环境差点挂掉。真的，别低估数据治理的难度。

还有，别信那些说“ES自带去重功能”的鬼话。ES确实有doc_values和stored fields，但那是为了查询优化，不是为了帮你擦屁股。你得自己定义什么是“重复”。是时间戳完全一致？还是坐标在10米范围内？这个业务逻辑必须清晰，否则去了个寂寞。

最后，提醒一句，日志别打得太密。每次去重操作，记得监控集群的CPU和内存。我见过因为一个错误的去重脚本，把整个集群打满，导致线上服务不可用的惨案。那时候哭都来不及。

总之，ES geo_point去重，核心不在ES，而在数据预处理。把脏数据拦在门外，比在门内打扫要轻松得多。别等数据堆积如山了，才想起来找解决方案。那时候，除了加班，你什么都做不了。

本文关键词：es geo_point去重