Hbase系统架构

典型Hbase Table 表

　  

Row Key (行键)

　　Row Key 用来检索记录的主键。访问 HBase Table 中的数据，只有以下三种方式：

• 通过指定的 Row Key 进行访问；

• 通过 Row Key 的 range 进行访问，即访问指定范围内的行；

• 进行全表扫描。

　　Row Key 可以是任意字符串，存储时数据按照 Row Key 的字典序进行排序。需要注意以下两点：

• 因为字典序对 Int 排序的结果是 1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。如果使用整型的字符串作为行键，为了保持整型的自然序，行键必须用 0 作左填充。

• 行的一次读写操作时原子性的 (不论一次读写多少列)。

Column Family（列族）

　　HBase 表中的每个列，都归属于某个列族。列族是表的 Schema 的一部分，列族需要在创建表时进行定义。列族的所有列都以列族名作为前缀，例如 courses:history，courses:math 都属于 courses 这个列族。

Column Qualifier (列限定符)

　　列限定符，具体的列名，例如 courses:history，courses:math 都属于 courses 这个列族，列限定符分别是 history 和 math。注意的是列限定符不是表 Schema 的一部分，在插入数据的过程中动态创建列。

Column(列)

　　HBase 中的列由列族和列限定符组成，由 :(冒号) 进行分隔，即一个完整的列名应该表述为 列族名:列限定符。

Cell

　　Cell 是行，列族和列限定符组合，包含值和时间戳。可以等价理解为关系型数据库中由指定行和指定列确定的一个单元格，但不同的是 HBase 中的一个单元格是由多个版本的数据组成的，每个版本数据用时间戳进行区分。

Timestamp(时间戳)

　　HBase 中通过 row key 和 column 确定的为一个存储单元称为 Cell。每个 Cell 都保存着同一份数据的多个版本。版本通过时间戳来索引，时间戳的类型是 64 位整型，时间戳可以由 HBase 在数据写入时自动赋值，也可以由客户显式指定。每个 Cell 中，不同版本的数据按照时间戳倒序排列，即最新的数据排在最前面。

存储结构

Regions

　　HBase Table 中所有行按照 Row Key 的字典序排列。HBase Tables 通过行键的范围 (row key range) 被水平切分成多个 Region, 一个 Region 包含了在 start key 和 end key 之间的所有行。

　　

 　　每个表一开始只有一个 Region，随着数据不断增加，Region 会不断增大，当增大到一个阀值的时候，Region 就会等分为两个新的 Region。当 Table 中的行不断增多，就会有越来越多的 Region。

　　 

 　　 Region 是 HBase 中分布式存储和负载均衡的最小单元。不同的 Region 可以分布在不同的 Region Server 上。但一个 Region 是不会拆分到多个 Server 上的。

　　  

Region Server

　　Region Server 运行在 HDFS 的 DataNode 上。具有以下组件：

• WAL(Write Ahead Log，预写日志)：用于存储尚未进持久化存储的数据记录，以便在发生故障时进行恢复。
• BlockCache：读缓存。将频繁读取的数据存储在内存中，如果存储不足，它将按照 最近最少使用原则 清除多余的数据。
• MemStore：写缓存。它存储尚未写入磁盘的新数据，并会在数据写入磁盘之前对其进行排序。每个 Region 上的每个列族都有一个 MemStore。
• HFile ：将行数据按照 Key\Values 的形式存储在文件系统上。

 　　

 　　Region Server 存取一个子表时，会创建一个 Region 对象，然后对表的每个列族创建一个 Store 实例，每个 Store 会有 0 个或多个 StoreFile 与之对应，每个 StoreFile 则对应一个 HFile，HFile 就是实际存储在 HDFS 上的文件。

　　

系统架构

　　HBase 系统遵循 Master/Salve 架构，由三种不同类型的组件组成：

       

Zookeeper

1. 保证任何时候，集群中只有一个 Master；

2. 存贮所有 Region 的寻址入口；

3. 实时监控 Region Server 的状态，将 Region Server 的上线和下线信息实时通知给 Master；

4. 存储 HBase 的 Schema，包括有哪些 Table，每个 Table 有哪些 Column Family 等信息。

Master

1. 为 Region Server 分配 Region ；

2. 负责 Region Server 的负载均衡 ；

3. 发现失效的 Region Server 并重新分配其上的 Region；

4. GFS 上的垃圾文件回收；

5. 处理 Schema 的更新请求。

6. 对于表的DDL操作：create，delete，alter

Region Server

1. Region Server 负责维护 Master 分配给它的 Region ，并处理发送到 Region 上的 IO 请求；

2. Region Server 负责切分在运行过程中变得过大的 Region。

WAL

　　由于数据要经MemStore排序后才能刷写到HFile，但把数据保存在内存中会有很高的概率导致数据丢失，为了解决这个问题，数据会先写入Write-Ahead logfile的文件中，然后再写入到Memstore中。
　　所以在系统出现故障的时候，数据可以通过这个日志文件重建。

MemStore

　　写缓存，由于HFile中的数据要求是有序的，所以数据是先存储在MemStore中，排好序后，等到达刷写时机才会刷写到HFile，每次刷写都会形成一个新的HFile。

StoreFile

