基于Hadoop的矢量空间数据库技术

孟 辉，朱美正，张锋叶

(华北计算技术研究所地理信息与图形图像技术研发中心，北京 100083)

0 引言

随着GIS应用的发展和普及，地理数据的空间和时间分辨率不断提高，其数据量将面对迅速增长的压力。大型GIS系统对海量数据的管理能力和多用户高效并发访问的要求也越来越高。传统GIS对数据的组织形式大多为文件系统与数据库结合或者完全基于关系型数据库的方式，这2种构架在解决日益增长的空间数据问题的思路一般为Scale-up模式的扩展，即增加垂直方向上硬件的处理能力。这种模式扩展成本很高，并且硬件更新的速度远远跟不上数据膨胀的速度，在应对海量数据管理上显得力不从心。云计算的出现为解决海量空间数据的管理提供了新的思路。得益于云计算集群多机协同作业的优势，利用云计算系统可以轻松地将廉价的计算资源组织起来形成存储量大、运算性能高的计算集群，并且云计算系统采用Scale-out的扩展模式，当现有集群性能、存储出现不足时，可以简单地通过添加新的机器来实现集群的扩展。这种纵向扩展省去了数据迁移的代价，扩展成本低，硬件资源廉价，较传统Scale-up模式有明显优势。本文研究存储的矢量数据是空间数据中结构复杂、查询显示困难的数据类型。矢量数据具有半结构化特点，存储设计比较困难，而且用户经常基于矢量数据做大量的查询计算操作，对矢量数据库的设计直接影响到用户请求服务的质量和服务体验。矢量数据库是地理信息系统的基础与关键，其设计的好坏直接影响整个系统的性能与质量，因此有必要对其进行深入的研究与设计。大型的GIS系统，地理信息采集入库后改动一般较少，大部分的用户请求为读操作，为提高存储模型设计的针对性，本文将矢量数据库面向的场景设定为多用户高并发访问。HDFS分布式文件系统是云计算的一种开源方案，在处理海量数据方面有着广泛的应用。本文采用基于HDFS分布式文件系统，由HBase分布式数据库来管理存储海量的矢量数据，充分利用分布式集群海量的存储空间和高效的并行运算，解决海量矢量数据的存储和多用户高效并发访问的问题。

1 Hadoop及HBase简介

Hadoop是一个分布式系统基础架构，由Apache基金会开发。它可以对用户屏蔽底层分布式细节，支持分布式程序，充分利用集群的高运算速度和海量数据存储。Hadoop实现了一个分布式文件系统HDFS(Hadoop Distributed File System)和 MapReduce并行计算框架。2部分分属Hadoop逻辑上的2层，如图1所示。HDFS是Hadoop框架的底层实现部分，具有高容错性(fault-tolerent)的特点，并且设计用来部署在低廉的(low-cost)硬件上。HDFS放宽了POSIX的要求，这样可以以流的形式访问文件系统中的数据，能提供高吞吐量的数据访问。MapReduce是在HDFS的基础上实现的并行计算框架，用户可以使用它轻松进行并行编程。MapReduce计算由2个阶段组成:Map映射阶段和Reduce规约阶段。首先Map函数把一组(Key，Value)输入，经过Map阶段的处理生成一组中间结果(Key，Value)，然后Reduce函数汇总所有Map的中间结果进行合并化简。分布式计算中移动数据的代价总是高于移动计算的代价。因此MapReduce将计算作业细化成小的分片分配到不同机器上进行计算，既保证了数据的可靠性又方便MapReduce在数据宿主机器上进行计算。

图1 Hadoop的结构图

由于HDFS设计之初的目的是存储大文件，一个典型HDFS文件大小一般都在G字节至T字节。其可以存储的文件容量可以达到海量，但是HDFS存储的文件数量并不能达到海量。当HDFS中存储的文件数超过一定量时，系统的性能会严重降低，足见其对海量小文件支持并不好。因此要将单文件数据量较小的矢量数据存储到HDFS中，还需要借助HBase分布式数据库管理系统来实现。

HBase是Google公司Bigtable的开源实现，是一个功能强大的分布式数据库系统。与传统关系型数据库不同的是，它的数据组织是按列来存储的，因此可以不用遵守第一范式的约束存储半结构、非结构的数据。HBase可以处理非常庞大的表，可以用普通计算机处理超过10亿行数据及由数百列数据组成的表。HBase的这一特性正好可以用来存储管理文件较小但是文件数量海量的矢量数据。HBase的底层物理存储可以基于任何文件系统，但是为了支持高性能的数据存取和海量数据的存储，提高数据的可靠性和系统的健壮性，可以使用HDFS作为文件系统来存储物理数据文件。将HBase和Hadoop结合起来使用可以解决海量矢量数据块的存储问题。

