第八章 Hbase专题之架构设计详述（图解）

1、Hbase0.96系统架构

系统架构示意图如下：即程序走数据

（1）Client客户端

①Hbase有两张特殊的表

.META.：记录了用户所有表拆分出来的的Region映射信息，.META.可以有多个Regoin
-ROOT-：记录了**.META.表的Region信息**，-ROOT-只有一个Region，无论如何不会分裂
注意事项：Hbase2.x架构将两个表文件合并成为一个，存在多个·Regin上

②数据访问逻辑

Client访问用户数据前需要首先访问ZooKeeper，找到-ROOT-表的Region所在的服务器位置，
然后访问-ROOT-表，
接着访问.META.表，最后才能找到用户数据的服务器位置去访问，
注意事项：中间需要多次网络操作，不过client端会做cache缓存。

（2）Zookeeper职责

①存储信息：存储所有Region的寻址入口：-ROOT-表在哪台服务器上，即-ROOT-这张表的位置信息。

②监控状态：实时监控RegionServer的状态，将RegionServer的上线和下线信息实时通知给Master

③存储Schema：存储HBase的Schema，包括有哪些Table，每个Table有哪些Column Family

④高可可用支撑：为HBase提供Failover机制，选举Master，避免单点Master单点故障问题

（3）Master职责

①为RegionServer分配Region

②负责RegionServer的负载均衡

③发现失效的RegionServer并重新分配其上的Region

master是管理者，一个hbase系统会有很多表，每个表又有很多region，那么这些region到底交给那些regionserver来管理就是由 master来决定

④HDFS上的垃圾文件（HBase）回收

region会compact也会split，必然会有失效的数据

⑤处理Schema更新请求（表的创建，删除，修改，列簇的增加等等）

这些关于schema的数据都是存储在ZOOKEeper，但是是master是负责更新的
如果涉及到表的创建，修改，删除等操作，master宕机了就没法做，但是数据的插入和查询还是可以继续做

（4）RegionServer职责

①RegionServer维护Master分配给它的Region，处理对这些Region的IO请求

②负责和底层的文件系统HDFS的交互，存储数据到HDFS 每个regionserver内部都有一个客户端（datnaode的代理），负责把数据写入到HDFS。

③负责Store中的HFile的合并Compact工作 + split工作

④RegionServer负责Split在运行过程中变得过大的Region，负责Compact操作 SplitPolicy 分割策略：有三个默认的策略！

（5）Hlog

WAL机制的产物，用来记录Hbase的操作日志，每个HRegionServer都有一个Hlog文件，记录着本地服务器上多个HRgion文件的变动。

（6）Hbase的元数据种类

①表结构信息：主要是指 表名，列簇的定义 等等，由master 管理的

②表的region分布信息：存储在meta表， meta表由多个region组成，这些region也会分散到各个regoinserver去存储

（7）Hmaster宕机有什么影响？

可以支持服务：读写数据
服务失效：
- ①创建，修改，删除，表
- ②负责均衡不能做
- ③split不能做了。

2、Hbase物理存储结构

整体物理结构示意图

物理存储结构简述：

①Table中的所有行都按照RowKey的字典序排列。hbase的一个rowkey就对应一行数据；

②Table 在行的方向上分割为多个HRegion；

③HRegion按大小分割的(默认10G)，每个表一开始只有一个HRegion，随着数据不断插入表，HRegion不断增大，当增大到一个阀值的时候，HRegion就会等分会两个新的HRegion。当表中的行不断增多，就会有越来越多的HRegion；

④HRegion是HBase中分布式存储和负载均衡的最小单元。最小单元就表示不同的HRegion可以分布在不同的HRegionServer上。但一个HRegion是不会拆分到多个server上的；

⑤HRegion虽然是负载均衡的最小单元，但Strore是才是存储的最小单元。事实上，HRegion由一个或者多个 Store组成，每个Store保存一个Column Family。每个Strore又由一个MemStore和0至多个StoreFile 组成。

