HBase架构(下)

jieforest · 发表于 2013-10-13 17:04

作为所有region servers的根节点，会记录它们是何时启动。用来追踪服务器的失败。每个内部的znode节点是临时性的，以它所代表的region server的服务器名称为名。比如:

[zk: localhost(CONNECTED) 4]
ls /hbase/rs
[rs1.internal,60000,1309859972983,rs2.internal,60000,1309859345233]
/hbase/shutdown

复制代码

该节点用于追踪集群状态。包含集群启动时间，当集群关闭时其内容为空。比如：

[zk: localhost(CONNECTED) 5]
get /hbase/shutdown
Tue Jul 05 11:59:33 CEST 2011
/hbase/splitlog

复制代码

jieforest · 发表于 2013-10-13 17:04

用于所有log splitting相关协调的parent znode, 细节详见 the section called “Log Splitting” 。比如:

[zk: localhost(CONNECTED) 6]
ls /hbase/splitlog
[hdfs%3A%2F%2Flocalhost%2Fhbase%2F.logs%2Ffoo.internal%2C60020%2C \
1309850971208%2Ffoo.internal%252C60020%252C1309850971208.1309851636647,
hdfs%3A%2F%2Flocalhost%2Fhbase%2F.logs%2Ffoo.internal%2C60020%2C \
1309850971208%2Ffoo.internal%252C60020%252C1309850971208.1309851641956,
...
hdfs%3A%2F%2Flocalhost%2Fhbase%2F.logs%2Ffoo.internal%2C60020%2C \
1309850971208%2Ffoo.internal%252C60020%252C1309850971208.1309851784396]
[zk: localhost(CONNECTED) 7]
get /hbase/splitlog/ \
\hdfs%3A%2F%2Flocalhost%2Fhbase%2F.logs%2Fmemcache1.internal%2C \
60020%2C1309850971208%2Fmemcache1.internal%252C60020%252C1309850971208. \
1309851784396
unassigned foo.internal,60000,1309851879862
[zk: localhost(CONNECTED) 8]
get /hbase/splitlog/ \
\hdfs%3A%2F%2Flocalhost%2Fhbase%2F.logs%2Fmemcache1.internal%2C \
60020%2C1309850971208%2Fmemcache1.internal%252C60020%252C1309850971208. \
1309851784396
owned foo.internal,60000,1309851879862
[zk: localhost(CONNECTED) 9]
ls /hbase/splitlog
[RESCAN0000293834, hdfs%3A%2F%2Flocalhost%2Fhbase%2F.logs%2Fmemcache1. \
internal%2C60020%2C1309850971208%2Fmemcache1.internal%252C \
60020%252C1309850971208.1309851681118, RESCAN0000293827, RESCAN0000293828, \
RESCAN0000293829, RESCAN0000293838, RESCAN0000293837]

复制代码

jieforest · 发表于 2013-10-13 17:05

这些例子列出了很多东西：你可以看到一个未被分配的log是如何被split的，之后又如何被一个region server所拥有。"RESCAN"节点表示那些workers，比如万一log split失败后可能被用于进一步的工作的region server。

/hbase/table

当一个表被禁用时,它会被添加到该节点下. 表名就是新创建的znode的名称，内容就是"DISABLED"。比如:

[zk: localhost(CONNECTED) 10]
ls /hbase/table
[testtable]
[zk: localhost(CONNECTED) 11]
get /hbase/table/testtable
DISABLED
/hbase/unassigned

复制代码

jieforest · 发表于 2013-10-13 17:05

该znode是由 AssignmentManager 用来追踪整个集群的region状态的。它包含了那些未被打开或者处于过渡状态的regions对应的znodes，zodes的名称就是该region的hash。比如:

[zk: localhost(CONNECTED) 11]
ls /hbase/unassigned
[8438203023b8cbba347eb6fc118312a7]

复制代码

4. Replication

