栅格GIS的分布式存储方案

中 国 地 质 大 学 研究生课程论文封面 课 程 名 称 遗 传 算 法 研究生姓名 研究生学号 研究生专业 2 / 23 基于栅格 GIS 系统的分布式存储 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 【摘要】本文第一部分介绍了云 GIS 的概念与优缺点，第二部分介绍了分布式的 NoSQL 数据库 HBase，第三部分介绍了如何将地理栅格数据如何存储到 HBase 中。 云计算作为一种新型的计算方式已经发展多年了，已经与各个行业相结合。 GIS 作为一种传统的行业应用，其最明显的特点是对超大规模数据集的存储，而 云计算的数据存储能力刚好迎合了 GIS 的需要，因此将云计算与 GIS 结合起来是 理所当然的。 当数据量变的巨大的时候，传统的关系型数据库性能会急剧下降。并且 ER 数据库也不符合云计算的特点，而最近快速发展的 NOSQL 数据库则成为的分布 式存储数据的一个选择。本文选取了 NOSQL 数据库中的一种文档型数据库 HBase 来作为存储载体，并针对 HBase 的限制，采取了切分栅格数据的方法，以达到最 好的性能。 3 / 23 一、基于云的 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 系统并没有出现。 4 / 23 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 服务器和 giscloud.com。但是，按照 3.1.2 的定义这些 GIS 系统没有一个可以真正的叫做基 于云的 GIS 系统。目前，谷歌地球引擎能够提供存储大量分布式 GIS 数据的集合， 它也能够提供一定程度上的卫星影像数据操作，但并没有具体的证据表明这就是 执行真正空间 GIS 算法的能力。 5 / 23 ESRI 提供了一些基于云的 GIS 解决方案：ArcGIS 服务应用在亚马逊 EC2， ArcGIS.com、ArcLogistics 和在线商业分析（BAO）上。亚马逊 EC2 和 ArcGIS.com 建立在相似的架构之上（见图 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 系统。 giscloud.com 也宣称是一个基于云的 GIS 系统。用户可以通过浏览器使用它 们的服务来上传、编辑、转换、创建和分析 GIS 数据。他们也提供了一定的空间 分析能力，比如热点和缓冲分析。但是，由于其鉴于他们没有公开说明他们的系 统作为一个基于云的系统是如何运行的，因此也没有证据来支持他们有利用云计 算分布式数据存储和并行计算优点的能力。 6 / 23 1.2 为什么让 GIS 建立在云上 2.2.1 基于云 GIS 的优点 一般来说基于云的 GIS 会从云计算的基础设施中得到很多好处。这些好处包 括更好的可扩展性、可靠性、可用性、并行化、规模经济，以及更有效率的升级 模型，更容易分享和分发，友好的大数据等等。 单就 GIS 来说，采用云计算基础设施的好处有：低门槛的准入 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 和更多的 面向服务化，特别是对业余的用户。GIS 系统前期通常需要投资大量的硬件、软 件。基于云的 GIS 给用户提供了简单的接入（访问）方式。和很多桌面 GIS 或者 C/S GIS 系统不同的是，基于云的 GIS 系统不需要任何的前期硬件和软件的投资。 用户能马上上传他或者她的数据到云 GIS，运行应用程序，只需为每一个用户付 一次费。所有的这一切只需要他或者她需要一张信用卡可以给服务付费。 另外的一个云计算 GIS 的特点是提供数据服务但不需要（赠送）真实的数据。 举个例子：这里有一份因为隐私问题而不能分发给研究人员的高分辨率的家庭人 口普查数据。当研究人员需要这样一份数据时，可以提供给他们一些粗粒度的区 块普查数据让他们进行推断。这可能会给那些研究者特别是那些需要执行基于人 口普查数据分析的研究者带来一些不便。利用云GIS的优点，研究者可以在Census Bureau 的服务器上做一次关于人口数据的分析服务请求，Census Bureau 能够返 回这些分析的结果给研究者而不需要提供真实的数据给他们。 2.2.2 云 GIS 的缺点 基于云计算的 GIS 也继承了一些云计算的缺点。需要被重点关注的问题是： 隐私和数据安全，数据锁和性能的不可预测性。但是，由于大多数 GIS 分析使用 了大量的数据，因此云 GIS 另一个缺点是云计算中的网络速度瓶颈。尽管在云计 算基础设施中采用了高速网络来连接计算节点，但是连接用户电脑和云计算基础 设施之间的网络的出站和入站速度受到公共互联网提供商（ISP）的巨大限制。 有时候用户可能在云 GIS 上需要上传或下载他们自己的数据，在这种情况下，如 果这些数据很大，完成传输这些数据可能要花费很多的时间。 7 / 23 二、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机制。 8 / 23 此外，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 Timestamp Column Family URI Parser r1 t3 url=http://www.taobao.com title=天天特价 t2 host=taobao.com t1 r2 t5 url=http://www.alibaba.com content=每天„ t4 host=alibaba.com Ø Row Key: 行键，Table的主键，Table 中的记录按照 Row Key 排序 9 / 23 Ø 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 10 / 23 图 3 存储映射结构 Client 访问用户数据之前需要首先访问 zookeeper，然后访问-ROOT-表，接 着访问.META.表，最后才能找到用户数据的位置去访问，中间需要多次网络操作， 不过 client 端会做 cache缓存。 2.3.4 MapReduce on HBase 在 HBase系统上运行批处理运算，最方便和实用的模型依然是 MapReduce， 如下图： 图 4 MapReduce 过程 11 / 23 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 12 / 23 可以随时感知到各个 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 请求过程 13 / 23 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中的数据）。 14 / 23 当 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 存储格式 15 / 23 首先 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 16 / 23 图 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，可参见上文描述。 17 / 23 三、设计 在了解到存储系统 HBase 之后，我们将准备将栅格数据存储到 HBase 中。由 于 HBase 的每列至多存储 14MB 数据的存储限制，我们必须对栅格 GIS 数据进行 切分才能存储到 Hbase 里。对于不同栅格 GIS 数据的分割，我们会针对栅格 GIS 数据的上层应用的特性而采取不同的分割方式。但这种分割方式与存储层的存储 没有任何关系，只是对上层应用程序来说，能提供更好的性能。 3.1 切分策略 我们一般把栅格数据分为两类：高 3D 数据集（H3D）与低 3D 数据集（L3D）。 H3D 在一个地理区间上含有很多图层，并且这些图层拥有相同的地理属性，如相 同的空间分辨率、坐标系统、投影系统等。这种类型最典型的一个例子就是时间 序列的气候数据图形。而 L3D 则只拥有有限的一个或几个图层，他们没有在某个 轴上的持续变化。 之所以讨论这两种类型的栅格数据，这是因为上层的应用程序对这两种栅格 数据具有不同的访问方式。对 H3D 数据集来说，用户更多的关注的是数据的持 续性，而 L3D 最关注的则是二维地理空间。举例来说，对 H3D，我们在某一时刻 更关注的是同一时间序列上的不同层上的一些像素点。而 L3D 则是某一区域的像 素点。针对这个特性，我们在切分的方式上采取不同的策略，能够给应用程序带 来更好的性能。 顺序存储：像素存储从左到右，从最高层到最底层。顺序存储主要用在 2D 的地理图片，当对这个区域进行操作时，该区域的其他像素点也很快速的访问。 18 / 23 图 11 顺序存储 交叉存储: 取不同层的相同区域的像素点来存储。如果同一区域有多个状态，那么交叉 存储在查询状态时会获得较好的性能。要求这些层拥有相同的空间分辨率、坐标系统、投影 系统。 图 12 交叉存储 但对于我们设计的存储模型来说，并不太要求像素点的存储模型，但应用程序对于不同 的栅格数据有不同的访问模式，根据栅格数据的特性来选择顺序或者交叉存储，可以获得更 19 / 23 好的性能。 3.2 块的产生 将栅格 GIS 数据存储到存储系统里，第一步就是要将栅格数据分割成块（Block）。 我们 采用经过修改的四叉树（quadtree，Q-tree）结构在 2 维的地理空间图片上来产生块。 quadtrees 是从地形中获得的，把它分割成四个较小的部分，每一个部分继续分下去， 直到一个分到 一个设定的大小，这看起来有点乱，让我结合图片解释一下，首先，从我们 的网。格出发，现在将他分为四份。 图 13 第一次划分 如图三，我们现在有四个子地形，继续分下去，知道一个部分只有一个单元，在下图中， 我们把第一个 小部分分成了四个更小的部分。 20 / 23 图 14 二次划分 然后继续，知道切分到满足我们的大小。 图 15 最终切分图 分割完毕后，我们为最终的块产生索引值。 21 / 23 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)，能提高性能。 22 / 23 图 17 切分与概念存储 下面这张图，是切分后的栅格数据的物理存储示意。 图 18 概念与物理存储 3.4 数据操作 1、创建(Create) 获取栅格数据集之后，我们按照之前四叉树结构对其进行分割，并产生索引值，把分割 后的切片存入 HBase 中，并以这个索引值作为该块的行键（Row key）。 23 / 23 2、查询（Query） 当应用程序需要在一个区域的栅格数据集上进行查询时，客户端程序会将这个区域的坐 标转换为块索引，然后将这个索引值传递到存储系统进行查询。 3、更新（Update） Hbase 的一个重要特性是在更新时锁住（Lock )该行以实现一致性。因此应用程序更新 块上的数据信息时，不必担心一致性问题。 4、删除（Delete） 不建议在存储系统中删除一行，除非该行会造成错误。删除会造成数据的永久丢失，并 且存储系统的价格并不是很贵，可以通过更新数据的时间戳（time stamp）来实现数据的假 删除。 3.5 小结 1、将 2 维栅格数据分割成多块（multiple blocks)，块（Block）是 2 维地理 空间的一个区域，它包含一组像素点。 2、像素点可以使用顺序存储或 交叉模型两种格式。 3、块作为最基本的存储单位存储到 HBase 里。 栅格数据集一般由图层叠加而成，我们主要使用的栅格数据可能有一个或少 数几个图层，并且我们不太关心第三维上的数据持续性问题。因此在存储模型上 我们选择了按层顺序存储。 但对于我们设计的存储模型来说，并不太要求像素点的存储模型，但应用程 序对于不同的栅格数据有不同的访问模式，根据栅格数据的特性来选择顺序或者 交叉存储，可以获得更好的性能。 我们一般是在一个地理区域上做查询操作，而不是在一个像素点或者一条像 素线上做查询，因此将一个块（Block）的所有像素点存储到同一行里，能够可 以获得最好的性能。 将像素点以块存储顺序存储还能够极大地提高查找和访问 速度。 好文档，我来分享! www.cooljsq.com