栅格GIS的分布式存储方案

中国地质大学研究生课程论文封面
课程名称遗传算法
研究生姓名
研究生学号
研究生专业
基于栅格GIS系统的分布式存储方案
【摘要】本文第一部分介绍了云GIS的概念与优缺点，第二部分介绍了分布式的NoSQL数据库HBase，第三部分介绍了如何将地理栅格数据如何存储到HBase中。

云计算作为一种新型的计算方式已经发展多年了，已经与各个行业相结合。

GIS作为一种传统的行业应用，其最明显的特点是对超大规模数据集的存储，而云计算的数据存储能力刚好迎合了GIS的需要，因此将云计算与GIS结合起来是理所当然的。

当数据量变的巨大的时候，传统的关系型数据库性能会急剧下降。

并且ER 数据库也不符合云计算的特点，而最近快速发展的NOSQL数据库则成为的分布式存储数据的一个选择。

本文选取了NOSQL数据库中的一种文档型数据库HBase 来作为存储载体，并针对HBase的限制，采取了切分栅格数据的方法，以达到最好的性能。

一、基于云的GIS
互联网的发展给传统的GIS带来了很多可能和机会。

一些GIS公司已经发布了像ESRI的ArcGIS服务器、谷歌地球和必应地图等这种面向互联网的各种不同层次的GIS系统。

现今出现的云计算将会给GIS界带来更多令人激动的机会。

1.1 云GIS定义
在定义云GIS之前，十分值得我们来回顾一下我们正在使用的GIS系统的通性。

根据如何将GIS系统的服务部署和如何分发到用户，我们可以把GIS系统分为如下三种：桌面GIS、C/S GIS和公共互联网GIS。

1.1.1GIS类型
桌面GIS：计算和存储单元存储在终端用户的电脑上。

ESRI公司的ArcGIS 桌面9.3，Clark 实验室的IDRISI 和MapInfo可以被分为这一类。

这种类型的GIS 并不一定需要网络。

C/S GIS：大量的存储空间未于服务器，能够根据操作的类型决定是在服务器上或(和）客户机上执行计算操作。

这种类型的GIS至少需要内部网的支持。

来自于经过认证的指定组的用户可以使用指定服务器上的资源。

用户使用客户机来显示和执行查询以及其他类型的编辑。

当这些操作完成，用户提交这些变化会服务器。

一个典型的例子是用ArcGIS桌面中的ArcMS用ArcGIS浏览器来浏览ArcGIS 服务器。

尽管这种类型的GIS系统有些时候能通过互联网传送一些数据，但基于它的硬件和软件组成，并不能用来被大量的公共用户来操作。

公共互联网GIS：计算和存储两者都位于服务器端。

这种类型的GIS一般只能提供数据可视化和像查询这样有限的操作。

这种Lexington的GIS系统通常只关注大量的公共用户。

谷歌地图、谷歌地球以及毕竟地图就是这种能够提供一些GIS功能但缺乏必要的分析之间的公共会联网的系统。

分布式GIS：不管是实现了那种分布式计算模型的GIS系统都叫分布式GIS 系统。

这些计算模型包括网格计算、点对点计算、云计算和高性能计算。

但是，一个真正的分布式GIS系统并没有出现。

1.1.2 云GIS定义
在理解不同的云计算系统之后，归纳出如下一个暂定的云计算GIS定义：“一个GIS系统建立在云计算基础设施之上，使用云基础设置动态地调整他的计算和（或）存储能力，提供并行化的服务。

”
上述关于服务的定义不但包括数据显示和查询功能，也包跨数据编辑和空间分析功能。

1.1.3云GIS和其他GIS最大的不同点
尽管从定义上就能很明显地看出不同种类GIS的不同点，但还是需要指出一些他们定义中的区别，基于云的GIS是分布式GIS的一个子集。

基于云的GIS和其他一些分布式的类似于基于网格的GIS和基于高性能的GIS的最大区别在于他们建立的硬件和协议以及用户群之上。

高性能GIS使用昂贵的硬件但云计算使用廉价的商业电脑。

网格使用更严格的访问控制和会联网协议但云计算使用相对宽松的访问控制和公共协议。

同时，不管是基于高性能的GIS还是基于网格的GIS都不是面向大规模的公共用户而设计的，而云计算是。

公共互联网的GIS和基于云的GIS的不同点在于他们的功能集以及他们所使用的硬件设施。

与Web服务器相比较，基于云的GIS使用的云计算基础设施能够提供更大的数据吞吐力。

通常来说，因为基础设施的不同，基于云的GIS能够提供更大的数据和更密集计算服务。

实际上，像谷歌地图和谷歌地球这些公共的互联网地图服务已经是基于云的。

1.1.4 当前基于云的GIS概览
随着云计算的发展，一些基于云或声称基于云的GIS系统已经发布了。

这些系统包括：谷歌地图引擎（Google Earth Engine）、基于云的ArcGIS 服务器和。

但是，按照3.1.2的定义这些GIS系统没有一个可以真正的叫做基于云的GIS系统。

目前，谷歌地球引擎能够提供存储大量分布式GIS数据的集合，它也能够提供一定程度上的卫星影像数据操作，但并没有具体的证据表明这就是执行真正空间GIS算法的能力。

ESRI提供了一些基于云的GIS解决方案：ArcGIS服务应用在亚马逊EC2，、ArcLogistics和在线商业分析（BAO）上。

亚马逊EC2 和 建立在相似的架构之上（见图3），ArcGIS服务器运行在亚马逊EC2云的虚拟机上。

安装在亚马逊EC2上的ArcGIS服务软件与安装在单个微型计算机上的ArcGIS 服务软件一样。

它在通过预装安装的AecGIS服务上通过创建更多的虚拟机来达到扩展性。

这种架构能够通过在同一时间段部署多台独立服务器的方法在一定程度上能够提供较好的扩展性。

但是，这些服务器不能提供与扩展性一样好的性能。

亚马逊EC2的所有ArcGIS服务器全部都是独立运行，这意味着它在并行任务自动化或转移任务加载的动态化上存在一定的管理系统短板。

因此，这种架构可以提供完美的访问性，但不能提供完美的性能。

ArcLogistics 和在线商业分析（BAO)是ESRI提供的软件即服务的一种类型。

