CN105354263A - 基于HBase分布式环境下移动对象并行网格索引同步方法 - Google Patents

Abstract

本发明提供了基于HBase分布式环境下移动对象并行网格索引同步方法，包括几步：(1)针对每一个网格单元，创建一个ZooKeeper结点作为锁目录；(2)每个希望获得锁的索引用户进程在锁目录下创建一个结点，该结点类型为有序临时节点。(3)当前索引用户进程调用ZooKeeper的getChildren方法得到锁目录所有子节点，并判断序号最小的子结点是不是自己创建的结点，是，那么它就获得了这个锁；(4)不是，那么它就调用ZooKeeper的exists方法并监控ZooKeeper上目录节点列表中比自己序号小的最晚创建的有序临时节点状态；(5)监视的比自己序号小的最晚创建的节点状态发生变化，则跳转到步骤3，直到退出锁竞争。本发明优点是支持云计算环境中基于HBase的网格索引的高吞吐率的并发操作。

Description

基于HBase分布式环境下移动对象并行网格索引同步方法

技术领域

本发明属于电子信息领域，特别是涉及基于HBase分布式环境下移动对象并行网格索引同步方法。

背景技术

随着智能手机，平板，全球定位系统(GPS)和地理信息系统的快速发展和应用，大量基于位置的服务(LBS)应运而生，广泛走进人们生活的方方面面^[1]。例如，手机用户通过“签到”，分享自己的位置信息，从而获得周围的餐饮、娱乐、地图信息以及折扣信息；百度地图中常见的“附近的加油站”、“最近的餐馆”，微信中的“摇一摇”等。LBS也成为学术界研究的热点之一。

基于位置服务相关技术的研究已经持续了很多年，取得很多的成果，而随着多样的定位手段、用户终端及广泛的通讯手段的出现、潜在的移动数据源迅速增长，以基于位置服务为代表的移动应用已步入移动大数据时代。移动大数据环境下，数据规模更大、传播速度更快、多样性更加广泛，传统LBS技术面临多种新的挑战。1)在应用规模方面，规模急剧扩大，移动服务提供商需要面临超大规模应用所带来的挑战。以手机为例，市场研究公司ICInsights发布的《2015年IC市场驱动报告》称，到2015年，全球手机用户量将首次超过全球人口总数。届时，全球人口总数将超过74亿，而手机用户总数将略高于75亿。面对如此大规模的用户量，传统集中式的LBS处理系统的性能遇到挑战。2)在性能方面，移动数据源及用户查询请求的迅速增长，系统需要具备高速的流数据处理能力。一方面，随着硬件技术与基础设施的进步，移动时空流数据(坐标、移动速度等)的产生、传播的速度更快。

在移动大数据时代，针对移动大数据的处理，传统存储与处理数据的技术手段遇到了瓶颈，海量数据与系统的数据处理能力之间存在一个鸿沟。现有的系统无法有效的处理在扩展性、实时性、可靠性及性能方面所面临的挑战。近几年随着云计算具有灵活的扩展性、强大的处理能力、高度的可靠性，云计算已经成为解决海量数据问题的有效方法。众所周知，HBase是云环境下重要的存储工具。HBase的特点使其非常适合LBS查询系统：首先，HBase扩展性非常好，性能突破了单点性能的瓶颈，并且随着集群规模的增加，HBase性能越来越高。其次，HBase读写性能良好，并且性能不会随着数据量的增长而下降，在海量移动的环境下，有效的保证了LBS查询系统的低延迟和实时性。最后，由于LBS对移动对象位置的聚集性很敏感，而HBase底层数据按RowKey有序存储和分块(Region)存储，使得良好设计的RowKey在批量读取时性能提升很快，减少了读取众多数据的磁盘I/O操作。所以在LBS关于范围的查询中，能大量减少I/O操作，节省存取时间。

在LBS查询中，由于对象是二维的移动对象点，选用网格索引作为索引结构，并将索引建立在HBase上。网格索引是一种常用的空间索引结构，网格索引结构如图1所示，它是在地图图层上，将空间区域进行规则划分，划分成相同大小的网格，然后基于网格建立空间索引，把落入网格的空间对象记录在该网格的索引项里。网格索引具有快速定位，结构简单等优点。网格索引非常适合应用于移动对象的范围查询，如图1所示，黑色范围框代表查询范围，可以根据查询框的左下角和右上角的端点坐标通过公式快速计算出每个端点所属的网格id，然后通过映射可以快速算出其覆盖的单元网格。由此再根据查询范围进行移动对象的过滤，得到查询结果。

