HBase与时空索引技术

所谓时空数据，顾名思义，包含了两个维度的信息：空间信息与时间信息。空间信息，以地理位置点最为基础，还包括线、多边形以及更为复杂的多维结构。最典型的时空数据，莫过于移动对象的轨迹点数据，如每隔5秒钟记录的车辆实时位置信息。这类数据，在物联网领域司空见惯，在可预见的未来，这类数据将会出现爆炸性的增长。

用HBase存放时空数据

时空数据，尤其是移动对象位置点数据，结构简单，但关于吞吐量的要求却往往很高。

单从这点信息来看，这类数据属于HBase的适用范畴。

先不谈论时间纬度与复杂的多边形数据，我们先从最简单的地理位置点数据开始，探讨一下如果用HBase来存储这类数据会遭遇哪些技术挑战。

地理位置点Point中包含两个信息：经度X与纬度Y，按照传统的思路，将一个Point存成一行数据，而经度X与纬度Y则分别是构成这行数据的两个列，可以为每一个Point设置一个ID，并以此ID作为数据RowKey。所有的Points在表中按ID字典顺序存放。

围绕地理位置点的典型的查询方式，如“查询某一个建筑附近有哪些酒店？”，按照刚刚表设计思路，数据如按主键ID顺序存放，某个建筑附近的所有酒店，它们在主键顺序上却未必是相邻的，因此，这个查询可能涉及扫描大量的无关数据。

可见，针对最简单的时空数据类型，传统HBase表设计思路已经显得非常低效，传统关系型数据库基于B-Tree的数据组织结构也更是疲于应对。再放大到整个时空数据的范畴，要支持的典型场景更为复杂：

1. 查询某一个地理区域在某个历史时间范围内发生的关键事件

2. 查询某一个地理区域的人流量、车流量信息

3. 查询某一天上午先后在A，B，C三个地理区域出现过的具有某些特征的人

4. 查询某嫌疑人在某一天的行动轨迹

归根结底，HBase中的数据按照RowKey单维度排序组织，而我们现在却面临的是一个多维数据问题。因此，HBase如果想很好的支持时空数据的存储，需要引入时空索引技术。

从上面的查询场景来看，原生HBase的访问接口难以直接支持这些能力，因此，时空数据领域需要更加专业的访问接口，这是GeoMesa项目存在的关键原因。

常见的时空索引技术

关于时空索引，已经有不少常见的技术，这里，我们主要介绍一下R-Trees、Quad-Trees、K-D Trees以及Space Filling Curve这四种技术。

R-Trees

R-Trees源自论文《R-Trees: A Dynamic Index Structure For Spatial Searching》，下面的图也源自此论文：

R-Trees基于这样的思想设计：

每一个空间对象，如一个多边形区域，都存在一个最小的矩形，能够恰好包含此时空对象，如上图中的矩形R6所包含的弯月形区域。这个最小包围矩形被称之为MBR(Minimum Bounding Rectangle)。

多个相邻的矩形，可以被包含在一个更大的最小包围矩形中。如R6、R9以及R10三个矩形，可以被包含在R3中，而R11与R12则被包含在R4中。

继续迭代，总能找到若干个最大的区域，以一种树状的形式，将所有的时空对象给容纳进去，如上图中的R1, R2。这样，整个树状结构，呈现如下：

从最小的矩形区域，到最大的矩形区域，就好比地图中的行政区域划分：村 -> 县 -> 市 -> 省份。查询时，先从锁定的最大区域开始，逐级缩小比例尺后，就可找到最终的对象。如若将上图中的R1与R2理解成两个平级的”行政区域”，却又存在本质的区别：不同的行政区域，并不存在相互重叠，而R1与R2却可能是重叠的。

R-Trees的定义：

1. 每一个Leaf Node包含m到M个索引记录（Root节点除外）。

2. 每一个索引记录是一个关于(I, tuple-identifier)的二元组信息，I是空间对象的最小包围矩形，而tuple-identifier用来描述空间对象本身。

3. 每一个Non-leaf节点，包含m到M个子节点（Root节点除外）。

4. Non-leaf节点上的每一个数据元素，是一个(I, child-pointer)的二元组信息，child-pointer指向其中一个子节点，而I则是这个子节点上所有矩形的最小包围矩形。

   如上图中，R3、R4以及R5，