HBase Snapshot原理和实现
HBase 从0.95开始引入了Snapshot,可以对table进行Snapshot,也可以Restore到Snapshot。Snapshot可以在线做, 也可以离线做。Snapshot的实现不涉及到table实际数据的拷贝,仅仅拷贝一些元数据,比如组成table的region info,表的descriptor,还有表对应的HFile的文件的引用。本文基于0.98.4
Snapshot命令如下所示:
hbase> snapshot 'sync_stage:Photo', 'PhotoSnapshot' //对sync_stage这个namespace下的Photo表做一次snapshot(表只有一个column family,叫做PHOTO),snapshot名字叫做PhotoSnapshot
这个Snapshot执行后,所有相关的元数据都会被保存在(假设hbase.rootdir设置为/sync/hbase) hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot目录中。如下所示:
$ bin/hadoop fs -ls -R hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/ -rw-r--r-- 3 work supergroup 44 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/.snapshotinfo //Snapshot的一些描述信息 drwxr-xr-x - work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/.tabledesc -rw-r--r-- 3 work supergroup 543 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/.tabledesc/.tableinfo.0000000001 //Photo表的HTableDescriptor的序列化 drwxr-xr-x - work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/.tmp drwxr-xr-x - work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/0595cf25f61de0f1c3ddf38e50a59b07 //Photo表有三个region,这里显示region encode name -rw-r--r-- 3 work supergroup 58 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/0595cf25f61de0f1c3ddf38e50a59b07/.regioninfo // region的HRegionInfo序列化 drwxr-xr-x - work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/0595cf25f61de0f1c3ddf38e50a59b07/PHOTO -rw-r--r-- 3 work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/0595cf25f61de0f1c3ddf38e50a59b07/PHOTO/7cfdcf5ef122422499e4bffa71485ee1 //这里的PHOTO是column family,从下面可以看出,这个column family下一共有3个HFile文件,这里,HFile文件名为7cfdcf5ef122422499e4bffa71485ee1,这个文件是空文件,代表对实际存有数据的同名HFile的一个引用,下个图可以看到 drwxr-xr-x - work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/395b0d05df155fddbb03b1da908dae3d -rw-r--r-- 3 work supergroup 72 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/395b0d05df155fddbb03b1da908dae3d/.regioninfo drwxr-xr-x - work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/395b0d05df155fddbb03b1da908dae3d/PHOTO -rw-r--r-- 3 work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/395b0d05df155fddbb03b1da908dae3d/PHOTO/74e4639c360c4cc59806ba48d13ba230 drwxr-xr-x - work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/87a9a6202d9f68d9ccbd184b19cb8933 -rw-r--r-- 3 work supergroup 55 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/87a9a6202d9f68d9ccbd184b19cb8933/.regioninfo drwxr-xr-x - work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/87a9a6202d9f68d9ccbd184b19cb8933/PHOTO -rw-r--r-- 3 work supergroup 0 2014-08-15 10:32 hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot/87a9a6202d9f68d9ccbd184b19cb8933/PHOTO/902eafefe50f4ba2ba01bd80d0846cf8
看看Photo表PHOTO column family下的HFile文件:
bin/hadoop fs -ls -R hdfs://sync/hbase/data/sync_stage/Photo/ drwxr-xr-x - work supergroup 0 2014-07-31 16:49 hdfs://sync/hbase/data/sync_stage/Photo/.tabledesc -rw-r--r-- 3 work supergroup 543 2014-07-31 16:49 hdfs://sync/hbase/data/sync_stage/Photo/.tabledesc/.tableinfo.0000000002 drwxr-xr-x - work supergroup 0 2014-07-31 16:49 hdfs://sync/hbase/data/sync_stage/Photo/.tmp drwxr-xr-x - work supergroup 0 2014-08-01 17:09 hdfs://sync/hbase/data/sync_stage/Photo/0595cf25f61de0f1c3ddf38e50a59b07 -rw-r--r-- 3 work supergroup 58 2014-08-01 16:31 hdfs://sync/hbase/data/sync_stage/Photo/0595cf25f61de0f1c3ddf38e50a59b07/.regioninfo drwxr-xr-x - work supergroup 0 2014-08-01 16:31 hdfs://sync/hbase/data/sync_stage/Photo/0595cf25f61de0f1c3ddf38e50a59b07/PHOTO -rw-r--r-- 3 work supergroup 67780675 2014-08-01 16:31 hdfs://sync/hbase/data/sync_stage/Photo/0595cf25f61de0f1c3ddf38e50a59b07/PHOTO/7cfdcf5ef122422499e4bffa71485ee1 //这个HFile存有实际的数据,并且HFile文件名相同 drwxr-xr-x - work supergroup 0 2014-08-02 12:51 hdfs://sync/hbase/data/sync_stage/Photo/395b0d05df155fddbb03b1da908dae3d -rw-r--r-- 3 work supergroup 72 2014-08-01 17:33 hdfs://sync/hbase/data/sync_stage/Photo/395b0d05df155fddbb03b1da908dae3d/.regioninfo drwxr-xr-x - work supergroup 0 2014-08-01 17:33 hdfs://sync/hbase/data/sync_stage/Photo/395b0d05df155fddbb03b1da908dae3d/PHOTO -rw-r--r-- 3 work supergroup 101932288 2014-08-01 17:33 hdfs://sync/hbase/data/sync_stage/Photo/395b0d05df155fddbb03b1da908dae3d/PHOTO/74e4639c360c4cc59806ba48d13ba230 drwxr-xr-x - work supergroup 0 2014-08-02 12:51 hdfs://sync/hbase/data/sync_stage/Photo/87a9a6202d9f68d9ccbd184b19cb8933 -rw-r--r-- 3 work supergroup 55 2014-08-01 17:33 hdfs://sync/hbase/data/sync_stage/Photo/87a9a6202d9f68d9ccbd184b19cb8933/.regioninfo drwxr-xr-x - work supergroup 0 2014-08-01 17:33 hdfs://sync/hbase/data/sync_stage/Photo/87a9a6202d9f68d9ccbd184b19cb8933/PHOTO -rw-r--r-- 3 work supergroup 222931250 2014-08-01 17:33 hdfs://sync/hbase/data/sync_stage/Photo/87a9a6202d9f68d9ccbd184b19cb8933/PHOTO/902eafefe50f4ba2ba01bd80d0846cf8
下面看看Snapshot的原理。
Snapshot的过程类似于两阶段提交,大体过程是,HMaster收到snapshot命令后,作为coordinator,然后从meta region中取出Photo表的region和对应的region server的信息,这些region server就作为两阶段提交的participant,prepare阶段就相当于对region server本地的Photo表的region做快照存入HDFS的临时目录,commit阶段其实就是HMaster把临时目录改成正确的目录。期 间,HMaster和region server的数据共享通过ZK来完成。
下面看Snapshot的具体实现。
在HMaster端,由SnapshotManager类的对象来负责和Snapshot相关的事务,内部有一个类型为 ProcedureCoordinator的对象,名为coordinator,从名字可以看出它就是协调者。HMaster收到Snapshot命令, 执行public SnapshotResponse snapshot(RpcController controller, SnapshotRequest request)函数,函数内部从request中解析出SnapshotDescription 对象,它就是对这次Snapshot的描述,其中就包括Snapshot的名字PhotoSnapshot,和Snapshot的表Photo等。然后调 用SnapshotManager的takeSnapshot()方法,方法内部首先会检查Photo表是不是正在做Snapshot,或者名为 PhotoSnapshot的snapshot已经做完了等前置检查,如果没有,由于这里做的是online snapshot,即表仍然可以读写处于enable状态,在这里,会调用snapshotEnabledTable(),进而提交一个 EnabledTableSnapshotHandler任务给内部线程池处理,在提交之前,也会做一些检查,并且准备好snapshot用的临时目录, 在这个例子中,临时目录为hdfs://sync/hbase/.hbase-snapshot/.tmp/PhotoSnapshot,前置检查环境准 备等由函数prepareToTakeSnapshot(snapshot)负责。重点看EnabledTableSnapshotHandler,它继 承于TakeSnapshotHandler,任务入口函数在TakeSnapshotHandler的process()方法。下面重点看这个方法。
process方法主要干几件事:
1. 将SnapshotDescription对象序列化写入到hdfs://sync/hbase/.hbase-snapshot/.tmp/PhotoSnapshot目录的.snapshotinfo文件中。
2. 调用TableInfoCopyTask任务将Photo表的最新的.tableinfo拷到hdfs://sync/hbase/.hbase- snapshot/.tmp/PhotoSnapshot/.tabledesc/ 目录下,名字为.tableinfo.0000000001。
3. 从meta region中独处Photo表的region和所在region server信息,传给snapshotRegions()函数,该函数被EnabledTableSnapshotHandler覆盖,流程进入 EnabledTableSnapshotHandler的 snapshotRegions()。
4. proc.waitForCompleted(); 等待snapshot完成,其实就是等待completedLatch变成0
5. 做一些postcheck ,然后调用completeSnapshot(this.snapshotDir, this.workingDir, this.fs) 将working dir改成正确的目录位置hdfs://sync/hbase/.hbase-snapshot/PhotoSnapshot
下面重点看第三步.EnabledTableSnapshotHandler的snapshotRegions(),这个函数首先调用
Procedure proc = coordinator.startProcedure(this.monitor, this.snapshot.getName(), this.snapshot.toByteArray(), Lists.newArrayList(regionServers));
启动一个Procedure,在HMaster端,这个Snapshot由一个Procedure来表示,在RegionServer端,有SubProcedure表示,后续会看到。实际上,这里提供了一套框架,以后如果有其他的需要两阶段提交的任务也可以放进来做。
Procedure同样提交给内部线程池处理,Procedure是一个callable,入口函数在call()。call内主要是执行如下几个函数:
sendGlobalBarrierStart(); // 发布Snapshot任务 waitForLatch(acquiredBarrierLatch, monitor, wakeFrequency, "acquired");//等所有的相关的region server都acquire这个任务 sendGlobalBarrierReached(); //建立reached节点 waitForLatch(releasedBarrierLatch, monitor, wakeFrequency, "released"); //等待所有的相关的region server完成本地snapshot sendGlobalBarrierComplete(); //将zk上相关节点删除 completedLatch.countDown();// proc结束
Procedure有几个关键的成员变量,acquiringMembers 初始化为Photo表的regions所在的serverName,意思是说这个任务需要这些serverName作为参与者,HMaster在ZK上发 布Snapshot任务,需要这些参与者都去acquire这个任务后,大家才可以进入下一个阶段。在当前例子,HMaster调用 sendGlobalBarrierStart()方法发布任务,方法内部实际上调用coordinator(ProcedureCoordinator 类)对象的ZKProcedureCoordinatorRpcs类型成员的sendGlobalBarrierAcquire()方法去ZK上发布 Snapshot任务,实际上就是在zk上创建/hbase/online-snapshot/acquired/PhotoSnapshot 路径,并且PhotoSnapshot是一个目录,目录的data为SnapshotDescription的序列化。RegionServer启动的 时候会监控/hbase/online-snapshot/acquired目录的改动,当region server在目录下发现一个新的节点后,就会在/hbase/online-snapshot/acquired目录下建立一个代表自己的znode, 名字为region server的server name,代表当前region server已经检测到这个任务了。一旦HMaster检测到一个新的znode,会触发coordinator的ZKProcedureUtil类型的 名为zkProc的成员变量的nodeCreated()方法,从而调用coordinator的memberAcquiredBarrier()方法, 检测,如果新加的节点确实在acquiringMembers内,则将acquiredBarrierLatch这个CountDownLatch减1。 这里需要检查新加的节点不在acquiringMembers内的原因在于,实际上,不相关的region server也会acquire这个任务,只是当它发现自己没有相关的region后,直接就执行完成了。所有的acquire成功的server name都会从acquiringMembers移除然后加入到inBarrierMembers中,随后,调用 sendGlobalBarrierReached()在zk上创建节点 /hbase/online-snapshot/reached /PhotoSnapshot,并且监控目录下的节点变化,本地snapshot完成的region server会在这个目录下建立一个代表自己的节点,与前面类似,通过releasedBarrierLatch这个CountDownLatch来控 制。
下面看看RegionServer检测到/hbase/online-snapshot/acquired下面的snapshot任务后如何做。
RegionServer使用RegionServerSnapshotManager来管理Snapshot相关的事务,主要工作由内部类型为ZKProcedureMemberRpcs
的成员变量memberRpcs来完成,region server初始化时,就会调用ZKProcedureMemberRpcs的waitForNewProcedures()方法来监控zk上 /hbase/online-snapshot/acquired下面节点的变化。当检测节点增加后,会调用ProcedureMember的
public Subprocedure createSubprocedure(String opName, byte[] data) { return builder.buildSubprocedure(opName, data); }
方法来创建SubProcedure,这里的builder是SnapshotSubprocedureBuilder,它的 buildSubprocedure()会创建FlushSnapshotSubprocedure类型的 subprocedure,FlushSnapshotSubprocedure有一个名为regions的成员变量,这里会进行初始化,从region server的online regions列表中检查是否有被snapshot表的region,如果有,则初始化regions,否则regions为空。同样,这个 subprocedure会提交给内部的线程池处理.FlushSnapshotSubprocedure继承于Subprocedure,它是一个 callable,入口函数是call。这个call实际上执行如下几个函数:
acquireBarrier();// 对于FlushSnapshotSubprocedure来说,do nothing rpcs.sendMemberAcquired(this); //在acquired下建立znode代表自己 waitForReachedGlobalBarrier(); //等在inGlobalBarrier这个CountDownLatch上,初始化为1,只有reached下面相应的snapshot节点建立后(这说明所有相关的re//gion server都已经acquire 任务了)才继续往下走 insideBarrier(); //调用子类FlushSnapshotSubprocedure的insideBarrier rpcs.sendMemberCompleted(this); //本地snapshot完成后,在reached下建立一个znode代表自己 releasedLocalBarrier.countDown(); executionTimeoutTimer.complete();
可以看出,只有reached相应节点建立,region server才可以往下走进行实际的snapshot操作,而reached节点的建立只有HMaster看到所有的相关的region server都已经acquire了任务后才会去建立,这就达到了同步的目的。
下面看FlushSnapshotSubprocedure的insideBarrier().
对于regions(创建FlushSnapshotSubprocedure的时候进行了初始化,这些regions就是本region server所包含的被snapshot表的region)里的每个region提交一个RegionSnapshotTask类型的任务,然后等待所有 的这些task完成。
每个RegionSnapshotTask的任务就是真正的这个region的数据进行snapshot,下面重点看。
1. 调region.flushcache(),转而调internalFlushcache(status)=>internalFlushcache(this.log, -1, status),主要逻辑在internalFlushcache(this.log, -1, status)中。看下面一段:
this.updatesLock.writeLock().lock();//加写锁,以便冻结region内所有的memstore long totalFlushableSize = 0; status.setStatus("Preparing to flush by snapshotting stores"); List<StoreFlushContext> storeFlushCtxs = new ArrayList<StoreFlushContext>(stores.size()); long flushSeqId = -1L; try { // Record the mvcc for all transactions in progress. // 目的是为了后续调用mvcc.waitForRead(w),使得w之前的所有的写事务结束并且可见,以便flush时不会把没有commit的事务flush到HFile中。 w = mvcc.beginMemstoreInsert(); mvcc.advanceMemstore(w); // check if it is not closing. if (wal != null) { if (!wal.startCacheFlush(this.getRegionInfo().getEncodedNameAsBytes())) { String msg = "Flush will not be started for [" + this.getRegionInfo().getEncodedName() + "] - because the WAL is closing."; status.setStatus(msg); return new FlushResult(FlushResult.Result.CANNOT_FLUSH, msg); } // flush 操作对应的日志的sequence id flushSeqId = this.sequenceId.incrementAndGet(); } else { // use the provided sequence Id as WAL is not being used for this flush. flushSeqId = myseqid; } for (Store s : stores.values()) { totalFlushableSize += s.getFlushableSize(); storeFlushCtxs.add(s.createFlushContext(flushSeqId)); } // prepare flush (take a snapshot) for (StoreFlushContext flush : storeFlushCtxs) { flush.prepare(); // 冻结memstore,后续进行flush到HFile } } finally { this.updatesLock.writeLock().unlock(); //解写锁,可以继续接受写入了 }
然后调用mvcc.waitForRead(w),该函数返回后,那么w之前的所有的写事务都已经结束并且对外可见,后续即可flush。接着,进行实际的flush操作,调用每个
StoreFlushContext的flushCache(),进而会调到HStore的flushCache():
// 对于不同的storeEngine返回的Flusher不一样,默认是DefaultStoreEngine,还可以是StripeStoreEngine,它来源于Compression策略参看(HBASE-7667) StoreFlusher flusher = storeEngine.getStoreFlusher(); IOException lastException = null; for (int i = 0; i < flushRetriesNumber; i++) { try { //对memstore进行flush,返回的文件名通过 fs.createTempName()得到,generateUniqueName(null)得到文件名(不包括目录) //对于DefaultStoreEngine来说,一个memstore会产生一个HFile,StripeStoreEngine会产生几个(HBASE-7667) List<Path> pathNames = flusher.flushSnapshot( snapshot, logCacheFlushId, snapshotTimeRangeTracker, flushedSize, status); Path lastPathName = null; try { for (Path pathName : pathNames) { lastPathName = pathName; validateStoreFile(pathName); } return pathNames;
2. 调region.addRegionToSnapshot(),它主要是将region info写入到snapshot到临时目录中的文件.regioninfo中,然后在临时目录的各个column family文件夹中,创建和存有数据的HFile文件名相同的空文件,代表对实际HFile的引用。
至此,Snapshot结束.
参考资料:
hbase-server-0.98.4-hadoop2.jar
https://issues.apache.org/jira/browse/HBASE-7667
https://issues.apache.org/jira/browse/HBASE-6055