本文介绍hbase的两个典型应用实例OpenTSDB和地理信息系统
学习一种技术最好的办法就是了解一个正在使用的应用系统是如何应用这种技术来解决问题的。其中开源的OPenTSDB数据监控系统就是应用hbase解决数据存储的。同时hbase还能很好的应对地理信息系统（GIS）中的两个挑战：大规模数据处理的延迟和空间位置建模。
1 hbase上查询地理信息系统
地理信息系统常作为在线交互用户体验的基础使用，如基于位置的服务。 对应GIS系统的两大挑战，hbase是一个在线系统可以很好地解决大数据延迟，对应空间位置建模以下重点介绍。 地球数据最简单的形式就是地球上的一个点，由经度和纬度组成。当我们查询数据是我们必须返回同一地点附近的信息，并且返回的数据越少越好，这样可以减少传输数据。GIS使用专门的空间索引来应对数据组织问题。并且我们将使用这种索引作为以下两种查询的基础，第一种查询，k个最近邻，第二种多边形区域内查询。 下面使用一个例子慢慢讲解如何建立索引： 假如你在纽约市，需要接入互联网，哪里有最近的wifi热点呢？ 为了完成这个问题我们需要快速访问到数据的相关子集，我们可以从如下两个目标开始。 1 我们希望在空间里彼此接近的点在硬盘上的存储位置点也彼此相近。 2我们希望响应查询时返回尽可能少的点。 下面给出如下的位置数据： 
geohash（地理散列）算法是一种把几个值转换为一个值的算法。下面介绍这个算法 下面以(39.92324, 116.3906)为例，介绍一下geohash的编码算法。首先将纬度范围(-90, 90)平分成两个区间(-90, 0)、(0, 90)，如果目标纬度位于前一个区间，则编码为0，否则编码为1。由于39.92324属于(0, 90)，所以取编码为1。然后再将(0, 90)分成 (0, 45), (45, 90)两个区间，而39.92324位于(0, 45)，所以编码为0。以此类推，直到精度符合要求为止，得到纬度编码为1011 1000 1100 0111 1001。
| 纬度范围 | 划分区间0 | 划分区间1 | 39.92324所属区间 |
| (-90, 90) | (-90, 0.0) | (0.0, 90) | 1 |
| (0.0, 90) | (0.0, 45.0) | (45.0, 90) | 0 |
| (0.0, 45.0) | (0.0, 22.5) | (22.5, 45.0) | 1 |
| (22.5, 45.0) | (22.5, 33.75) | (33.75, 45.0) | 1 |
| (33.75, 45.0) | (33.75, 39.375) | (39.375, 45.0) | 1 |
| (39.375, 45.0) | (39.375, 42.1875) | (42.1875, 45.0) | 0 |
| (39.375, 42.1875) | (39.375, 40.7812) | (40.7812, 42.1875) | 0 |
| (39.375, 40.7812) | (39.375, 40.0781) | (40.0781, 40.7812) | 0 |
| (39.375, 40.0781) | (39.375, 39.7265) | (39.7265, 40.0781) | 1 |
| (39.7265, 40.0781) | (39.7265, 39.9023) | (39.9023, 40.0781) | 1 |
| (39.9023, 40.0781) | (39.9023, 39.9902) | (39.9902, 40.0781) | 0 |
| (39.9023, 39.9902) | (39.9023, 39.9462) | (39.9462, 39.9902) | 0 |
| (39.9023, 39.9462) | (39.9023, 39.9243) | (39.9243, 39.9462) | 0 |
| (39.9023, 39.9243) | (39.9023, 39.9133) | (39.9133, 39.9243) | 1 |
| (39.9133, 39.9243) | (39.9133, 39.9188) | (39.9188, 39.9243) | 1 |
| (39.9188, 39.9243) | (39.9188, 39.9215) | (39.9215, 39.9243) | 1 |
经度也用同样的算法，对(-180, 180)依次细分，得到116.3906的编码为1101 0010 1100 0100 0100。
| 经度范围 | 划分区间0 | 划分区间1 | 116.3906所属区间 |
| (-180, 180) | (-180, 0.0) | (0.0, 180) | 1 |
| (0.0, 180) | (0.0, 90.0) | (90.0, 180) | 1 |
| (90.0, 180) | (90.0, 135.0) | (135.0, 180) | 0 |
| (90.0, 135.0) | (90.0, 112.5) | (112.5, 135.0) | 1 |
| (112.5, 135.0) | (112.5, 123.75) | (123.75, 135.0) | 0 |
| (112.5, 123.75) | (112.5, 118.125) | (118.125, 123.75) | 0 |
| (112.5, 118.125) | (112.5, 115.312) | (115.312, 118.125) | 1 |
| (115.312, 118.125) | (115.312, 116.718) | (116.718, 118.125) | 0 |
| (115.312, 116.718) | (115.312, 116.015) | (116.015, 116.718) | 1 |
| (116.015, 116.718) | (116.015, 116.367) | (116.367, 116.718) | 1 |
| (116.367, 116.718) | (116.367, 116.542) | (116.542, 116.718) | 0 |
| (116.367, 116.542) | (116.367, 116.455) | (116.455, 116.542) | 0 |
| (116.367, 116.455) | (116.367, 116.411) | (116.411, 116.455) | 0 |
| (116.367, 116.411) | (116.367, 116.389) | (116.389, 116.411) | 1 |
| (116.389, 116.411) | (116.389, 116.400) | (116.400, 116.411) | 0 |
| (116.389, 116.400) | (116.389, 116.394) | (116.394, 116.400) | 0 |
接下来将经度和纬度的编码合并，奇数位是纬度，偶数位是经度，得到编码 11100 11101 00100 01111 00000 01101 01011 00001。
最后，用0-9、b-z（去掉a, i, l, o）这32个字母进行base32编码，得到(39.92324, 116.3906)的编码为wx4g0ec1。
| 十进制 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| base32 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | b | c | d | e | f | g |
| 十进制 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| base32 | h | j | k | m | n | p | q | r | s | t | u | v | w | x | y | z |
解码算法与编码算法相反，先进行base32解码，然后分离出经纬度，最后根据二进制编码对经纬度范围进行细分即可，这里不再赘述。不过由于geohash表示的是区间，编码越长越精确，但不可能解码出完全一致的地址。
用途 & 缺点：
geohash的最大用途就是附近地址搜索了。不过，从geohash的编码算法中可以看出它的一个缺点：位于格子边界两侧的两点，虽然十分接近，但编码会完全不同。实际应用中，可以同时搜索当前格子周围的8个格子，即可解决这个问题。
因此根据geohash计算的到的值作为行健是最佳的选择。如果使用一个库计算出每个节点的geohash，并且添加到数据中，则原来的数据变化成如下
有计算出的数据可看地点越是相近，前边相同的数字个数就多，因此我们使用geohash算法计算的结果作为行健存储在hbase中，就可以把地点相近的点存储在物理相近处。具体实现k近邻的查询，和如何使用过滤器（filter）和协处理器（coprocessor）把计算工作推往RegionServer不做介绍。
2 OpenTSDB
OpenTSDB是一种基于Hbase来构建的分布式的，可拓展的时间序列数据库，OpenTSDB可以用来处理一种通用需求：存储、索引和服务于从大规模计算机系统（网络设备、操作系统、应用程序）采集来的监控指标数据并且使这些数据易于访问和可视化。从根本上OpenTSDB是一种在线数据可视化工具。 基础设施监控，需要监控的项目很多，包括，每秒服务的请求数、并发活跃用户数、数据库读写、平均响应延迟、进程占用内存等。每一个数据都是一个特定监控指标的时间序列检查结果，只提供了整个系统运行视图的一小部分快照，在一段时间窗口里把这些检测结果收集起来，就拥有了一个系统运行的视图。 OpenTSDB必须能够从大量系统里收集各种监控指标，还必须支持对监控指标的在线查询。hbase具有可拓展的数据存储能力和支持低延迟的查询，同时hbase是一种通用的具有灵活数据模型的数据存储，它支持OpenTSDB设计一种高效的、相对可定制的模式来存储数据，因此OpenTSDB采用了hbase数据库存储数据。
一下一系列的内容展示的是OpenTSDB中hbase设计模式和OpenTSDB的架构设计（住：拍自hbase一书）