2 矢量空间数据库整体架构及存储策略

2.1 整体架构

虽然目前业界各大地理信息系统都已经具备了比较成熟的空间数据库技术，但是绝大多数空间数据库都是针对有限数据和应用规模的应用场景，采用的大都是基于集中存储和关系型数据库管理系统的技术路线。集中式的存储方案使数据量很难扩展，无法管理海量的空间数据。采用关系型数据库来管理地理信息，空间数据以数据记录的形式组织，受限于索引机制，当数据记录数量增大到一定程度，关系数据库的访问性能会严重降低，并且其支持的并发用户数有限，无法满足大型地理系统面向大量用户高效并发访问的需求。

沿用传统的技术路线，无法从根本解决海量空间数据存储以及高效访问问题，很难取得质的突破。因此本文摒弃传统关系数据库+集中存储的技术体制，彻底摆脱传统空间数据库本质上的缺陷，研究基于分布式存储的空间数据库技术。

本文设计的整体结构如图2所示，数据存储层采用分布式文件系统和关系数据库组成，以分布式文件系统存储用于显示和空间查询的矢量数据，这些数据压缩成数据块存储到分布式文件系统中;将用于属性查询的空间属性信息以及图层描述信息、元数据信息等数据量小、查询更新频繁、结构性强的数据存储在关系数据库中。分布式半结构数据管理系统HBase在HDFS高性能存储能力的基础上提供半结构化空间数据的存储和管理功能。空间数据访问中间件用于维护存储在分布式文件系统和关系型数据库中数据的一致性。空间数据访问引擎用于对上层应用提供数据接入、查询、存储等功能。这种存储方案可以充分利用分布式存储集群提供的海量存储空间、平滑的存储扩展能力，轻松应对海量空间数据的存储。计算集群的高I/O带宽和高运算性能可以满足大用户量高并发的访问需求。同时关系数据库强大的SQL查询功能可以用来完成属性查询功能。

图2 整体结构图

2.2 存储策略

通过分析，传统的空间数据库方案以地理目标为单位进行组织，与大型地理信息系统管理的海量数据量相比存储粒度过细，查询读取数据时需要逐条加载目标信息，导致数据库的读取性能很低。本文采用HBase分布式海量半结构化数据管理技术，将矢量数据进行瓦片化分块处理，每个数据块交由HBase进行管理，分布存储到HDFS中。数据瓦片内则基于矢量目标记录进行存储组织，并以块为单位进行压缩。这样提高了数据存储的粒度，极大地提高了加载的速度，明显地改进了地图显示和空间查询的性能。

矢量数据存储策略如图3所示，考虑某一层次的矢量数据，由于可视范围有限，往往只需要对较小区域内的矢量数据进行可视化、编辑、更新，如何快速地查找指定区域的矢量数据是影响系统性能的关键因素。为此，本文采用数据分块的方法来实现矢量数据的快速定位和灵活调度。根据分块规则在全球范围内按一定规则进行瓦片分块，对每个瓦片进行唯一标识，建立快速索引。根据全球划分瓦片后计算当前矢量所覆盖的范围，将矢量图层划分为一系列子块，子块中包含图层的地理目标，将矢量图层划分块后，在逻辑上空间数据是无缝组织的。对数据块所包含的地理目标建立地理目标级索引，实现矢量数据的多级索引。将划分所得的数据块压缩后存储到HBase分布式数据库中进行管理。同时考虑矢量数据中的空间属性数据多为结构化数据，通常需要频繁更新，而且需要按不同字段进行检索查询，NoSQL目前的单键值存储限制了属性查询的灵活性，并且属性数据的数据量通常较小，因此本文选择将属性数据冗余存储到关系型数据库中，充分利用关系型数据库灵活的检索特性弥补HBase在检索方面的不足。这样存储在HBase中的矢量数据专门用来进行高速的加载显示以及空间查询，存储在关系型数据库中的属性数据用来支持属性查询。

图3 存储策略

3 矢量空间数据库设计

空间数据库作为整个GIS系统最底层的存储媒介，承载组织矢量数据模型并统一存储和集中管理的功能，为整个GIS系统提供数据存储支持。数据库的读取性能和面对高并发访问的抗压能力，直接决定了系统对用户访问请求的响应速度。良好的数据库的设计是决定一个空间数据库性能的基础和关键。