AecLogistics能够给用户提供经过基于一些因素优化了的日常和计划。

BAO是一个能够提供基于位置的统计、消费者消费和其他一些商业数据的报告和地图的web服务。

基于云的ArcLogistics运行在亚马逊EC2上，而BAO运行在ERSI数据中心。

ArcLogistics和BAO会肯定会提供强大的GIS查询和分析功能，但是根据3.1.2的定义它们因为只提供了有限的几种GIS分析功能而不能被归类于我们强调的基于云的GIS系统。

也宣称是一个基于云的GIS系统。

用户可以通过浏览器使用它们的服务来上传、编辑、转换、创建和分析GIS数据。

他们也提供了一定的空间分析能力，比如热点和缓冲分析。

但是，由于其鉴于他们没有公开说明他们的系统作为一个基于云的系统是如何运行的，因此也没有证据来支持他们有利用云计算分布式数据存储和并行计算优点的能力。

1.2 为什么让GIS建立在云上
2.2.1 基于云GIS的优点
一般来说基于云的GIS会从云计算的基础设施中得到很多好处。

这些好处包括更好的可扩展性、可靠性、可用性、并行化、规模经济，以及更有效率的升级模型，更容易分享和分发，友好的大数据等等。

单就GIS来说，采用云计算基础设施的好处有：低门槛的准入标准和更多的面向服务化，特别是对业余的用户。

GIS系统前期通常需要投资大量的硬件、软件。

基于云的GIS给用户提供了简单的接入（访问）方式。

和很多桌面GIS或者C/S GIS系统不同的是，基于云的GIS系统不需要任何的前期硬件和软件的投资。

用户能马上上传他或者她的数据到云GIS，运行应用程序，只需为每一个用户付一次费。

所有的这一切只需要他或者她需要一张信用卡可以给服务付费。

另外的一个云计算GIS的特点是提供数据服务但不需要（赠送）真实的数据。

举个例子：这里有一份因为隐私问题而不能分发给研究人员的高分辨率的家庭人口普查数据。

