189 8069 5689
这期内容当中小编将会给大家带来有关HBase工作原理是什么，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
目前成都创新互联已为上千的企业提供了网站建设、域名、虚拟空间、绵阳服务器托管、企业网站设计、香格里拉网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
1. HBase系统架构图
整个HBase架构重点关注几部分：HMaster、HRegionServer、Zookeeper、HRegion（内部包括HLog、StoreFile、MemStore）。
2. HMaster介绍
Hbase集群采用的是master/slave模式，HMaster是集群老大（后面简称Master），统筹管理，所以干的底层杂活不多，负载不高。
2.1 Master职责
（1）为RegionServer分配Region。
（2）负责RegionServer的负载均衡。
（3）发现下线或dead的RegionServer，并重新分配其上的Region。
（4）回收HDFS上的垃圾文件。
（5）处理Schema的更新请求。
2.2 Master工作机制
(1) master上线
1）从zookeeper上获取唯一一个代表active master的锁，用来阻止其它master成为master。
2）扫描zookeeper上的server父节点，获得当前可用的region server列表。
3）和每个region server通信，获得当前已分配的region和region server的对应关系。
4）扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。
(2) master下线
由于master只维护表和region的元数据，而不参与表数据IO的过程（寻址访问zk和RegionServer，数据读写访问RegionServer），所以Master的负载很低，master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的合并，唯一例外的是region的split可以正常进行，因为只有region server参与)，表的数据读写还可以正常进行。因此master下线短时间内对整个hbase集群没有影响。从上线过程可以看到，master保存的 信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来），因此，一般hbase集群中总是有一个master在提供服务，还有一个以上 的’master’在等待时机抢占它的位置。
3. HRegionServer介绍
HRegionServer（后面简称RegionSever）是集群中的slave，负责处理具体的读写请求及对数据的compact和split等具体过程。
3.1 RegionServer职责
(1) 维护Master给它分配的Region，并处理这些Region的I/O请求。
(2) 负责切分在运行过程中不断变大的Region。
3.2 RegionServer工作机制
(1) regionserver上线
master通过zk来获取regionserver信息。当某个regionserver启动时，首先会在zk的server目录下建立一个属于自己的文件，并获得该文件的独占锁。由于master订阅了server目录的变更消息，所以当server目录下的文件出现新增或变更时，zk会及时通知master。
(2) regionserver下线
当region server下线时，它和zookeeper的会话断开，zookeeper而自动释放代表这台server的文件上的独占锁。而master不断轮询 server目录下文件的锁状态。如果master发现某个region server丢失了它自己的独占锁，(或者master连续几次和region server通信都无法成功),master就是尝试去获取代表这个region server的读写锁，一旦获取成功，就可以确定：
1) region server和zookeeper之间的网络断开了。
2) region server挂了。
的其中一种情况发生了，无论哪种情况，region server都无法继续为它的region提供服务了，此时master会删除server目录下代表这台region server的文件，并将这台region server的region分配给其它还活着的同志。
如果网络短暂出现问题导致region server丢失了它的锁，那么region server重新连接到zookeeper之后，只要代表它的文件还在，它就会不断尝试获取这个文件上的锁，一旦获取到了，就可以继续提供服务。
4. Zookeeper介绍
Zookeeper应该可以说是在Hadoop生态中主从结构架构的设计中是大众情人，它能够很好的协调整个集群统统一有序的工作。在HBase的架构中，ZooKeeper提供了类似文件系统一样的访问目录和文件（称为znode）的功能，通常分布式文件系统利用它协调所有权、注册服务、监听更新。
每台Region服务器在ZooKeeper中注册一个自己的临时节点，主服务器会利用这些临时节点来发现可用服务器，还可以利用临时节点来跟踪机器故障和网络分区。
在ZooKeeper服务器中，每个临时节点都属于某一个会话，这个会话是客户端连接ZooKeeper服务器后自动生成的。每个会话在服务器中有一个唯一的id，并且客户端会以此id不断的向ZooKeeper发送“心跳”，一旦发生故障ZooKeeper客户端进程死掉，ZooKeeper服务器会判定该会话超时，并自动删除属于它的临时节点。
HBase还可以利用ZooKeeper确保只有一个主服务器在运行，存储用于发现Region的引导位置，作为一个Region服务器的注册表，一级实现其他目的。ZooKeeper是一个关键组成部分，没有它HBase就无法工作。
Zookeeper的主要功能：
(1) 保证master的唯一性。 原理：master启动时会从ZK上获取一个active master锁，阻止其他节点成为master。
(2) 实时监控RegionServer的状态，将Regionserver上下线的消息及时告知master。
(3) 存储所有Region的寻址入口（即ROOT表在哪台服务器上）。
(4) 存储Hbase的Scema（Zookeeper存的是-ROOT-和.META.这两张表的location，实际存在HBase中），包括有哪些table，每个table有哪些column family。
5. Region介绍
Region是HBase存储和管理数据的基本单位。Region和RegionServer是多对一的关系，即一个Region只能同时被一个RegionServer使用，而一个RegionServer可以同时处理多个Region。
5.1 Region和Table的关系
Region实际是Table在行方向上的一个个划分，一般来说一个表在初始的时候只有一个Region，随着数据的增多，当达到某个阈值时，ReginServer就会把这个Region切分成两个Region，以此类推。
5.2 Region细分
继续深究的话，Region还是可以再细分的，它是由一个或多个Store组成的，在这里有必要搞清楚几个基本概念：HFile、HLog、StoreFile、MemStore。
上图反应了客户端对数据请求在底层的流转，可以简单理解为：HLog实际就是备份数据，用来做灾难恢复的；MemStore是缓存数据，用来提高读写效率；StoreFile是最下面一层的存储，它基本等于HFile，前者是相对于HBase而已逻辑上的存储，后者是相对于HDFS在物理上的存储（也就是前面说的hbase不管存，数据二进制文件存在HDFS上，指的就是HFile）。
5.2.1 关于HLog
(1)HLog 又叫WAL(Write Ahead Log)，类似于MySQL中的binlog，用来做灾难恢复的，HLog记录所有数据的变更，一旦数据发生变化就会在HLog里记录，所以也可以从这里恢复。
(2) 每个RegionServer维护一个HLog，而不是每个Region对应一个。所以不同的Region（来自不同的table）的日志就会混合在一起。
好处：所有日志都往一个文件写，减少磁盘寻址次数，提高对Hbase写的性能。
缺点：假设某台RegionServer下线，正好要恢复某个Region，这时就需要将这个HLog发送到其他RegionServer然后再恢复。
补充：HLog就是一个普通的Hadoop Sequence File，Sequence File的key为HLogKey对象（包括数据的归属信息、tablename、region等信息，还包括sequence number和timestamp），value为Hbase实际的key-value对象数据。
5.2.2 关于MemStore
MemStore是挡在StoreFile前面的一层缓存，当Region请求到达时，会先去在MemStore中查找，若命中直接返回结果，这样可以避免对大规模的StoreFile进行扫描。
6. 数据读写过程
数据在更新时首先写入Log(WAL log)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。于此同时，系统会在Zookeeper中记录一个Redo Point，表示这个时刻之前的变更已经持久化了。(minor Compact)当系统出现意外时，可能导致内存(MemStore)中的数据丢失，此时使用Log(WAL log)来恢复Checkpoint之后的数据。StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(Major Compact),将对同一个Key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行Split，等分为两个StoreFile。由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的 StoreFile和MemStore，将他们的按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，合并的过程还是比较快。
6.1 读请求
（1）客户端通过ZK和ROOT表、META表找到目标数据所在的RegionServer。
（2）请求RegionServer查找目标数据。
（3）由RegionServer定位到目标数据所在的Region，发出查询请求。
（4）Region会先从Memstore中查，命中则返回（先查Memstore的好处是在内存中，查询快）。
（3）若Memstore没有，则扫描StoreFile（这个过程可以能会扫描很多StorFfiel，借助Bloomfilter）。
6.2 写请求
（1）Client向Regionserver提交写请求。
（2）Regionserver找到目标Region。
（3）Region会检查数据是否与Schema一致。
（4）若客户端没有指定时间戳，默认取当前时间。
（5）将数据更新到WAL Log。
（6）将数据写入到Memstore。
（7）判断Memstore是否需要Flush为Storefile文件。
7. -ROOT-和.Meta.两张内置表介绍
Hbase内置两张表(-ROOT-、.META.)来管理region相关信息，且这两张表结构相同。
大致寻址过程：client-->Zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client
关于两张表的具体介绍及实例寻址过程，参考：http://greatwqs.iteye.com/blog/1838904
注意几点：
(1) 为什么要设计两张一模一样的表？
首先要注意这两张表也是两张普通的表，所以有可能会有多个region的情况（其实只有.META.表可能会有，.ROOT.很小）。
.META.表用来存储的是region相关的信息，每一行代表一个region，.META.表可能也会有很多region，且散落到不同的regionServer上，所以就用-ROOT-表，以同样的原理来管理.META.表的region（有点绕，其实就是公司管理的层级关系），然后把-ROOT-表的地址放到Zookeeper上（默认地址：/hbase/root-region-server），这样大家就知道所有查询的入口了。
(2) -ROOT-表并不会很大，永远不会被split，所以不会出现-ROOT-表也有很多region的情况，就避免了一直套表的现象了。
(3) -ROOT-表是放在内存中的，所以查询很快。
(4) 其实client的每次请求并非都走这么复杂的过程，client会将查询过的位置信息缓存起来，缓存不会主动失效。
上述就是小编为大家分享的HBase工作原理是什么了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。