在LBS查询中，由于查询和更新进程同时共享移动对象位置信息，必须控制多个进程对共享资源的访问。移动对象的位置更新和相关查询都是分布式环境下进行，许多进程来共同完成移动用户的服务请求。这些进程可能在相同的机器上，也有可能分布在不同的机器上。如果这些进程共享了一些资源，不进行相应的控制就可能造成结果的错误。例如，在LBS查询中，多个查询和更新进程同时进行并且由于和位置更新相比，移动对象进行查询更加耗时，所以在查询执行的过程中，原本属于查询范围的移动对象可能进行了位置更新，使其位于查询范围之外，这样查询结果就少包含了此对象，相反，如果原本不属于查询范围内的移动对象在此期间移动到查询范围内，那么最终结果就多包含了该对象。这两种情况都造成了查询结果的错误。图2说明了这种情况。

如图2所示，范围查询q还未执行完毕时，移动对象p进行了更新，图中p1代表移动对象p更新前的位置，p2代表对象p要将要更新的位置，黑色的范围框是范围查询q的范围框。根据定义4.2，范围查询q发起查询的时刻，对象p位于查询范围内，查询结果应该包含对象p。但是由于查询和更新相比执行时间更长，因此如果范围查询在遍历到对象p时，p的位置已经更新到了p2，那么此时查询结果没有包含移动对象p。因此和定义不符合，查询结果错误。

在LBS查询的网格索引中，有两个共享资源需要使用锁来协调控制，分别是是单元格和移动对象。两者都需要被查询和更新进程访问，如果不对其进行加锁，就可能出现查询结果错误，或者更新无效等情况。锁粒度是影响系统系能的关键因素，锁的粒度越大，越容易实现，但是系统的性能会下降很大。锁的粒度越小，相应的复杂度也会增大，但是系统性能受到的影响就会很小。朴素的策略是table-lock，即对HBase数据库表进行加锁；我们提出的策略是cell-lock，即对单元格加锁。考虑到设计的HBase数据表，对网格索引中每个单元格以及移动对象加锁，由于在HBase数据库表中，每个单元格是表中的行健，相当于HBase表中的一行，这种情况下锁粒度比朴素策略小的多。

在LBS查询中，基于HBase分布式环境下移动对象并行网格索引同步非常重要，但是目前没有具体的方法来解决基于HBase分布式环境下移动对象并行网格索引的同步问题。

发明内容

为了解决上述问题本发明提出的技术方案是：

基于HBase分布式环境下移动对象并行网格索引同步方法，包括以下几步：

(1)针对每个网格单元，创建一个ZooKeeper结点作为锁目录，并且结点类型为持久节点(PERSISTENT)，这种类型的节点在创建后，就一直存在，直到有删除操作来主动清除这个节点——不会因为创建该节点的索引用户连接失效而消失。这个节点用来描述被共享的资源，称为/lock_node，并有一个标志符；

(2)每个希望获得锁的索引用户进程在锁目录下创建一个结点，作为锁/lock_node的子结点，该结点类型为有序临时节点(EPHEMERAL_SEQUENTIAL)，这类节点的基本特性和持久节点是一致的，在ZooKeeper中，每个父节点会为他的第一级子节点维护一份时间顺序，会记录每个子节点创建的先后顺序，每个节点有一个序号。

(3)当前索引用户进程调用ZooKeeper的getChildren(/lock_node)方法得到锁目录下所有子节点，并判断序号最小的子结点是不是自己创建的结点，如果是，那么它就获得了这个锁；

(4)如果序号最小的子结点不是自己创建的，那么当前索引用户进程就调用ZooKeeper的exists方法并监控ZooKeeper上目录节点列表中比自己序号小的最晚创建的有序临时节点状态；

(5)如果监视的节点状态发生变化，则跳转到步骤3，直到退出锁竞争。

分布式锁是分布式环境下进行共享资源控制的常用手段，它能有效协调分布式环境下的多线程协调问题，十分适合应用于基于TwitterStormLBS查询框架之中。因此，本文将基于ZooKeeper的分布式锁服务来解决分布式环境下LBS并行处理的同步问题。

