<强> Hbase实现
,,,Hbase由一个主节点负责协调管理一个或多个RegionServer从属机部分负责启动,把区域分配给注册的RegionServer,恢复RegionServer的故障。主负载很轻。RegionServer负责零个或多个区域的管理以及响应客户端的读写请求,RegionServer还负责区域的划分,并通知主人有了新的子区域Hbase依赖于管理员。如果区域的分配过程中有服务器崩溃,就通过饲养员来协调,分配,在动物园管理员分配事务状态有助于在恢复时可以从崩溃遗留的状态开始继续分配。在启动一个客户端到集群上的连接时,客户端必须至少拿到集群所传递的饲养员整体的位置。这样,客户端才能访问饲养员的层次,了解集群的属性,如服务器的位置。
<强>运行中Hbase
,,,Hbase中保留着根——和.META。的特殊目录,它们维护着当前集群上所有区域的列表,状态,位置。根表维护着元表的信息,元表维护着用户表的信息,元表中的项使用区域名作为主键,区域名由所属的表名,区域的起始行,创建的时间戳进行哈希后的结果组成。区域变化时,即分裂,禁用/启用。删除,为负载均衡重新部署机器或由于Regionserver崩溃而重新部署区域时,目录表都会相应进行更新,这样,集群上所以区域的信息都能保持是最新的。
客户端的每一个行操作都要访问三次远程节点:
,,,, 1。从动物园管理员获取主人的位置
,,, 2。从主获取.Meta。表的信息
,,, 3。根据.Meta。表的信息,获取地区位置信息
,,,,为了减少访问远程节点,Hbase客户端会缓存它们遍历根表时获取的信息和元表位置以及用户空间的区域的开始行和结束行,这样不用访问元表也能得知区域存放的位置。当客户端碰到错误时会再去查看元获取区域的新位置,如果.Meta也移动了,就去查询根表,
<人力资源/><强>客户
1包含访问Hbase的接口、客户维护着一些缓存来加快对Hbase的访问,比如regione的位置信息。
<强>管理员
1保证任何时候,集群中只有一个主
2存贮所有地区的寻址入口。
3实时监控区域服务器的状态,将区域服务器的上线和下线信息实时通知给主人
4存储Hbase的模式,包括有哪些表,每个表有哪些列族
<强>主
1为地区服务器分配地区
2负责区域服务器的负载均衡
3发现失效的区域服务器并重新分配其上的地区
4 GFS上的垃圾文件回收
5处理模式更新请求
<强>区域服务器
1地区服务器维护主分配给它的地区,处理对这些地区的IO请求
2地区服务器负责切分在运行过程中变得过大的地区
可以看的到,客户访问Hbase上数据的过程并不需要主参与(寻址访问饲养员和地区服务器,数据读写访问regione服务器),主仅仅维护者表和地区的元数据信息,负载很低
<强>地区定位
系统如何找到某个行键(或者某个行键范围)所在
bigtable的地区使用三层类似B +树的结构来保存地区位置。
第一层是保存管理员里面的文件,它持有根区域的位置。
第二根层地区是.Meta。表的第一个地区其中保存了.Meta。z表其它地区的位置。通过根地区,我们就可以访问.META。表的数据。
.META。是第三层,它是一个特殊的表,保存了hbase中所有数据表的区域位置信息。
说明:
1根地区永远不会被分裂,保证了最需要三次跳转,就能定位到任意。
2.元。表每行保存一个区域的位置信息,行关键采用表名+表的最后一样编码而成。
3为了加快访问,.META。表的全部地区都保存在内存中。
假设,.META。表的一行在内存中大约占用1KB。并且每个region限制为128MB。
那么上面的三层结构可以保存的region数目为：
(128MB/1KB) * (128MB/1KB)==2(34)个region
4 client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的region(其中三次用来发现缓存失效，另外三次用来获取位置信息)。
读写过程
上文提到，hbase使用MemStore和StoreFile存储对表的更新。
数据在更新时首先写入Log(WAL log)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并 且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在zookeeper中 记录一个redo point，表示这个时刻之前的变更已经持久化了。(minor compact)
当系统出现意外时，可能导致内存(MemStore)中的数据丢失，此时使用Log(WAL log)来恢复checkpoint之后的数据。