（1）StoreFile&HFile结构

含义：StoreFile 以 HFile 格式保存在 HDFS 上。

Hfile数据结构详述：Hfile分成6段
- ①Data Block 段：保存表中的数据，这部分可以被压缩；
- ②Meta Block 段 (可选的)：保存用户自定义的key-value对，可以被压缩；
- ③File Info 段：HFile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息；
- ④Data Block Index 段：Data Block的索引。每条索引的key是被索引的block的第一条记录的key；
- ⑤Meta Block Index段 (可选的)：Meta Block的索引；
- ⑥Trailer段：这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer， Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的 block，通过一次磁盘IO将整个block读取到内存中，再找到需要的key。
  - DataBlock Index采用LRU机制淘汰。

Datablack的数据结构：记录了每个Data块的起始点，每个KeyValue对就是一个简单的byte数组。
- ①开始是两个固定长度的数值，分别表示Key的长度和Value的长度。
- ②中间数据是Key：开始是固定长度的数值，表示RowKey的长度，紧接着是 RowKey，然后是固定长度的数值，表示Family的长度，然后是 Family，接着是Qualifier，然后是两个固定长度的数值，表示TimeStamp和KeyType（Put/Delete）。
- ③Value部分：是纯粹的二进制数据了。

（2）StoreFile&MemStore内存

①一个HRegion由多个Store组成，每个Store包含一个列族的所有数据；

②Store包括位于内存的一个Memstore和位于硬盘的多个StoreFile组成；

③写操作先写入Memstore，当Memstore中的数据量达到某个阈值，HRegionServer启动flush cache进程写入Storefile，每次写入形成单独一个HFile；

④当总Storefile大小超过一定阈值后，会把当前的Region分割成两个，并由HMaster分配给相应的Region 服务器，实现负载均衡

⑤客户端检索数据时，先在Memstore找，找不到再找Storefile。

（3）Hlog&WAL机制

作用：通过HLog回放补救丢失数据

①WAL机制原理

基本原理是在数据写入之前首先顺序写入日志，然后再写入缓存，等到缓存写满之后统一落盘。

②Hlog文件

Hbase实现WAL机制的产物，每个Region Server维护一个HLog，而不是每个Region一个。

每个HRegionServer中都会有一个HLog对象，HLog是一个实现Write Ahead Log的类，每次用户操作写入Memstore的同时，也会写一份数据到HLog文件，HLog文件定期会滚动出新，并删除旧的文件 (已持久化到 StoreFile中的数据)。

3、寻址机制

问题引入：每个RegionSever为一定数量的Region服务，那么Client要对某一行数据做读写的时候如何能知道具体要去访问哪个RegionServer呢？

访问路径描述：
- 第1步：Client请求ZooKeeper获取.META.所在的RegionServer的地址。
- 第2步：Client请求.META.所在的RegionServer获取访问数据所在的RegionServer地址，Client会将.META.的相关信息cache下来，以便下一次快速访问。
- 第3步：Client请求数据所在的RegionServer，获取所需要的数据。

4、Hbase读流程

读流程示意图

读数据流程

①第一步：客户端通过ZooKeeper以及-ROOT-表和.META.表找到目标数据所在的RegionServer(就是数据所在的 Region的主机地址)

②第二步：联系RegionServer查询目标数据

③第三步：RegionServer定位到目标数据所在的Region，发出查询请求

④第四步：Region先在Memstore中查找，命中则返回

⑤第五步：如果在Memstore中找不到，则在Storefile中扫描

5、写数据流程

写数据流程示意图

写数据流程具体描述：

①第一步：Client先根据RowKey找到对应的Region所在的RegionServer

②第二步：Client向RegionServer提交写请求

③第三步：RegionServer找到目标Region

④第四步：Region检查数据是否与Schema一致

⑤第五步：如果客户端没有指定版本，则获取当前系统时间作为数据版本

⑥第六步：将更新写入WAL Log

