介绍
hbase是面向列族存储的分布式数据库，基于HDFS（本文基于hbase 1.3.x）。
假如在关系型数据库中有以下数据（第一行是字段名，RowKey字段对应的是主键）：
| RowKey | Col1 | Col2 | Col3 |
|---|---|---|---|
| com.cnn.www | <html>… | CNN | John Doc |
| com.example.www | <html>… | John Doc |
把它映射到HBase表里是怎么存储的呢？往下看。。。
hbase表的逻辑视图
图中的t5、t8等代表真实的时间戳，共有三个列族：contents、author、people；
rowkey相当于关系型数据库的主键，表内唯一标识一行记录；同一个rowkey对应的列默认会保存最近的3个版本（写入时的时间戳就是版本），且按时间倒序排列；查询的时候，对于一行下的列只会返回最新版本的数据，当然也可以在查询时指定要查的版本；
真实的数据更像（但不是）下面的json，字段值为空的是不会占用空间的：
{
"com.cnn.www": {
contents: {
t6: contents:html: "<html>..."
t5: contents:html: "<html>..."
t3: contents:html: "<html>..."
}
anchor: {
t9: anchor:cnnsi.com = "CNN"
t8: anchor:my.look.ca = "CNN.com"
}
people: {}
}
"com.example.www": {
contents: {
t5: contents:html: "<html>..."
}
anchor: {}
people: {
t5: people:author: "John Doe"
}
}
}
rowkey是按照字典顺序排列的，因此可以通过设计rowkey进行遍历；
字典序对int排序的结果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,要保持整形的自然序，rowkey必须用0作左填充。（怎么做到有序？见下文）
hbase表的物理视图
列族author：
列族contents：
再看一张更直观的图：
hbase物理存储结构：
Table (hbase表)
Region (组成表的region)
Store (一个region里一个列族对应一个Store)
MemStore (每个Store里都有一个MemStore)
StoreFile (一个Store里会有多个StoreFile，在hdfs上叫HFile)
Block (一个StoreFile里有多个Block)
hbase是在hdfs上存储的，在hdfs上的真实存储目录结构：
/hbase
/data
/<Namespace>
/<Table>
/<Region>
/<ColumnFamily>
/<StoreFile>
一张hbase表最初只有一个region，如果表的数据量很少，那么很有可能所有的数据都在一个region里，随着数据量增大，单个region会逐渐分裂（超过某个阈值会触发split，有点类似于细胞分裂），由HMaster做负载均衡；一张表分成多个region，一个RegionServer上往往有多个Region，像下图这样：
hbase如何定位数据
Hbase的读操作大致分为两种：
1、通过rowkey get出一条；
2、通过scan操作来遍历（rowkey是有序的，所以遍历很高效）
那么给定一个rowkey如何快速查找到该条记录呢？
Hbase有个.meta.表，记录了每个region的startKey和endKey
结构如下：
Key：[table],[region start key],[region id]
Values：
info:regioninfo (serialized HRegionInfo instance for this region)
info:server (server:port of the RegionServer containing this region)
info:serverstartcode (start-time of the RegionServer process containing this region)
第一次查询时，先从zookeeper上拿到ROOT .META.（也就是.META.表的第一个region，这个region不会split）的位置，.META表的其他region记录了其他表的region的元数据，客户端把要访问的数据对应的region的位置信息和.META.表的位置缓存在本地；如果下一次要查询的rowkey不在这个region，则会重新查询.META.表，然后继续缓存region的位置信息，那么随着查询越来越多，客户端缓存的region的位置也就越来越多，所以这时候就几乎没必要查.META.表了，除非某region被移动；
MemStore Flush
Hbase写入数据时是先写到MemStore，当MemStore累积足够的数据时，整个有序的数据集合都会被写入（flush）到hdfs中一个新的HFile中，这个写入是顺序写入，效率高。如果这时候读取数据，hbase把查MemStore、HFile，并把两者进行合并（因为有些数据还没有flush到HFile）。
rowkey如何有序
hbase表的region会按照RowKey的字典顺序排列，因为region最初只有一个，startKey、endKey都是空的，随着数据量增大分裂为两个，一个只有endKey，另一个只有startKey，然后数据量增大会继续分裂，所以region之间是有序的；HFile内部的数据记录也是有序的，因为数据刚写入时是放在MemStore中，在MemStore保持有序，随后写入HFile中也是顺序写入的，随着HFile越来越多会有一个负责压缩的线程（关于压缩的更多细节不在本文介绍范围内）将一堆小的HFile压缩着仍然有序的大的HFile。
说了这么多废话，那么hbase到底是如何存储的呢？
Hbase的数据是放在HFile里的，上文说到HFile里有很多的Block，Block里又有很多KeyValue，KeyValue里有什么？
举个例子：假如进行两次PUT操作
Put #1: rowkey=row1, cf:attr1=value1
Put #2: rowkey=row1, cf:attr2=value2
Put #1产生的KeyValue如下:
rowlength -----------→ 4
row -----------------→ row1
columnfamilylength --→ 2
columnfamily --------→ cf
columnqualifier -----→ attr1
timestamp -----------→ timestamp
keytype -------------→ Put
Put #2产生的KeyValue如下:
rowlength -----------→ 4
row -----------------→ row1
columnfamilylength --→ 2
columnfamily --------→ cf
columnqualifier -----→ attr2
timestamp -----------→ timestamp
keytype -------------→ Put
具体HFile里除了Block还有其他内容，如下图：
hbase架构
Hbase整体有三个组件构成：
1、 HMaster节点：管理RegionServer，并负责负载均衡；管理和分配Region；接受增删改操作（不包含查）；管理namespace和hbase表的元数据；
2、 HRegionServer节点：接受读操作；读写hdfs；region分裂（split）
3、 ZooKeeper集群：存放hbase集群的元数据；实现HMaster的故障转移、active选举；
从这张图可以看出namenode、HMaster都有从节点，通过zookeeper协调，regionserver往往也是datanode，减少读写hdfs的网络开销；
最后
由于本人水平有限，文中如有错误，欢迎指正。