指南上这一章的开篇即提出：HBase是一个分布式的、面向列的开源数据库。如果需要实时的随机读/写超大规模数据集，HBase无疑是一个好的选择。
简介
HBase 是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用 HBase 技术可在廉价 PC Server 上搭建起大规模结构化存储集群。
HBase 的目标是存储并处理大型的数据，更具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。
HBase 是 Google Bigtable 的开源实现，但是也有很多不同之处。比如：Google Bigtable利用 GFS 作为其文件存储系统，HBase 利用 Hadoop HDFS 作为其文件存储系统；Google运行 MapReduce 来处理 Bigtable 中的海量数据，HBase 同样利用 Hadoop MapReduce 来处理 HBase 中的海量数据；Google Bigtable 利用 Chubby 作为协同服务，HBase 利用 Zookeeper作为对应。
HBase 位于结构化存储层，Hadoop HDFS 为 HBase 提供了高可靠性的底层存储支持，Hadoop MapReduce 为 HBase 提供了高性能的计算能力，Zookeeper 为 HBase 提供了稳定服务和 failover 机制。 此外，Pig 和 Hive 还为 HBase 提供了高层语言支持，使得在 HBase 上进行数据统计处理变的非常简单。 Sqoop 则为 HBase 提供了方便的 RDBMS 数据导入功能，使得传统数据库数据向 HBase 中迁移变的非常方便。
另外，HBase 存储的是松散型数据。具体来说，HBase 存储的数据介于映射（key/value）和关系型数据之间。进一步讲，HBase 存储的数据可以理解为一种 key 和 value 的映射关系，但又不是简简单单的映射关系。除此之外它还有许多其他的特性。HBase 存储的数据从逻辑上来看就像一张很大的表，并且它的数据列可以根据需要动态增加。除此之外，每个 cell（由行和列所确定的位置）中的数据又可以具有多个版本（通过时间戳来区别）。
数据模型
1、Row Key: 行键，Table的主键，Table中的记录按照Row Key排序
2、Timestamp: 时间戳，每次数据操作对应的时间戳，可以看作是数据的version number
3、Column Family：列簇，Table在水平方向有一个或者多个Column Family组成，一个Column Family中可以有任意多个Column组成，即Column Family支持动态扩展，无需预先定义Column的数量以及类型，所有Column均以二进制格式存储，用户需要自行进行类型转换。
|
Row Key |
Time Stamp |
Column Contents |
Column Anchor |
Column “mime” |
|
|
cnnsi.com |
my.look.ca |
||||
|
“com.cnn.www” |
T9 |
CNN |
|||
|
T8 |
CNN.COM |
||||
|
T6 |
“<html>.. “ |
Text/html |
|||
|
T5 |
“<html>.. “ |
||||
|
t3 |
“<html>.. “ |
|
|||
物理存储
Table 在行的方向上分割为多个HRegion，一个region由[startkey,endkey)表示，每个HRegion分散在不同的RegionServer中
架构体系
1、Client
包含访问hbase 的接口，client 维护着一些cache 来加快对hbase 的访问，比如regione 的位置信息
2、Zookeeper
保证任何时候，集群中只有一个running master
存贮所有Region 的寻址入口
实时监控Region Server 的状态，将Region server 的上线和下线信息，实时通知给Master
存储Hbase 的schema,包括有哪些table，每个table 有哪些column family
3、Master
可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行
为Region server 分配region
负责region server 的负载均衡
发现失效的region server 并重新分配其上的region
4、Region Server
维护Master 分配给它的region，处理对这些region 的IO 请求
负责切分在运行过程中变得过大的region
可以看出，client 访问hbase 上数据的过程并不需要master 参与，寻址访问zookeeper 和region server，数据读写访问regioneserver，master仅仅维护着table 和region 的元数据信息，负载很低。HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。
HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个Column Family的存储，可以看出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family中，这样最高效。
HStore存储是HBase存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。下图描述了Compaction和Split的过程：
在理解了上述HStore的基本原理后，还必须了解一下HLog的功能，因为上述的HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，因此一旦HRegionServer意外退出，MemStore中的内存数据将会丢失，这就需要引入HLog了。每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中（HLog文件格式见后续），HLog文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的 HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的region重新分配，领取 到这些region的HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。