3.1 相关数据结构设计

矢量图层在全球范围内按照一定规则划分瓦片，瓦片是一次矢量数据存储的基本单位。本文将一块瓦片数据组织成一种叫做桶的基本单位。一个桶对应一个地图瓦片，每个桶属于且只属于一个矢量图层，一个矢量图层可以包含多个桶。桶是矢量入库的基本单位也是构建空间索引的基本单位。

桶是根据待存储的地图瓦片构建而成。首先桶以目标集合的形式获得瓦片中的地理目标，通过遍历目标集合内的所有目标，计算每个目标的最小外界矩形(MBR)，以MBR的几何中心表示目标的位置;同时统计出所有地理目标的ID范围，以及桶所包含的目标集合所覆盖的地理范围;然后根据桶的地理范围按照一定规则划分成块，对每一块内的地理目标建立空间索引。将空间索引以及各个块所包含的地理目标ID作为桶的组成部分进行保存。将每一个地理目标块进行压缩序列化后存储到数据库中。桶的形成过程如图4所示。

图4 桶形成过程

3.2 数据库的物理模型

本文设计将矢量数据冗余存储到分布式NoSQL数据库HBase和关系数据库Oracle中。为提高矢量数据的存取效率，简化数据库的存储模型，本文设计直接将矢量数据分块序列化后以二进制流的形式存储到HBase中。同时将矢量数据中数据量较小的元数据信息以及需要大量SQL语句查询的属性信息冗余存储到关系数据库中，弥补HBase查询操作的不足。

3.2.1 关系数据库表的设计

系统为了支持系统的大用户量和高并发访问，将矢量数据打包成块存储到分布式空间数据库中。同时考虑属性数据要大量用到SQL查询操作，适合存储到关系数据库中。矢量数据的描述和管理类信息，数据量小，数据条目少，查询和修改操作频繁，亦适合存储在关系型数据库(Oracle)中。同时也可利用关系数据库的事务机制维护关键数据的一致性，因此将矢量数据的属性信息部分冗余存储到关系型数据库中。

关系数据库中存储的数据均为数据量较小的数据。图层描述表存储的是矢量图层的架子，该表维护一个图层最基本的描述信息，包括图层ID、图层类型、图层名称、空间参考、图层范围、拓扑信息等信息。图层中的目标组织需要有唯一的ID，在为图层创建目标之前需要为目标分配ID，图层目标ID表用来管理每个图层地理目标ID的统一分配。当需要批量分配目标ID时，从表中读取图层对应的最大ID值，再将分配后的最大ID值存回表中。元数据表包括基本元数据和扩展元数据2部分，图层和图幅的元数据统一交由元数据表来维护。以上各表均只有一张，由各个图层共同使用。

此外在创建图层时，还会分别为每个图层相应地创建图幅信息表、图幅版本信息表、属性信息表，表名由图层ID进行区分，与具体图层进行关联。属性信息表用来存储图层地理目标的属性信息。当新建图层时相应地创建属性信息表。该部分数据与分布式空间数据库中存储的属性信息冗余存储，方便对矢量数据进行属性查询。为支持图层的分幅管理以及多版本管理，还会为每个图层建立一张图幅信息表和图幅版本表。图幅信息表用来存储图层对应的图幅的ID、编号、范围和保存时间。图幅版本表用来存储每个图幅不同版本的信息。

3.2.2 Hbase 表的设计

HDFS分布式文件系统对海量小文件的支持效果不好，因此海量的矢量数据分块不适合直接由分布式文件系统来存储，而是交由分布式数据库HBase来管理，每个矢量数据块作为HBase表中的一个Cell存储。如前文所述，HBase为按列存储的数据库，表中相邻记录的同列族数据在物理存储上是相邻组织的。同时HBase物理模型简单，没有复杂的关系和事务机制，因此可以满足对海量数据高性能读写的需求。

HBase中存储的数据主要包括图层信息——属性字段和桶信息、矢量数据块2部分，分别由图层信息表和矢量数据表来存储。

图层信息表VEC_LAYER_INFO用来存储矢量图层的属性字段信息和桶信息。如表1所示，该表由一个列族组成:Info。Info列族又分为2列，分别存储。该表的存储为简单的键值对的形式，每一行存储一个序列化的桶信息。为方便将同一图层的所有桶信息区分出来，每行数据的RowKey前缀为图层ID，RowKey由图层ID和桶ID拼接组成。当打开图层时，一次性按前缀将图层对应的桶信息加载到内存中，用来进行图层内的空间查询。