　　保存实际数据的物理文件，StoreFile以HFile的形式存储在HDFS上。每个Store会有一个或多个StoreFile(HFile)，数据在StoreFile上是有序的。

　　  

组件间的协作

　　HBase 使用 ZooKeeper 作为分布式协调服务来维护集群中的服务器状态。 Zookeeper 负责维护可用服务列表，并提供服务故障通知等服务：

• 每个 Region Server 都会在 ZooKeeper 上创建一个临时节点，Master 通过 Zookeeper 的 Watcher 机制对节点进行监控，可以发现新加入的 Region Server 或故障退出的 Region Server；

• 所有 Masters 会竞争性地在 Zookeeper 上创建同一个临时节点，由于 Zookeeper 只能有一个同名节点，必然只有一个 Master 能够创建成功，此时该 Master 就是主 Master，主 Master 会定期向 Zookeeper 发送心跳。备用 Masters 则通过 Watcher 机制对主 HMaster 所在节点进行监听；

• 如果主 Master 未能定时发送心跳，则其持有的 Zookeeper 会话会过期，相应的临时节点也会被删除，这会触发定义在该节点上的 Watcher 事件，使得备用的 Master Servers 得到通知。所有备用的 Master Servers 在接到通知后，会再次去竞争性地创建临时节点，完成主 Master 的选举。

　　

读取数据的流程

　　

1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。
2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。
  并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
3）与目标 Region Server 进行通讯；
4）分别在 Block Cache（读缓存），MemStore 和 Store File（HFile）中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）。
5）将从文件中查询到的数据块（Block，HFile 数据存储单元，默认大小为 64KB）缓存到Block Cache。
6）将合并后的最终结果返回给客户端。

　　注：META 表是 HBase 中一张特殊的表，它保存了所有 Region 的位置信息，META 表自己的位置信息则存储在 ZooKeeper 上。

　　

写入数据的流程

         

1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。 #zk   get /hbase/meta-region-server
2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。
　　并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。  #hbase scan 'hbase:meta'  查询到具体哪张表由哪个Region Server维护
3）与目标 Region Server 进行通讯；
4）将数据顺序写入（追加）到 WAL；
5）将数据写入对应的 MemStore，数据会在 MemStore 进行排序；
6）向客户端发送 ack；
7）等达到 MemStore 的刷写时机后，将数据刷写到 HFile。

MemStore刷写时机

　　

 

1.当某个MemStore大小达到hbase.hregion.memstore.flush.size（默认值 128M），其所在 region 的所有 memstore (对应的列簇)都会刷写。
　　当达到128M的时候会触发flush memstore，当达到128M * n还没法触发flush时候会抛异常来拒绝写入。两个相关参数的默认值如下：
　　hbase.hregion.memstore.flush.size=128M(默认)
　　hbase.hregion.memstore.block.multiplier=4(默认)
2.当 region server 中 memstore 的总大小达到
    java_heapsize(应用的堆内存)
　　　　*hbase.regionserver.global.memstore.size（默认值 0.4） 
　　　　*hbase.regionserver.global.memstore.size.lower.limit（默认值 0.95），
　　region 会按照其所有 memstore 的大小顺序（由大到小）依次进行刷写。直到 region server中所有 memstore 的总大小减小到上述值以下。
   当 region server 中 memstore 的总大小达到java_heapsize*hbase.regionserver.global.memstore.size（默认值 0.4）时，会阻止继续往所有的 memstore 写数据。
3.到达自动刷写的时间，也会触发 memstore flush。自动刷新的时间间隔由该属性进行配置 hbase.regionserver.optionalcacheflushinterval（默认 1 小时）。
4.当 WAL 文件的数量超过 hbase.regionserver.maxlogs，region 会按照时间顺序依次进行刷写，直到 WAL 文件数量减小到 hbase.regionserver.maxlogs 以下（该属性名已经废弃，现无需手动设置，最大值为 32）。

StoreFile Compaction

　

　  由于memstore每次刷写都会生成一个新的HFile，且同一个字段的不同版本(timestamp)和不同类型(Put/Delete)有可能分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile的个数，以及清除掉过期和删除的数据，会进行StoreFile Compaction。

　　Compaction分为两种，分别时Minor Compaction和Major Compaction。Minor Compaction会将临时的若干较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据。Major Compaction会将一个Store下的所有HFile合并为一个大HFile，并且会清理掉过期和删除的数据。

Region Split

　　

HMaster 容错
　　HMaster 配置HA，利用 Zookeeper 重新选择新的 HMaster，并且 HMaster 宕机的情况，数据仍然可以读取，但是无法进行负载均衡和 Region 切分等操作。

HRegionServer 容错
　　RegionServer 如果出现宕机，HMaster 会通过 Zookeeper 监听到，重新分配 RS 上的 Region，同时将宕机RS的 WAL 进行分割，有新的 RS 读取恢复数据。RS上的 Region 迁移的代价并不大，一般都在毫秒级别完成，所以对应用造成的影响也很有限。

Zookeeper 容错
　　作为协调者的 Zookeper 本身就是就是一个可靠的分布式服务，一般会配置3到5个实例。

HDFS 容错
　　底层存储依赖于 HDFS，数据对 HDFS 透明，设置有多副本冗余。HDFS 本身是稳定可靠的分布式存储系统。