当研究人员需要这样一份数据时，可以提供给他们一些粗粒度的区块普查数据让他们进行推断。

这可能会给那些研究者特别是那些需要执行基于人口普查数据分析的研究者带来一些不便。

利用云GIS的优点，研究者可以在Census Bureau的服务器上做一次关于人口数据的分析服务请求，Census Bureau能够返回这些分析的结果给研究者而不需要提供真实的数据给他们。

2.2.2 云GIS的缺点
基于云计算的GIS也继承了一些云计算的缺点。

需要被重点关注的问题是：隐私和数据安全，数据锁和性能的不可预测性。

但是，由于大多数GIS分析使用了大量的数据，因此云GIS另一个缺点是云计算中的网络速度瓶颈。

尽管在云计算基础设施中采用了高速网络来连接计算节点，但是连接用户电脑和云计算基础设施之间的网络的出站和入站速度受到公共互联网提供商（ISP）的巨大限制。

有时候用户可能在云GIS上需要上传或下载他们自己的数据，在这种情况下，如果这些数据很大，完成传输这些数据可能要花费很多的时间。

二、HBase介绍
2.1HBase简介
HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。

HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce 来处理HBase中的海量数据；Google Bigtable利用 Chubby作为协同服务，HBase 利用Zookeeper作为对应。

图1 Hadoop生态系统
上图描述了Hadoop EcoSystem中的各层系统，其中HBase位于结构化存储层，Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce 为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。

此外，Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。

Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。

2.2 HBase访问接口
1. Native Java API，最常规和高效的访问方式，适合Hadoop MapReduce Job 并行批处理HBase表数据。

2. HBase Shell，HBase的命令行工具，最简单的接口，适合HBase管理使用。

3. Thrift Gateway，利用Thrift序列化技术，支持C++，PHP，Python等多种语言，适合其他异构系统在线访问HBase表数据。

4. REST Gateway，支持REST 风格的Http API访问HBase, 解除了语言限制。

5. Pig，可以使用Pig Latin流式编程语言来操作HBase中的数据，和Hive 类似，本质最终也是编译成MapReduce Job来处理HBase表数据，适合做数据统计。

6. Hive，当前Hive的Release版本尚没有加入对HBase的支持，但在下一个版本Hive 0.
7.0中将会支持HBase，可以使用类似SQL语言来访问HBase。

2.3 HBase数据模型
3.3.1 Table & Column Family
Ø Row Key: 行键，Table的主键，Table中的记录按照Row Key排序
Ø Timestamp: 时间戳，每次数据操作对应的时间戳，可以看作是数据的version number
Ø Column Family：列簇，Table在水平方向有一个或者多个Column Family 组成，一个Column Family中可以由任意多个Column组成，即Column Family 支持动态扩展，无需预先定义Column的数量以及类型，所有Column均以二进制格式存储，用户需要自行进行类型转换。

2.3.2 Table & Region
当Table随着记录数不断增加而变大后，会逐渐分裂成多份splits，成为regions，一个region由[startkey,endkey)表示，不同的region会被Master 分配给相应的RegionServer进行管理。

图2 表与区间的关系
3.3.3 -ROOT- && .META. Table
HBase中有两张特殊的Table，-ROOT-和.META.
Ø .META.：记录了用户表的Region信息，.META.可以有多个regoin
Ø -ROOT-：记录了.META.表的Region信息，-ROOT-只有一个region
Ø Zookeeper中记录了-ROOT-表的location
图3 存储映射结构
Client访问用户数据之前需要首先访问zookeeper，然后访问-ROOT-表，接着访问.META.表，最后才能找到用户数据的位置去访问，中间需要多次网络操作，不过client端会做cache缓存。

2.3.4 MapReduce on HBase
在HBase系统上运行批处理运算，最方便和实用的模型依然是MapReduce，如下图：
图4 MapReduce 过程
HBase Table和Region的关系，比较类似HDFS File和Block的关系，HBase 提供了配套的TableInputFormat和TableOutputFormat API，可以方便的将HBase Table作为Hadoop MapReduce的Source和Sink，对于MapReduce Job 应用开发人员来说，基本不需要关注HBase系统自身的细节。

