基于HBase的空间矢量数据存储模型设计与优化
高分对地观测、遥感、导航定位和移动互联网等技术的不断发展，获取地理空间信息的手段不断丰富，地理空间数据呈现出数据来源多样化、数据模型差异化、数据存储分散化、空间关系复杂化、数量海量化的特点[1]。各种移动智能终端的普及和互联网应用的多元化发...
- 作者：谢鹏，杨春成，熊顺，何列松，周校东来源：测绘学报|2021年01月11日
高分对地观测、遥感、导航定位和移动互联网等技术的不断发展，获取地理空间信息的手段不断丰富，地理空间数据呈现出数据来源多样化、数据模型差异化、数据存储分散化、空间关系复杂化、数量海量化的特点[1]。各种移动智能终端的普及和互联网应用的多元化发展，特别是Web2.0技术的兴起，地图的使用被赋予了一种全新的方式[2]，互联网已成为地图编制与应用的平台[3]，网络地图[4]所服务的用户规模显著扩大。因此，如何高效地对海量地理空间数据进行组织管理以满足用户高并发访问请求已成为大数据时代互联网环境下亟待解决的技术问题。特别是对于空间矢量数据，由于其具有空间特征、非结构化特征以及空间关系特征[5]，给上述问题的解决增加了更大的复杂性。
1 空间矢量数据管理现状1.1 基于关系型数据库的空间矢量数据管理
空间数据的海量特征和空间数据的多维特性使得空间数据的存储与管理不同于其他数据[6]。在其组织管理方式不断演进的过程中，对象关系型数据库通过在关系型数据库中增加用户自定义抽象数据类型(如Oracle Spatial)或者基于关系型数据库设计专用访问引擎(如ArcSDE)的方法，实现了属性数据与图形数据的统一存储，已成为当前主流的空间数据库管理系统。文献[7]在Oracle Spatial对象关系型数据库基础上，提出了空间数据存储模型，探讨了矢量和栅格数据在对象-关系模型中存储的关键技术。文献[8]分析了采用ArcSDE+SQLServer模式开展空间数据库设计的基本理论和实现方法，构建了大别山低丘缓坡地空间数据库, 为开展大别山低丘缓坡地土地评价和综合利用模式等方面的研究提供了地理空间数据支撑。文献[9]基于Oracle10g，利用ArcSDE建立了三峡水库温室气体空间数据库，实现了三峡库区范围内的水系、植被、数字高程模型等基础地理信息的关系型数据库存储。
但是，对象关系型数据库是集成了抽象数据类型(ADT)和其他面向对象设计原则的关系数据库[10]，弹性伸缩能力较弱，当单机能力无法承载日益增长的计算和存储需求时，只能采用垂直扩容[11]的方法应对。如果支撑垂直扩容的计算机和网络硬件能力达到上限，对象关系型数据库就无法解决海量空间数据的存储与并发访问的问题了。
1.2 基于HBase的空间矢量数据管理
HBase具有水平扩展能力，能够有效利用云计算所提供的海量数据存储管理、分布式并行计算能力[12]，为解决上述问题提供了有效技术途径。近年来，在基于HBase的空间矢量数据管理方面已经开展了许多研究。文献[13]设计了基于HBase的矢量空间数据的存储图层表，表中的列族依次是空间数据列族、属性列族和拓扑关系列族。空间数据列族只有一个列，没有区分数据几何类型，属性列族由属性项作为列组成，并根据不同比例尺、不同图层建立不同的表。文献[14]设计了包含过滤列族、几何列族和属性列族的空间数据HBase逻辑存储模式。其中，几何列族由点、线、面3个列组成。文献[15]根据WKB中定义的6类空间数据几何要素类型设计了由不同要素类型为列族的HBase地理空间矢量数据存储表模式，并将几何数据的Geohash码作为行键存储。文献[16]设计了由坐标列族、属性列族和拓扑列族组成的矢量空间数据逻辑存储模式。
上述研究成果虽然都实现了基于HBase的空间矢量数据组织管理，但还存在以下3点不足：第一，没有根据“横向分幅、纵向分层”的空间矢量数据组织方式设计存储模式，无法开展基于图层、图幅的查询检索；第二，都只是利用了HBase面向列族存储的特性, 没有考虑如何利用HBase的其他特性；第三，由于HBase在物理上将不同列族的数据分开独立存储，如果简单地将空间矢量数据按照数据类型或几何要素类型组织到不同的列族进行管理，那么在没有辅助索引支持的情况下，开展根据属性信息查找空间要素或拓扑信息查询时会出现跨存储区域访问数据的情况，影响查询效率。
为解决对象关系型数据库管理空间矢量数据存在的问题以及现有的基于HBase的空间矢量数据存储模型的不足，本文采用关系模式向HBase模式转换规则[17]，基于关系型空间数据库存储模式，提出了针对空间矢量数据的关系型存储模式向HBase存储模式转换方法。设计了空间矢量数据HBase存储模型，并利用HBase特性提出了模型优化策略。
2 关系型空间数据库逻辑模型设计
为了确保转换后HBase中空间矢量数据存储模型的正确性与合理性，需要理解和掌握关系型空间数据库逻辑模型。以下简要介绍空间矢量数据在关系型数据库中的存储模式。
关系型数据库中实体信息及实体间的联系均用二维表来表示[18]。由于空间数据组织大多按不同比例尺、横向分幅和纵向分层的方式进行[19]，因此，在关系型空间数据库中需要设计用于存储图幅、图层以及空间对象的二维表，建立表之间的关联关系。图 1所示为关系型空间数据库中表的逻辑结构及相互联系。
|
|
| 图 1 关系型空间数据库逻辑表结构Fig. 1 Logical table structure of relational spatial database |
|
图选项 |
图 1中，区域是具有一定范围的地理空间，范围可以是全球、一个国家或一个感兴趣的地区[20]，区域表记录了描述该区域的基本信息。图幅是指按经纬线分幅[21]的基本比例尺地形图，图幅表记录了某一比例尺地形图的元数据信息。具有相同属性的图形存放于同一个图形数据层中[22]，一个图形数据层应该包含属性结构固定的点、线、面要素。图层表存储了图形数据层的元数据信息。要素类存储具有相同几何类型的空间要素[23]，根据空间要素几何类型分别创建点要素类表、线要素类表和面要素类表。空间对象包含有3个方面的信息：图形信息、拓扑关系和属性描述信息[24]。具有数据类型BLOB(binary large object)的空间数据以特定字段存储为一个二进制数据的集合[23]，空间对象之间的拓扑关系通过结点元素表、弧段元素表、面域元素表以及岛元素表建立与维持。
3 HBase空间数据库逻辑模型设计3.1 HBase模型结构
HBase继承自BigTable模型[11]。图 2所示为HBase模型结构关系图。在逻辑世界中，组成HBase表的基本单元是列[25]，多个列组成一个列族，多个列族组成一行。在物理世界中，HBase通过HRegionserver(RS)组织和管理数据，一张HBase表中的数据被分散存储到多个RS中。RS包含多个HRegion和一个预写入日志(WAL)。HRegion包含多个HStore，HStore由一个BlockCache、一个MemStore以及多个HFile组成。横向上，HBase表被分割成多个被称为HRegion的片[26]；纵向上，一个列族中的所有数据在HDFS中对应一个独立的存储，该存储是由多个HFile组成的HStore。
|
|
| 图 2 HBase逻辑模型与物理模型之间的关系Fig. 2 Relationship of logical model and physical model in HBase |
|
图选项 |
3.2 关系型空间数据库到HBase空间数据库的模式转换方法
3.2.1 转换规则
关系数据库通过建立主外键约束和关系表的方法构建实体之间的联系。联系可以是1:1(一对一的)，1:N(一对多的)或M:N(多对多的)[27]。有非常多的方法来转换一对一、一对多、多对多的关系，以适应HBase底层架构[11]。文献[17]根据HBase特性，提出了由关系型数据库存储模式向非关系型数据库存储模式转换的3条规则：①将关系数据库中的表映射为HBase中的表，原关系表中的主键映射为HBase表中的行键，其他列组织到列族中；②对于表与表之间的关系，通过在关系两端的HBase表中分别建立存储主键值列族的方法消除主外键约束；③合并主从表，减少使用外键。
3.2.2 转换实现
(1) 消除主外键约束。NoSQL数据库一个共同的特点就是去掉关系型数据库的关系特性[28]。按照规则1完成转换后，需要利用规则2消除图 1中表之间的1:N关系。具体方法是利用HBase反范式化[29]特性，在基数约束为1的表中增加一个列族存储基数约束为N的表中的主键值。本文中，区域表增加了一个图幅列族存储组成该区域的所有图幅的ID值。图幅表增加了一个图层列族存储组成该图幅的所有图层ID值。图层表则增加了3个列族，分别存储组成该图层的点要素、线要素和面要素的ID值。图 3所示为消除了1:N关系的区域表在HBase中的逻辑结构。
|
|
| 图 3 区域表HBase逻辑结构Fig. 3 Logical structure of region table in HBase |
|
图选项 |
(2) 合并主从表。按照规则2完成转换后，形式上看已经消除了表与表之间的主外键约束关系，但查询时还是需要执行关联查询。比如查询一个区域中某一幅地图的元数据信息，需要首先查询区域表获取图幅的ID，再到图幅表中根据ID提取相关元数据信息。为避免关联查询，需要按照规则3合并主从表，也就是利用HBase实体嵌套[29]功能，将从表中具有相同外键的实体作为子实体存储在与从表存在主外键约束关系的主表实体中。以区域表和图幅表为例，区域表为主表，图幅表为从表，合并后的“区域_图幅表”逻辑结构如图 4所示。
|
|
| 图 4 区域_图幅表HBase逻辑结构Fig. 4 Logical structure of region_tile table in HBase |
|
图选项 |
图 4中，组成区域的每一个图幅都可以作为该区域的子实体与其存储在同一张表中。其中，区域为主实体，地形图为子实体，所有子实体组成一个独立的列族。理想情况下，再经过两次嵌套，就可以将所有的表合并到一张表中。但是，HBase的实体嵌套技术只适用于一个层次的深度[29]，即组成图幅的图层不能再作为子实体嵌套到图幅子实体中。因此需要分别建立“图幅_图层表”(图 5)和“图层_要素表”(图 6)。
|
|
| 图 5 HBase中图幅_图层表逻辑结构Fig. 5 Logical structure of tile_layer table in HBase |
|
图选项 |
|
|
| 图 6 HBase中图层_要素表逻辑结构Fig. 6 Logical structure of layer_feature table in HBase |
|
图选项 |
4 HBase空间矢量数据存储模型优化
上一节中设计的存储模型实现了空间矢量数据在HBase中存储，但还存在以下两方面问题：
(1) 行键设计不合理。每一张表都是简单地将对象ID值作为行键，没有考虑HBase行键的作用。
(2) 表中的子实体都是经过组合打包后的字节对象。访问子实体中的数据需要先解析数据，增添了系统负担，影响查询效率。
第1个问题可以采用主键分段的方式[30]设计组合行键解决。组合行键不仅可以控制数据存储的方式和存储的位置，还可以使用行键的部分内容进行范围检索[11]。
第2个问题利用HBase无模式特性，将子实体中重要的或者需要经常访问的属性值作为列标识符，减少数据包解析次数，提升查询效率。
4.1 “区域_图幅表”优化策略
对“区域_图幅表”进行优化时，首先设计了“比例尺+区域名称”的组合行键。这样设计的优势在于：第一，将比例尺信息放在行键首位，可以利用行键的索引功能提高基于比例尺的属性查询效率；第二，由于在HBase中行键以字典序排列，行键又是HBase表划分HRegion的依据。因此，将比例尺放在行键首位可以实现相同比例尺下不同区域的数据尽可能地存储在同一个HRegion中，提高依据比例尺查询区域的效率。其次，利用HBase的无模式特性将tile列族中的列标识符由图幅ID替换成图幅号。这样在进行基于图幅号的查询时，可以直接从列标识符获取数值，避免了查询数据单元和解析字节对象。优化后的“区域_图幅表”逻辑结构如图 7所示。
|
|
| 图 7 优化后的区域_图幅表逻辑结构Fig. 7 Optimized logical structure of region_tile table |
|
图选项 |
4.2 “图幅_图层表”优化策略
在“图幅_图层表”中将行键由图幅ID替换成图幅号。对于组成图幅的图层，将Layer列族中各列的列标识符由图层ID替换为图层名，提高查询图层信息的效率。优化后的“图幅_区域表”逻辑结构如图 8所示。
|
|
| 图 8 优化后的图幅_图层表逻辑结构Fig. 8 Optimized logical structure of tile_layer table |
|
图选项 |
4.3 “图层_要素表”优化策略
为了避免要素数据解析操作，减少查找HRegion的数量，“图层_要素表”进行了以下优化：首先将点要素、线要素和面要素的原始数据组织到Vector一个列族中；其次设计了由要素几何类型、图层名称、图幅号以及要素ID值构成的组合行键；最后在vector列族中设计了LFID列，用于记录要素在本图层内的ID值。优化后的“图层_要素表”逻辑结构如图 9所示。
|
|
| 图 9 优化后的“图层_要素表”逻辑结构Fig. 9 Optimized logical structure of layer_featuretable |
|
图选项 |
由于HBase行键按照字典序排列，行键又是HBase划分HRegion的依据。因此，将要素几何类型信息放在行键首位可以使得具有相同几何特征的要素尽可能的存储到同一个HRegion中。组合行键中元素的选择及其位置可以根据数据访问模式灵活调整。如果基于图层的查询较多，则可以将图层名称放在行键首位，实现在一个HRegion中保存同一图层要素数据。采用一个列族管理空间矢量数据，可以将HRegion中所有空间数据存储在一个HStore，避免了多列族设计导致的数据跨文件存储。LFID列中存储的要素在本图层内的ID值可以方便、快速地建立本图层内要素拓扑关系。
5 试验与分析
鉴于文献[13]与文献[15]设计的模型为目前常用的空间矢量数据HBase存储模型。不失一般性，本文基于上述两种模型开展对比查询试验。为确保试验公平，执行查询时都不使用辅助索引。特别是对于文献[15]中的模型，在执行空间查询时，将其行键由空间数据的GeoHash值替换为要素ID值。
5.1 试验环境
将Hadoop2.7.3和HBase1.1.2部署在一个由4台虚拟机组成的集群上。4台虚拟机包括1个主节点，3个从节点，运行在Dell 7910 Tower工作站上。工作站CPU为Intel Xeon E5-2620 v4(32个虚拟核)，64 G内存。虚拟机CPU为Intel Xeon E5-2620 v4(4个虚拟核)，12 G内存，操作系统为CentOS Linux release 7.2.1511(Core)。
试验数据采用1:100万、1:25万两种比例尺的分幅shapfile格式数据。其中，1:100万数据量约为512 MB，共686 406条记录，1:25万数据量约为6.25 GB，共7 359 287条记录。
5.2 试验方法
分别开展组合查询、属性查询、空间查询和KNN查询。组合查询为“分别提取1:100万比例尺和1:25万比例尺下所有图层的点要素”；属性查询为“查找名称为‘黄河’的线要素”；空间查询为“提取一个给定的矩形区域范围内的所有点要素”；KNN查询为“查找与某个点距离最近的k个点要素”。
5.3 结果分析
表 1所示为对每一种查询进行了多次操作后统计的平均查询时间，图 10为查询结果比对图。其中，存储模型1为文献[13]中的模型，存储模型2为文献[15]中的模型，存储模型3是本文设计的模型。
|
|
| 图 10 查询结果比对Fig. 10 Comparison of query results |
|
图选项 |
表 1 查询平均响应时间Tab. 1 A average response time for queryms
| 模型 | 组合查询(1:100万) | 组合查询(1:25万) | 属性查询 | 空间查询 | KNN查询 |
| 存储模型1 | 55 702 | 370 296 | 74 372 | 366 623 | 372 742 |
| 存储模型2 | 148 943 | 181 954 | 78 253 | 188 682 | 173 953 |
| 存储模型3 | 54 883 | 153 246 | 60 019 | 154 804 | 168 987 |
表选项
如表 1和图 10所示，利用本文设计的存储模型开展的1:100万组合查询效率较存储模型1和存储模型2分别提高了1.5%和63.2%；1:25万组合查询效率较存储模型1和存储模型2分别提高了58.6%和15.7%；属性查询效率较存储模型1和存储模型2分别提高了19.3%和23.3%；空间查询效率较存储模型1和存储模型2分别提高了57.8%和18%；KNN查询效率较存储模型1和存储模型2分别提高了54.5%和2.9%。总体来说，针对常见的空间数据库访问模式，本文设计的存储模型查询效率明显优于其他两种模型，原因在于：
(1) 按照空间矢量数据的组织方式存储数据。存储模型1将数据分图层存储在不同表中，致使在执行上述查询时，均需要先扫描多张图层表。本文设计的存储模型由于在“区域_图幅表”和“图层_要素表”中存储了图幅和图层的元信息，不仅有效避免了多表扫描，而且还支持开展基于图幅、图层以及比例尺的查询。
(2) 充分利用HBase行键索引特性。本文设计的存储模型在执行组合查询时利用了HBase组合行键索引与行键字典序排列特性，执行空间查询和KNN查询时利用了HBase行键前缀过滤功能。对于组合行键中元素的构成及其排列位置，也是根据空间矢量数据访问模式而定，因此查询效率优于其他两个模型。
(3) 有效减少列族数量。在执行包含过滤列族操作的查询时，本文设计的存储模型中“图层_要素表”只需要过滤两个列族就可获得查询结果，而存储模型1和存储模型2需要分别过滤3个和6个列族。由于HBase将每个列族数据存放在单独的文件中，过滤列族的数量与访问磁盘文件的次数相对应。因此，“图层_要素表”中2个列族的设计策略在提升整体查询效率方面发挥了重要作用。
此外，在更新复杂度方面，由于没有辅助索引，更新操作主要包括建立表连接、更新列族数据、关闭表连接3个步骤。因此，更新复杂度与模型包含的表数量和表中的列族数量成正比。存储模型1根据不同比例尺、不用图层建立不同的表[13]，其表数量和列族数量随着更新数据的增多而增大，更新复杂度最高。本文设计的存储模型共有3张表，每张表有两个列族，表数量和列族数量固定且少于存储模型1，更新复杂度较存储模型1低。存储模型2仅有一张表，共6个列族，表数量和列族数量固定且少于本文设计的存储模型，更新复杂度最低。虽然更新复杂度高于存储模型2，但是从应用角度看，本文设计的存储模型顾及了空间矢量数据组织方式和使用方式，因此更具实用性。
6 结论
本文提出的存储模型是依据关系型数据库向HBase数据库模式转换规则逐步设计实现，保证了模型设计的合理性与正确性。通过试验证明了本文设计的存储模型在没有辅助索引的情况下可以有效提高空间矢量数据的查询效率，为研究基于HBase的空间矢量数据存储管理奠定了基础。后续将围绕如何分布式并行更新数据以及如何构建高效辅助索引等方面开展研究工作。
参考文献
| [1] |
吴政, 李成名, 武鹏达, 等. Oracle数据库矢栅数据一体化存储与管理[J]. 测绘学报, 2017, 46(5): 639-648. |
| [2] |
陈超, 王亮, 闫浩文, 等. 一种基于NoSQL的地图瓦片数据存储技术[J]. 测绘科学, 2013, 38(1): 142-143, 159. |
| [3] |
廖克. 中国地图学发展的回顾与展望[J]. 测绘学报, 2017, 46(10): 1517-1525. |
| [4] |
王家耀, 成毅. 论地图学的属性和地图的价值[J]. 测绘学报, 2015, 44(3): 237-241. |
| [5] |
龚健雅. 空间数据库管理系统的概念与发展趋势[J]. 测绘科学, 2001, 26(3): 4-9. |
| [6] |
喻占武, 郑胜, 李忠民, 等. 基于对象存储的海量空间数据存储与管理[J]. 武汉大学学报(信息科学版), 2008, 33(5): 528-532. |
| [7] |
毛静.基于Oracle Spatial的GIS数据存储管理系统的研究[D].西安: 长安大学, 2012. |
| [8] |
马元龙.基于Arc SDE和SQL Server空间数据库的设计与优化方法研究[D].合肥: 安徽农业大学, 2016. |
| [9] |
李剑峰.三峡水库温室气体空间数据库管理系统设计与开发研究[D].武汉: 华中科技大学, 2016. |
| [10] |
SHEKHAR S, CHAWLA S. Spatial databases:a tour[M]. New Jersey: Prentice Hall, Inc, 2003. |
| [11] |
GEORGE L. HBase:the definitive guide[M]. Sebastopol: O'Reilly Media, Inc, 2011. |
| [12] |
CATTELL R. Scalable SQL and NoSQL data stores[J]. ACM SIGMOD Record, 2011, 39(4): 12-27. DOI:10.1145/1978915.1978919 |
| [13] |
范建永, 龙明, 熊伟. 基于HBase的矢量空间数据分布式存储研究[J]. 地理与地理信息科学, 2012, 28(5): 39-42. |
| [14] |
丁琛.基于HBase的空间数据分布式存储和并行查询算法研究[D].南京: 南京师范大学, 2014. |
| [15] |
GAO Fan, YUE Peng, WUZhaoyan, et al. Geospatial data storage based on HBase and MapReduce[C]//Proceedings of 2017 6th International Conference on Agro-Geoinformatics. Fairfax, VA: IEEE, 2017: 1-4. |
| [16] |
ZHENG Kun, FU Yanli. Research on vector spatial data storage schema based on Hadoop platform[J]. International Journal of Database Theory and Application, 2013, 6(5): 85-94. DOI:10.14257/ijdta.2013.6.5.08 |
| [17] |
LI Chongxin. Transforming relational database into HBase: a case study[C]//Proceedings of 2010 IEEE International Conference on Software Engineering and Service Sciences. Beijing, China: IEEE, 2010: 683-687. |
| [18] |
张巍, 龚健雅. 地理信息系统中复杂地物的OO模型[J]. 测绘学报, 1995, 24(4): 293-300. |
| [19] |
涂振发.云计算环境下海量空间数据高效存储关键技术研究[D].武汉: 武汉大学, 2012. |
| [20] |
王家耀. 空间信息系统原理[M]. 北京: 科学出版社, 2001. |
| [21] |
王家耀, 孙群, 王光霞, 等. 地图学原理与方法[M]. 2版. 北京: 科学出版社, 2014. |
| [22] |
刘仁义, 刘南, 苏国中. 图形数据与关系数据库的结合及其应用[J]. 测绘学报, 2000, 29(4): 329-333. |
| [23] |
CHANG K T. Introduction to geographic information systems[M]. 8th ed. New York: McGraw-Hill Education, 2016. |
| [24] |
龚健雅. GIS中面向对象时空数据模型[J]. 测绘学报, 1997, 26(4): 289-298. |
| [25] |
GAO Fan, YUE Peng, WU Zhaoyan, et al. Geospatial data storage based on HBase and Map Reduce[C]//Proceedings of 2017 6th International Conference on Agro-Geoinformatics. Fairfax, VA, USA: IEEE, 2017: 1-4. |
| [26] |
HUANG Shidong, CAI Lizhi, LIU Zhenyu, et al. Non-structure data storage technology: a discussion[C]//Proceedings of 2012 IEEE/ACIS 11th International Conference on Computer and Information Science. Shanghai, China: IEEE, 2012: 482-487. |
| [27] |
毋河海. 地图数据库系统[M]. 北京: 测绘出版社, 1991. |
| [28] |
马延辉, 孟鑫, 李立松. HBase企业应用开发实战[M]. 北京: 机械工业出版社, 2014. |
| [29] |
DIMIDUK N, KHURANA A. HBase in action[M]. New York, USA: Manning Publications, 2012. |
| [30] |
李青云, 余文. 关系型数据库到HBase的转换设计[J]. 信息网络安全, 2015, 15(1): 51-55. |
