高性能瓦片数据存储与发布应用技术研究

王 伟，姚晓婧，蒋许峰，陈 静，刘 烁

（1.天津职业技术师范大学信息技术工程学院，天津 300222；2.中国科学院大学空天信息研究院，北京 110101）

地图瓦片缓存技术是广泛应用于WEBGIS 系统建设的核心技术之一。通过将地图数据在服务器上预先渲染生成尺寸相同的图片（瓦片），避免了浏览器每一次地图请求都在后端动态生成图片。瓦片缓存技术显著提高了地图显示效率，极大地增强了图形浏览的用户体验。依据瓦片分割方案，瓦片数据在数量上按缩放等级呈金字塔结构，且具有单个文件小、文件数量多、整体数据量大等特点。使用简单的磁盘存储方法会造成严重磁盘碎片化、IO 读写性能下降、数据易损坏以及难于管理维护等问题。同时，存储在磁盘上的不同瓦片数据，需要使用ArcgisServer 或其他地理信息服务器软件，以地图服务的形式对每一数据集对外发布应用。随着不同版本、批次、类别瓦片数据集的增多，必然要在服务器上创建更多的服务进程，进而急剧消耗服务器CPU 及内存资源，最终造成服务器瘫痪。针对时空多序列海量瓦片缓存数据的存储、管理与发布应用问题，亟需一种经济实用、可横向扩展、高性能存储并能够无缝对接前端发布应用的解决方案。

近年来，基于HBase 数据库具有开源、横向可扩展、高性能等特性，国内外很多学者提出使用HBase作为海量瓦片数据的存储载体，用来解决瓦片数据在存储管理上的诸多问题。宋关福等[1-3]指出，大数据平台是未来GIS 空间数据存储与应用的发展方向，并给出了运用大数据平台存储遥感数据的模型和方法。针对一般磁盘存储方案无法对海量地图瓦片进行有效存储和管理的问题，喻凯等[4-6]提出在Hadoop、Hbase的数据存储环境中保存遥感影像切片数据，通过引入Hilbert 曲线，将二维空间数据映射成一维连续索引，进而有效提高数据存储与检索效率的技术方案。针对瓦片金字塔结构以及生成方法等问题，郭宁等[7]作了深入研究，并提出一种多层级自适应的瓦片生成方法，优化了可视化引擎，实现了大规模栅格数据瓦片金字塔的快速构建。方金云等[8]根据空间查询特性和Spark 分布式内存计算模型，设计了HBase 分布式存储、分布式空间索引、Spark 分布式内存计算框架的空间区域查询算法和Spark Streaming 的空间查询算法，提供实时在线空间查询服务。王乃生等[9]为解决天地图建设和更新过程中遇到的电子地图瓦片数据的版本管理、共享访问、存储扩容限制等方面的问题，基于NoSQL 数据库MongoDB 的存储结构设计并实现了一种时态地图瓦片数据存储模型。李绍俊等[10]提出基于内存数据库和No-SQL 数据库的空间大数据分布式存储与综合处理策略，用以解决大数据存储与管理方面面临的复杂问题。上述研究均从瓦片数据特性的角度出发，深入研究了瓦片数据生成、数据存储及运用Hilber 曲线提升查询效率等技术，普适性地实现瓦片数据在大数据平台上的存储与查询效率的提高。但就WebGIS 系统中应用的瓦片数据而言，用户在前端对某一缩放级别地图进行浏览时，前端框架具有能够为每一块瓦片产生唯一编号的特性。通过将这一编号直接映射到键值数据库上的行键上，并发调用瓦片，就可最大化地发挥NoSQL 数据库在已知键值查询效率最高的特性，从而简化数据结构设计，提高数据获取效率，实现应用与数据的完美统一。

本文从WebGIS 在前端调用瓦片数据的原理出发，针对海量瓦片数据存储及一体化显示功能所面临的文件碎片化、不易管理、发布应用依赖商用平台软件等诸多问题，运用NoSql 数据库键值关系（keyvaluepair）结构，开展了瓦片数据在Hadoop、HBase 大数据平台上的存储模型设计。充分利用键值数据库行键索引的高效性以及RESTful 接口的通用性，实现了瓦片数据在Openlayers 开源前端可视化地图引擎中的高效加载。

