做Geo相关的项目快七年了，说实话，每次听到客户说“我们要用HBase存海量位置数据，还要秒级查询”，我头皮都发麻。不是技术不行，是坑太多。很多团队刚起步时，觉得HBase天生就是为海量数据设计的，随便建个表，把经纬度扔进去，就能跑通。结果上线一测，查询慢得像蜗牛，CPU飙到100%，运维电话被打爆。今天不聊虚的，就聊聊怎么把HBase geo性能做到极致，全是真金白银砸出来的教训。
先说个真实案例。去年有个做共享出行的大客户，每天产生上亿条轨迹数据。他们最初的设计很简单，RowKey直接拼接用户ID和时间戳。查询时，用Filter去扫描全表，找某个区域内的车辆。这操作，简直是自杀。当时他们的查询延迟在5秒以上，对于实时调度来说，这数据已经废了。后来我们介入，第一件事就是重构RowKey。
很多人不知道，HBase geo性能的核心不在于存储，而在于如何把空间关系转化为HBase能理解的顺序关系。如果你还在用简单的经纬度拼接，那基本告别高性能了。我们采用的方案是基于HBase的自定义RowKey设计，结合GeoHash或者S2 Geometry库。
第一步，确定空间索引策略。别迷信通用方案，要根据你的查询场景来。如果是点查询，GeoHash是个不错的选择，因为它能把二维坐标映射为一维字符串，且前缀匹配效率高。但要注意，GeoHash在边界处会有跳跃问题，导致相邻区域在HBase中分布极远。这时候，S2库就更靠谱，它将地球表面划分为层级化的四边形，查询时可以通过范围扫描，大幅减少IO。
第二步，优化RowKey结构。这是最关键的一步。我们将RowKey设计为：[空间索引前缀][时间戳倒序][唯一标识]。比如，用S2生成的6级精度编码作为前缀，这样同一区域的数据在物理存储上就是连续的。时间戳倒序是为了让最新的数据排在前面，因为大多数业务场景下，最新位置的查询频率最高。这样设计后，查询时只需要扫描特定的Region，而不是全表扫描。
第三步，调整HBase配置。别忽视这些参数。对于高并发的Geo查询，建议开启预分区（Pre-splitting）。根据S2的层级，手动划分Region，避免热点数据集中在一个Region上。另外，增加MemStore的大小，减少刷盘频率，能显著提升写入性能。我们当时把MemStore从默认的64MB调到了256MB，写入吞吐量提升了近一倍。
还有一个容易被忽视的细节：数据倾斜。在做Geo项目时，市中心的数据量往往是郊区的几十倍。如果RowKey设计不当，会导致某些Region负载过高。解决办法是在RowKey中加入随机数或哈希值，打散热点。但这会牺牲一定的查询效率，需要权衡。我们采用的折中方案是，对高频查询区域使用更细粒度的索引，对低频区域使用粗粒度索引。
经过这些优化，客户的查询延迟从5秒降到了200毫秒以内，CPU使用率也稳定在30%以下。这不仅仅是技术的胜利，更是对业务场景深刻理解的结果。
最后，我想说，HBase geo性能优化没有银弹。它需要你深入理解数据分布、查询模式以及HBase的内部机制。不要盲目追求新技术，有时候，一个简单的RowKey重构，比引入复杂的搜索引擎更有效。希望这些经验能帮你在踩坑的路上少摔几跤。毕竟，在这个行业，活得久比跑得快更重要。
