HBase的构成
物理上来讲，HBase是由三种类型的服务器以主从模式构成的。这三种服务器分别是：Region server，HBase HMaster，ZooKeeper。node
其中Region server负责数据的读写服务。用户经过沟通Region server来实现对数据的访问。算法
HBase HMaster负责Region的分配及数据库的建立和删除等操做。数据库
ZooKeeper做为HDFS的一部分，负责维护集群的状态（某台服务器是否在线，服务器之间数据的同步操做及master的选举等）。缓存
另外，Hadoop DataNode负责存储全部Region Server所管理的数据。HBase中的全部数据都是以HDFS文件的形式存储的。出于使Region server所管理的数据更加本地化的考虑，Region server是根据DataNode分布的。HBase的数据在写入的时候都存储在本地。但当某一个region被移除或被从新分配的时候，就可能产生数据不在本地的状况。这种状况只有在所谓的compaction以后才能解决。安全
NameNode负责维护构成文件的全部物理数据块的元信息（metadata）。服务器
HBase结构以下图所示：网络
Regions架构
HBase中的表是根据row key的值水平分割成所谓的region的。一个region包含表中全部row key位于region的起始键值和结束键值之间的行。集群中负责管理Region的结点叫作Region server。Region server负责数据的读写。每个Region server大约能够管理1000个region。Region的结构以下图所示：负载均衡
HBase的HMaster分布式
HMaster负责region的分配，数据库的建立和删除操做。
具体来讲，HMaster的职责包括：
- 调控Region server的工做
- 在集群启动的时候分配region，根据恢复服务或者负载均衡的须要从新分配region。
- 监控集群中的Region server的工做状态。（经过监听zookeeper对于ephemeral node状态的通知）。
- 管理数据库
- 提供建立，删除或者更新表格的接口。
HMaster的工做以下图所示：
ZooKeeper
HBase利用ZooKeeper维护集群中服务器的状态并协调分布式系统的工做。ZooKeeper维护服务器是否存活，是否可访问的状态并提供服务器故障/宕机的通知。ZooKeeper同时还使用一致性算法来保证服务器之间的同步。同时也负责Master选举的工做。须要注意的是要保证良好的一致性及顺利的Master选举，集群中的服务器数目必须是奇数。例如三台或五台。
ZooKeeper的工做以下图所示：
HBase各组成部分之间的合做
ZooKeeper用来协调分布式系统的成员之间共享的状态信息。Region Server及HMaster也与ZooKeeper链接。ZooKeeper经过心跳信息为活跃的链接维持相应的ephemeral node。以下图所示：
每个Region server都在ZooKeeper中建立相应的ephemeral node。HMaster经过监控这些ephemeral node的状态来发现正常工做的或发生故障下线的Region server。HMaster之间经过互相竞争建立ephemeral node进行Master选举。ZooKeeper会选出区中第一个建立成功的做为惟一一个活跃的HMaster。活跃的HMaster向ZooKeeper发送心跳信息来代表本身在线的状态。不活跃的HMaster则监听活跃HMaster的状态，并在活跃HMaster发生故障下线以后从新选举，从而实现了HBase的高可用性。
若是Region server或者HMaster不能成功向ZooKeeper发送心跳信息，则其与ZooKeeper的链接超时以后与之相应的ephemeral node就会被删除。监听ZooKeeper状态的其余节点就会获得相应node不存在的信息，从而进行相应的处理。活跃的HMaster监听Region Server的信息，并在其下线后从新分配Region server来恢复相应的服务。不活跃的HMaster监听活跃HMaster的信息，并在起下线后从新选出活跃的HMaster进行服务。
HBase的第一次读写
HBase中有一个特殊的起目录做用的表格，称为META table。META table中保存集群region的地址信息。ZooKeeper中会保存META table的位置。
当用户第一次想HBase中进行读或写操做时，如下步骤将被执行：
1.客户从ZooKeeper中获得保存META table的Region server的信息。
2.客户向该Region server查询负责管理本身想要访问的row key的所在的region的Region server的地址。客户会缓存这一信息以及META table所在位置的信息。
3.客户与负责其row所在region的Region Server通讯，实现对该行的读写操做。
在将来的读写操做中，客户会根据缓存寻找相应的Region server地址。除非该Region server再也不可达。这时客户会从新访问META table并更新缓存。这一过程以下图所示：
HBase的META table
- META table中保存了HBase中全部region的信息。
- META table的格式相似于B tree。
- META table的结构以下：
- 键：region的起始键，region id。
- 值：Region server
- 以下图所示：
Region Server的组成
运行在HDFS DataNode上的Region server包含以下几个部分：
- WAL：既Write Ahead Log。WAL是HDFS分布式文件系统中的一个文件。WAL用来存储还没有写入永久性存储区中的新数据。WAL也用来在服务器发生故障时进行数据恢复。
- Block Cache：Block cache是读缓存。Block cache将常常被读的数据存储在内存中来提升读取数据的效率。当Block cache的空间被占满后，其中被读取频率最低的数据将会被杀出。
- MemStore：MemStore是写缓存。其中存储了从WAL中写入但还没有写入硬盘的数据。MemStore中的数据在写入硬盘以前会先进行排序操做。每个region中的每个column family对应一个MemStore。
- Hfiles：Hfiles存在于硬盘上，根据排序号的键存储数据行。
- Region server的结构以下图所示：
- **HBase的写操做步骤
步骤一
当HBase的用户发出一个PUT请求时（也就是HBase的写请求），HBase进行处理的第一步是将数据写入HBase的write-ahead log（WAL）中。
- WAL文件是顺序写入的，也就是全部新添加的数据都被加入WAL文件的末尾。WAL文件存在硬盘上。
- 当server出现问题以后，WAL能够被用来恢复还没有写入HBase中的数据（由于WAL是保存在硬盘上的）。
- 以下图所示：
步骤二
当数据被成功写入WAL后，HBase将数据存入MemStore。这时HBase就会通知用户PUT操做已经成功了。
过程以下图所示：
HBase的MemStore
Memstore存在于内存中，其中存储的是按键排好序的待写入硬盘的数据。数据也是按键排好序写入HFile中的。每个Region中的每个Column family对应一个Memstore文件。所以对数据的更新也是对应于每个Column family。
以下图所示：
HBase Region Flush
当MemStore中积累了足够多的数据以后，整个Memcache中的数据会被一次性写入到HDFS里的一个新的HFile中。所以HDFS中一个Column family可能对应多个HFile。这个HFile中包含了相应的cell，或者说键值的实例。这些文件随着MemStore中积累的对数据的操做被flush到硬盘上而建立。
须要注意的是，MemStore存储在内存中，这也是为何HBase中Column family的数目有限制的缘由。每个Column family对应一个MemStore，当MemStore存满以后，里面所积累的数据就会一次性flush到硬盘上。同时，为了使HDFS可以知道当前哪些数据已经被存储了，MemStore中还保存最后一次写操做的序号。
每一个HFile中最大的序号做为meta field存储在其中，这个序号标明了以前的数据向硬盘存储的终止点和接下来继续存储的开始点。当一个region启动的时候，它会读取每个HFile中的序号来得知当前region中最新的操做序号是什么（最大的序号）。
以下图所示：
HFile
HBase中的键值数据对存储在HFile中。上面已经说过，当MemStore中积累足够多的数据的时候就会将其中的数据整个写入到HDFS中的一个新的HFile中。由于MemStore中的数据已经按照键排好序，因此这是一个顺序写的过程。因为顺序写操做避免了磁盘大量寻址的过程，因此这一操做很是高效。
以下图所示：
HFile的结构
HFile中包含了一个多层索引系统。这个多层索引是的HBase能够在不读取整个文件的状况下查找数据。这一多层索引相似于一个B+树。
- 键值对根据键大小升序排列。
- 索引指向64KB大小的数据块。
- 每个数据块还有其相应的叶索引（leaf-index）。
- 每个数据块的最后一个键做为中间索引（intermediate index）。
- 根索引（root index）指向中间索引。
文件结尾指向meta block。由于meta block是在数据写入硬盘操做的结尾写入该文件中的。文件的结尾同时还包含一些别的信息。好比bloom filter及时间信息。Bloom filter能够帮助HBase加速数据查询的速度。由于HBase能够利用Bloom filter跳过不包含当前查询的键的文件。时间信息则能够帮助HBase在查询时跳过读操做所指望的时间区域以外的文件。
以下图所示：
HFile的索引
HFile的索引在HFile被打开时会被读取到内存中。这样就能够保证数据检索只需一次硬盘查询操做。
以下图所示：
HBase的读合并（Read Merge）以及读放大（Read amplification）
经过上面的论述，咱们已经知道了HBase中对应于某一行数据的cell可能位于多个不一样的文件或存储介质中。好比已经存入硬盘的行位于硬盘上的HFile中，新加入或更新的数据位于内存中的MemStore中，最近读取过的数据则位于内存中的Block cache中。因此当咱们读取某一行的时候，为了返回相应的行数据，HBase须要根据Block cache，MemStore以及硬盘上的HFile中的数据进行所谓的读合并操做。
1.HBase会首先从Block cache（HBase的读缓存）中寻找所需的数据。
2.接下来，HBase会从MemStore中寻找数据。由于做为HBase的写缓存，MemStore中包含了最新版本的数据。
3.若是HBase从Block cache和MemStore中没有找到行所对应的cell全部的数据，系统会接着根据索引和bloom filter从相应的HFile中读取目标行的cell的数据。
以下图所示：
这里一个须要注意的地方是所谓的读放大效应（Read amplification）。根据前文所说，一个MemStore对应的数据可能存储于多个不一样的HFile中（因为屡次的flush），所以在进行读操做的时候，HBase可能须要读取多个HFile来获取想要的数据。这会影响HBase的性能表现。
以下图所示：
HBase的Compaction
Minor Compaction
HBase会自动选取一些较小的HFile进行合并，并将结果写入几个较大的HFile中。这一过程称为Minor compaction。Minor compaction经过Merge sort的形式将较小的文件合并为较大的文件，从而减小了存储的HFile的数量，提高HBase的性能。
这一过程以下图所示：
Major Compaction
所谓Major Compaction指的是HBase将对应于某一个Column family的全部HFile从新整理并合并为一个HFile，并在这一过程当中删除已经删除或过时的cell，更新现有cell的值。这一操做大大提高读的效率。可是由于Major compaction须要从新整理全部的HFile并写入一个HFile，这一过程包含大量的硬盘I/O操做以及网络数据通讯。这一过程也称为写放大（Write amplification）。在Major compaction进行的过程当中，当前Region基本是处于不可访问的状态。
Major compaction能够配置在规定的时间自动运行。为避免影响业务，Major compaction通常安排在夜间或周末进行。
须要注意的一点事，Major compaction会将当前Region所服务的全部远程数据下载到本地Region server上。这些远程数据可能因为服务器故障或者负载均衡等缘由而存储在于远端服务器上。
这一过程以下图所示：
Region的分割（Region split）
首先咱们快速复习一下Region：
- HBase中的表格能够根据行键水平分割为一个或几个region。每一个region中包含了一段处于某一块儿始键值和终止键值之间的连续的行键。
- 每个region的默认大小为1GB。
- 相应的Region server负责向客户提供访问某一region中的数据的服务。
- 每个Region server可以管理大约1000个region（这些region可能来自同一个表格，也可能来自不一样的表格）。
- 以下图所示：
- 每个表格最初都对应于一个region。随着region中数据量的增长，region会被分割成两个子region。每个子region中存储原来一半的数据。同时Region server会通知HMaster这一分割。出于负载均衡的缘由，HMaster可能会将新产生的region分配给其余的Region server管理（这也就致使了Region server服务远端数据的状况的产生）。
- 以下图所示：
读操做的负载均衡（Read Load Balancing）
Region的分割最初是在Region server本地发生的。可是出于负载均衡的缘由，HMaster可能会将新产生的region分配给其余的Region server进行管理。这也就致使了Region server管理存储在远端服务器上的region状况的产生。这一状况会持续至下一次Major compaction以前。如上文所示，Major compaction会将任何不在本地的数据下载至本地。
也就是说，HBase中的数据在写入时老是存储在本地的。可是随着region的从新分配（因为负载均衡或数据恢复），数据相对于Region server再也不必定是本地的。这种状况会在Major compaction后获得解决。
以下图所示：
HDFS的数据备份（Data Replication）
HDFS中全部的数据读写操做都是针对主节点进行的。HDFS会自动备份WAL和HFile。HBase以来HDFS来提供可靠的安全的数据存储。当数据被写入HDFS本地时，另外两份备份数据会分别存储在另外两台服务器上。
以下图所示：
HBase的异常恢复（Crash Recovery）
WAL文件和HFile都存储于硬盘上且存在备份，所以恢复它们是很是容易的。那么HBase如何恢复位于内存中的MemStore呢？
当Region server宕机的时候，其所管理的region在这一故障被发现并修复以前是不可访问的。ZooKeeper负责根据服务器的心跳信息来监控服务器的工做状态。当某一服务器下线以后，ZooKeeper会发送该服务器下线的通知。HMaster收到这一通知以后会进行恢复操做。
HMaster会首先将宕机的Region server所管理的region分配给其余仍在工做的活跃的Region server。而后HMaster会将该服务器的WAL分割并分别分配给相应的新分配的Region server进行存储。新的Region server会读取并顺序执行WAL中的数据操做，从而从新建立相应的MemStore。
以下图所示：
数据恢复（Data Recovery）
WAL文件之中存储了一系列数据操做。每个操做对应WAL中的一行。新的操做会顺序写在WAL文件的末尾。
那么当MemStore中存储的数据由于某种缘由丢失以后应该如何恢复呢？HBase以来WAL对其进行恢复。相应的Region server会顺序读取WAL并执行其中的操做。这些数据被存入内存中当前的MemStore并排序。最终当MemStore存满以后，这些数据被flush到硬盘上。
- 须要更多大数据开发相关学习资料（Hadoop，spark，kafka，MapReduce，scala，，推荐算法，实时交易监控系统，用户分析行为，推荐系统）加裙免费获取：792133408 点击加入 【大数据开发交流圈子】
以下图所示：
Apache HBase的优缺点
优势
- 强一致性模型
- 当一个写操做获得确认时，全部的用户都将读到同一个值。
- 可靠的自动扩展
- 当region中的数据太多时会自动分割。
- 使用HDFS分布存储并备份数据。
- 内置的恢复功能
- 使用WAL进行数据恢复。
- 与Hadoop集成良好
- MapReduce在HBase上很是直观。
缺点
- WAL回复较慢。
- 异常恢复复杂且低效。
- 须要进行占用大量资源和大量I/O操做的Major compaction