1. 总览
Apache HBase是一个开源的面向列的数据库。它通常被描述为一个稀疏的，一致的，分布式的，多维排序的Map。 HBase模仿Google的“Bigtable：一种分布式结构化数据存储系统”，它可以容纳数十亿行，X百万列的超大型表格。
HBase是一个no-SQL数据库，它与传统的RDBMS有着不同的范式，传统的RDBMS强调SQL以及数据之间的关系，而HBase存储的是具有键值风格的结构化和半结构化数据。 HBase中的每一行都由（Rowkey，Column Family，Column Qualifier，Version）定位。
HBase的数据存储在分布式的HDFS上，具有很高的可靠性，可扩展性和可用性，但缺点是HDFS将数据拆分成块（64MB或128MB），可以很好地处理大块数据，但对于小块数据和低延迟数据访问却不太好。换句话说，HDFS不适合在线实时读取和写入，这也就是HBase存在的意义。HBase的目标是利用分布式数据存储来实现在线实时数据访问。
2. 使用场景
图2.1 Hbase的使用场景：
Hbase的使用场景
Data random online, real time access: HBase provides block cache and index on files for real time queries.
数据随机在线，实时访问：HBase为文件提供块缓存和索引以实时查询。
3. 逻辑架构
图3.1 Hbase架构-HighLevel：
Hbase架构-HighLevel
1. 分层架构
- 客户端层：各种API
- HBase层：两个重要的组件，HMaster 和 RegionServer
- HDFS：分布式文件存储和备份
2. 主从架构
对于分布式应用程序，如何处理数据块是一个关键点。有两种典型风格：集中式和非集中式。集中式模式非常适用于可扩展性和负载平衡器，但主节点上存在单点失效（SPOF）问题和性能瓶颈。非集中模式没有SPOF问题和性能瓶颈，但负载均衡并不容易，并且存在数据一致性问题。
HBase采用集中模式：主从风格。顺便说一句，Hadoop也是主从。 Hadoop生态系统中的架构风格是一种一致的主从风格。
图3.2 Master-Slave架构：
Master-Slave架构
- HMaster：负责监控RegionServer，region分配，元数据操作，RegionServer故障转移等。在分布式集群中，HMaster在HDFS NameNode上运行。
- RegionServer：负责服务和管理region。在分布式集群中，它在HDFS DataNode上运行。
- Zookeeper：Zookeeper将跟踪RegionServer的状态，其中托管ROOT表，可以查询region在server上的分布。自HBase 0.90.x以来，它引入了与Zookeeper更紧密的集成。
3.2 Hbase的数据模型
基于列簇的数据模型：
- kv存储：表中的每个单元格都由四个维度键组成，Rowkey，Column Family，Column Qualifier，Version，表不会像RDBMS那样存储空值，非常适合于存储大型稀疏表格。
- 按键排序，只对键创建索引：row key设计是HBase Schema Design中唯一最重要的事情。
- 每个cell可以存储不同版本的数据：通过时间戳来区别不同的版本
- 列的限定符是无模式的，可以在运行时更改
- 列限定符和值按照字节码存储。
表3.1 数据模型的逻辑视图：
数据模型的逻辑视图
如表3.1中所示，列按照列簇来组织，每行都有唯一的键row key，某个row key对应的某个列的值可以有多个版本，默认通过时间戳来标识。
表3.2 数据模型的物理视图：
数据模型的物理视图
如果按照表3.1中的结构进行存储，也就是按照行存储，会保存很多null值，但是在HBase中，通过列示存储，通过kv的形式只保存非空的值。实际的物理存储中，一个表通过列簇被拆分，每个列族被保存在RegionServer的region中的HStore中。
3.3 HBase的分布式模型
在实际的分布式存储过程中，HBase的Table被拆分存储在集群中。
图3.3 Table的拆分：
Table的拆分
表被拆分成大致相同的region，分布到集群的不同的server中。
3.3.2 Region server
图3.4 Region Server的架构：
Region Server的架构
- 一个 Block Cache：用于数据读取的LRU优先级缓存。
- 一个 One WAL(Write Ahead Log)：HBase使用Log-Structured-Merge-Tree(LSM tree)来处理数据，创建索引，数据写到MemStore之前会先写入WAL，WAL会被持久化到HDFS上，这里注意一个Region Server只有一个WAL，不会为每个Table单独创建一个WAL。
- 多个HRegions：table被拆分成多个HRegions。
- 一个HRegion对应多个HStore：一个HRegion中会按照列簇被拆分成多个HStore。
- 一个HStore对应一个MemStore：数据的更改首先在MemStore中执行。
- 一个HStore对应多个StoreFile，一个StoreFile对应一个HFile：不能修改的，从MemStore中flush到HDFS上的文件。
3.3.3 -ROOT- and .META 表
数据被拆分成不同的region，查找数据的时候如何定位到正确的region上，-ROOT- and .META两个目录表就是干这件事。
- .META. 表：保存region的位置信息，region中保存了执行范围的row key的数据，.META. 表会被拆分到不同的region server中。
- -ROOT- 表：保存.META. 表的信息，-ROOT- 表只有一个，不会被拆分。
总体上讲就是：-ROOT-中保存.META.所在的服务器，.META.中保存region所在的服务器。
3.3.4 region查找
图3.6 region查找：
region查找
通过zookeeper来实现region的查找，假设需要找row T10006：
- 通过zk找到-ROOT-所在的服务器，假设找到RS1
- 到RS1上的-ROOT-找到哪个.META.包含T10006，假设找到META1 on RS2
- 到RS2的META1中查找T10006位于哪个region，假设找到Region on RS3
- 去RS3的region上找到T10006
- 如果该region存在与缓存中，优先从缓存中取
3.5 Log-Structured Merge-Trees(LSM-trees)
图3.8 B+树：
B+树
NO-SQL数据库通常使用LSM树作为数据存储过程体系结构， HBase也不例外。众所周知，RDBMS采用B树来组织其索引，如Fugure 3.8所示。这些B树通常是3级n向平衡树。 B+树的节点是磁盘上的块，所以对于RDBMS的更新，它可能需要5倍的磁盘操作（B+树查找目标行块1次，目标块读取1次，数据更新1次）。B+树非常适合读取数据，但对数据更新效率不高。考虑到大量的分布式数据，到目前为止，B树并不是LSM树的竞争对手。
图3.9 LSM树的合并：
LSM树的合并
LSM树可以被看作n级合并树。它使用日志文件和内存存储将随机写入转换为顺序写入。图3.9显示了LSM-tree的数据写入过程。
首先将数据顺序写入日志文件，然后写入内存中，数据组织为排序树，如B+树。当内存中的存储已满时，内存中的树将被刷新到磁盘上的存储文件。磁盘上的存储文件像B+树一样排列，如图3.9所示的C1树。但是存储文件针对顺序磁盘访问进行了优化。
LSM-tree的数据更新在内存中运行，不需要磁盘访问，它比B+树更快。当数据读取总是在最近写入的数据集上时，LSM树将减少磁盘搜索并提高性能。当磁盘IO是我们必须考虑的成本时，LSM树比B+树更合适。
