本文主要是介绍HBase_HBase架构解析_基于Hbase2.0，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
参考文章 :
HBase(2.2)-HBase架构详解_不务正业的土豆的博客-CSDN博客
Hbase中的各个组件介绍_hbase的分布式架构中有哪些组件_疯狂哈丘的博客-CSDN博客
文章目录
-
- 一、Hbase中的4大组件
-
- 1、hbase-client
- 2、Zookeeper
- 3、HMaster
- 4、HRegionServer
- 二、Hbase 组件的HA保证
-
- 1、zk的HA保证
- 2、HMaster的HA保证
- 3、HRegionServer的HA保证
HBase架构组成
HBase 采用 Master / Slave 架构搭建集群，它隶属于 Hadoop 生态系统，由以下几个类型的节点组成
- Hbase-client
- HMaster节点
- HRegionServer节点
- ZooKeeper集群
而在底层，它将数据存储于HDFS中，因而涉及到HDFS的NameNode、DataNode等。Hbase中主要有3个组件，客户端库（Shell，JavaAPI），一台主服务器（Master），多台Region服务器。总体结构如下：
1、hbase-client
客户端，用来访问hbase集群。可以和Hbase交互，也可以和HRegionServer交互。都是通过hbase rpc来访问对应的接口。
这里的客户端模式有多种，可以是Thrift、Avro、Rest等。
另外，hbase-client自身会缓存region的一些信息。
2、HMaster组成
主服务器 （Master）HMaster 利用 Zookeeper 为 Region 服务器分配Region。 Master 负责侦测各个 RegionServer 之间的状态， 并平衡 RegionServer 之间的负载，不提供任何服
HBaseMaster 还有一个职责就是负责分配 Region 给 RegionServer。HBase 允许多个 Master 节点 共存，但是这需要 Zookeeper 的帮助。
不过当多个Master节点共存时，只有一个Master 是提供服务的，其他的 Master 节点处于待命的状态。当正在工作的 Master 节点宕机时，其他的 Master 则会接管 HBase 的集群。
作用总结：
1）协调HRegionServer
为 RegionServer 分配 region , 启动时 HRegion的分配，以及负载均衡和修复时HRegion的重新分配，在 HRegion split 时分配新的 HRegion。 在HRgionServer 退出时迁移其内的 HRegion到其他 HRegionServer 上。监控集群中所有 HRegionServer 的状态，（通过 Heartbeat 和 监听 Zookeeper 中的状态），实现其负载均衡。
- 管理RegionServer的负载均衡，调整Region的分布
- 在RegionServer宕机或下线后，负责迁移RegionServer上的Region到其他的RegionServer上
- Region在分裂后，负责分配新的Region
2) Admin 职能
创建，删除，修改 Table的定义，即实现 DDL 操作
namespace 和 table 的增删改， column family 的增删改等。
管理namespace 和 table 的元数据 (实际存储在 HDFS 上 )。
权限控制 （ACL）
- 用户对表的增删改查
-----------------------------------
3、HRegionServer节点
HRegionServer一般和 DataNode 在同一台机器上运行，实现数据的本地性。 HRegionServer 包含多个 HRgion，由 WAL(HLog), BlockCache, MemStore, HFile 组成。
1） WAL 即Write Ahead Log
HBase 中的 HLog 机制是 WAL 的一种实现(底层 SequenceFile），而 WAL (一般翻译为预写日志) 是事务机制中常见的一致性的实现方式。每个 RegionServer 中都会有一个 HLog 的实例。
RegionServer 会将更新操作（如 Put, Delete） 先记录到 WAL (也就是 HLog) 中，然后将其写入到 Store 的 MemStore ，最终 MemStore 会将数据写入到持久化的 HFile (MemStore 到达配置的内存阈值)。这样就保证了 HBase的写的可靠性。 如果没有WAL, 当 RegionServer 宕掉的时候， MemStore 还没有写入到 HFile， 或者 StoreFile 还没有保存，数据就会丢失。或许有的读者会担心HFile 本身会不会丢失，这是由 HDFS 来保证的。在 HDFS 中的数据默认会有 3份。因此这里并不考虑 HFile 本身的可靠性。
HFile 由很多个数据块 （Block ）组成，并且有一个固定的结尾块。其中的数据块是由一个 Header 和 多个 Key-Value的键值对组成。在结尾的数据块中包含了数据相关的索引信息，系统也是通过结尾的索引信息找到 HFile 中的数据。
2）BlockCache
是一个读缓存，即 “引用局部性” 原理（ 也应用于 CPU , 分空间局部性 和 时间局部性 ，空间局部性是指 CPU 在某一个时刻需要某个数据， 那么有很大的概率在 下一时刻，它需要的数据在其附近 。 时间局部性是指某个数据在被访问一次后，它有很大的概率在不久的将来会被再次的访问。 将数据预读取到内存中，以提升读的性能。
HBase 中提供两种 BlockCache 的实现，默认 on-heap LRUBlockCache 和 BucketCache (通常是 Off-heap)。通常 BucketCache 的性能 要差于 LRUBlockCache, 然而由于GC的影响，LRUBlockCache的延迟会变得不稳定，而BucketCache 由于是自己管理 BlockCache, 而不需要GC, 因而它的延迟通常比较稳定，这也是有些时候需要选用 BucketCache 的原因。
3）HRegion
一个Table可以有多个Region, 他们可以在一个相同的 HRegionServer 上，也可以分布在不同的 HRegionServer 上，一个 HRegionServer 可以有多个 HRegion, 他们分别属于不同的 Table。
HRegion 由多个 Store( HStore) 构成，
每个 HStore 对应了一个 Table 在这个HRegion 中的一个 Column Family, 即每个 Column Family 就是一个集中的存储单元，因而最好将具有相近 I/O 特性的 Column 存储在 Column Family, 以实现高效读取 (数据局部性原理，可以提高缓存的命中率 )。HStore 是 HBase 中存储的核心，它实现了读写 HDFS 功能，一个 HStore 由 一个MemStore 和 0个或者多个 StoreFile 组成。
HBase 使用 RowKey 将表水平切割成多个 HRegion, 从 HMaster 的角度，每个 HRegion 都记录了它的 StartKey 和 EndKey (第一个 HRegion 的 StartKey 为空， 最后一个 HRegion 的 EndKey为空 )，由于 RowKey 是排序的（按字典顺序 从小到大排序），因而 Client 可以通过 HMaster 快速的定位每个 RowKey 在那个 HRegion 中。HRegion 由 HMaster 分配到相应的 HRegionServer 中，然后由 HRegionServer 负责 HRegion 的启动和管理，和 Client 的通信，负责数据的读 （使用 HDFS）。每个 HRegionServer 可以同时管理 1000个左右的 HRegion 。
4）MemStore
一个写缓存（In Memory Sorted Buffer ）,所有数据的在 完成 WAL 日志写后，后写入MemStore 中，由 MemStore 根据一定的算法将数据 Flush到 底层 HDFS 文件中 (HFile), 通常每个HRegion中的每个 Column Family 都有一个自己的 MemStore.
5) HFile (StoreFile)
用于存储HBase的数据（Cell / Key/ Value ）。在 HFile 中的数据是按 RowKey, Column Family, Column 排序，对相同的 Cell（即这三个值都一样 ），则按 timestamp 倒序排列。
HRegionServer宕机恢复
- HMaster通过zk检测到有HRegionServer下线，开始处理它遗留的WAL文件
- 将该WAL文件中不同Region的数据进行拆分，然后放到对应的Region的目录下
- 接着HMaster开始将这些失效的Region进行分配，也就是各个在线的HRegionServer都可能领到这些Region
- HRegionServer实例分配到Region后，发现对应的Region目录下有WAL文件需要处理，就会读取这些数据进行回放，数据也就重新加载到MemStore中去了
HRegionServer 功能总结
- 维护Master 分配给它的 Region, 处理对这些 region 的 I/O 请求
- 负责切分在运行过程中变得过大的 region
- 读写 HDFS, 管理Table 中的数据。
- Client 直接通过 HRegionServer 独写数据 （从 HMaster 中获取元数据，找到RowKey 所在的 HRegion / HRegionServer 后）。
-----------------------------------------------------------
4、Zookeeper集群
Zookeeper 为 HBase 集群提供协调服务，它管理着HMaster和HRegionServer的状态(available/alive等)，并且会在它们宕机时通知给HMaster，从而HMaster可以实现HMaster之间的failover（故障转移），或对宕机的HRegionServer中的HRegion集合的修复(将它们分配给其他的HRegionServer)。ZooKeeper集群本身使用一致性协议(PAXOS协议)保证每个节点状态的一致性。
总结：
- HMaster的HA，哪个HMaster先抢到zk上的锁，哪个就是active
- 存储-ROOT-表的地址，HMaster的地址
- 存储所有HRegionServer的状态，监控HRegionServer的上下线
- 存储Hbase的一些schema和table的元数据
---------------------------------------------------------
Hbase 组件的HA保证
(1) Master容错：
Zookeeper重新选择一个新的Master。如果无Master过程中，数据读取仍照常进行，但是，region切分、负载均衡等无法进行；
HMaster一般采用一主多备的方式来保证HA。HMaster在启动后通过尝试创建zk节点来成为Active，其他没有创建成果的则成为standby。如果active节点的HMaster因为一些原因挂掉了，standby的HMaster实例就可以迅速成为新的active然后开始工作。
HMaster的HA依赖于zk，因此只要zk能正常提供服务，HMaster只要部署2台即可保证高可用。
(2) RegionServer容错：
定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer；
HRegionServer只是一个工作节点，负责一部分的Region，因此只要不是所有的HRegionServer全挂了，都不会对hbase有什么影响。
HRegionServer下线后，HMaster会将它负责的那些Region分发给其他的HRegionServer来管理。
(3) Zookeeper容错：
Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例。
作为一个分布式协调系统，zk本身就有做HA。只要有足够的zk实例在运行，zk就可以正常的提供服务。
zk一般建议部署单数台的实例，这主要和他的选举机制有关。zk在读数据的时候可以去任何一台节点读取数据，但是在写数据时需要把请求转发给leader节点进行处理，如果无法选出leader节点的话，zk集群是无法正常工作的。leader的选举规则是某个节点必须获得超过一半的选票才可以成为leader，所以如果挂掉n/2台，选举无法进行，zk集群就无法提供服务了。举几个例子：
- 假设有2台zk节点，挂掉了一台后，只剩下一台zk节点，这时候只能获取到一个投票，没有超过1/2，所以剩下的那台zk节点也无法成为leader，集群无法提供服务（此时容忍度是可以挂掉0台）
- 假设有3台zk节点，挂掉了一台后，只剩下2台zk节点，这时候可以获取到2个投票，占2/3，超过了1/2，所以zk可以选出leader，是可以正常工作的（此时容忍度是可以挂掉1台）
- 假设有4台zk节点，挂掉两台后，只剩下两台zk节点，这时候只能获取到两个投票，没有超过1/2，所以剩下的那台zk节点也无法成为leader，集群无法提供服务（此时容忍度是可以挂掉1台）
从上面3个例子可以看出，1台zk节点和2台zk节点的容忍度都是0台，3台zk节点和4台zk节点的容忍度都是1台。可以推出2n-1和2n的效果是一样的，没必要花更多的资源去部署多余的zk节点。因此普遍建议部署奇数台zk节点即可。
hbase有许多地方都依赖于zk，如果zk无法正常工作，会严重影响hbase的运行。因此建议zk至少部署3个实例。
这篇关于HBase_HBase架构解析_基于Hbase2.0的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
