HBase物理模型

标签：

HMaster

1. 为HR分配HRS，并负责HRS的负载均衡。
2. 发现失效的HRS重新分配其上的HR。
3. 管理用户对Table的增删查改操作。
4. Client访问HBase数据的过程中并不需要HMaster参与【寻址访问ZK和HRS，数据读写访问HRS】，HMaster仅仅维护者Table和HR的元数据信息，负载很低。
5. Client在修改表的结构时，需要访问HMaster。

HRegion和HRegion Server

1. 一台物理节点只能跑一个HRegion Server(HRS)，一个HRS管理多个HRegion。 
2. HRS负责切分HR：最初只有一个HR，当记录数超过某个阈值时，开始分裂成两个HR，并由HMaster分配到其他的HRS，实现负载均衡。
3. HBase表中的数据按照Row Key字典顺序排列，在行的方向上分割为多个HR，每个HR的副本分散在不同的HRS中。
4. HR虽然是分布式存储、运行的最小单元，但并不是存储的最小单元。
5. 一个HR包括一个HLog和多个Store，一个Store包含一个Mem Store(内存数据)和多个Store File(磁盘数据)， 每个Store File保存一个Columns Family，其中Store File存储在HDFS上，对应为HFile文件。

HLog日志

1. 每个HRS中都包含一个HLog文件，在用户每次操作写入Mem Store的同时，也会写一份数据到HLog中。
2. HLog存放在HDFS上，会定期回滚产生新的，并删除旧的文件（已持久化到Store File中的数据）。
3. 当HRS意外终止后，HMaster会通过ZK感知到，HMaster根据HR的不同对HLog进行拆分Split，并分配给对应的HR。领取到这些HLog的HRS在Load HRegion的过程中，发现有历史HLog需要处理，因此会“重做”Replay HLog中的数据到Mem Store中，然后Flush到Store File，完成数据恢复。

Mem Store与Store File

1. 一个HR包含多个Stroe，每个Store包含一个列族的所有数据。
2. 一个Store包括一个位于内存的Mem Store和多个位于硬盘的Store File。
3. 写操作首先写入Mem Store，当Mem Store数据量达到某个阈值，HRS会启动一个后台进程Flush到磁盘，每次Flush产生一个Store File。
4.  当Store File数量增长到一定阈值，系统会进行合并，合并过程中会进行版本合并和删除工作，形成更大的Store File。
5. 客户端检索数据时，先在Mem Store找，找不到再找Store File。

-ROOT- 和 .META. 表

1. .META.表：记录了用户表对应的HRS信息，由于.META.表太大，会被切分成多个HR，存储在不同的HRS中。
2. -ROOT-表：记录了.META.表对应的HRS信息，-ROOT-表只有一个HR。
3. ZK中保存了-ROOT-表对应的HRS位置，默认的路径是 "/hbase/root-region-server"
4. 读取数据的流程：ZooKeeper --> -ROOT-(单Region) --> .META. --> HRS --> 用户Table。

HBase物理模型

标签：

原文地址：http://www.cnblogs.com/skyl/p/4794931.html