新技术的发展给空间数据存储与管理又提出了新的挑战。物联网、移动互联网和云计算技术及应用的蓬勃发展，使得空间数据在数据量和应用模式上发生了转变；此外，传感器技术的发展，使采集数据的空间分辨率和时间分辨率显著提高，导致所获取的数据规模成指数级快速上升，面对动辄以TB(trillionbyte)，甚至PB(petabyte)计的数据，也给空间数据存储和处理带来巨大的压力^[1-3]。

传统的基于关系型数据库的空间数据存储与管理已经无法满足大数据存储和处理的实际应用要求，随着互联网领域云技术、非关系型数据库技术的迅速发展，各种分布式GIS技术的研究成为研究热点。本文主要着眼于空间大数据的存储与管理，首先分析了传统集中存储模式在大数据存储方面的局限性；然后，针对互联网领域大数据的成功解决方案，研究当前主流NoSQL数据库的特点，分析其在处理空间数据时的优势与不足；最后，针对这些需求和存在的问题，本文提出空间大数据分布式存储与处理策略，并在原型系统中进行试验验证。

1 空间数据存储技术现状

基于成熟的关系型数据库设计空间数据引擎，集中存储和管理空间数据是当前应用的主流模式。

1.1   空间数据集中存储模式及其局限性

从空间数据引擎和关系数据库与应用程序结合的紧密程度来看，可以将空间数据引擎的体系结构分为内置模式、三层结构模式和两层结构模式^{[4, 5]}，这些集中存储模式很好地解决了海量空间数据存储和管理的问题。

目前，各种地理空间信息获取手段多样、数据规模巨大、更新频率快、数据应用现势性强。传统的空间数据集中，单一的存储方式不能满足大数据高并发甚至高时效的应用要求，空间数据从海量特征转变为大数据特征对存储技术的要求主要表现如下。

1) 存储对象的变化。关系型数据库不擅长处理大量位置相关的视频、音频、图片等数据。

2) 存储能力的扩展。在容量上，传统关系型数据库难以维护动辄千万级别的二维表，且存储能力的横向扩展也非常困难。在性能上，由于需要维护数据的完整性、一致性，数据存储的性能受到很大影响。

3) 并发访问能力。 关系型数据库区别传统文件的最大优势在于其对数据的多用户并发访问能力，但在云服务、互联网等应用领域，用户的并发量要求是关系型数据库无法满足的。

1.2   基于NoSQL的空间数据单一存储模式优势与不足

在互联网领域，基于非关系型数据库的NoSQL数据库技术已经得到成功应用。从数据存储的角度来说，NoSQL数据库非常适合空间大数据的存储，但互联网领域的应用模式与GIS领域存在一定差异，由此产生的局限性主要包括如下方面。

1) 数据操作方式的局限性。在空间数据库中对数据的修改是常用操作，但NoSQL数据库一般不建议对数据进行修改，不慎重的修改操作甚至会因为引起相关存储数据的大量迁移而导致性能急剧下降。

2) 数据查询方式的局限性。基于空间数据的各种专题图展示能力以数据库的查询能力为重要基础，需要按图层的属性信息提取数据，因此基于数据库的按字段查询、排序、统计等功能是重要基础。NoSQL数据库提供的查询能力非常有限，MongoDB也不能满足GIS常用查询的需要。

3) 单一空间索引算法或技术的局限。类似关系型数据库，空间数据的索引技术是空间数据存储技术的重要研究内容^[6-9]，但有一定局限性^[10-14]。在大数据应用环境下，应该考虑把空间索引技术从算法层面提升到方法策略层面，才能解决空间数据的高效检索问题。

本文综合NoSQL数据库和关系型数据库各自的优势，提出一种混合的空间大数据分布式存储策略，既满足大数据存储的需要，又能满足传统GIS应用的需求。

2 空间大数据分布式存储策略

本文提出空间大数据分布式存储策略是针对传统的矢量、栅格及各种移动设备产生的实时/近实时的流式大数据存储与管理，设计基于内存数据库、关系型数据库、NoSQL数据库的三层物理存储体系及数据调度系统。

2.1   空间大数据存储与管理系统

面向空间大数据的分布式存储与管理系统具备存储和管理矢量、栅格和流式大数据的能力，整个系统能够对外提供多种能力，既包括实时/近实时的流式数据的存储和管理，又能对分布式数据库中的数据进行快速提取从而支持传统应用，如专题图展示、空间关联分析等。基于该系统的应用框架结构见图 1。