HBase replication是在不同的HBase部署之间拷贝数据的一种方式。它可以作为一种灾难恢复解决方案，也可以用于提供HBase层的更高的可用性。同时它也能提供一些更实用的东西：比如，可以作为从面向web的集群中拷贝最新的更新内容到MapReduce集群的简单方式，然后利用MapReduce集群对新老数据进行处理再自动地返回结果。

HBase replication采用的基本架构模式是：master-push；因为每个region server都有自己的write-ahead-log(即WAL或HLog)，这样就很容易记录下从上次复制之后又发生了什么，非常类似于其他一些著名的解决方案，就像MySQL 的主从复制就只用了一个binary log来进行追踪。一个master集群可以向任意数目的slave集群进行复制，同时每个region server会参与复制它本身所对应的一系列的修改。

Replication是异步进行的，这意味着参与的集群可能在地理位置上相隔甚远，它们之间的连接可以在某段时间内是断开的，插入到master集群中的那些行，在同一时间在slave集群上不一定是可用的(最终一致性)。

jieforest · 发表于 2013-10-15 12:05

在该设计中所采用的replication格式在原理上类似于MySQL的基于状态的replication。在这里，不是SQL语句，而是整个的WALEdits(由来自客户端的put和delete操作的多个cell inserts组成)会被复制以维持原子性。

每个region server的HLogs是HBase replication的基础，同时只要这些logs需要复制到其他的slave集群上，它们就需要保存在HDFS上。每个RS会从它们需要复制的最老的log开始读取，同时为简化故障恢复会将当前读取位置保存到ZooKeeper上。对于不同的slave集群来说，该位置可能是不同的。参与replication各集群大小可能不是对称的，同时master集群会通过随机化来尽量保证在slave集群上的replication工作流的平衡。

Figure 8.12. Overview on the replication architecture

jieforest · 发表于 2013-10-15 12:05

4.1 Life of a Log Edit

下面的几节里会描述下来自客户端的一个edit从与master集群通信开始到到达另一个slave集群的整个生命历程。

4.1.1 正常处理流程

客户端会使用HBase API将Put，Delete和Increment发送给region server。Key values会被region server转换为一个WALEdit对象。该edit对象会被append到当前的WAL上，同时之后会被apply到它的MemStore中。

通过一个独立的线程，将该edit对象从log中读出然后只保留那些需要复制的KeyValues(也就是说只保留那些在family schema中只属于GLOBAL作用域的family的成员，同时是非元数据也就是非.META和-ROOT-)。当buffer被填满或者读取者读到文件末尾后，该buffer会被随机发送到slave集群上的某个region server上。region server顺序地接受读到的这些edits，同时将它们按照table放到不同的buffers中。一旦所有的edits读取完毕，所有的buffer就会通过正常的HBase客户端进行flush。

回头再看master集群的region server，当前复制到的WAL偏移位置会注册到ZooKeeper上。

jieforest · 发表于 2013-10-15 12:06

4.1.2 Non-responding Slave Clusters

Edit会以同样的方式进行插入。在独立的线程中，region server像正常处理过程那样进行读取，过滤以及对log edits进行缓存。假设现在所联系的那个slave集群的region server不再响应RPC了，这样master集群的region server会进行休眠然后等待一个配置好的时间段后再进行重试。如果slave集群的region server仍然没有响应，master集群的region server就会重新选择一个要复制到的region server子集，然后会重新尝试发送缓存的那些edits。

与此同时，WALs将会进行切换同时会被存储在ZooKeeper的一个队列中。那些被所属的region server归档(归档过程基本上就是把一个日志从它所属的region server的目录下移到一个中央的logs归档目录下)了的日志会更新它们在复制线程的内存队列中的路径信息。

当slave集群最终可用后，处理方式就又跟正常处理流程一致了。Master集群的region server就又开始进行之前积压的日志的复制了。

jieforest · 发表于 2013-10-15 12:07

4.2 Internals

本节会深入描述下replication的内部操作机制。

4.2.1 选择复制到的目标Region Servers