表1 图层信息表

矢量数据表VEC_DATA用来存储所有图层的分块数据。如表2所示，该表由一个列族组成。Data列族用来存储分块数据。

表2 图层数据表

Data列族存储的是桶切分成块后对应范围内各个图层的矢量数据。每一个图层对应该范围内的矢量目标均被组织成块，序列化后以二进制流的形式存储到矢量数据表中。每个图层的块都作为Data列族中的一列进行存储，每一行的列数可以不同。这样的设计可以保证每块区域内各个图层的数据可以连续地存储在一起，方便地图显示时连续地一次性读取出来，可以提高数据读取的效率。

3.2.3 物理存储优化

由于HBase表中的数据在组织时是按RowKey的字典序来组织的，字典序上相邻的RowKey对应的行会被连续地存储到HDFS中，HBase的这一存储特点为底层数据存储提供了优化的空间。利用HBase存储的这个特点，可以通过设计RowKey的结构来保证将显示中经常会被一同读取的数据连续地存储到一起，以提高数据读取的速度。

在实际应用中，同一区域的各个图层的数据会被一同读取出来，因此这些数据应该优先存储到一起。在地图漫游操作中，当前区域内的数据块周围的数据块会在后续的拖动中被读取，因此这些空间上相邻的数据块也应该尽量存储到一起。所以在读取HBase中的一块数据时，会连续地将该块周围的数据一同调入到缓存中，这样在请求周围的块数据时可以直接从内存缓存中获取，减少HBase访问文件系统的次数，提高系统的读取速度。在表设计中，将同一区域的不同图层的块数据作为多个列存储在Data列族中，这样可以利用HBase的存储机制，绝对保证同一区域内的多个图层数据连续存储在一起。在RowKey的设计中，综合考虑到图幅内块的连续性和各个图幅之间的连续性。图幅内的块号按照希尔伯特曲线进行编码，按照该编码可以自然地将图幅内临近的区域块连续地存储。在考虑相邻图幅连续存储的设计时，本文研究标准分幅规则的图幅号命名规则，通过图幅号获得图幅之间的相邻关系，类似地将每相邻的16个图幅按希尔伯特曲线进行编码，按照编码来顺序存储相邻的图幅数据。最终RowKey的结构如图5所示。

图5 RowKey的结构

同时为避免HBase读写的单点问题的出现，将每16块相邻的图幅邻接存储到一个Region中。不同的16块图幅随机存储到不同的Region，这样既可以避免入库时，多台客户端机器同时将数据入到一台机器中，造成单台机器的数据写入成为瓶颈，也可以避免在数据读取时，无法利用集群多机运算的优势，并行地读取数据。考虑到上述需求，本文在RowKey的开头添加了一个根据图幅区域随机生成的前缀，通过此前缀将不同范围内的数据分散存储到不同的Region-Server中去。实验表明，RowKey的设计好坏大大影响数据库访问的性能。

4 实验结果及分析

4.1 实验环境及数据

用作实验的Hadoop集群由5台机器组成，系统为Ubuntu Linux。5台机器上部署HDFS，在其中3台上部署HBase。关系数据库采用Oracle，部署在5台Windows计算机，机器配置与Hadoop集群机器相同。测试客户端机器由3台组成，配置均为2 GB内存，2.83 GHz四核CPU，系统同样为Ubuntu Linux。集群各台机器的配置及具体程序的部署如图6所示。

图6 集群环境

实验数据采用矢量数据中数据量最大的1:50000比例尺的数据，选取其中的1000幅作为入库实验数据，数据总量为28 GB，图层包含陆地地貌及土质、居民地及附属设施等11个图层。

4.2 矢量入库

矢量入库采用3台客户端同时进行，每台客户端运行3个线程并行入库。矢量数据的数据主要集中在“陆地地貌及土质”和“居民地及附属设施”2个图层。本实验将“陆地地貌及土质”图层(26 GB，7003541个目标)和“居民地及附属设施”(300 MB，673195个目标)存入 HDFS中所用时间分别为:1094.52 min、123.36 min。存入 Oracle 中所用的时间分别为:5316.17 min、613.92 min。

4.3 并发空间查询