图  1  空间大数据分布式存储管理系统应用框架图

Figure  1.  Application Diagram of the System of Spatial Big Data Storage and Management

下载: 全尺寸图片 幻灯片

空间数据存储子系统。综合内存数据库、传统空间数据库和NoSQL数据库，三者结合对外提供流式数据处理能力、传统空间数据库查询和分析能力及分布式系统大数据处理能力。

1) 内存数据库，高效的数据操作层。I/O处理速度比传统数据库要快很多，一般都在10倍以上。

2) 传统空间数据库，提供数据集中存储的能力，与此同时使得整个空间大数据分布式存储管理系统对外具备传统GIS的能力，保证整个系统对外提供的能力不退化。

3) 分布式存储系统，基于NoSQL数据库的分布式存储系统作为大数据仓库，为空间大数据提供低成本、高可扩展、高可用性、高通量I/O的持久化存储和数据提取能力。

2.2   关键技术

1) 空间数据在NoSQL数据库中的存储实现。本文主要研究MongoDB的数据库存储特点。MongoDB是一种基于文档的NoSQL数据库，与空间数据库中的各类对象的映射关系见表 1。

表  1  各数据库中空间数据存储组织方式

Table  1.  Object Types Mapping in Database

	SQLite:Mem	PostgreSQL	MongoDB
空间位置信息存储格式	Text	bin	BSON
数据源对应的数据库对象	database	database	database
图层对应的数据库对象	table	table	collection
空间对象对应的数据库对象	row	row	document

下载: 导出CSV 

| 显示表格

2) NoSQL数据库中空间大数据的组织结构设计。本文主要讨论MongogDB的Replica Set集群和Sharding集群。在实际应用中，应用场景会极大地影响数据存储策略。本文的实验场景中，通过多次优化验证，采用的是根据地理范围进行外部分片，再搭建Sharding集群，可称之为滞后Sharding集群。

3) NoSQL数据库中空间大数据的快速提取技术。除空间数据的组织结构会影响数据的提取效率，空间索引策略也是提高数据访问效率的关键点。本文设计的空间索引策略充分与集群方案结合，是基于元数据的多级图幅索引。

4) 数据合理调度问题。考虑空间大数据高效分析和处理的需要，其存储需要设计内外存协同的存储模式。将高频率访问热点数据直接内存于数据库中，实现高通量I/O；其余海量的低频率“冷”数据以归档形式存储在关系型数据库或者NoSQL数据库中。

5) 空间数据访问接口设计。对关系型数据提供的API(application programming interface)基于开源的OGDC(open geospatial database connectivity)^[15]，类似于空间数据库领域的ODBC，提供最基础的空间数据库访问接口，包含了多种关系型数据库的驱动程序，如Oracle、DB2、MySQL、DM、Kingbase等；对分布式存储系统，本文基于OGDC接口进行完善，为数据的并行存取提供通道。

3 空间大数据分布式存储实践

本文分别选取SQLite、PostgreSQL和MongoDB作为内存数据库、关系型数据库和NoSQL数据库的存储实践实现原型系统，重点解决空间大数据在MongoDB中的底层存储和上层逻辑组织结构等关键技术，实现大数据仓库中的空间数据快速存储与提取，对本文的存储策略进行验证。

实验选取空间大数据入库和空间叠加统计分析两个场景对本文提出的存储策略进行对比和验证。

实验数据采用全国大范围土地覆盖测试数据，共10 101幅shape文件，数据量5.4TB，约11亿个空间面对象。

实验主要硬件为三台32核、内存128GB的服务器挂载磁盘存储；操作系统为64位RedHat。

3.1   原型系统存储体系结构

空间大数据存储原型系统分三层结构，包括数据库层、中间件层和数据访问接口层，见图 2。

图  2  分布式存储系统体系结构图

Figure  2.  Distributed Storage Architecture of Spatial Big Data

下载: 全尺寸图片 幻灯片

1) 数据库层。SQLite是一个跨平台的开源小型桌面数据库，提供全内存模式；PostgreSQL是一个传统类型的开源关系型数据库；MongoDB是目前为止与关系型数据库最接近的NoSQL数据库，实验搭建MongoDB的Sharding集群。

2) 中间件层。属于核心部分，包括传统的空间数据库引擎、分布式空间数据库引擎和数据调度子模块。传统的空间数据库引擎主要负责空间数据在关系型数据库中的存储和管理，由于SQLite是关系型数据库，SQLite:Mem和PostgreSQL的存储处理方式基本类似；分布式空间数据库引擎负责空间大数据在MongoDB中的组织。各数据库中数据的组织方式见表 1。