1 瓦片数据生成

基于NoSql 数据库瓦片存储模型研发的关键，在于对瓦片数据的特点有比较清晰的认识。目前，不论是主流商用GIS 平台，还是开源GIS 软件产品，所使用的缓存瓦片数据虽然存储格式稍有不同，但一般均采用四叉树算法进行分层切割，各层切割后的瓦片数量呈金字塔型。

1.1 TMS瓦片生成算法

瓦片地图服务（tile map service，TMS）是广泛应用于WebGIS 开发的技术规范，由开源地理空间基金会（open source geospatial foundation，OGC）开发，在瓦片缓存技术中具有极高的影响力[11-12]。本文以WGS84 标准TMS 瓦片为例，详细讲述TMS 瓦片生成及在磁盘的存储格式。TMS 瓦片切割算法可由如下伪代码表述

在上述算法描述中，以投影后的平面地图左下角为原点，经度方向为横轴，纬度方向为纵轴建立平面直角坐标系，通过三重循环来实现瓦片数据的切割。按照TMS 切割算法生成的标准瓦片数据，根目录下的第一级目录为缩放级别zoom；第二级目录是沿经度方向切割的列数，从原点开始由小到大编号；第三级是切割瓦片的文件名称，从原点开始沿纬度方向由小到大按序编号。因此，切割的瓦片可由缩放级别、横向列号和纵向行号来组合位移确定，TMS 瓦片金字塔模型如图1 所示。其他主流GIS 平台，如ArcGIS、Supermap等，虽然在瓦片存储时文件夹及文件的命名规则稍有不同，但存储结构与TMS 基本相同，数据结构具有一致性。

图1 TMS 瓦片金字塔模型

1.2 瓦片编号与空间坐标关系

当前，一般的做法是将切割出来的瓦片直接存储在磁盘上，并以树状结构来组织。某一地区某一版本的空间数据在一定的瓦片切割算法下生成瓦片数据，这些数据被保存在一个目录下（树根）。在该目录下，同一缩放级别的瓦片被放在以缩放级别命名的文件夹里；在任一缩放级别下面，将不同列的瓦片分别存放在以列号命名的文件夹内；列文件夹内直接保存该列内以行号命名的瓦片文件。瓦片文件的磁盘存储结构如图2 所示。

图2 WGS84 标准TMS 瓦片磁盘存储格式

2 瓦片数据NoSql 存储模型

NoSQL 数据库的出现，为海量瓦片数据存储模型的设计与实现，提供了一种全新的思路。NoSQL 不仅指SQL，其为结构化、半结构化以及非结构化数据的存储和检索提供了一种机制[13]。NoSQL 数据库包括简单的结构设计、更简单的机器集群水平扩展和更精细的可用性控制[14]。通过使用简单的Key-Value 结构，NoSQL 数据库能够实现对具有确定Key 值数据的快速提取。NoSQL 数据库在设计上的优势，非常适合海量瓦片数据的存储。

2.1 瓦片数据集元数据

在使用大数据平台存储瓦片数据时，通过将包含数据分类、版本、瓦片切片方案、空间坐标引用等信息的元数据一齐保存在大数据平台中，能够确保瓦片元数据与瓦片数据在数据存储介质上的一致。瓦片元数据结构用JSON 数据结构表示为

在项目建设中，使用HBase 数据库保存瓦片数据，并在瓦片入库之前同步瓦片元数据，做到了元数据与数据本体同源一致。

2.2 NoSQL存储结构

HBase 是基于HDFS 的分布式NoSQL 数据库，由Apache 基金会开发、基于BigTable 算法的开源软件产品，在处理非结构化数据方面具有较强优势[15]。HBase数据库的设计包括行键（RowKey）设计和列族（Column Family）设计2 部分。行键是不可分割的字节数组，在大表中按字典排序由低到高存储，是瓦片数据唯一的索引。为了提高用户瓦片数据随机查询读取效率，避免单个节点过热，数据库的设计采用高表方案，即每一行数据中仅保留一个列族，列族内仅有一列，用于存储二进制瓦片数据的base64 编码[16-17]。基于此，对数据库的设计主要体现在行键的设计上。

