[原]HBase Snapshot- 2 -Snapshot源码分析

作者:clark010
出处:http://www.jianshu.com/u/f9af3f199145
版权:本文版权归作者所有
转载:欢迎转载,但未经作者同意,必须保留此段声明;必须在文章中给出原文连接;否则必究法律责任


Snapshot过程不涉及到底层数据文件的移动和拷贝,中间只会对当前snapshot所引用的文件做meta记录,生成对应的data.manifest文件,并且SnapshotFileCache会通过freshCache更新被snapshot引用的文件到cache中,这样后台的清理线程就不会将hfile清理掉,以便于后面restore恢复。
因为涉及到对一个表的所有region做snapshot操作,本质上是一个分布式操作,HBase底层实现了一套Procedure机制支持分布式任务(包括snapshot、balance、mem flush等)。客户端请求Master对某一个表做snapshot,Master通发布snapshot任务到zk上并等待所有RS完成,RS接受并处理请求到最终完成请求,Master收集结果并返回最终结果给客户端。
下面会分别分析一下Client、Master、RegionServer的代码实现


Client

  1. Client调用HBaseAdmin的snapshot接口发起snapshot请求
    • SnapshotDescription数据结构中最主要的是snapshot_name/table_name/type,其中type为enum类型,有三个常量:DISABLED/FLUSH/SKIPFLUSH,指定三种做snapshot的方式,第一个是对disabled的表做snapshot,后两个是对enable的表的操作,FLUSH是snapshot之前先flush内存,SKIPFLUSH不需要flush内存
  • 调用taskSnapshotAsync,向master异步提交一个snapshot请求
    [原]HBase Snapshot- 2 -Snapshot源码分析_第1张图片
  • 拿到response,循环等待snapshot完成,如果超过最大的timeout时间则抛SnapshotCreationException异常并退出,但是实际上snapshot可能还在做,并最终成功
    [原]HBase Snapshot- 2 -Snapshot源码分析_第2张图片