关系型数据库中，图层与表对应。矢量图层的每个对象对应表中的一行，这一行数据就包括了位置信息和属性信息，对于MongoDB来说，每个对象包装成一个带有空间信息和属性信息的BSON对象。

数据调度主要是基于数据操作接口，在不同的数据库之间进行数据的输入和提取。

3) 数据访问接口层。主要为上层应用提供操作存储于不同数据库的空间数据的接口。

3.2   空间大数据入库实验

实验目标：将5.4TB shape数据全部导入MongoDB，并建立空间索引。

实验目的：对本文空间大数据分布式存储方案、空间索引策略和内存数据库的应用进行验证。

1) 数据分布式存储方案

数据入库主要是对数据集合 (记为collection)写操作，由于MongoDB采用的是数据库级锁，过多并发对同一数据库(记为database)中同一集合或不同集合的插入操作都会导致锁争用而产生性能瓶颈；通过Sharding集群的实例节点写入数据，由于节点间通信及维护开销，单个shape导入的性能比单节点写入性能慢2~3倍。为提高入库效率，本实验放弃对单个collection的Sharding集群存储，将研究区域的数据进行划分，存储到两个存储节点的6个database中,每个database包含多个collection，每个collection包含200万～300万个对象(见图 3)。图 3中，A1、A2；B1、B2；C1、C2等为研究区域的数据分片，DB_A1、DB_A2、DB_B1、DB_B2、DB_C1、DB_C2等为对应的存储节点数据库，Shard Node1、Shard Node2为存储节点。集群搭建采用滞后方式，即两个存储节点先作为单独实例启动，数据入库完成后再搭建Sharding集群。实际环境中也建议在数据入库完成后再建立各Sharding集群结点的备份结点，搭建数据副本-分片集群(Replica Set-Sharding)。

图  3  基于MongoDB的分布式空间数据存储方案

Figure  3.  Spatial Database Storage in MongDB Sharding

下载: 全尺寸图片 幻灯片

本实验环境下，对单个数据库级别的database开启10进程并发持续写入能够获得较好的效果。

2) 基于元数据的多级空间索引策略

通过元数据表记录不同存储粒度的地理范围：存储结点级别(Shard Node)、数据库级别(database)和图层级别(layer)。图层的数据粒度为300万～400万对象，用图幅索引进行划分，即每个对应一张collection。在存储结构上，layer对应的database.collection的Tile_ID(图幅标识)列记录空间对象所在的图幅号，索引表的结构如图 4(b)所示。其中各变量满足以下条件：

图  4  图幅索引的数据表

Figure  4.  Index Collection of the Tile Index

下载: 全尺寸图片 幻灯片

① $\sum\limits_{i = 0}^k {{n_i} = N} $,N为对象总个数；

② t_i∈T,T=∪Obj_ID_Tile,Obj_ID_Tile为索引表对象Obj_ID

3) 内存数据库的应用

入库过程中对图层建立图幅索引需要多次对collection进行ID查询，统计地理范围极值等操作，而MongoDB并不直接提供对列求极值的操作算子，需要遍历数据。本实验利用内存数据库，实现了单个shape(要素)入库处理时间不随目标层数据量增加而增长的目标。步骤如下。

(1) 单个要素(shape)导入内存数据库得到MemLayer；

(2) 对MemLayer切分图幅T₁,T₂,…T_n；

(3) 将n图幅数据追加至目标图层。对第T_i图幅数据，获取数据范围、对象数，获取目标数据集的新图幅标识(Tile_ID)，写入目标图层。

数据写入完毕，实际上图层的图幅索引也建立完毕。本文统计3个图层约60个shape，每个shape约500MB，11万个对象，单个shape处理的平均时间见表 3。实验中整个入库过程shape处理速度基本平稳。

表  2  单个要素平均处理时间

Table  2.  Average Time Consumption for One Shape File

	耗时/s	备注
导入内存数据库	20.6	-
内存图层切分图幅	2.3	12列×3行
追加到目标图层	46.7	-
总计	69.6	-

下载: 导出CSV 

| 显示表格

4) 实验结果

基于以上方案，对5.4TB的矢量数据采用2个存储节点、60进程并发入库并建立空间索引的总时间耗费为3 h 42 min，有效地保障了海量数据高并发环境下的入库效率。

