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

 一、HBase知识介绍

考虑到来听分享的大部分都是MySQL DBA，因此这里做了个简单的HBase相关介绍，主要介绍了如下三个方面的内容：

1、HBase简介

HBase是基于google bigtable的开源实现，又称为hadoop database，具有高性能、高可用、易伸缩等特点，是一个面向列的分布式存储系统，可以在廉价PC Server的机器上搭建海量存储服务。

随着数据量的不断增大，查询和写入的性能并不会出现明显的下降，可以说是目前各大企业构建数据中心很好的选择。

2、HBase的优缺点

HBase的优点

总结了HBase的几个优点如下：

• 列可以动态增加

其实更准确的说，HBase是面向列族的数据库，一个表可以有多个列族，而每个列族下面可以有非常多的列，也就是说列族下面的列可以动态增加或者减少。

• 卓越的写入性能

HBase采用的是LSM类型系统结构，写入都是先写内存，后面再异步批量刷新到磁盘，因此写入性能非常好。并且这种写入性能很容易通过扩容机器提升。

• 海量存储

HBase就是为海量存储而生的，由于其优秀的架构设计，使得数据量的不断增长，在查询时延方面并不会下降特别多。因此HBase在海量数据的场景下，优势非常明显。

• 极易扩展

HBase由于其架构的特性(后端采用HDFS存储，借助ZK的相关特性)，HBase极易扩展，通过添加节点，来增加存储量和提升写入性能，使得HBase极具伸缩性。

HBase的缺点

总结了HBase的缺点如下：

• HBase原生不支持SQL

HBase原生并不支持SQL，业务接入HBase需要通过接口做一些改造，这在一定程度上还是不太友好。虽然目前有一些组件也为HBase提供一些接口支持，比如phoenix。但是就我们的测试来看，稳定性仍然是一个很大的问题。

• 查询延迟比DB大

HBase比较多的应用是通过廉价的PC Sever构建海量存储服务，而目前DB的标配基本都是SSD盘，DB的延迟可以做到0.x个毫秒，而基于廉价PC Server构建的海量存储服务的延迟一般在几十毫秒到上百毫秒之间。

当然HBase也可以采用SSD盘来构建海量存储，但这种成本就比较高。目前HBase已经支持了异构存储功能，可以将热数据存储到SSD，冷数据存储到SATA，这是一个很好的方案。

• RegionServer单点

运维过RegionServer的同学都可能深有体会，表的某一个region只能分配到某一台RegionSever的机器上，因此，当某一台RegionServer异常的时候，上面的Region肯定会有影响，尤其是当一个RegionServer上有超过1000个region的时候，影响可能会达到几分钟。这个单点的问题还是一个比较大的硬伤。

目前HBase2.0版本已经引入了Region Replica的支持，但是由于需要更多的资源和强读一致性的问题，业界真正在生产环境使用这个功能的非常少。比较多的是采用集群容灾方式，在业务层做切换，目前我们就是采用这种方式，以减少单个RegionServer异常对业务造成影响。

3、HBase架构

HBase的架构图如下：

上面是比较经典的HBase架构图，偷个懒，直接借来用一下，从图中我们可以看出HBase的架构层次还是很清晰的。可以把这个架构分成三层来看(暂时把Zookeeper和Master忽略)：

第一层：客户端层

客户端层主要是业务发起的地方，可以是写入发起端，也可以是业务查询端，这个比较好理解，就是HBase的调用方。

第二层：RegionServer层

RegionServer提供所有访问层的功能，你可以简单地理解为那一层是路由层、缓存层、引擎层等。所有对HBase的读写请求都需要经过RegionServer层。

第三层：存储层

HBase底层采用HDFS作为存储层，所有的数据都存储在HDFS，前面说的HBase极具伸缩性，很大程度上得益于底层采用的HDFS存储。

4、一个DBA都能理解的HBase使用场景

上面讲了那么多，那么HBase到底是怎么使用的?

其实HBase可以用在很多的场景中，比较消息订单、时序DB、对象存储、推荐画像等。这里讲一个DB最能理解的使用场景，那就是存储需要长久保存的海量历史数据。

比如：对于金融数据，由于监管的要求，至少需要保留5年，对于支付的订单、支持流水等数据，本身数据量非常大，并且历史数据还有查询需求。

这种数据如果保留在关系型的DB中，历史DB的扩容、迁移、维护，还有访问将会是DBA的噩梦。但是如果这种数据保留在HBase中，就会非常的方便。

二、HBase跨机房迁移

1、背景及挑战

背景

这次HBase跨机房迁移的背景是机房裁撤，必须在规定的时间内把HBase集群从裁撤机房迁移到新机房。

挑战

针对这次HBase跨机房迁移，我们主要面临如下几个挑战：

• 经验缺乏

在做这次迁移之前，我们团队缺乏HBase大规模数据迁移经验，而我自己之前主要做MySQL数据库相关的工作，对HBase也只是做过一些研究，实战经验并不多。只能摸着石头过河。

• 业务不能中断

由于是金融业务，业务上是不能出现中断的，因此，必须确保此次迁移平滑进行。

• 数据一致性

金融数据必须保证数据的准确性和一致性，数据不能少，也不能错。数据一致性我们始终是放在最重要的位置上。

• 数据量大

此次迁移涉及到10P+的数据，并且不能影响现有的业务，这本身就是一个蛮大的挑战。

2、方案选型

此次迁移，由于缺乏经验，我们研究了很多业界的一些迁移的方案和案例，总结出如下几个方案，我们最终选择了SnapShot+集群写的方案：

下面我们分别来看看各个方案的具体情况：

Replication方案

Replication和MySQL同步的方案比较类似，也是通过同步日志(WAL日志)的方式实现HBase数据的增量同步，这个方案主要是基于增量数据的同步，并且主从集群版本相同，启用replication功能还需要重启集群。

我们这次迁移涉及到比较大的版本变动(之前的集群版本比较老)，并且有10P+的历史数据，并且这种方式和我目前的集群双写方案也不兼容，因此我们没有采用这个方案。

Distcp方案

Distcp是通过MR拷贝HDFS底层文件的形式实现数据的迁移，由于不涉及到RegionServer层，因此效率非常高，非常适合历史数据(不会再有修改的数据)的迁移。针对实时表的话，则需要停写才能确保数据的一致性。

CopyTable方案和Export/Import方案

（编辑：核心网）

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