ZooKeeper分布式服务框架是ApacheHadoop的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、分布式锁服务、集群管理、分布式应用配置项的管理等。它支持单机模式和分布式模式，在分布式模式下，能够为分布式应用提供高性能和可靠的协调服务，而且使用ZooKeeper可以大大简化分布式协调服务的实现，这就为开发分布式应用大大降低了成本。

ZooKeeper在集群中每个节点都维护着一棵相同的树，树的结构和Linux的目录结构的概念类似。

本发明的优点是：支持云计算环境中基于HBase的网格索引的高吞吐率的并发操作。

附图说明

图1网格索引结构示意图

图2并行更新与查询例子

图3基于ZooKeeper的分布式共享锁算法流程图

具体实施方式

实施例1

网格划分如图1所示，假设共享资源为图中单元格20，有四个索引用户进程要访问此单元格

(1)首先针对网格单元20，创建一个ZooKeeper结点作为锁目录，并且结点类型为PERSISTENT。用它来描述被共享的资源，称为：/lock_node，用网格id作为标识符，表示为/20。

(2)每个希望获得锁的索引用户进程在锁目录下创建一个结点locks_i，作为锁/20的子结点，该结点类型为有序临时节点(EPHEMERAL_SEQUENTIAL)。此时，有四个进程创建了结点，根据它们创建节点的时间先后顺序，分别表示为/20/locks_1、/20/locks_2、/20/locks_3和/20/locks_4。

(3)当前索引用户进程调用ZooKeeper的getChildren(/20)方法得到锁目录所有子节点：/20/locks_1、/20/locks_2、/20/locks_3和/20/locks_4，获取序号最小的子节点/20/lock-1，并判断获取到的序号最小的子结点是不是自己创建的结点，如果当前索引用户进程创建了/20/locks_1，最小的节点是自己创建的，那么它就获得了锁/20。

(4)如果当前索引用户创建了节点/20/locks_4，最小的节点/20/locks_1不是当前索引用户进程创建的，那么它就调用ZooKeeper的exists(/20，true)方法，监控ZooKeeper上目录节点列表中比自己序号小的最晚创建的有序临时节点/20/locks_3的状态，因为目录节点列表中比自己序号小的节点分别有/20/locks_1、/20/locks_2和/20/locks_3，其中，/20/locks_3节点创建时间和/20/locks_4节点的创建时间最接近。

(5)如果当前索引用户监视的节点/20/locks_3状态发生变化，则跳转到步骤3，直到退出锁竞争。

如果索引用户进程想要释放锁或者退出锁竞争，只需要删除其在锁目录下创建的子结点即可。本文在此不在详细陈述。

可以看出，基于ZooKeeper的分布式共享锁是按照FIFO的策略分配共享资源。进程请求锁的顺序和获得锁的顺序是一致的。

图3是ZooKeeper实现分布式共享锁的算法流程图，从图中可以看出通过ZooKeeper进行分布式环境下的进程同步非常方便。

Claims (1)

1.基于HBase分布式环境下移动对象并行网格索引同步方法，其特征在于，包括以下几步：

(1)针对每个网格单元，创建一个ZooKeeper结点作为锁目录，并且结点类型为持久节点，这种类型的节点在创建后，就一直存在，直到有删除操作来主动清除这个节点——不会因为创建该节点的索引用户连接失效而消失。这个节点用来描述被共享的资源，称为/lock_node，并有一个标志符；

(2)每个希望获得锁的索引用户进程在锁目录下创建一个结点，作为锁/lock_node的子结点，该结点类型为有序临时节点，这类节点的基本特性和持久节点是一致的，在ZooKeeper中，每个父节点会为他的第一级子节点维护一份时间顺序，会记录每个子节点创建的先后顺序，每个节点有一个序号；

(3)当前索引用户进程调用ZooKeeper的getChildren方法得到锁目录下所有子节点，并判断序号最小的子结点是不是自己创建的结点，如果是，那么它就获得了这个锁；

(4)如果序号最小的子结点不是自己创建的，那么当前索引用户进程就调用ZooKeeper的exists方法并监控ZooKeeper上目录节点列表中比自己序号小的最晚创建的有序临时节点状态；

(5)如果监视的节点状态发生变化，则跳转到步骤3，直到退出锁竞争。