作者：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请求
  
• 拿到response，循环等待snapshot完成，如果超过最大的timeout时间则抛SnapshotCreationException异常并退出，但是实际上snapshot可能还在做，并最终成功
  

Master

1. master端接收到client端的snapshot rpc请求，调用snapshotManager的takeSnapshot实际处理snapshot请求，taskSnapshot也是异步的处理逻辑，所以很快返回
   

• 再看SnapshotManager的takeSnapshot中的逻辑

  • 判断是否已经做过snapshot

    
    

  • 触发pre snapshot coprocessor逻辑

    
    

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

    
    
    • disabled表snapshot
      • 首先prepareToTabkeSnapshot，判断是否正在做snapshot或者在restore过程，如果是则直接异常退出，否的话继续。然后清理并创建workingDir(/<hbase-root>/.hbase-snapshot/.tmp/<snapshot-name>)
      • 重置SnapshotDescription的type为DISABLED
      • 构造TableSnapshotHandler，其中创建SnapshotManifest对象以及snapshot表的写锁（在prepare中aquire）
        
      • 调用snapshotTable
        • handler prepare，对表加写锁，加载table的description信息
        • 将handler提交线程池分配线程执行
        • 将handler加入到snapshotHandler中
          
      • ok再进入table snapshot handler中看一下process执行逻辑

        • 首先创建了两个文件，.inprogress标志文件、.snapshot-info写入本次Snapshot的desc信息

          
          
        • 请求得到表的所有region信息，并对所有region进行同步的snapshot（snapshotRegions接口逻辑在[Enabled|Disabled]TableSnapshotHandler中实现）
          
          • 进入DisabledTableSnapshotHandler中看一下snapshotRegions的接口实现
          • 实际通过snapshotManifest调用了region的snapshot，每个region也会在workingDir下临时生成每个region的manifest文件
            
          • manifest addRegion
            1. 创建ManifestBuilder
            2. 将region信息写入manfiest
            3. 将family信息写入manifest
            4. 将当前region的所有store file写入manifest
            5. 最终调用regionClose将manifest内容写出到文件中
               
          • 看一下store file写入manifest的逻辑，主要保存了file的name和size，如果是reference文件，则set reference标志
            
            • reference文件会在split过程产生，在实际hfile没有split完成时逻辑表示一个region的hfile
              
        • 所有region的snapshot结束后，做了三件事
          • snapshotManifest内容写出到data.manifest文件
          • 验证region snapshot（防止region的迁移等情况），如果不一致需要failed掉

          • 将snapshot数据从.tmp路径移动到正式路径(.hbase-snapshot)下

            
            
        • 到这里disabled表的snapshot流程就完成了
    • enabled表snapshot
      • enabled表的snapshot过程的代码调用路径和disabled的情况基本一致，只是在TableSnapshotHandler的snapshotRegions接口的实现不一样，下面直接从这个函数入口分析一下enabled table，对于其他的流程调用参考disabled的情况
      • 可以看到enabled表通过ProcedureCoordinator提交了一个Procedure任务，然后就waitForCompleted
        
      • 在这里不具体讲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
  
  
  
• 判断type类型是否需要flush内存，但是貌似flush和skipflush的代码一样，具体在FlushSnapshotSubprocedure中判断
  
• 进入FlushSnapshotSubprocedure的call方法，首先调用region的startRegionOperation方法，对region加锁防止数据的更新，然后判断是否需要flush内存，最后调用HRegion的addRegionToSnapshot方法执行实际的逻辑
  
• 进入addRegionToSnapshot方法，发现最后处理逻辑也是调用了SnapshotManifest的addRegion方法，这和Disabled表的逻辑就汇合一致了，其实EnabledTableSnapshot要分布式的通过RS完成还是为了对region加锁的一个操作……
  

结语

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