大数据时代的空间数据引擎

【摘要】本文是有关分布式空间数据库相关空间大数据库技术的综述性文章，主要包括几个方面：（1）目前三种主要的分布式空间数据库类型；（2）目前三种重要的分布式空间数据库的实现途径；（3）六个分布式数据库重点考虑的技术点，其中核心是空间索引模型、查询方法和查询语言；（4）三类主要的空间索引模型；（5）空间运算及空间查询方法，有关具体查询算法和空间索引模型密切相关，本文不做过多细节展开；（6）空间查询语言，由于目前不是本人关注重点，暂略，待后面补充。希望通过本文的介绍，让同学们能够对当前分布式空间数据库的技术现状有所了解，更多技术细节请参考文中列出的链接或参考文献，自信深入阅读。

一、分布式空间数据库的三种类型

根据目前空间大数据存储、组织和计算的现状，初步梳理如下：

3.1 以专业应用为重点，基于并行数据库的系统

以Parallel Secondo、Paradise、Sphinx为代表
重点解决的是如何在并行数据库（如：Exodus、Impala等）中实现空间数据的高效组织
此类系统的分布式能力来源于数据库本身
此类分布式空间数据库受限于并行数据库本身的弹性和可扩展性。

参考资料：

Parallel Secondo

Paradise

Sphinx

3.2 以海量空间数据组织为重点，以分布式文件系统或分布式数据库为基础的系统

此类以GeoMesa、SpatialHadoop、HadoopGIS等为代表
重点解决的是分布式集群环境下的数据存储与组织问题
组织和管理的主体是过去的不再需要更新的时空数据
其基础大多为分布式的NoSQL数据库，如：HBase,、Accumulo、 Cassandra、 Kafka、Elastic Search、MongoDB等分布式数据库
或者直接在HDFS等分布式文件系统支撑下设计自己的存储机制（SpatialHadoop和HadoopGIS都属于这一类，GeoMesa也有自己的文件系统支持）
研究重点是如何适应上述分布式存储系统或分布式数据库，实现空间数据的分区存储、分级索引，同时提供诸如点查询、范围查询、邻近查询、空间Join等分布式空间数据检索功能。
由于此类空间数据引擎主要解决的是“海量存储”的问题，因此，其关键技术点是在如何优化数据在多个节点的外围存储设备中合理分布的问题，如：硬盘等
其优点是可以存储、组织和管理巨量的空间数据
缺点是在做任何数据分析时，输入数据、中间成果、输出结果都要从HDFS文件系统中读取数据，而且HDFS文件系统自身存在块容量大、只能追加、不允许更新的缺点，所以此类空间数据库难以适应数据快速更新（如：物联网传感器数据、车流数据等）、和需要近实时做空间分析和计算的场景要求。

参考资料：

SpatialHadoop

GeoMesa

HadoopGIS

（3）以响应速度为重点，以内存计算框架和分布式存储为技术特点的系统

此类以GeoSpark、SpatialIgnite、Simba、GeoTrellis等为代表，GeoTrellis是个挺有意思的系统，它以栅格数据为主。
重点解决在内存计算处理框架下，如何提升空间数据的分布式计算能力
其基础大多为Spark、Ignite、Redis 、Kudu、Storm等内存计算框架
提供内存对象创建、数据导入、分区存储、分级索引
提供诸如点查询、范围查询、邻近查询、空间join等基于分布式查询和计算功能
优点是在内存中存储和索引，检索、访问和计算速度非常快，对于快速处理应用适应性较好
缺点是处理结果最终还是要进入永久存储中，因此需要批量读入内存才能使用
此类系统主要为高性能计算系统提供快速空间数据检索、访问和基础空间分析支持。

参考资料：

GeoSpark — 基于Spark的内存存储与计算框架

SpatialIgnite — 基于Ignite的内存存储与计算框架

Simba — 基于Spark的内存存储与计算框架

GeoTrellis — 基于Spark的内存存储与计算框架，以栅格数据模型为主

二、分布式空间数据库的三种架构形式

分布式空间数据库的架构和实现形式，大致可以分为三类：

（1）On top 类型

此类引擎是较早的一类，如：SJMR、K-Means等
主要研究命题在于如何利用MapReduce实现各种空间逻辑运算，对底层存储和索引机制关心较少，更多出于分布式空间分析的算法研究而设计
优点在于实现简单
缺点在于数据的组织和访问性能相对较差。