3.3   叠加分析统计实验

实验目标：从MongDB中提取安徽省相关数据，并对安徽省各县市土地覆盖类型进行分类统计。参与叠加分析的安徽省行政区划图层为L_AnHui，包含105个面对象。

实验目的：对本文的空间索引策略的有效性进行验证；对本文的内存数据库、关系型数据库和分布式数据库的协同应用策略进行验证。

实验步骤分为数据提取到关系型数据库PostgreSQL和基于关系型数据库的叠加分析统计。

1) 数据提取过程

充分利用基于元数据的空间索引，提取图幅粒度的相关数据输入PostgreSQL数据库。

(1) 根据L_AnHui得到矩形查询范围rcBounds；

(2) 查询元数据表找到与查询范围(rcBounds)相关的layer：L₁,L₂,…,L_n。数据入库后，存储结点、数据库和图层级别的元数据总计354条，因此对元数据的范围查询时间在ms级别；

(3) 对图层L_i查询rcBounds相关的图幅T_i1 ,T_i2…T_im；

(4) 取图层L_i的T_i1 ,T_i2,…,T_im图幅的数据，采用图幅追加的方式写入PostgreSQL。

各步骤时间统计见表 3。与安徽省相关的图层共计8个，这8个图层中再次过滤得到3 861个图幅。最终分8个图层启用8个进程写入PostgreSQL，总对象数12 574 739。

2)叠加分析统计

在PostgreSQL中对提取的土地覆盖数据与L_AnHui进行叠加裁剪，并按土地覆盖类型字段CType对各县市进行分类统计求和。假设L_AnHui中的对象为A₁,A₂,…,A_n,土地覆盖数据各layer为L₁,…,L_m，对于A_i和L_j计算步骤如下。

表  3  数据提取时间记录

Table  3.  Data Extraction Bases on Spatial Index

	耗时/s	备注
元数据查询	0.6	-
图层内图幅查询	2.3	8个图层
图幅数据追加	978	3 861个图幅
总计	981	12 574 739对象

下载: 导出CSV 

| 显示表格

(1) 通过L_j的图幅索引，提取被A_i完全包含的图幅TID_in和相交的图幅TID_intersect。通过图幅TID_in取对象面积以及CType值，得到结果R_in1；

(2) 对于TID_intersect提取各图幅中空间对象的四至，与A_i叠加：被A_i包含的取出对象面积及CType值，写入结果R_in2；相交的对象写入内存数据库图层Mem layer等待计算；

(3) 在内存数据库中对Mem layer和A_i进行叠加裁剪(线段打散→求交→拓扑构面)，并计算裁剪后的对象面积，得到结果R_clip；

(4) R_in1、R_in2和R_clip结果合并。

该过程通过逐级过滤，尽量过滤掉不需要进行叠加裁剪的对象，并将裁剪过程迁移至内存数据库，减少计算过程中对数据库的频繁访问，提高计算效率。

表 4对比了是否采用内存数据库的测试结果，实验中实际参与叠加计算的对象总数为182 947个。

3) 实验结果

本实验中，基于元数据的空间索引能够快速过滤定位到相关图幅，从MongoDB中提取安徽省相关数据并输入PostgreSQL的耗时主要用在数据的I/O；叠加分析和统计过程中采用内存数据源减少了与数据库的交互，有效提高了空间分析的效率。

表  4  各图层叠加统计耗时

Table  4.  Time Consumption on Overlay Analysis

图层	图幅数	对象数	耗时A/s	耗时B/s(内存数据库)
L1	73	253 454	192	126
L2	385	1 264 189	643	397
L3	656	2 159 563	1072	658
L4	656	2 111 632	1123	744
L5	658	2 176 057	1070	723
L6	762	2 475 838	1119	691
L7	581	1 879 148	649	419
L8	90	254 858	215	141

下载: 导出CSV 

| 显示表格

4 结 语

面向大数据的空间数据分布式存储策略结合了传统的基于关系型数据库的GIS基本能力和NoSQL数据库提供的大数据分布式存储能力，既满足了大数据存储的需要，又保证了整个系统对外提供的GIS功能不退化。本文基于SQLite、PostgreSQL和MongoDB数据库，开发了原型系统，并选取了两个实验场景对该存储策略的有效性进行了验证。空间大数据的存储和管理是一个相对复杂的问题，根据应用的实际情况，大数据的空间索引策略、数据分解方法、数据调度策略等都值得进一步深入研究。