HBase源码分析（向我的师傅致敬）

     HBase是构建在Hadoop软件簇之上的数据库软件。它的目的是解决针对大数据随机、实时读写访问的问题，面临的环境是需要处理总计十亿级数目的行*百万级数目的列的大表集合。其理论基础来自Google的贡献：Bigtable: A Distributed Storage System for Structured Data。然后今年大家有福了，在六月份的SIGMOD’11上HBase的开发者Facebook发表了论文：Apache Hadoop Goes Realtime at Facebook（工业界的成果很少能上这么学术的会议）。
    其实，HBase下面的HDFS也提供对大数据处理和访问，但是HDFS中数据访问的特性却和Hbase完全相反——顺序、批处理类型的访问。HDFS是通过存储大文件来极大地减少磁盘磁臂寻道时间（这正是磁盘时间开销的大头），从而增大了数据访问的吞吐率；而HBase往往面临小文件的问题。正所谓巧妇难为无米之炊，你给俺糙米，还敢叫老娘做糯米糍粑！而HBase正需要从HDFS中获得数据，调和这两种南辕北辙的存取方式貌似是不可能的。但是神奇的事情发生了，HBase在HDFS上工作得很high。我承认我乱了。。。因此，本次就好好分析Google和Facebook的那两篇文章，以期找到相关的线索。
    Bigtable: A Distributed Storage System for Structured Data一文讨论了“简单数据模型”和Bigtable的设计：
简单数据模型
    Bigtable是一个稀疏、多维的有序map，这个map的索引由行key、列key和时间戳共同组成。Map中的每个value都是未经处理过的序列。
行
    map的每一行有行key，它可以是小于64KB的任意字符串。这些key基本是以字典序排列。一个大表的数据按照一定的行key范围进行分割，分割的结果是从一个table得到多个tablet，这些tablet分布地存储在不同的机器上。那么，用户为了访问需要的数据不可避免地要从多个机器上进行读操作。从效率角度考虑，一次操作需访问的机器数越少越好，这就需要对行key作一些处理，使相关度高的key尽量落在同一个行key范围中。比如文章中举例，对于一个存Web页面的table，同一个国际顶级域名下的网页相关度高，其中同一域名下的网页相关度也比较高，因此先按顶级域名分割，再按域名分割就是很好的分区方法。这样就把类似maps.google.com/index.html处理成com.google.maps/index.html当作行key。
    每一行是一次读/写原子操作的单元，每个tablet是分布存储和负载均衡操作的单元。
列簇
     Bigtable每列拥有一个列key，按照需求将一些列key组合在一起称为列簇。当有数据要存入列中时，要预先建立该列所在的列簇。每个列簇中的列key以family:qualifier进行表示（其中，family必须是可打印字符，qualifier可以是任意字符串）。属于一个列簇的列中的value都是同样类型的，便于压缩。
     列簇是访问控制和磁盘/内存存取的单元。
时间戳
     每个value中存储着同样数据的多个版本，每个版本由时间戳来索引。这个时间戳可以由管理Bigtable的软件来设置，也可由发起访问的客户端程序来定义。
     在同一时间内一份数据能保存的版本数是有限制的，因为当数据拥有的版本数超过了预设的阈值时，Bigtable会自动地定期垃圾回收最久的几个版本的数据。
Bigtable
     Bigtable的实现分三部分：a.供客户端连接Bigtable进行相关操作的函数库；b.master server；c.tablet server。master负责table分片tablet的分发，管理tablet server的添加和移除以及平衡tablet server负载，垃圾回收过期的数据。tablet server管理一定数量的tablet，客户端对tablet的操作请求都是由tablet server来处理，即客户端的数据不会经由master server。这样极大地减轻master的负担，对于一个单主节点的分布式存储系统来说，是非常有效的。
tablet层次结构
                                                      [METADATA tablet]-->[UserTable1]
[Chubby file]-->[Root tablet]-->|METADATA tablet|-->[UserTable2]
            (第一个元数据tablet)         |METADATA tablet|-->[...............]     
                                                      [METADATA tablet]-->[UserTableN]
    tablet的层次结构类似3层B+树。当然，要找到这个结构需要从维护Bigtable的Chubby集群里找到root tablet，它是B+树的根。root tablet包含其它所有METADATA tablet的地址，其实它和其它METADATA tablet存放在一起，可以算作第一个METADATA tablet，区别是处理方式不同（作为B+根节点），而且是无法分割的。
    位于B+树的的二层是METADATA tablet，它包括真正存放数据的tablet地址，这些地址的索引是由对应tablet所在table标识符和该tablet最后一行数据的编码而成。
    B+树的第三层就是访问的数据。
    客户端会缓存METADATA tablet，在命中的情况下，tablet的位置信息可以直接从内存中获得，而无需访问底层文件系统。
tablet分配策略
   
提供tablet服务
   
tablet数据封装  
    再来看看另一篇热乎乎的文章。Apache Hadoop Goes Realtime at Facebook一文主要描述了。

提供：
1.类图；
2.顺序图
3.时序图