hbase 结构及工作过程
最近关注 Hadoop ，因此 也顺便关注了一下 Hadoop相关的项目 。 HBASE就是基于 Hadoop的一个开源项目，也是对 Google的 BigTable的一种实现。
BigTable是什么？ Google的 Paper对其作了充分的说明。字面上看就是一张大表，其实和我们想象的传统数据 库的表还是有些差别的。松散数据可以说是介于 Map Entry（ key & value）和 DB Row之间的一种数据。在我使用 Memcache的时候，有时候的需求是需要存储的不仅仅是简单的一个 key对应一个 value，可能我需要类似于数据库表结构中多属性的存储，但是又不会有传统数据库表结构中那么多关联关系的需求，其实这类数据就是所谓的 松散数据。 BigTable最浅显来看就是一张很大的表，表的属性可以根据需求去动态增加，但是又没有 表与表之间关联查询的需求。
互联网应用有一个最大的特点，就是速度，功能再强大，速度慢，还是会被舍弃。因此在大访问量的网站都采 取前后的缓存来提升性能 和响应时间。对于 Map Entry类型的数据，集中式分布式 Cache都有很多选择，对于传统的关系型数据，从 MySQL 到 Oracle都给了很好的支持，唯有松散数据这类数据，采用前后两种解决方案都不能最大化它的处理能力。因此 BigTable才有了它用武之地。
HBASE作为 Apache的开源项目，也是出于起 步阶段，因为其实它所依赖的 Hadoop也不能说已经到了成熟阶段，所以都有很大的发展空间，这也为我 们这些开源爱好者提供了更多空间去贡献。这里主要会谈到 HBASE的框架设计方面的知识和它的一些特 点，不论是否采用 HBASE去解决工作中的问题 ，一种好的流程设计总会给开发者和架构 设计者带来一些思想上的火花。 HBASE 设计介绍 数据模型
HBASE中的每一张表，就是所谓的 BigTable。 BigTable会存储一系列的行记录，行记录有三个基本类型的定义： Row Key,Time Stamp,Column。 Row Key是行在 BigTable中的唯一标识， Time Stamp是每次数据操作对应关联的时间戳，可以看作 类似于 SVN的版本， Column定义为： <family>:<label>，通过这两部分可以唯一的指定一个数据的存储列， family的定义和修改需 要对 HBASE作类似于 DB的 DDL操作，而对于 label的使用，则不需要定义直接可以使用，这也为动态定制列 提供了一种手段。 family另一个作用其实在于物理存储优化读写操作，同 family的数据物理上保存的会比较临近，因此在业务设计的过程中可以利用这个特性。
看一下逻辑数据模型：
| Row Key |
Time Stamp |
Column "contents:" |
Column "anchor:" |
Column "mime:" |
|
| "com.cnn.www" |
t9 |
"anchor:cnnsi.com" |
"CNN" |
||
| t8 |
"anchor:my.look.ca" |
"CNN.com" |
|||
| t6 |
"<html>..." |
"text/html" |
|||
| t5 |
"<html>..." |
||||
| t3 |
"<html>..." |
上表中有一列，列的唯一标识为 com.cnn.www，每一次逻辑修改都有一个 timestamp关联对应，一共有四个列定义： <contents:>,<anchor:cnnsi.com>,<anchor:my.look.ca>,<mime:>。如果用传统的概念来将 BigTable作解释，那么 BigTable可以看作一个 DB Schema，每一个 Row就是一个表， Row key就是表名，这个表根据列的不同可以划分为多个版本， 同时每个版本的操作都会有时间戳关联到操作的行。
再看一下 HBASE的物理数据模型：
| Row Key |
Time Stamp |
Column "contents:" |
| "com.cnn.www" |
t6 |
"<html>..." |
| t5 |
"<html>..." |
|
| t3 |
"<html>..." |
| Row Key |
Time Stamp |
Column "anchor:" |
|
| "com.cnn.www" |
t9 |
"anchor:cnnsi.com" |
"CNN" |
| t8 |
"anchor:my.look.ca" |
"CNN.com" |
| Row Key |
Time Stamp |
Column "mime:" |
| "com.cnn.www" |
t6 |
"text/html" |
物理数据模型其实就是将逻辑模型中的一个 Row分割成为根据 Column family存储的物理模型。
对于 BigTable的数据模型操作的时候，会锁定 Row，并保证 Row的原子操作。 框架结构及流程
图 1 框架结构图
HBASE依托于 Hadoop的 HDFS作为存储基础 ，因此结构也很类似于 Hadoop的 Master-Slave模式， Hbase Master Server 负责管理所有的 HRegion Server，但 Hbase Master Server本身并不存储 HBASE中的任何数 据。 HBASE逻辑上的 Table被定义成为一个 Region存储在某一台 HRegion Server上， HRegion Server 与 Region的对应关系是一对多的关系。每一个 HRegion在物理上会被分为三个部分： Hmemcache、 Hlog、 HStore，分别代表了缓存，日志，持久层。通过一次更新流程来看一下这 三部分的作用：
图 2 提交更新以及刷新 Cache 流程
由流程可以看出，提交更新操作将会写入到两部分实体中， HMemcache和 Hlog中， HMemcache就是为了提高效率在内存中建立缓存，保证了部分最近操 作过的数据能够快速的被读取和修改， Hlog是作为同步 Hmemcache和 Hstore的事务日志，在 HRegion Server周期性的发起 Flush Cache命令的时候，就会将 Hmemcache中的数据持久化到 Hstore中，同时会清空 Hmemecache中的数据，这里采用的是比较简单的策略来做数据缓存和同步，复杂一些其实可以参照 java的垃圾收集机制来做。
在读取 Region信息的时候，优先读取 HMemcache中的内容，如果未取到再去读取 Hstore中的数据。
几个细节：
1．
由于每一次 Flash Cache，就会产生一个 Hstore File，在 Hstore中存储的文件会越来越多，对性能也会产 生一定影响，因此达到设置文件数量阀值的时候就会 Merge这些文件为一个大文件。
2．
Cache大小的设置以及 flush的时间间隔设置需要考虑内存消 耗以及对性能的影响。
3．
HRegion Server每次重新启动的时候会将 Hlog中没 有被 Flush到 Hstore中的数据再次载入到 Hmemcache，因此 Hmemcache过大对于启动的速度也有直接影响。
4．
Hstore File中存储数据采用 B-tree的算法，因此也 支持了前面提到对于 Column同 Family数据 操作的快速定位获取。
5．
HRegion可以 Merge也可以被 Split，根据 HRegion的大小决定。不过在做这些操作的时候 HRegion都会被锁定不可使用。
6．
Hbase Master Server通过 Meta-info Table来获取 HRegion Server的信息以及 Region的信息， Meta最顶部的一个 Region是虚拟的一个叫做 Root Region，通过 Root Region可以找到下面各个实际的 Region。
7．
客户端 通过 Hbase Master Server获得了 Region所在的 Region Server，然后就直接和 Region Server进行交 互，而对于 Region Server相互之间不通信，只和 Hbase Master Server交互，受到 Master Server的监控和管理。
对 HBase 还没有怎 么使用，仅仅只是看了 wiki去了解了一下结构和作用，暂时还没有需要使用的场景，不过对于各种开源项 目的设计有所了解，对自己的框架结构设计也会有很多帮助，因此分享 一下。