（2）Built from scratch类型

为轨迹数据、遥感数据、地球科学数据等特殊任务而从底层分布式存储开始做起的空间数据引擎
如：EarthDB, TrajStore等
其优势在于更大的灵活性、专业性
缺点在于维护成本太高，尤其是同时实现空间数据与非空间数据的混合处理时，性能较差。

参考资料：

EarthDB

TrajStore

（3）Built inside类型

结合Hadoop/Spark等体系框架，在分布式存储（如：HDFS）、分布式检索与计算(如：MapReduce）、分布式数据库（如：HBase、Accumulo）等不同层次上实现相应组件
- 例如：
- GeoMesa利用空间填充曲线，在HBase基础上，实现空间数据检索和访问接口；
- SpatialHadoop直接在HDFS上建立数据存储模型和空间索引结构，并提供数据检索和访问接口；
- GeoSpark在Spark的RDD模型基础上建立内存空间数据引擎等。
主要功能：海量空间大数据的分布式存储索引、分布式查询检索、分布式空间分析、分布式可视化可视化实现等功能。

参考资料：

SpatialHadoop

GeoMesa

HadoopGIS

GeoSpark

上述三种类型中，Built Inside类型由于实现相对简单，而且不失灵活性，是目前普遍采用的一种方式。

三、分布式空间数据库的核心技术

空间数据库主要涉及以下核心技术问题：

3.1 数据模型

主要涉及矢量、栅格等。原来大多数空间数据引擎都有自己的数据模型，自OGC和ISO提出了ISO 19125国际标准（一个定义了点、线、面、多点、多线、多面、TIN等通用二维几何体的格式、存储、访问方法的国际标准）后，数据存储和交换的模型逐步得到了统一。

关于ISO 19125 Simple Feature Access 标准：

Part I：

该部分规定了基础几何实体的定义、模型和表达方法。

定义了常见的点、线、链、环、面、表面、TIN等几何实体模型

定义了几何实体模型应当具备的基本属性函数（如：维度、几何类型、空间参考系、求外包等）

定义了几何实体模型两两之间应当具备的空间关系判定函数（如：相等、相离、相交、相接、包含、重叠等）

定义了几何实体模型应当具备的常见空间分析函数（如：距离、缓冲区、凸外包、交运算、并运算、差运算等）

定义了空间数据Well-known Text Representation的文本格式和二进制格式

PartII：

该部分定义了以SQL为基础的空间要素表、几何实体和空间参考系等相关信息的管理方案，共由四种表组成基本架构：

一张 GEOMETRY_COLUMNS 表：

该表是个空间数据库的元数据表，描述了数据库中所有可用的空间要素表和它们的几何属性；

每一行由<要素表分类，要素表方案，要素表名称，几何列名称，几何表存储方案，几何表名称，几何类型，坐标范围，参考系等…>等列定义

一张 SPATIAL_REF_SYS 表：

数据库中参考系列表

该表描述了数据库中可用的参考坐标系统和转换参数；

每行由（参考系ID，国际标准坐标系名称、国际标准坐标系ID，WKT描述的坐标系参数信息）等列定义

若干张 FEATURE_TABLE 表：

空间要素的集合，以表结构形式定义，其中：各列表示空间要素的属性，各行分别表示一个特定的要素，Geometry是空间要素表的最重要属性，其中存储的是几何表中几何实体的ID；

若干张 GEOMETRY_TABLE 表：

几何表中存储的是采用SQL数值类型或二进制类型存储的几何对象

每一行代表一个几何对象，由<GID, YMIN, YMAX, XMIN, XMAX, WKB_GEOMETRY>六元组定义（还有另外一种归一化的表达方式，略）；

同时，该标准定义了数据库系统应该实现的基本空间关系运算

各种类型空间对象的基本属性Routines，如：多边形对象的外环、内环等

空间对象之间空间关系计算的Routines

如：ST_Equals, ST_Disjoint, ST_Intersects, ST_Touches, ST_Crosses, ST_Within, ST_Contains, ST_Overlaps and ST_Relate 等

参考资料：

ISO 19125 Part I

ISO 19125 Part II

相关开源库：

JTS Topology Suite (Java)：完成了ISO 19125标准几乎所有的功能。

GEOS (C/C++ port of JTS)：基于JTS实现的C++封装库。

Shapely (Python)：基于JTS的python封装库

GDAL (C/C++)：各种栅格和矢量地理空间数据格式的读取和转换库。

3.2 存储模型与实现机制

  目前的主要还是基于文件系统或数据库，随着分布式技术的广泛应用，存储也从单机的文件系统和数据库（如：NTFS、EXT、ZFS等），过渡到了分布式文件系统和数据库（如：GFS、HDFS、HBase、Accumulo、AsterixDB等），再到分布式内存文件系统和数据库（如：Spark、Storm、Ingite、等），并出现了对象存储等新的模型和机制。

（1）存储模型

大体分为有索引的模型和无索引的模型
但分布式空间数据库的主流还是有索引的存储模型

（2）分布式空间数据库的存储主要有五种实现机制：

直接基于分布式文件系统，自己设计数据模型和索引方案，如：SpatialHadoop、HadoopGIS等都是基于HDFS、GFS等
基于传统数据库系统的分布式版本，主要支持原有的关系数据库模型：如：Oracle、ElasticSearch等都支持分布式部署
基于并行数据库，主要用于遥感数据、地球数值数据等科学数据，如：EarthDB基于SciDB数据库
基于分布式数据库系统：如：GeoMesa、GeoWave的设计基本都基于HBase、Accumulo、AsterixDB等
基于分布式内存文件系统或数据库系统：如： GeoSpark、SIMBA、GeoTrellis基于Spark、SpatialIgnite基于Apache Ignite等
- 需要注意的是，最近几年出现了一个名为Alluxio的虚拟分布式文件系统，作为HDFS等分布式文件系统的缓冲层，以内存文件系统的方式，底层支持HDFS等文件系统的数据注入和缓存，向上支持Spark等分布式计算引擎，值得研究。

3.3 索引模型

索引模型是空间数据库的核心，其目的是通过对空间对象的某种编排，使得各类检索（重点是时空检索）的时效性有较大提升。不太严肃地说，索引数据和元数据类似，是有关数据加速的数据。

判断一个索引模型好坏的核心指标：

功能是否全面：
- 范围查询、临近查询、连接查询等的实现度
指标是否满足：
- 算法的复杂度分析：插入、删除、更新、查询的时间和算法复杂度的理论分析
- 查询的准确性：同样样本情况下的查全率、查准率指标
- 查询的效率：对于外部索引，主要体现为物理I/O次数，而不是时间

有关索引模型的更详细情况，参见[第四节空间索引模型](#四、空间索引模型)。

3.4 查询算法

（1）查询算法的实现方式

与数据存储模型绑定的，根据存储模型的不同，实现方式上主要是三种：

基于并行扫描的算法
- 如：在HDFS分布式文件系统中，由于其只能追加记录，不能修改和删除记录的特点，有些分布式空间数据引擎就把问题简单化处理，利用Map/Reduce的分布式并行特性提高检索效率，而在块内采用按照key顺序扫描的方法进行检索，或者设计各种Bloom Filter，实现对数据的过滤。理论上该方法只能提升并行带来的效率，且对集群节点的压力较大，属于比较早期的设计。
基于分区的算法
- 部分分布式空间数据引擎，对扫描方式做了优化，将重点放在如何对数据进行合理的分区问题上。例如：按照某个行键对数据进行分块，然后利用HASH等技术，索引到键值所在的数据块。该领域研究的重点方向之一是如何适应数据的分布特性，通过合理地规划分区解决数据倾斜问题。
基于索引的算法（重点讨论）
- 前两种方法都是在数据集上直接做空间查询，直接返回结果集；第三种是在索引上做查询，获得索引指向的分区，然后再对分区进行处理，获得最终结果；此外，基于索引数据本身，还能获得很多意外的好处，比如：数据的分区统计、数据的分布特性分析、数据的聚簇性分析等。

注：

在分布式存储系统中，需要了解几个基本的术语：

扇区（Sector）：存储设备物理上的最小I/O单位，例如：硬盘的一个扇区通常为512Byte

页（Page）：由操作系统定义的、逻辑上的最小I/0单位，如：Windows系统和Linux默认页大小为4KB（即8个连续的扇区），页的特点是：页内连续存储，页间随机存储。因此，页配置越大，同样大小的文件占用的页数就越小，物理I/O的次数就越小，读写速度就越快，页内碎片多，页间碎片少；反之，页配置越小，同样大小的文件占用的页数就越多，物理I/O的次数就越大，读写速度就会变慢，但页内碎片小，页间碎片多。

块（Block）：由分布式文件系统定义的逻辑上的最小I/O单位，如：HDFS中Block的大小默认为128MB（连续的），通常可以通过对分布式文件系统的参数设置调整该值。

文件（File）：分布式文件系统中，一个文件是由多个Block组成，每个Block可能存储在集群中的不同节点上，为保证可靠性，每个Block 可能在其他节点上有多个备份。

分区（Partition）：分区是业务逻辑术语，在空间数据库中通常和某个特定的空间划分相关联，即某个空间划分内的数据存储在一个分区中。在分布式数据库系统中，分区通常以一个或多个文件的形式存在。

（2）三类重要的查询算法

范围查询算法：
- 点查询：
- 范围查询：
邻近查询算法：
- NN、kNN等给定查询点，返回数据集中最邻近的若干记录。
空间连接查询算法：
- 一元连接查询：在数据集内部，依据相交、包含等空间拓扑关系查询关联的其他记录
- 二元连接查询：在两个数据集 $R、S$ 中，依据相交、包含等空间拓扑关系，输出空间关联的 $<r,s>$ 对
- 多元连接查询：在多个数据集 $R_1,R_2,..R_n$ 中，依据相交、包含等空间拓扑关系，输出 $<r_1,r_2,..r_n>$ 元组
- 最近邻连接查询：
- kNN连接查询：

有关查询算法的更详细情况，参见空间查询方法

3.5 查询语言

（暂略）

3.6 对空间关系计算、空间分析和可视化的支持

除了数据组织和检索能力外，如何利用系统已有的分布式特性，实现对空间大数据挖掘、时空分析和可视化也逐步成为分布式空间数据库的研究热点问题，部分能力也成为了分布式空间数据的内置能力，而分布式空间数据库的外延逐步扩大。典型如：

时空分析：
- 如：并行的缓冲区分析、叠加分析、数据聚合等
空间数据挖掘：
- 如：并行的空间K均值分类、空间异常数据检测、空间位置协同模式挖掘等
时空数据可视化：
- 如：并行的可视化数据处理、可视化数据生成（矢量瓦片、删格瓦片动态生成等）

四、空间索引模型

4.1 空间索引的基础知识

（1）三种不同物理介质的空间索引

一种是内存时空索引，主要用于对内存中的空间对象快速检索和访问，解决的核心问题是内存中的时间和空间复杂度问题
另外一种是外部时空索引，主要用于对外围存储设备（主要指硬盘）中的存储的空间对象进行快速检索和访问，其本质是如何有效地减少物理IO的次数（重点讨论）
另外需要指出的是，随着固态存储的广泛应用，目前有大量有关在固态存储设备上实现多维索引和存储的技术方法。

（2）常见的空间索引方法

空间索引技术是多维空间索引技术的一个子集，技术发展脉络也清晰表明，在地理信息技术领域出现的各种空间索引技术，大多是计算机科学领域多维空间索引技术的变种。目前，多维索引技术主要分为三种类型：

基于空间划分的索引模型
- 特点：在二维、三维或者四维时空中进行区间划分，而后为每一个区间建立存储和索引
- 此类索引的建立是依据在二维、三维或四维空间中的某种划分方式展开的，在索引结构上通常采用树状结构，非叶子节点指向其子划分节点，叶子节点指向存储位置。
- 典型如：R树、四叉树、Kd树、X树等。
- 优点：空间聚簇性好，理论上物理I/O效率能够较优
缺点：索引更新比较麻烦，对数据分布的变化适应性不足，对数据分布变化不大的历史数据非常有用。
基于降维的索引模型
- 特点：通过降维将二维、三维或四维时空中的点映射到一维空间后，然后在一维空间中进行排序和多叉划分，从而将多维问题降解为一维问题。
此类索引的建立，是采用一些巧妙的映射方法，将二维或三维空间映射到一维空间中，从而使空间数据能够利用计算机的线性存储特征和数值的排序特性
- 在数据结构上常采用B+树等
- 优点：大部分表形式的数据库系统都能直接使用，（如：MySQL、MangoDB等），便于依据一维键值动态调整分区存储的大小
- 缺点：由于在一维空间中无法严格满足聚簇性要求，一个在多维空间中的范围查询，会被分解为多个一维空间中的范围查询，在临近查询时也存在类似的问题。
- 常用的降维技术包括：空间填充曲线（Z序、Hilbert等）、Pyramid技术、iMinMax等。
基于多维Hash函数的索引模型
- 特点：通过某个Hash函数，将多维空间中某个包围盒中的所有点，映射到一个索引键值上。
- 此类索引需要设计比较好的多维Hash函数，而其中最简单的方式，就是等经纬度划分。
- 在每个索引键值下，有N多个可能的数据点构成的数据集，为提升检索效率，通常内部也需要做排序。
- 优点：计算简单
- 缺点：数据分布不均匀时，每个键值下的数据集大小不同，会造成数据检索效率不一致的问题。
- 常用的Hash函数：GeoHash（采用Z序作为降维函数）、GridFile、Flood等。

参考资料：

4.2 分布式空间索引的布局

（1）分布式空间数据引擎的特点

	与传统基于DBMS的空间数据引擎不同，分布式空间数据引擎组织管理的数据分布在多个节点上，以往集中式的索引技术方案在分布式空间数据存储体系中，难以直接使用。特别是在谷歌三大论文发表和Hadoop开源项目之后，分布式数据存储的技术体系也基本定型，大数据块、只能追加不能更新等新的存储特点，也对分布式空间数据引擎带来了新的挑战。

此外，由于海量数据的特点，使得索引数据本身也变得非常庞大，如何合理的组织和存储索引数据，也是分布式空间数据引擎要解决的核心问题。

（2）分布式空间数据引擎的索引布局

	分布式空间数据索引不仅涉及到节点内部的空间索引问题，还涉及到分布式节点之间的空间数据编排问题。因此，目前成熟的分布式空间数据引擎，通常采用**全局索引**和**本地索引**两级布局形式。

（1）全局索引

目的：确定如何在不同计算机之间，依据空间数据的分布特性，合理划分、调整和分配分区（Partition，通常每个分区存储为一个文件），使得访问者能够根据检索范围，快速捕获相应的分区集合（Partitions Set），进而为基于分区的分布式并行检索提供支撑。
部署：一般部署在master节点上，当空间数据集为静态数据集时，客户端可以将该全局索引缓存到本地，以加快检索效率。
动态性：全局索引的动态性是由数据集的动态性决定的。
- 对于静态数据集，批量构建分区和全局索引，通过bulk load等技术优化内存与存储之间的调度;
- 对于动态数据集，需要动态更新全局索引。
- 需要注意的是，动态索引在HDFS的Written Once and Never Modified特点下，维护起来是一个相当麻烦的事情，必须采用LSM等技术定期对磁盘中的索引文件进行合并和压缩。这也是目前开源的分布式空间数据引擎主要处理历史数据的原因，当数据动态性比较强时，为规避上述问题，大部分分布式空间数据引擎会直接采用HBase作为存储引擎（HBase内部实现了LSM），或者使用Spark、Storm、Ignite等分布式内存引擎。
带来的好处：
- 便于查询处理器将查询范围外的分区修剪掉，即在分区层面实现一次过滤（Filtering）；
- 空间相邻的分区可以存储在一起，便于一些分布式计算的实施，例如：Join操作。
问题：
- 存在不同地区的数据倾斜问题，如何在节点有限的分布式系统中，灵活、智能地处理不同地区的负载均衡问题，是一个目前的研究热点问题，见分布式空间索引的创建。

（2）本地索引

目的：在每个节点内部或分区内部组织空间对象
本质：对空间对象的集合进行某种形式的编排，使得在节点内部或分区内部检索速度更快
部署：通常本地索引数据会和分区数据一块儿，部署在各slave节点上

全局索引和本地索引都会用到R-tree、Quad-tree、KD-tree、Z-Curve等空间索引技术。

（3）关于分区的数量

现有的分布式空间数据库大致存在三种分区方式：

根据集群中slave节点的数量决定分区数量，每个节点对应一个分区;
根据分布式文件系统的Block决定分区数量，每个Block对应一个分区;
用户自定义分区，此情况下分区成为Block的集合，可以考虑不同分区不同Block数，或不同分区相同Block数等多种方式，优点是用户可以自己灵活定义和优化。

（4）关于聚集索引和非聚集索引

聚集索引和非聚集索引是数据库领域的专业术语，但对于如何构建索引非常重要。

聚集型索引
- 指数据记录在物理上严格按照索引顺序存储的一种索引形态，例如：关系型数据库中，通常依据主键值做聚集索引; Key-Value数据库通常依据Key值做聚集索引。
非聚集型索引
- 指数据记录在物理存储上和索引顺序无关的一种索引形态，例如：关系型数据库中，对某些字段建立的辅助索引（Secondary Index）大多是非聚集型索引，其存储还是依据主键聚集的。
注意：
- 填充曲线的应用建议采用聚集索引，因为只有这样才能发挥其聚簇性的技术优势，减少物理I/O数量。

4.3 分布式空间索引的构建

（1）均匀分区

不考虑数据的空间分布特征，直接按照统一的网格进行空间划分
不同网格的数据存储在不同节点上，节点内部建立本地索引
优势：简单，甚至不需要全局索引，对均匀分布的数据比较有优势
缺点：当存在数据倾斜时，负载不均衡

（2）非均匀分区

依据数据的空间分布特征，灵活做空间划分，空间划分的尺度不一定相同
通常分为三步：
- 第一步：空间分布的抽样（downsize）
  - 对空间数据集进行小比例随机抽样（如：1%），生成点对象抽样数据集（线和面会被抽象到点）
  - 用抽样数据集表征整体的空间分布特征，能够有效降低生成空间划分方案的复杂度
- 第二步：生成空间划分方案（space subdivision）
  - 任务：依据抽样数据集，策划空间划分方案
  - 方法：将整个空间依据抽样数据集划分为n个分区，平衡每个分区中的数据量。
  - 具体技术：R-树、 $R^+$ 数、四叉树、KD树、空间填充曲线（Z序或Hilbert曲线）
  - 注意：某些技术无法做到全空间覆盖、某些技术可能存在空间上的重叠，需要单独做优化处理
- 第三步：建立分区索引（partitioning）
  - 对整个数据集进行顺序扫描处理，根据第二步生成的分区方案，将数据记录分别填充到n个分区单元中去;
  - 由于抽样数据集是点集形式，因此此处可能会出现“线”或“多边形”跨分区的情况，通常的做法是将其在各分区中都存储一份，进而会出现重复存储，这最终可能会造成检索准确率下降的问题。

（3）自适应分区

前面两种索引主要用于静态索引的生成，自适应索引主要面向动态索引。
如前所述，在实现方式上，大多数分布式空间数据引擎都规避了该问题。
比较多采用的方式，是利用空间填充曲线，将多维空间映射到一维空间，然后以一维空间中的值作为分布式数据库（如：HBase、Accumulo等）的主键做聚集索引，分区的动态性和自适应性完全由分布式数据库自身LSM的split和merge来实现。
部分时空轨迹数据库根据自身数据特点（历史数据不会再变更），采用了时间离散化的方式实现索引的动态化，其基本思路是将时间切分成若干不相交的时间区间，每个时间区间内单独建空间索引，从而保证每个时间区间内的分区存储是最优化的。
注意：此处可以思考利用空间填充曲线，在一维空间中处理时空轨迹数据是否存在问题。

五、空间查询方法

5.1 空间运算是空间查询的基础

  在空间数据库中，空间查询条件的描述，通常是以空间拓扑关系的形式表达的，因此要了解空间查询，必须先了解基础的空间关系计算。

例如：

查找离学校最近5km的火锅店
- 实现过程：以北大为多边形对象做5km的缓冲区运算–>用缓冲区和火锅店数据集做交或包含运算
查找海淀区内的所有书店
- 实现过程：获取海淀区多边形–>用海淀区多边形与书店数据集做交或包含运算。

5.2 两类基础空间运算

用于支撑空间查询的基础空间运算，主要包括两类：

一是空间拓扑关系的元运算，
- 用于支撑基于空间拓扑关系的查询。例如：
  - “海淀区内林地”，基于海淀区多边形与林地多边形数据集的交运算
二是空间分析的元运算
- 用于支撑空间分析类型的查询。例如：
  - 计算距离：“距离学校最近的三家火锅店”，基于距离计算实现。
  - 计算缓冲区：“清河周边1km内的绿化带”，基于缓冲区计算实现。
  - 计算面积：“北京市面积小于5平方公里的公园”，基于面积计算实现。

5.3 空间拓扑关系的元运算

空间拓扑关系计算

大部分空间查询应当支持9交运算集合（OGC标准支持）中最常被使用、已命名的10种空间断言（Predicates)，断言返回值为真或假，用于辅助查询算法判断当前对象是否满足空间查询条件。
- 基础计算：
  - Equals(a,b) – 是否相等
  - Disjoint(a,b) – 是否相离
  - Touches(a,b) – 是否邻接
  - Contains(a,b) – 是否包含（边界不允许相交）
  - Covers(a,b) – 是否覆盖
- 派生计算（可由上述运算推导得出）：
  - Intersects(a,b) — 是否相交，Intersects(a,b)= not Disjoint(a,b)）
  - Within(a,b) — a是否在b内，Within(a,b) = Contains(b,a)）
  - CoveredBy(a,b) — a是否被b包含，CoveredBy(a,b)= Coveres(b,a)
- 拓扑关系
  - Crosses(a,b) — a是否穿过b（a与b的维度不同，或a和b同为线）
  - Overlaps(a,b) — a是否与b存在重叠（a与b维度相同）

关于9交运算

什么是9交运算模型

DE-9IM是一种拓扑模型，也是描述二维空间中几何对象空间关系的标准，具有旋转、平移、变换不变性。

该计算模型采用矩阵方式区分几何对象之间的不同空间关系类型，理论上能够通过两个空间对象的内部、边界和外部是否相交，表达两者之间512种可能的拓扑关系，不过传统上通常只使用其中类似“相交”、“邻接“、“包含”等10种。

点/线/面的内部、边界和外部定义 9交计算矩阵

什么是空间断言（Spatial Predicate）

判断两个空间对象是否属于某种特定的空间关系的布尔函数

5.4 空间分析的元运算

主要应当实现距离、维度、包络、长度、面积、缓冲区、凸包等运算

5.5 空间检索的两个阶段

基于索引的空间检索一般要经过过滤（Filtering）和精化（Refine）两个阶段：

过滤（Filtering）
- 也被称为粗检索，其作用是过滤掉肯定不在结果集中的数据，对于分布式空间数据引擎而言，就是将肯定不包含查询结果的分区先过滤掉，剩下可能包含查询结果的分区候选集。因此，对于分布式空间数据引擎来说，过滤通常是基于全局索引的。
精化（Refine）
- 精化也被称为精检索，其作用是在候选的分区中，通过顺序扫描或本地索引，筛选出符合空间查询条件的数据记录，即最终结果集。

5.6 分布式空间查询的实现

过滤和精化两个步骤，在分布式空间查询系统中，处于MapReduce的不同阶段：

过滤：通常发生在Map之前，即过滤阶段无法实现并行。
精化：过滤产生的候选分区集合，可按照分区实施Map，各Map获得的中间结果，最终通过Reduce合并成最终成果文件。

六、空间查询语言

待定

七、空间大数据的应用支持

分布式空间数据库的主要目的是实现海量空间数据的组织管理和高效查询，但由于其基础支撑环境是分布式计算环境，同时很多空间数据处理、分析和可视化功能依赖于底层数据存储和索引支持（如：计算和存储的本地化要求），所以越来越多的功能也被置于分布式空间数据系统中，由此形成近年逐步发展成熟的云GIS系统。

针对越来越多空间信息处理业务转移到了服务端（如：服务端实现的Overlay、Union、Intersects等），OGC2015年正式发布了WPS（Web Processing Server）接口标准，用于控制和协调客户端和服务器端之间的服务发布、服务请求、服务协同等。

  此外，空间大数据的范畴越来越广（典型如：移动轨迹数据、微博数据、物联网传感器数据等），衍生出很多传统地理信息系统很少涉及到的时空大数据分析需求，由此带来时空大数据分析和挖掘的新兴浪潮。其中，大量时空数据的分析和挖掘工作也依赖于空间数据引擎的分布式计算环境和本地化存储优势。因此，可以毫不夸张的说，掌握了分布式空间数据库的核心技术能力，就掌握了敲开时空大数据分析和挖掘大门的钥匙。