本周六晚上八点，在dbaplus进行了一场关于HBase跨机房迁移的分享，通过这次分享，给大家系统地介绍了10+p金融数据迁移的整个过程。下面是对这次分享的文字总结，希望对想了解HBase跨机房迁移的技术网友有帮助。
一、个人简介（这里就忽略了）
二、HBase知识介绍
考虑到来听分享的大部分都是MySQL DBA，因此这里做了个简单的HBase相关知识的介绍，主要介绍了如下三个方面的内容。
（一）、HBase简介
HBase是基于google bigtable的开源实现，又称为hadoop database，具有高性能、高可用、易伸缩等特点，是一个面向列的分布式存储系统。可以在廉价PC Server的机器上搭建海量存储服务，并且随着数据量的不断增大，查询和写入的性能并不会出现明显的下降。是目前各大企业构建数据中心很好的选择。
（二）、HBase的优缺点
1、HBase的优点
总结了HBase的几个优点如下：
a、列可以动态增加
其实更准确的说，HBase是面向列族的数据库，一个表可以有多个列族，而每个列族下面可以有非常多的列，也就是说列族下面的列可以动态增加或者减少。
b、卓越的写入性能
HBase采用的是LSM类型系统结构，写入都是先写内存，后面再异步批量刷新到磁盘，因此写入性能非常好。并且这种写入性能很容易通过扩容机器提升。
c、海量存储
HBase就是为海量存储而生的，由于其优秀的架构设计，使得数据量的不断增长，在查询时延方面并不会下降特别多。因此HBase在海量数据的场景下，优势非常明显。
d、极易扩展
HBase由于其架构的特性（后端采用HDFS存储，借助ZK的相关特性），HBase极易扩展，通过添加节点，来增加存储量和提升写入性能，使得HBase极具伸缩性。
2、HBase的缺点
总结了HBase的缺点如下：
a、HBase原生不支持SQL
HBase原生并不支持SQL，业务接入HBase需要通过接口做一些改造，这在一定程度上还是不太友好。虽然目前有一些组件也为HBase提供一下接口支持，比如phoenix。但是就我们测试来看，稳定性仍然是一个很大的问题。
b、查询延迟比DB大
HBase比较多的应用是通过廉价的PC Sever构建海量存储服务，而目前DB的标配基本都是SSD盘，DB的延迟可以做到0.x个毫秒，而基于廉价PC Server构建的海量存储服务的延迟一般在几十毫秒到上百毫秒之间。当然HBase也可以采用SSD盘来构建海量存储，但这种成本就比较高。目前HBase已经支持了异构存储功能，可以将热数据存储到SSD，而冷数据存储到SATA，这是一个很好的方案。
c、RegionServer单点
运维过RegionServer的同学都可能深有体会，表的某一个region只能分配到某一台RegionSever的机器上，因此，当某一台RegionServer异常的时候，上面的Region肯定会有影响，尤其是当一个RegionServer上有超过1000个region的时候，影响可能会达到几分钟。这个单点的问题还是一个比较大的硬伤。目前HBase2.0版本已经引入了Region Replica的支持，但是由于需要更多的资源和强读一致性的问题，业界真正在生产环境使用这个功能的非常少。比较多的是采用集群容灾方式，在业务层做切换，目前我们就是采用这种方式，以减少单个RegionServer异常对业务造成影响。
（三）、HBase架构
HBase的架构图如下：
上面是比较经典的HBase架构图，偷个懒，直接借来用一下，从图中我们可以看出HBase的架构层次还是很清晰的。可以把这个架构分成三层来看（暂时把Zookeeper和Master忽略）：
第一层：客户端层
客户端层主要是业务发起的地方，可以是写入发起端，也可以是业务查询端，这个比较好理解，就是HBase的调用方。
第二层：RegionServer层
RegionServer提供所有访问层的功能，你可以简单地理解为那一层是路由层、缓存层、引擎层等。所有对HBase的读写请求都需要经过RegionServer层。
第三层：存储层
HBase底层采用HDFS作为存储层，所有的数据都存储在HDFS，前面说的HBase极具伸缩性很大程度上得益于底层采用的HDFS存储。
（四）、一个DBA都能理解的HBase使用场景
上面讲了那么多，那到底HBase是怎么使用的？ 其实HBase可以用在很多的场景中，比较消息订单、时序DB、对象存储、推荐画像等很多领域，这里讲一个DB最能理解的使用场景，那就是存储需要长久保存的海量历史数据。
比如：对于金融数据，由于监管的要求，至少需要保留5年，对于支付的订单、支持流水等数据，本身数据量非常大，并且历史数据还有查询需求。这种数据如果保留在关系型的DB中，历史DB的扩容、迁移、维护，还有访问将会是DBA的噩梦。但是如果这种数据保留在HBase中，就会非常的方便。
三、HBase跨机房迁移
（一）、背景和面临的挑战
1、背景
这次HBase跨机房迁移的背景就是机房裁撤，必须在规定的时间内把HBase集群从裁撤机房迁移到新机房。
2、挑战
针对这次HBase跨机房迁移，我们主要面临如下几个挑战：
a、经验缺乏
在做这次迁移之前，我们团队缺乏HBase大规模数据迁移经验，而我自己之前主要做MySQL数据库相关的工作，对HBase也只是做过一些研究，实战经验并不多。只能摸着石头过河。
b、业务不能中断
由于是金融业务，业务上是不能出现中断的，因此，必须确保此次迁移平滑进行。
c、数据一致性
金融数据必须保证数据的准确性和一致性，数据不能少，也不能错。数据一致性我们始终是放在最重要的位置上。
d、数据量大
此次迁移涉及到10+P的数据，并且不能影响现有的业务，这本身就是一个蛮大的挑战。
（二）、方案选型
此次迁移，由于缺乏经验，我们研究了很多业界的一些迁移的方案和案例，总结出如下几个方案，我们最终选择了SnapShot+集群写的方案。下面我们分别来看看各个方案的具体情况：
1、Replication方案
Replication和MySQL同步的方案比较类似，也是通过同步日志（WAL日志）的方式实现HBase数据的增量同步，这个方案主要是基于增量数据的同步，并且主从集群版本相同，启用replication功能还需要重启集群。我们这次迁移涉及到比较大的版本变动（之前的集群版本比较老），并且有10+P的历史数据，并且这种方式和我目前的集群双写方案也不兼容，因此我们没有采用这个方案。
2、Distcp方案
Distcp是通过MR拷贝hdfs底层文件的形式实现数据的迁移，由于不涉及到RegionServer层，因此效率非常高，非常适合历史数据（不会再有修改的数据）的迁移。针对实时表的话，则需要停写才能确保数据的一致性。
3、CopyTable方案和Export/Import方案
CopyTable和Export方案类似，都是通过MR去scan表的方式实现，不同的是，CopyTable通过MR scan出数据后直接写入另外一个集群，实现数据的迁移。而Export则是scan后保存为文件，传输到另外一个集群后再做import的操作，从而实现数据的迁移。这种由于需要通过RegionServer层来做数据的scan，如果表很大的话，会对线上的读写有比较大的影响。这种方案比较适合小表的迁移。
4、SnapShot方案
SnapShot是通过快照来实现HBase数据一致性迁移，这种方式在创建快照的时候会创建文件的引用指针，在传输的时候，通过MR直接拷贝底层HDFS文件，因此创建非常快，效率很高。并且对线上冲击很小，又能很好的保证数据的一致性。SnapShot是目前各个commiter比较推荐的迁移数据的方式，再加上这种方案和我们的集群双写方案完全兼容，因此我们最终采用了这个方案。
备注：SnapShot的方案有一个特别需要注意的地方，就是hbase.hstore.time.to.purge.deletes设置的时间一定要比表整体的迁移时间要长（包含做快照、传输快照和导入快照总时间），否则会导致数据冗余的问题。
（三）、迁移的架构图和详细流程
1、迁移的架构图
2、迁移的详细流程
如上图所示，我们迁移的详细流程如下：
a、将表结构同步从A机房同步到B机房；
b、启用集群双写；
c、针对某一类表创建SnapShot；
d、创建好SnapShot后，使用exportsnapshot工具将快照迁移到新集群；
e、使用bulkload的方式将快照涉及到的HFile文件导入到新集群；
f、使用集群间数据比对工具，对表做集群间数据校验；
g、数据校验通过以后，就可以开始灰度切换业务；
（三）、注意事项和应对策略
进行大规模的数据迁移，还是有比较多的注意事项，下面是需要注意的事项和我们的应对措施：
1、数据一致性性问题
在迁移中，数据一致性问题是首先要考虑的问题，加上我们迁移的是金融数据，一致性问题更是我们考虑的重点，为了保证数据的一致性，我们的应对措施如下：
a、在制定迁移方案之前就将数据一致性列在最重要的位置，充分考虑数据一致性问题
b、在方案制定后，进行各个场景的测试，确保数据的一致性
c、集群双写保证增量数据一致，通过snapshot来保证历史数据的一致性
d、使用集群间数据对账来兜底，保证数据最终一致性
2、业务连续性问题
针对业务的连续性问题，我们是对接口做了更细粒度的改造，目前使得切换粒度支持表级别的切换，我们在切换的时候也根据业务的重要优先级以及访问量，来做接口级别的跨机房灰度切换。确保对业务的影响最小。
3、流量控制问题
对于如此大规模的数据迁移，比较担心的是跨机房传输快照的时候把机房带宽打满，大致其他的业务受影响。因此我们的应对策略有两个：
a、传输快照的时候，添加-bandwidth参数做好流控；
b、和网平联动，同步迁移计划，关闭防火墙限流，并密切关注机房间的流量，逐步灰度任务，确保流量控制在60%以下；
4、数据量大涉及表多的问题
针对表数据量大和表多的问题，主要担心的是迁移的时候会造成遗漏，或者迁移任务失败了后遗漏了。因此这里主要是做好任务管理，因此，我们主要做了两个事情来保证项目的进展和任务：
a、制定详细的迁移计划，粒度细化到表
b、开发自动化迁移工具，实现自动化任务发起、查看、追踪、和重试
（四）、跨机房经验总结
在做HBase跨机房迁移的过程中，我们遇到了非常多的问题，也积累了非常多的经验，我们对于迁移的流程、注意事项、使用到的技术、部署等都做了总结，这里列出来方便大家学习，有兴趣的网友可以根据主题做对应的阅读：
HBase金融大数据乾坤大挪移
https://www.jianshu.com/p/cb4a645dd66a
HDFS异构存储实战
https://www.jianshu.com/p/167d7677a050
HBase隔离方案实战
https://www.jianshu.com/p/04d56a2c8b5c
玩转HBase快照
https://www.jianshu.com/p/8d091591d872
HBase生产环境部署指南
https://www.jianshu.com/p/9533ac9de0fe
dfs.datanode.du.reserved引发的问题
https://www.jianshu.com/p/508449d8f12c
SSD耗尽问题
https://www.jianshu.com/p/167d7677a050
MapReduce相关问题排查思路
https://www.jianshu.com/p/ebd469da07d2
四、HBase SnapShot深入介绍
（一）、SanpShot原理简介
HBase的SnapShot可以理解为是原数据的指针，包含表对应的元数据和涉及到的HFile相关的信息。之所以创建快照后，HBase能根据这些数据的指针就能还原出做快照时刻的数据，是因为HBase数据文件一旦落盘，就不允许在原地做修改，如果要修改，则必须追加写入新的文件。还有一点需要注意的地方，就是HBase本身也会对HFile文件做修改，因为涉及到文件的合并。这里HBase会在HFile文件合并之前将对应的表复制到archive目录下，确保HFile文件的完整性。
（二）、SnapShot详细流程
由于HBase表相关的数据以region的形式分布在多台RegionServer上，在做快照的时候，必须保证快照的要么都成功或者都失败，不能出现部分RegionSever创建快照成功，部分RegionServer创建快照失败的情况。下图就是HBase创建快照的详细流程，下面就详细来介绍：
HBase采用两阶段提交的方式才创建快照，分别是prepare阶段和commit阶段，当创建快照异常的异常的时候，还有有个abord阶段，下面来介绍HBase创建快照的流程：
1、客户端向master发起表创建快照的请求；
2、prepare阶段，master会在zookeeper上创建/acquired-snapshotname（简写为/acquired_sname）节点，并记录表相关的信息；
3、RegionServer检测到/acquired_sname节点，并根据上面表的信息确认该RegionServer是否含有那个表的Region，如果有则参与到快照的创建中来，如果没有则忽略；
4、RegionServer参与parepare阶段的时候，首先会加一把全局锁，此时不允许这个表有数据写入、更新和删除，将memstore中的数据flush到文件中，并为涉及到的所有HFile文件创建引用指针，这些指针元数据便是snapshot，并将这些元数据以及表相关信息写入到临时目录中；
5、在第4步完成后，便会在/acquired_sname新建RegionServer对应的子节点，表示该RegionServer完成了prepare阶段；
6、当master发现所有的涉及到的RegionServer都完成了prepare阶段的工作后，就会发起commit阶段的操作；
7、在commit阶段，master会在zookeeper上创建/reached-snapshotname（简写为/reached-sname）,该表涉及的RegionSever监听到事件后，就会启动commit阶段的工作，将临时目录中的snapshot的数据写入到正式的目录，操作完成后便会在/reached-sname新建该RegionServer对应的子节点；
8、当master发现所有涉及到的RegionServer都完成了commit阶段的工作后，master还需要做一次汇总操作，汇总操作完成后，整个snapshot的创建就完成了。
9、如果在一定时间内前面阶段有的regionserver没有完成对应的操作，则会进入abord阶段，在abord阶段，master会在zookeeper上创建/abord_snapshotname（简称/abord_sname），涉及的RegionServer会进行创建快照流程的回滚操作，即将临时文件夹的快照内容删除。
（三）、SanpShot实战
snapshot的使用相对还是比较简单，下面来实战一下：
1、创建snapshot
snapshot 'tableName', 'snapshotName'
备注：在hbase shell中执行
2、查看snapshot
list_snapshots
查找以map开头的snapshot
list_snapshots 'map.*'
3、删除snapshot
delete_snapshot 'snapshotName'
4、迁移snapshot
hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot \
-snapshot snapshot_src_table \
-copy-from hdfs://src-hbase-root-dir/hbase\
-copy-to hdfs://dst-hbase-root-dir/hbase\
-mappers 20 \
-bandwidth 1024
这种方式用于将快照表迁移到另外一个集群的时候使用，使用MR进行数据的拷贝，速度很快，使用的时候记得设置好bandwidth参数，以免由于网络打满导致的线上业务故障。如果没有混布MR，则还需要搭建一个MR集群，并且命令行中需要再加入MR集群的相关参数
5、恢复snapshot
restore_snapshot ‘snapshotName’
备注：这种方式需要对表进行过disable才能进行restore_snapshot的操作，如果这个还在写入数据，则需要采用bulkload的方式导入。
6、将snapshot使用bulkload的方式导入
hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles \
-Dhbase.mapreduce.bulkload.max.hfiles.perRegion.perFamily=1024 \
hdfs://dst-hbase-root-dir/hbase/archive/datapath/tablename/filename tablename
备注：这种方式需要将所有的文件进行遍历并全部通过bulkload导入，上面的只是一个文件的导入，这种方式不需要disable表。
