不中断业务，腾讯10P+金融数据跨机房迁移实战

CopyTable和Export方案类似，都是通过MR去scan表的方式实现，不同的是，CopyTable通过MR scan出数据后直接写入另外一个集群，实现数据的迁移。而Export则是scan后保存为文件，传输到另外一个集群后再做import的操作，从而实现数据的迁移。

这种由于需要通过RegionServer层来做数据的scan，如果表很大的话，会对线上的读写有比较大的影响。这种方案比较适合小表的迁移。

SnapShot方案

SnapShot是通过快照来实现HBase数据一致性迁移，这种方式在创建快照的时候会创建文件的引用指针，在传输的时候，通过MR直接拷贝底层HDFS文件，因此创建非常快，效率很高，并且对线上冲击很小，能很好的保证数据的一致性。

SnapShot是目前各个commiter比较推荐的迁移数据方式，再加上这种方案和我们的集群双写方案完全兼容，因此我们最终采用了这个方案。

备注：SnapShot的方案特别需要注意的是，hbase.hstore.time.to.purge.deletes设置的时间一定要比表整体的迁移时间要长(包含做快照、传输快照和导入快照总时间)，否则会导致数据冗余的问题。

3、迁移的架构图和详细流程

迁移的架构图

迁移的详细流程

如上图所示，我们迁移的详细流程如下：

• 将表结构同步从A机房同步到B机房;
• 启用集群双写;
• 针对某一类表创建SnapShot;
• 创建好SnapShot后，使用exportsnapshot工具将快照迁移到新集群;
• 使用bulkload的方式将快照涉及的HFile文件导入到新集群;
• 使用集群间数据比对工具，对表做集群间数据校验;
• 数据校验通过以后，就可以开始灰度切换业务;

4、注意事项和应对策略

进行大规模的数据迁移，还是有比较多的注意事项，下面是需要注意的事项和我们的应对措施：

数据一致性性问题

在迁移中，数据一致性问题是首先要考虑的问题，加上我们迁移的是金融数据，一致性问题更是我们考虑的重点。为了保证数据的一致性，我们的应对措施如下：

• 在制定迁移方案之前就将数据一致性列在最重要的位置，充分考虑数据一致性问题;
• 在方案制定后，进行各个场景的测试，确保数据的一致性;
• 集群双写保证增量数据一致，通过snapshot来保证历史数据的一致性;
• 使用集群间数据对账来兜底，保证数据最终一致性。

业务连续性问题

针对业务的连续性问题，我们是对接口做了细粒度的改造，目前使得切换粒度支持表级别的切换。我们在切换的时候也根据业务的重要优先级以及访问量，来做接口级别的跨机房灰度切换，确保对业务的影响最小。

流量控制问题

对于如此大规模的数据迁移，我们比较担心的是跨机房传输快照的时候，把机房带宽打满，导致其他的业务受影响。因此我们的应对策略有两个：

• 传输快照的时候，添加-bandwidth参数做好流控;
• 和网平联动，同步迁移计划，关闭防火墙限流，并密切关注机房间的流量，逐步灰度任务，确保流量控制在60%以下。

数据量大涉及表多的问题

针对表数据量大和表多的问题，主要担心的是迁移的时候会造成遗漏，或者迁移任务失败了后遗漏了。因此这里主要是做好任务管理，我们主要做了两个事情来保证项目的进展和任务：

• 制定详细的迁移计划，粒度细化到表;
• 开发自动化迁移工具，实现自动化任务发起、查看、追踪、和重试。

5、跨机房经验总结

在做HBase跨机房迁移的过程中，我们遇到了非常多的问题，也积累了非常多的经验，我们对于迁移的流程、注意事项、使用到的技术、部署等都做了总结，这里列出来方便大家学习，有兴趣的网友可以根据主题做对应的阅读：

• HBase金融大数据乾坤大挪移
• www.jianshu.com/p/cb4a645dd66a
• HDFS异构存储实战
• www.jianshu.com/p/167d7677a050
• HBase隔离方案实战
• www.jianshu.com/p/04d56a2c8b5c
• 玩转HBase快照
• www.jianshu.com/p/8d091591d872
• HBase生产环境部署指南
• www.jianshu.com/p/9533ac9de0fe
• dfs.datanode.du.reserved引发的问题
• www.jianshu.com/p/508449d8f12c
• SSD耗尽问题
• www.jianshu.com/p/167d7677a050
• MapReduce相关问题排查思路
• www.jianshu.com/p/ebd469da07d2

三、HBase SnapShot深入介绍

1、SanpShot原理简介

HBase的SnapShot可以理解为是原数据的指针，包含表对应的元数据和涉及到的HFile相关的信息。

之所以创建快照后，HBase能根据这些数据的指针还原出做快照时刻的数据，是因为HBase数据文件一旦落盘，就不允许在原地做修改。如果要修改，则必须追加写入新的文件。

还有一点需要注意的地方，就是HBase本身也会对HFile文件做修改，因为涉及到文件的合并。这里HBase会在HFile文件合并之前将对应的表复制到archive目录下，确保HFile文件的完整性。

2、SnapShot详细流程

由于HBase表相关的数据以region的形式分布在多台RegionServer上，在做快照的时候，必须保证快照的要么都成功，或者都失败，不能出现部分RegionSever创建快照成功，部分RegionServer创建快照失败的情况。

HBase采用两阶段提交的方式来创建快照，分别是prepare阶段和commit阶段，当创建快照异常的时候，还有个abord阶段：

Step 1：客户端向master发起表创建快照的请求;

Step 2：prepare阶段，master会在zookeeper上创建/acquired-snapshotname(简写为/acquired_sname)节点，并记录表相关的信息;

Step 3：RegionServer检测到/acquired_sname节点，并根据上面表的信息确认该RegionServer是否含有那个表的Region，如果有则参与到快照的创建中来，如果没有则忽略;

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!