地理空间索引与分区方法详解：Geohash、S2、H3和Quadbin全解析

照片由摄影师 CHUTTERSNAP 在 Unsplash 分享了这张照片

所有确定性的数据处理从根本上来说都是基于搜索和排序的。为了高效处理数据，通常会先丢弃不需要的数据，进行搜索和排序——索引和分区就是为此而存在的。索引和分区的具体实现细节通常对最终用户来说是抽象的，不过，不同类型的索引和分区更适合不同类型的数据。

关系型数据库和数据仓库平台支持诸如B-tree、B+树、GiST、SP-GiST和Hash之类的索引。其中一些索引更适合用于数字和短文本字段的点查找，而其他的则更适合全文检索等。说到地理空间数据，一种流行的索引是R-树，下面是从PostgreSQL文档中摘录的关于R-树的描述：

_> R-树将数据分成矩形、子矩形、孙矩形等。这是一种能自我调整的索引结构，能自动应对数据密度的变化，不同的重叠程度，并且能自动处理不同对象的大小。

在[kd-tree]、[Quadtree]、[Octree]等索引方法中存在许多变体，这些索引方法被包含在数据库的底层实现中，这意味着添加、删除或更改数据会导致昂贵的树平衡和索引重建。这不仅会增加计算成本，还会影响正在进行查询的性能。由于这一限制，各种数据处理系统开发了可插拔的[地理空间索引和分区系统]，以将索引与核心数据库操作解耦。这些系统基于地球表面可以被看作网格系统的理念。摘自Uber的工程博客文章：

一个全球网格系统通常需要两个基本要素：地图投影法和覆盖在地图上的网格层。地图投影法是将地球上的三维位置转换为地图上的二维坐标点所必需的。然后在地图上叠加网格层，形成全球网格系统框架。

在这篇文章里，我将简单介绍其中一些系统及其背景，重点关注Google的S2、Uber的H3和Bing Maps的Quadbin的索引方式。但在我们开始之前，首先让我们快速了解一下地理空间数据中的索引和分区是怎么运作的。

在传统的数据库意义上，建立索引是指根据特定列的某种排序建立索引表。而在同样的背景下，分区通常是指在同一逻辑表下，物理上将文件分割。

尽管在地理空间领域有许多索引方法，我们稍后会详细讨论这些方法，但重要的是要注意，它们其实并不是真正的索引技术。相反，它们实际上是分区技术。

为什么我会这么说？索引通常帮助你以特定方式对数据进行排序，以便更快速地检索，而分区则帮助你将数据隔离开以达到同样的目的，即。当涉及到地理空间数据时，我们使用流行的地理空间分区方法如S2、H3和Quadbin实际上是在进行分区，而不是索引。

这就是为什么Uber H3的文档称H3为一个六边形分层空间索引系统，可以“让用户将地球划分成六边形，从而进行更准确的分析。”我们现在来了解一下网格系统的一些分区方法，。

虽然存在许多索引（分区）方法，但有四种方法在很多数据处理和可视化系统中得到广泛应用和支持，因此脱颖而出。这四种方法中的三种，S2、H3 和 Quadbin，分别由三家大公司开发，这些公司试图解决导航地图相关的问题，而 Geohash 则是由 Canonical 的首席技术官 Gustavo Niemeyer 创建的。

这是我们讨论过的四种方法中最古老的一种。Geohash的作者在2008年将其公开。它基于的是在几千年前被发明的等积矩形投影法。它和其他即将讨论的方法一样，也存在一些缺点。毕竟，我们试图将一个不规则的椭球体（我们美丽的星球）映射到一个完美的矩形中。投影可能会带来哪些问题呢？不妨通过观看这个简短的视频来了解更多有关投影问题的信息。

不过，它仍然是实现近距离搜索的最常用方法之一。它将位置信息编码为字符串而非数字，同时创建了一个分层的四叉树网格系统。它用于地点识别，但更易于人类理解的类似哈希的方法是what3words，这是一种将任何经纬度对转换为一个面积为3平方米的方块，可以用三个单词来表示，如///candy.wire.dull。顺便说一下，这也是我们Versent墨尔本办公室的地址。

Geohash 可以达到任意级别的细分。当你放大查看时，你会将这些方格分成四个，使它们排列成用于搜索和遍历的树状结构。这时就会用到 Z 顺序曲线，它对这些方格进行排序，从而自动支持你对整个树进行广度优先搜索，就像一层一层地查看一样。

有趣的是，Z-顺序曲线也被用来重组磁盘上的数据以加快查询速度。此功能在 Delta Lake 文件格式中本机支持。Databricks 的文档中提到：

Z-顺序是一种将相关数据放在同一组文件内的技术。这种局部性会被 Delta Lake 在 Databricks 的数据跳过算法中自动利用。这种行为大大减少了 Delta Lake 在 Databricks 中需要读取的数据量。

Cloudera 的博客也提到使用 Z-顺序曲线来加速查询，Apache Hudi、AWS DynamoDB 和 Aurora MySQL 等也有相关介绍等等。

