大数据技术-HBase：HBase 日志划分详解

我们都知道，hbase数据更新是存储到一个叫做memstore的内存区块，这样可以便于快速写入。当regionserver失效的适合，memstore里面的内容会丢失，因为没有被持久化到磁盘上。为了防止这种情况的数据丢失，更新操作放入memstore的时候被持久化到WAL中。这样可以依据WAL记录的内容对丢失的数据进行replay。

regionserver有多个region。其中的所有region共享同一个WAL文件，每个Edit保持有更新属于哪个region的信息及数据信息。当region被打开的时候，我们需要replay WAL中属于这个region的内容。所以WAL文件内容需要按照region进行分组便于replay。做这个事情的过程就叫做日志划分。

日志划分是由hmaster完成的，发生在集群启动或者regionserver死掉的情况下。由于需要保证一致性，受影响的region需要数据恢复完以后才可用。所以我们需要恢复和replay所有的edit，在region变得可用之前。

当日志划分开始后，日志目录被重命名为：

/hbase/.logs/<host>,

<port>,<startcode>-splitting

这样做很有必要，因为master认为rs死掉的情况下，很有可能其实其并没有。这样rs就没法再往里面写了，自己会进行自毁过程。log splitter现场读取日志文件一个个的edit，然后将其放入对应的edit归属的region。写线程是多个，从buffer读到内容，写入对应的日志目录：

/hbase/

<table_name>/<region_id>/recovered.edits/.temp

一旦完成会被重命名为：

/hbase/

<table_name>/<region_id>/recovered.edits/<sequenceid>

当日志划分完成，每个受影响的region都被分到了一个regionserver。当region打开的时候便会开始检查recoverd.edits文件夹。如果有文件，replay。当写入memstore被刷新生成hfile后，才会删除edit files。

但这个过程是及其耗时的，因为全是由master来做这个事情，并且是顺序的，可能有的时候会占用好几个小时来恢复。为了应对这个问题，0.92版本开始引入了一个叫做分布式日志划分distributed log splitting的机制。它减少了完成日志划分的整个过程，提升了可用性。例如我们知道一个集群崩溃了，如果使用单线程的方式日志划分，可能会占用9个小时的时间恢复，但分布式日志划分可能就几分钟的时间完成。

分布式日志划分情况下，master充当boss的角色。它有一个日志划分manager的后台线程管理所有的需要划分的日志文件。将这些任务通过zookeeper节点发布出去/hbase/splitlo.

每一个rs上面会有一个叫做日志划分worker的后台线程，它们监听zk节点，并努力去争取抢到日志划分的任务，一旦抢到，便把owner改为自己，阻止其他rs的继续争抢。可以通过hbase.master.distributed.log.splitting配置属性确认是否开启分布式日志划分，默认是开启的。

split log manager当所有task都成功返回后返回。如果有异常情况的task，将会发起重试。由于异步的实现机制，导致split log manager可能会丢失一些完成了的task跟踪。所以它会周期性检查是否其内存map或者zk上是否还有未完成的任务。如果没有，它将会抛出异常便于日志划分可以马上重试，避免hang住。