行键是不可分割的字节数组，在表中按照字典排序由低到高存储，是唯一的索引，决定了数据的处理性能。瓦片数据存储包含瓦片元数据以及瓦片路径信息2 部分，行键结构结果如图3 所示。

图3 行键结构

元数据包括瓦片数据的类别、标题、版本、数据来源等描述字段，通过将这些描述信息按序组合即可得到瓦片数据元数据描述字符串。由于描述字符串长度较长且长短不一，需要使用MD5 算法获取描述字符串的32 位数字摘要值，并作为行键的头部。瓦片路径信息是指某一瓦片的缩放级别、列编码及行编码的组合。对于图2 中的瓦片3.jpg 文件，瓦片路径可以表述为“203.jpg”。由于TMS 并未使用等长编码，故瓦片路径字段的长度会有不同。

3 技术架构

为了解决瓦片数据在存储、管理方面的诸多问题，综合考虑前端发布技术，设计集数据存储、管理与前端应用于一体的技术框架。

3.1 设计要求

基于瓦片数据的特点，面向瓦片数据存储与发布的数据平台应该满足：①数据存储横向可扩展，解决海量数据存储的问题；②支持瓦片元数据存储，易于管理；③前端能够高效获取瓦片，并在前端系统中直接调用。

3.2 瓦片数据存储与应用技术框架

在私有云计算环境下，部署Hadoop 高可用大数据运行环境，搭建HDFS 分布式文件系统，并在此基础上安装实时、分布式、高维数据库HBase。利用HBaseREST Server，实现瓦片数据、瓦片元数据入库、前端可视化组件对瓦片的动态调用。瓦片数据存储技术框架如图4 所示。

图4 基于HBase 的瓦片数据存取技术框架

3.2.1 RESTful接口

REST（representational state transfer）描述了一个架构样式的网络系统，当前被广泛应用于webGIS 系统开发[18-19]。利用HBase REST Server 提供的数据存取接口，可方便地实现瓦片数据入库与读取。接口描述如表1 所示。

表1 数据存取接口

通过遍历磁盘上的瓦片文件，并将瓦片图片转换为Base-64 编码，调用REST 接口后，即可完成瓦片数据的入库操作。

3.2.2 Openlayers前端发布

HBase 数据库提供的RESTServerAPI 为前端应用的开发提供了丰富的接口。基于这些接口，可以开发更加高效的、不需要任何商用GIS 服务软件产品的前端瓦片缓存数据应用。运用Openlayers 前端JS 组件开发基于HBase 的发布软件业务流程如图5 所示。

图5 瓦片数据存储与应用一体化

（1）创建数据源

在Openlayers 中，可以使用ol.source.XYZ 组件实现瓦片数据源的构建。在该类的构造函数中，可以通过在传入参数中定义属性tileUrlFunction 的回调函数，实现在HBase 中存储瓦片的准确命中。核心代码为

4 应用实践与性能分析

4.1 性能分析

为了验证本文所述技术框架的实际工作性能，使用VirtualBox（6.1）搭建虚拟实验环境，在同等硬件环境下，针对商用平台ArcgisServer（10.3）及本文所述技术框架在IO 性能、CPU 占用、内存消耗等方面进行全面比较分析。

4.1.1 物理环境

在Dell Precession 5510 工作站上，搭建虚拟实验环境。为了能更合理、准确地比较2 种技术方案的性能差别，2 套技术方案分配的硬件资源应一致。ArcGIS Server 部署在单节点主机上，Hadoop & Hbase集群则部署在由5 个单节点主机组成的集群上，分配的硬件资源与单节点主机相当。具体硬件资源分配情况如表2 所示。

表2 实验硬件资源配置

4.1.2 服务器响应

由于ArcGISServer 部署在单节点主机上，而Hadoop&Hbase 集群运行在多个节点服务器上，所以很难直接获取磁盘的IO 性能。为此，针对地图任一视域加载的瓦片数据，分别使用经过缓存的ArcgisImageServer 和通过HBaseRESTServer API 直接调用2 种不同技术方案，对服务器性能表现作比较分析，从而间接获取2种技术方案的IO 性能评价。