然而，使用Geohash（以及Z顺序曲线来遍历）也存在一些问题，主要是由于投影的选择和使用的网格形状。在不同纬度下，方格的差异会变得很大。在搜索靠近Geohash方格边界附近的点时，也会遇到一些限制，也就是说，靠近边界点的哈希值会非常不同，因此无法识别。

地理空间处理可能需要很多计算资源。为解决这个问题，Google 开源的索引库 S2 假设地球是一个完美的数学球体，从而使特定地理空间处理更简单且成本更低。

S2是我们在讨论的三种方法中唯一一个以三维球面上的四边形层次结构来表示数据的方法。因此，S2在接近南北两极的区域扭曲较少。

S2 提供多种形状和尺寸，您可以用它们来划分网格，包括球冠或圆盘、经纬度矩形、多段线和多边形。因此，这使得 S2 成为实现基于邻近性的搜索、地理信息的简化和快速查找功能的好选择。

请注意，面积占比表示该分区方法在其所有分区组合中成功表示的准确度。S2 使用基于连续并填充空间的 Hilbert 曲线的函数，该曲线会遍历单位正方形中的每一个点，以此将球体划分为更小的部分；这就是你在地图上遍历网格并进行搜索的方式。

这值得一提，因为在讨论H3和Quadbin的过程中，虽然使用了稍微不同的方法，网格遍历也会再次出现。想了解更多，请参阅以下内容。

• BigQuery 中的网格系统空间分析
• Google 的 S2 系统，球面几何，网格和 Hilbert 曲线

然而，谷歌的S2与Geohash一样存在同样的问题。网格单元与其邻近单元并不保持等距，这在很多应用场景中带来了很多麻烦。至少可以保证一个数据点总是落在唯一的网格单元中，相比之下，Uber的H3可能会落入多个单元格，我们稍后再详谈这一点。S2在很多方面都比Geohash要好，但它在便携性、互操作性和广泛支持方面都不如Geohash，这也是它可能难以普及的原因。

必应地图也在2005年推出，与谷歌地图同年，但采用了不同的方式来绘制全球地图时，使用了四叉树（在概念上与GeoHash非常相似）。必应地图的四叉树可以达到最多23层。这种实现方式被称为Quadkey。

Quadkey 指标和缩放级别 — 来自 Azure Maps 文档的图片.

Quadbin 是一种基于 Quadkey 的分层索引。它将网格单元值存储在一个 64 位的数字中，并将细节层次进一步扩展至 27 层，这可以指向小于 1 平方米的区域。Bing Maps 使用墨卡托投影，这带来了一些挑战，尤其是在 Bing Maps 中使用时。虽然 Bing Maps 计划在 2025 年被淘汰，但 Azure Maps 将继续使用球面墨卡托投影坐标系。

与其他系统使用矩形和正方形创建可映射的全球网格不同，H3 使用六边形，假设地球是一个正二十面体而非一个完美的球体。这与 Geohash（使用等积投影）、S2（使用立体投影）和 Quadbin（使用麦卡托投影）的方法不同。H3 开源之初的博客文章对这种选择这样解释：

这种投影将地球从一个球体投射到一个二十面体，即一个每个面都是等边三角形的正多面体。基于二十面体的地图投影将地球分成二十个二维平面，而不是单一的平面。二十面体可以以多种方式展开，每次展开都会生成一个二维地图。然而，H3 并不通过展开二十面体来构建网格系统，而是直接在其面上铺设网格，形成一个地理离散网格系统。

我在另一篇文章中讨论了H3，这篇文章是关于Snowflake中的地理空间数据的摄入、索引和分析的。我也讨论了为什么在进行网格之间的距离计算、邻近搜索以及导航时，六边形更有优势，尤其是在这些场景下。

本·费夫克在他的博客文章中最后部分比较了这三个索引和分区方法，并讨论了使用时机。详情请参阅这篇文章。

这些索引和分区系统在大多数数据库和数据仓库系统中都能找到。它们可以独立使用，也可以与数据库的核心索引实现解耦。例如，Foursquare的层库提供H3、S2 和 Hexbin 层，这些层既可以用于分析计算，也可以作为现有地理空间可视化之上的叠加层。

对不同网格系统（尤其是H3和Geohash）的支持在数据生态系统中前景非常看好。PostgreSQL、Snowflake、Databricks、ClickHouse 乃至更新的数据库如 DuckDB 都提供了相应的扩展或内置库支持。这意味着你可以根据具体需求选择合适的索引和分区方案。

我的地理空间索引和分区系统的工作经验是使用PostgreSQL搭配PostGIS（可以说是最经典的），Redshift，还有MySQL等。不过最近，我花了不少时间研究Snowflake在地理空间数据上的新功能，它每天都在变得更有前景。可以查看2024年6月更新的最后部分，了解更多关于新H3函数的信息。

我希望这篇关于地理空间索引与分区系统的概述对你有所帮助。我接下来要写的是这个系列的下一篇，将探讨一个实际的地理空间数据应用场景，使用上面提到的其中一个数据库系统。

感谢 Kroum Kluctchkov、Dima Marr 和 Haymang Ahuja 三位在本篇博客文章上提供的反馈。