当一个master集群的region server开始作为某个slave集群的复制源之后，它首先会通过给定的集群key联系slave集群的ZooKeeper。

该key由如下部分组成：

hbase.zookeeper.quorum
zookeeper.znode.parent
hbase.zookeeper.property.clientPort。

复制代码

之后，它会扫描/hbase/rs目录以找到所有可用的sinks(即那些可用接收用于复制的edits数据流的region servers)同时根据配置的比率(默认是10%)来选出它们中的一个子集。比如如果slave集群有150台机器，那么将会有15台选定为master集群的region server将要发送的edits的接受者。因为复制过程中，master的所有region server都会进行，这样这些slave集群的region server的负载就可能会很高，同时该方法适用于各种大小的集群。

比如，一个具有10台机器的master集群向一个具有10%比率的5台集群的slave集群进行复制。意味着master集群的region servers每次都会随机选择一台机器，这样slave集群的重叠和总的使用率还是很高的。

jieforest · 发表于 2013-10-15 12:08

4.2.2 日志追踪

每个master集群的region server在replication znodes体系中都有自己的节点。同时节点下针对每个集群节点还会有一个znode(如果有5个slave集群，就会有5个znode创建出来)，每个znode下又包含一个待处理的HLogs队列。

这些队列是用来追踪由该region server创建的HLogs的，这些队列的大小可能有所不同。比如，如果某个slave集群某段时间不可用，那么这段时间的HLogs就不能被删除，因此它们就得呆在队列里(而其他的可能已经处理过了)。具体例子可以参考：the section called “Region Server Failover”。

当一个source被实例化时，它会包含region server当前正在写入的HLog。在log切换时，新的文件在可用之前就会被添加到每个slave集群的znode的队列中。这可以让所有的sources在该HLog可以append edits之前就能够知道一个新log已经存在了，但是该操作的开销目前是很昂贵的。

当replication线程无法从文件中读出更多的记录之后(因为它已经读到了最后一个block)，就会将它从队列中删除，此时要求队列中的还有其他文件存在{!还有其他文件存在就意味着这个文件是一个已经写完的日志文件，而不是正在写入的那个}。这就意味着如果一个source已是最新状态，同时复制进程已经到了region server正在写入的那个log，那么即使读到了当前文件的”end”部分，也不能将它从队列中删除{!如果该文件正在被写入，那么即使读到了末尾，也不能认为它已经结束}。

当一个log被归档后(因为它不再被使用或者是因为插入速度超过了region flushing的速度导致当前log文件数超过了hbase.regionserver.maxlogs的限制)，它会通知source线程该log的路径已经发生改变。如果某个source已经处理完该log，会忽略该消息。如果它还在队列中，该路径会更新到相应的内存中。如果该log目前正在被复制，该变更会自动完成，读取者不需要重新打开该被移动的文件。因为文件的移动只是一个NameNode操作，如果读取者当前正在读取该log文件，它不会产生任何异常。

jieforest · 发表于 2013-10-16 14:15

4.2.3 读，过滤及发送Edits

默认情况下，一个source会尽量地读取日志文件然后将日志记录尽快地发送给一个sink。但是首先它需要对log记录进行过滤；只有那些具有GLOBAL作用域同时不属于元数据表的KeyValues才能保留下来。第二个限制是，附加在每个slave集群上所能复制的edits列表的大小限制，默认是64MB。这意味着一个具有三个slave集群的master集群的region server最多只能使用192MB来存储被复制的数据。

一旦缓存的edits大小达到上限或者读取者读到了log文件末尾，source线程将会停止读取然后随机选择一个sink进行复制。它会对选定的集群直接产生一个RPC调用，然后等待该方法返回。如果成功返回，source会判断当前的文件是否已经读完或者还是继续从里面读。如果是前者，它会将它从znode的队列中删除。如果是后者，它会在该log的znode中注册一个新的offset。如果PRC抛出了异常，该source在寻找另一个sink之前会重试十次。

[转载] HBase架构(下)