2.4 HBase系统架构
图5 Hbase架构
Client
HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client 与HRegionServer进行RPC
Zookeeper
Zookeeper Quorum中除了存储了-ROOT-表的地址和HMaster的地址，HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中，使得HMaster
可以随时感知到各个HRegionServer的健康状态。

此外，Zookeeper也避免了HMaster的单点问题，见下文描述
HMaster
HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper 的Master Election机制保证总有一个Master运行，HMaster在功能上主要负责Table和Region的管理工作：
1. 管理用户对Table的增、删、改、查操作
2. 管理HRegionServer的负载均衡，调整Region分布
3. 在Region Split后，负责新Region的分配
4. 在HRegionServer停机后，负责失效HRegionServer 上的Regions迁移
HRegionServer
HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。

图6 HBase请求过程
HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了Table 中的一个Region，HRegion中由多个HStore组成。

每个HStore对应了Table 中的一个Column Family的存储，可以看出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family 中，这样最高效。

HStore存储是HBase存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。

MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。

当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split 操作，同时把当前Region Split成2个Region，父Region会下线，新Split 出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。

下图描述了Compaction和Split 的过程：
图7 表分裂
在理解了上述HStore的基本原理后，还必须了解一下HLog的功能，因为上述的HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，因此一旦HRegionServer意外退出，MemStore中的内存数据将会丢失，这就需要引入HLog了。

每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中（HLog文件格式见后续），HLog 文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。

当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的 HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的region重新分配，领取到这些region 的HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。

2.5 HBase存储格式
HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，主要包括上述提出的两种文件类型：
1. HFile， HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile
2. HLog File，HBase中WAL（Write Ahead Log）的存储格式，物理上是Hadoop的Sequence File
HFile
下图是HFile的存储格式：
图8 HFile存储格式
首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。

正如图中所示的，Trailer中有指针指向其他数据块的起始点。

File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等。

Data Index和Meta Index块记录了每个Data块和Meta块的起始点。

Data Block是HBase I/O的基本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制。

每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询。

每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字，目的是防止数据损坏。

后面会详细介绍每个KeyValue对的内部构造。

HFile里面的每个KeyValue对就是一个简单的byte数组。

但是这个byte 数组里面包含了很多项，并且有固定的结构。

我们来看看里面的具体结构：
图9 Key Value组成
开始是两个固定长度的数值，分别表示Key的长度和Value的长度。

紧接着是Key，开始是固定长度的数值，表示RowKey的长度，紧接着是RowKey，然后是固定长度的数值，表示Family的长度，然后是Family，接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type（Put/Delete）。

Value 部分没有这么复杂的结构，就是纯粹的二进制数据了。

HLogFile
图10 HLog结构
上图中示意了HLog文件的结构，其实HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number 和timestamp，timestamp是“写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。

HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue，可参见上文描述。

三、设计
在了解到存储系统HBase之后，我们将准备将栅格数据存储到HBase中。

由于HBase的每列至多存储14MB数据的存储限制，我们必须对栅格GIS数据进行切分才能存储到Hbase里。

对于不同栅格GIS数据的分割，我们会针对栅格GIS 数据的上层应用的特性而采取不同的分割方式。

但这种分割方式与存储层的存储没有任何关系，只是对上层应用程序来说，能提供更好的性能。

3.1 切分策略
我们一般把栅格数据分为两类：高3D数据集（H3D）与低3D数据集（L3D）。

H3D在一个地理区间上含有很多图层，并且这些图层拥有相同的地理属性，如相同的空间分辨率、坐标系统、投影系统等。

这种类型最典型的一个例子就是时间序列的气候数据图形。

而L3D则只拥有有限的一个或几个图层，他们没有在某个轴上的持续变化。

之所以讨论这两种类型的栅格数据，这是因为上层的应用程序对这两种栅格数据具有不同的访问方式。

对H3D数据集来说，用户更多的关注的是数据的持续性，而L3D最关注的则是二维地理空间。

举例来说，对H3D，我们在某一时刻更关注的是同一时间序列上的不同层上的一些像素点。

而L3D则是某一区域的像素点。

针对这个特性，我们在切分的方式上采取不同的策略，能够给应用程序带来更好的性能。

顺序存储：像素存储从左到右，从最高层到最底层。

