HBase的介绍

HBase是一个典型的非关系型的数据库(NoSQL)。它是运行在Hadoop Distributed File System上的，基于行的，提供带有容错机制的存储，能够快速访问大量的稀疏数据。它还添加了事务处理能力到Hadoop中，允许用户更新，插入和删除。它是基于Google的Big Table白皮书在Hadoop上的实现。

抽象来说，HBase是一个稀疏的，分布式的，读写一致的，多维的排序映射。它是从一组键值（Keys）到值（Value）的映射。数据单元格是按照键值的字典序来存储的。每个键值实际上由以下几部分组成：

Row Key，Column Family，Column和Timestamp

我们由Row Key, Column Family, Column和Timestamp, 就可以找到对应的Value。空值是不会被存储的，因此是稀疏型的，可以存在大量的空值而不占用空间。由于它是基于HDFS的，因此是一个分布式的数据库，并且在读写上保持了一致性。

那我们什么时候需要用到HBase呢？相对于Hadoop的批处理，HBase适合随机的实时的读写。通常可以创建非常大的表，可以有几十亿行百万列的数据。而这个只需要普通的硬件集群就可以做到。

HBase具有线性的和模块化的扩充能力。它会自动进行表的分片，在RegionServer之间进行自动的Failover，还可以结合Hadoop的Map/Reduce，Hive，Pig来进行分析。它还带有集群到集群的复制功能。

以下是我们访问的逻辑数据模型：

 

存储的时候，行与行之间是根据rowkey来进行排序的。在每一行中，取值是根据Column Family和Column Qualifier来定位的。每个值都包含有一个对应的timestamp。所以对一个值来说，它可以有多个版本，由timestamp来区分。在一个Column Family里，数据是没有任何类型和结构的。所有的Qualifier和值都是以一串任意的字节来对待的。

最简单直观的使用方式是通过HBase Shell。我们可以用以下的方式来操作一个表：

Create ‘sampletable’, ‘cf1’

我们可以用上面的命令来创建表sampletable。在创建表的时候，我们必须指定对应的ColumnFamily, 比如cf1

如果要添加行中的数据，我们可以用下面的命令：

Put ‘sampletable’, ‘row1’, ‘cf1:col1’, ‘value1’

这里我们指定了表名和Row Key (row1)，然后告诉对应的ColumnFamily(cf1)和Column Qualifier(col1)，这样就可以添加单元格对应的值value1了。

如果要读这个表，我们可以用:

Scan ‘sampletable’

它会把该表按rowkey顺序把每个单元格的内容显示出来。由于一行会包含多个单元格，因此可能需要多行来显示一个rowkey对应的内容。

那么HBase为什么会有这么好的随机读写性能呢？在它的设计理念中，参考了Log-Structured Merge Tree的实现。相对于关系型数据库经常使用的B, B+树，一个LSM树在这个基础上可以由2个或者多个树形结构组成。其中小的树形结构(c0)是完全存在于内存中，而大的树形结构(c1)是存放在磁盘上的。由于文件的写都是在结尾扩展，并且会经历长时间的大量记录的插入和删除，因此这样的基于磁盘的数据结构能够提供低花销的索引。

当数据要求写入时，数据会被首先强制写到Write Ahead Log中，这样可以保证在出现节点失败的时候可以通过Log进行恢复。当WAL写完，那么就可以更新对应的在内存中的部分。当内存填满以后，会将存储的键-值配对写到磁盘上，创建新的HFile. 那这个时候其实Log的部分就可以被丢弃了。存储的HFile都是按照类似于B树的方式组织的，不过优化为顺序磁盘访问，所有的树节点都是填充存储为单页或者多页的块。随着更多的写入，有后台的进程会对小文件进行合并，这样有几个文件就有几次寻道，因此效率很高。而对于查找来说，它先搜索内存，然后才是磁盘，所以效率也很高。由此可见，LSM树的开销是可以预见的，它基于磁盘传输速率，而避免无法确定数量的寻道。

HBase的大表是由若干个Region组成, 分布到不同的RegionServer上。每个RegionServer可以包含来自不同表的不同的Region，但一个Region只能被一个RegionServer提供服务。RegionServer一方面对Region进行管理和服务，另外一方面它与HMaster进行交互提供负载和健康状态信息，这样使得HMaster可以进行分布式的协调管理，包括失效备援，负载均衡等。客户端的请求通过Root Region Server到META Region Server查找RowKey对应的Region位置，然后请求被传到对应的Region Server进行处理 

在Region内每个ColumnFamily的数据组成一个Store, 每个Store包括一个内存部分MemStore和若干个StoreFile (HFile)。文件依靠HDFS本身的存储机制来存放，因此可以保证文件本身的高可用性和负载均衡。在HDInsight中存储转为Windows Azure Blob Storage。