Master

  1. master端接收到client端的snapshot rpc请求,调用snapshotManagertakeSnapshot实际处理snapshot请求,taskSnapshot也是异步的处理逻辑,所以很快返回
    [原]HBase Snapshot- 2 -Snapshot源码分析_第3张图片
  • 再看SnapshotManagertakeSnapshot中的逻辑
    • 判断是否已经做过snapshot


    • 触发pre snapshot coprocessor逻辑


    • 判断是enabled的表还是disabled的表,对于disabled的表直接通过master做snapshot,而enabled的表则需要有RS实际完成snapshot过程,下面分别看一下两个路径的实现


      [原]HBase Snapshot- 2 -Snapshot源码分析_第4张图片
      • disabled表snapshot
        • 首先prepareToTabkeSnapshot,判断是否正在做snapshot或者在restore过程,如果是则直接异常退出,否的话继续。然后清理并创建workingDir(//.hbase-snapshot/.tmp/)
        • 重置SnapshotDescription的type为DISABLED
        • 构造TableSnapshotHandler,其中创建SnapshotManifest对象以及snapshot表的写锁(在prepare中aquire)
          [原]HBase Snapshot- 2 -Snapshot源码分析_第5张图片
        • 调用snapshotTable
          • handler prepare,对表加写锁,加载table的description信息
          • 将handler提交线程池分配线程执行
          • 将handler加入到snapshotHandler
            [原]HBase Snapshot- 2 -Snapshot源码分析_第6张图片
        • ok再进入table snapshot handler中看一下process执行逻辑
          • 首先创建了两个文件,.inprogress标志文件、.snapshot-info写入本次Snapshot的desc信息


          • 请求得到表的所有region信息,并对所有region进行同步的snapshot(snapshotRegions接口逻辑在[Enabled|Disabled]TableSnapshotHandler中实现)
            [原]HBase Snapshot- 2 -Snapshot源码分析_第7张图片
            • 进入DisabledTableSnapshotHandler中看一下snapshotRegions的接口实现
            • 实际通过snapshotManifest调用了region的snapshot,每个region也会在workingDir下临时生成每个region的manifest文件
              [原]HBase Snapshot- 2 -Snapshot源码分析_第8张图片
            • manifest addRegion
              1. 创建ManifestBuilder
              2. 将region信息写入manfiest
              3. 将family信息写入manifest
              4. 将当前region的所有store file写入manifest
              5. 最终调用regionClose将manifest内容写出到文件中
                [原]HBase Snapshot- 2 -Snapshot源码分析_第9张图片
            • 看一下store file写入manifest的逻辑,主要保存了file的name和size,如果是reference文件,则set reference标志
              [原]HBase Snapshot- 2 -Snapshot源码分析_第10张图片
              • reference文件会在split过程产生,在实际hfile没有split完成时逻辑表示一个region的hfile
          • 所有region的snapshot结束后,做了三件事
            • snapshotManifest内容写出到data.manifest文件
            • 验证region snapshot(防止region的迁移等情况),如果不一致需要failed掉
            • 将snapshot数据从.tmp路径移动到正式路径(.hbase-snapshot)下


              [原]HBase Snapshot- 2 -Snapshot源码分析_第11张图片
          • 到这里disabled表的snapshot流程就完成了
      • enabled表snapshot
        • enabled表的snapshot过程的代码调用路径和disabled的情况基本一致,只是在TableSnapshotHandlersnapshotRegions接口的实现不一样,下面直接从这个函数入口分析一下enabled table,对于其他的流程调用参考disabled的情况
        • 可以看到enabled表通过ProcedureCoordinator提交了一个Procedure任务,然后就waitForCompleted
          [原]HBase Snapshot- 2 -Snapshot源码分析_第12张图片
        • 在这里不具体讲Procedure的逻辑,我们只需要大概的知道,hbase master通过zk和region server做交互(具体对应ZKProcedureCoordinatorRpcs实现),master在zk上创建具体任务的aquire根节点,并对table所有Region的RegionServer创建一个对应的znode节点并watch此node,而RegionServer上有对应的watcher(ZKProcedureMemberRpcs)发现有任务就领取,处理结束后通过zk通知完成

RegionServer

通过前面的代码分析,我们知道disabled表的snapshot直接在master端完成,而enabled表的snapshot需要RS参与并实际执行snapshot逻辑,下面分析一下snapshot在RS端的实现逻辑,同样Procedure部分的代码部分省略

  • 首先RS接收到任务后,会先create一个SubProcedure

    [原]HBase Snapshot- 2 -Snapshot源码分析_第13张图片
  • 判断type类型是否需要flush内存,但是貌似flush和skipflush的代码一样,具体在FlushSnapshotSubprocedure中判断
    [原]HBase Snapshot- 2 -Snapshot源码分析_第14张图片
  • 进入FlushSnapshotSubprocedurecall方法,首先调用region的startRegionOperation方法,对region加锁防止数据的更新,然后判断是否需要flush内存,最后调用HRegion的addRegionToSnapshot方法执行实际的逻辑
    [原]HBase Snapshot- 2 -Snapshot源码分析_第15张图片
  • 进入addRegionToSnapshot方法,发现最后处理逻辑也是调用了SnapshotManifest的addRegion方法,这和Disabled表的逻辑就汇合一致了,其实EnabledTableSnapshot要分布式的通过RS完成还是为了对region加锁的一个操作……
    [原]HBase Snapshot- 2 -Snapshot源码分析_第16张图片

结语

OK,到这里基本Snapshot的整个流程就分析完了,虽然没有详细到分析到具体data.manifest文件的格式,但是主要把握住大的逻辑,小逻辑就靠后面细细的看代码了,也许后面有精力也会单独加一章分析data.manifest的格式

你可能感兴趣的:([原]HBase Snapshot- 2 -Snapshot源码分析)