顺序存储主要用在2D 的地理图片，当对这个区域进行操作时，该区域的其他像素点也很快速的访问。

图11 顺序存储
交叉存储:取不同层的相同区域的像素点来存储。

如果同一区域有多个状态，那么交叉存储在查询状态时会获得较好的性能。

要求这些层拥有相同的空间分辨率、坐标系统、投影系统。

图12 交叉存储
但对于我们设计的存储模型来说，并不太要求像素点的存储模型，但应用程序对于不同的栅格数据有不同的访问模式，根据栅格数据的特性来选择顺序或者交叉存储，可以获得更
好的性能。

3.2 块的产生
将栅格GIS数据存储到存储系统里，第一步就是要将栅格数据分割成块（Block）。

我们采用经过修改的四叉树（quadtree，Q-tree）结构在2维的地理空间图片上来产生块。

quadtrees 是从地形中获得的，把它分割成四个较小的部分，每一个部分继续分下去，直到一个分到一个设定的大小，这看起来有点乱，让我结合图片解释一下，首先，从我们的网。

格出发，现在将他分为四份。

图13 第一次划分
如图三，我们现在有四个子地形，继续分下去，知道一个部分只有一个单元，在下图中，我们把第一个小部分分成了四个更小的部分。

图14 二次划分然后继续，知道切分到满足我们的大小。

图15 最终切分图分割完毕后，我们为最终的块产生索引值。

3.3 块的索引值
在HBase中，我们需要为每个提供一个唯一的主键。

创建主键的规则：1、左上的索引值是0，右上的索引值是1。

2、左下的索引值是2，右下的索引值是3。

3、下一级的划分也是同样的规则。

我们将这些四叉树的叶子节点（块）的索引值作为这些块存储在Hbase里面的行键（Row key)。

比如图中这些四叉树叶子节点的索引值为：0130，0131，0132，0133。

图16 索引产生
这样分配块（Block）的行键（Row key 的好处：每一个块都存储在HBase 中的一行，并且HBase的行是按字典序存储的，因此2维地理上的相邻区域在物理存储上也是相近的。

行键前缀相同的行在物理上的存储是相近的，因此在读取时，可以减少硬盘的随机访问(Random Access)，能提高性能。

图17 切分与概念存储
下面这张图，是切分后的栅格数据的物理存储示意。

图18 概念与物理存储
3.4 数据操作
1、创建(Create)
获取栅格数据集之后，我们按照之前四叉树结构对其进行分割，并产生索引值，把分割后的切片存入HBase中，并以这个索引值作为该块的行键（Row key）。

2、查询（Query）
当应用程序需要在一个区域的栅格数据集上进行查询时，客户端程序会将这个区域的坐标转换为块索引，然后将这个索引值传递到存储系统进行查询。

3、更新（Update）
Hbase的一个重要特性是在更新时锁住（Lock )该行以实现一致性。

因此应用程序更新块上的数据信息时，不必担心一致性问题。

4、删除（Delete）
不建议在存储系统中删除一行，除非该行会造成错误。

删除会造成数据的永久丢失，并且存储系统的价格并不是很贵，可以通过更新数据的时间戳（time stamp）来实现数据的假删除。

3.5 小结
1、将2维栅格数据分割成多块（multiple blocks)，块（Block）是2维地理空间的一个区域，它包含一组像素点。

2、像素点可以使用顺序存储或交叉模型两种格式。

3、块作为最基本的存储单位存储到HBase里。

栅格数据集一般由图层叠加而成，我们主要使用的栅格数据可能有一个或少数几个图层，并且我们不太关心第三维上的数据持续性问题。

因此在存储模型上我们选择了按层顺序存储。

但对于我们设计的存储模型来说，并不太要求像素点的存储模型，但应用程序对于不同的栅格数据有不同的访问模式，根据栅格数据的特性来选择顺序或者交叉存储，可以获得更好的性能。

我们一般是在一个地理区域上做查询操作，而不是在一个像素点或者一条像素线上做查询，因此将一个块（Block）的所有像素点存储到同一行里，能够可以获得最好的性能。

将像素点以块存储顺序存储还能够极大地提高查找和访问速度。

好文档，我来分享! 。