做LBS（基于位置的服务）这行，最怕的不是技术难，而是数据脏。
上周有个老客户找我救火。他们的APP上线半年，用户量涨得挺快，但后台的地图热力图乱成一锅粥。有的用户明明在上海，定位却飘到了太平洋中心；有的店铺坐标重复录入，导致推送广告时，同一个用户一天收到三遍同样的优惠券。老板急得跳脚，问我是不是地图API挂了。
我一看日志，根本不是API的问题。是前端采集的数据太野，加上后端入库时没做校验，直接把垃圾数据存进了库。这就是典型的geo数据库数据清洗没做到位。
很多人觉得，数据清洗是IT部门的事，业务只管用。大错特错。
地理数据有个特性，它是不连续的、非结构化的。手机号错了还能打不通，地址错了还能猜个大概，但经纬度错了，整个业务逻辑就崩了。比如你做外卖配送，坐标偏差500米，骑手就得多跑两公里，用户体验直接拉胯。
我经手过几个大项目，总结下来，清洗流程其实就三步，但每一步都有坑。
第一步，去重与异常值剔除。
别信那些“精确到小数点后10位”的数据，那是扯淡。手机GPS本身就有漂移，室内定位更是玄学。我们通常会把精度低于50米的坐标直接标记为低置信度，或者在入库前做一次简单的聚类分析。
有个案例，某连锁咖啡店的数据里，有30%的订单坐标集中在同一个点，但时间跨度长达三年。查了才知道，那是他们的总部大楼，很多员工在总部下单，但收货地址填的是家里。如果不清洗，这部分数据会严重干扰商圈分析。我们后来加了个逻辑：如果同一坐标点频繁出现，且与用户历史常驻地不符，就标记为“疑似办公地”，在营销推送时单独处理。
第二步，地址标准化与地理编码纠错。
用户输入的地址千奇百怪。“万达广场对面”、“星巴克隔壁”、“那个卖煎饼的地方”。这些非结构化文本，必须通过地理编码接口转换成经纬度。但接口不是万能的，它会把“北京”解析为北京市中心，而不是用户所在的北京某小区。
这时候需要引入模糊匹配算法。我们通常会建立一套本地化的地址库，把常见的错误写法映射到标准地址上。比如把“王府井大街”和“王府井”统一，把“朝阳区”和“朝阳”做关联。这个过程很繁琐，需要人工抽检，大概每清洗10万条数据，就要人工复核500条左右，确保算法没跑偏。
第三步，时空一致性校验。
这是最容易被忽略的。一个人不可能在1分钟内从北京移动到上海。如果数据库里出现这种数据，要么是设备故障，要么是人为作弊。我们曾发现一个黑产团伙，利用虚拟定位软件刷单，他们的轨迹呈现出明显的“瞬移”特征。通过设置速度阈值，比如每小时移动不超过100公里，就能过滤掉大部分作弊数据。
清洗不是一劳永逸的。
数据是流动的，今天的清洗规则，明天可能就过时了。比如随着北斗精度的提升，以前认为的“漂移”，现在可能就是正常误差。所以，建立自动化的监控机制很重要。当异常数据比例突然飙升，系统得自动报警，而不是等老板发现用户投诉了才去查。
我常跟团队说，geo数据库数据清洗，本质上是在重建用户对品牌的信任。你给的定位准，用户觉得你专业；你推的广告对，用户觉得你懂他。反之，如果数据脏，用户只会觉得这是个骗子平台。
别嫌麻烦，数据质量决定业务上限。那些看似不起眼的坐标点，背后都是真金白银的投入。把基础打牢，后面的算法模型才能跑得稳。
本文关键词：geo数据库数据清洗