等待时间（time to first byte，TTFB）是衡量应用程序服务器性能的重要指标之一，其是发出页面请求（request）到接收到应答（response）数据第1 个字节所花费的ms 数。利用Chrome 浏览器开发者模式，分别获得2 种技术方案下，同一地图视域下20 个瓦片请求的TTFB。为了便于比较分析，以瓦片编号作为横轴，获取瓦片的TTFB 为纵轴，分别绘制HBase、Arcgis Server 2 种技术方案下的用时曲线，如图6 所示。

图6 不同技术方案下的服务器性能测试

从图6 可以看出，与基于ArcGIS Server 的技术框架相比，运用HBase REST Server 实现瓦片数据的发布功能，具有服务响应速度快、性能表现稳定高效的突出优点，具有非常明显的IO 性能优势。

为了最大限度接近服务器性能表现的真值，分别对HBase、ArcGIS Tiled Image Server 2 种数据源下的地图页面作3 次刷新操作，对同一瓦片提取3 组TTFB 数据，并使用平均值作为获取该瓦片的最终TTFB 数值，测量结果如表3 所示。

表3 不同技术方案下的TTFB 数据

4.1.3 资源占用情况

为了科学地比较分析2 种技术方案下的资源占用情况，在实验环境下将ArcGIS Server 和Hadoop&Hbase集群均部署在CentOS（7.9）操作系统上，各个节点服务器部署运行的应用进程/角色如表4 所示。

表4 资源占用

对于ArcgisServer，系统会加载多个Command 命令名称为arcsoc 的应用进程。随着在GIS 服务器上发布服务数量增多，这些进程的数量也会相应增多；对于Hadoop & Hbase 集群，在namenode 上固定运行Namenode、HMaster、DFSZKFailoverController 3 个进程，在datanode 上 固 定 运 行Datanode、HRegionServer、JournalNode、QuorumPeer-Main 4 个进程。

分别在Arcgis Server 服务器、Hadoop & Hbase 集群的Namenode、Datanode 上运行top 命令，查看2 种技术方案下的CPU 占用、内存消耗情况，运行结果分别如图7、图8 和图9 所示。

图7 ArcGIS Server CPU 占用及内存消耗

图8 Namenode 节点CPU 占用及内存消耗

图9 Datanode 节点CPU 占用及内存消耗

从图7、图8 和图9 的测试结果中可以看出，相比于Arcgis Server 服务器，Hadoop& Hbase 单节点占用CPU 及消耗的内存较少。同时，Hadoop&Hbase 集群运行应用进程固定，不随发布数据量的增加而增加；而ArcGISServer 则随发布服务器的增多，不断增加arcsoc 进程，由于内存数量的限制，不能无限制地发布瓦片地图服务。

4.2 应用实践

本文所述的技术平台直接应用于“中新天津生态城GIS 服务平台”的开发建设。在私有云计算环境下部署高可用性（high available，HA）Hadoop 集群环境，并在此基础上安装HBase 数据库。在HBase 数据库中保存了生态城从2010 年开始各个月份的行政图、高清影像图以及部分倾斜摄影、街景数据。利用HBase 的REST Server API，实现了瓦片数据在前端的直接快速渲染。

5 结 语

本文提出的面向Hadoop、HBase 的地图瓦片数据存储框架技术，综合运用了Hadoop 集群的横向可扩展、高可用性，开源经济性，以及基于key-value 存储结构的HBase 数据库对于确定key 值提取数据的高效性，为海量瓦片数据的存储和管理提供了全新开源解决方案。同时，框架技术基于HBase REST Server API，实现了瓦片数据在前端组件Openlayers 上的无缝加载，彻底解除了瓦片数据发布应用中对商用GIS 软件平台的依赖，极大地降低了软件开发成本。HBase 作为开源NoSQL 数据库成熟软件产品，广泛应用于各类非结构化数据的存储。在空间大数据存储及应用领域，不仅能够实现本文所述的瓦片数据存储，对于矢量空间数据在HBase 中的存储也值得深入研究。