⑦第七步：将更新写入Memstore

⑧第八步：判断Memstore的是否需要flush为StoreFile文件。

数据恢复机制描述：当HRegionServer意外终止后，HMaster会通过ZooKeeper感知， HMaster首先处理遗留的HLog文件，将不同Region的log数据拆分，分别放到相应Region目录下，然后再将失效的Region（带有刚刚拆分的log）重新分配，领取到这些Region的 HRegionServer在load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后 flush到StoreFiles，完成数据恢复。

6、Region的Split&Compact

机制描述：Client写入 -> 存入MemStore，一直到MemStore满 -> Flush成一个StoreFile，直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除 -> 当 StoreFiles Compact后，逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后，触发 Split操作，把当前Region Split成2个Region，Region会下线，新Split出的2个孩子Region会被HMaster 分配到相应的HRegionServer 上，使得原先1个Region的压力得以分流到2个Region上。
相关参数剖析：

①执行刷盘时机

1、全局内存控制:当所有memstore占整个heap的最大比例的时候，会触发刷盘的操作。这个参数是hbase.regionserver.global.memstore.upperLimit，默认为整个heap内存的40%。
2、局部内存控制:当MemStore的大小达到hbase.hregion.memstore.flush.size大小的时候会触发刷盘，默认128M大小。
3、HLog的数量:当达到HLog的最大个数的时候，会强制刷盘。这个参数是hase.regionserver.max.logs，默认是32个。
4、手动操作:可以通过HBase Shell或者Java API手工触发flush的操作。

②Split策略

1、ConstantSizeRegionSplitPolicy           // 常数数量
2、IncreasingToUpperBoundRegionSplitPolicy // 递增上限
3、SteppingSplitPolicy                     // 步增上线

7、RegionServer工作机制

（1）Region分配

任何时刻，一个Region只能分配给一个RegionServer。

master记录了当前有哪些可用的 RegionServer。以及当前哪些Region分配给了哪些RegionServer，哪些Region还没有分配。当需要分配的新的Region，并且有一个RegionServer上有可用空间时，Master就给这个RegionServer发送一个装载请求，把Region分配给这个RegionServer。RegionServer得到请求后，就开始对此Region提供服务。

（2）RegionServer上线

Master使用zookeeper来跟踪RegionServer状态。

当某个RegionServer启动时，会首先在ZooKeeper 上的server目录下建立代表自己的znode。由于Master订阅了server目录上的变更消息，当server目录下的文件出现新增或删除操作时，Master可以得到来自ZooKeeper的实时通知。因此一旦 RegionServer上线，Master能马上得到消息。

（3）RegionServer下线

当RegionServer下线时，它和zookeeper的会话断开，ZooKeeper而自动释放代表这台server的文件上的独占锁。Master就可以确定：

6.9、master工作机制

（1）Master上线

Master启动进行以下步骤:
- ①从ZooKeeper上获取唯一一个代表Active Master的锁，用来阻止其它Master成为Master，使用zookeeper实现了分布式独占锁
- ②扫描ZooKeeper上的server父节点，获得当前可用的RegionServer列表。 rs节点下的regionserver列表
- ③和每个RegionServer通信，获得当前已分配的Region和RegionServer的对应关系。每个表有多少个regoin, 那些regionserver保管了那些region。
- ④扫描.META. Region的集合，计算得到当前还未分配的Region，将他们放入待分配Region列表。有一些regoin是无人认领的

（2）Master下线

由于Master只维护表和Region的元数据，而不参与表数据IO的过程，Master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行Region的负载均衡，无法处理Region上下线，无法进行Region的合并，唯一例外的是Region的split可以正常进行，因为只有RegionServer参与)，表的数据读写还可以正常进行。因此Master下线短时间内对整个hbase集群没有影响。

从上线过程可以看到，Master保存的信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来，因此，一般HBase集群中总是有一个Master在提供服务，还有一个以上的Master在等待时机抢占它的位置。