以数据量最大的“陆地地貌及土质”图层为待查图层，图层内目标数量为7003541。通过在文件中预先定义好1000个覆盖不同空间范围的矩形，矩形覆盖的范围大小均匀，以矩形为空间查询条件查询加载被包含和相交地理目标。使用3台客户端以多线程的方式模拟多用户分别对基于2种存储方案实现的空间数据库进行空间查询。以每台计算机模拟10个并发用户，循环执行查询条件，持续10 min。每过10 min每台计算机增加10个并发用户。记录2种情况下各并发用户数空间查询的平均耗时，并以如折线图7的形式将实验结果呈现出来。

图7 空间查询实验结果

从图7可以看出，随着并发用户数的递增，基于2种方案的空间数据库应对空间查询的响应时间都有所增加，传统方案实现空间数据库空间查询耗时始终较高。基于Oracle的空间数据库，在并发访问数较少的情况下请求响应时间比较稳定，当并发访问数超过一定数量时响应时间会急剧增长;基于Hadoop实现的空间数据库在并发访问数增长时可以保持比较稳定的缓慢增长。由此可见基于Hadoop的空间数据库可以轻松应对高并发的空间查询请求，而基于Oracle的空间数据库则无法满足高并发访问的需求。

4.4 并发漫游操作

以相同的方式测试空间数据库在高并发漫游操作场景下的表现。待测试的空间数据库实现方案分别为基于传统关系型数据库集中存储、分布式存储未经存储优化以及基于分布式存储经过存储优化3种。测试过程为:以“陆地地貌及土质”图层上某一显示区域范围为起点，之后以1/2图幅范围为单位逐次加载区域四周临近2个图幅范围内的地图数据，以模拟用户漫游操作。为避免起点区域选取的偶然性对实验结果的影响，实验开始前随机在图层内选取10个起始范围，当完成以一个区域起始的漫游之后，再漫游下一个区域，直到将10个区域都漫游完记录下10次操作完成的总耗时，并计算出10次漫游操作的平均耗时。测试依然在并发用户数逐级递增的情况下进行。最终的实验结果如图8所示。

图8 漫游实验结果

由图8可以看出，在地图漫游操作的实验中，当并发用户数较少时基于Oracle集中存储的方案与基于Hadoop分布式存储的方案性能相当，略高于后者。但是，当并发用户数超过一定数值时，关系数据库的性能急剧下降，访问响应时间大幅提高。分布式集群的性能受并发用户数的影响不大，只是缓慢地上升。经过存储优化之后，地图漫游时对临近数据的加载速度会比未经存储优化情况下快约30%。

5 结束语

本文针对大型GIS系统中海量矢量数据组织困难，面对大量用户高并发访问时效率底下的问题，提出一种全新的基于Hadoop分布式存储的方案。通过实验验证了该方案的有效性，在解决海量矢量数据高效并发访问方面效果明显。

［1］陆嘉恒.Hadoop实战［M］.北京:机械工业出版社，2011:260-261.

［2］邬伦，刘瑜，张晶，等.地理信息系统——原理、方法和应用［M］.北京:科学出版社，2005.

［3］萨师煊，王珊.数据库系统概述［M］.北京:高等教育出版社，1990.

［4］胡鹏，吴艳兰，杨传勇，等.大型GIS与数字地球的空间数学基础研究［J］.武汉大学学报:信息科学版，2001，26(4):296-302.

［5］刘鹏.云计算［M］.北京:电子工业出版社，2010:189-230.

［6］龚健雅.地理信息系统基础［M］.北京:科学出版社，2001:29-35.

［7］常燕卿.大型GIS空间数据组织方法初探［J］.遥感信息，2000(2):28-31.

［8］毋河海.地图数据库系统［M］.北京:测绘出版社，1991:236-251.

［9］胡志勇，何建邦.分布式地理信息服务类型及解决方案［C］//中国GIS协会年会论文集.1999.

［10］屈红刚，潘懋，王勇，等.设计模式在GIS软件开发中的应用研究［J］.计算机工程与应用，2003，39(25):1-4.

［11］张洪岩，王钦敏，周成虎，等.“数字地球”与地理信息科学［J］.地球信息科学，2001(4):1-4.

［12］The Apache Software Foundation.Hadoop［DB/OL］.http://hadoop.apache.org/，2011-10-31.

［13］Chang F，Dean J，Ghemawat S，et al.Bigtable:A distributed storage system for structured data［C］//Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation.2006:205-218.

［14］Ghemawat S，Gobioff H，Leung S T.The Google file system［C］//Proceedings of the 19th ACM Symposium on Operation Systems Principles.2003:29-43.