当前位置: 首页 > 科技观察

业务不中断,腾讯10P+财务数据跨机房迁移实践

时间:2023-03-15 15:46:48 科技观察

本次分享将系统介绍10P+财务数据迁移的全过程。以下是本次线上分享的文字总结,希望对想了解HBase跨机房迁移技术的网友有所帮助。一、HBase知识介绍考虑到前来听讲分享的大部分都是MySQLDBA,这里对HBase做一个简单的介绍,主要介绍以下三个方面:一、HBase介绍HBase是一个开源实现基于googlebigtable,又称hadoop数据库,具有高性能、高可用、易扩展等特点。它是一个面向列的分布式存储系统,可以在廉价的PCServer机器上构建海量存储服务。随着数据量的不断增加,查询和写入的性能不会有明显的下降。可以说是各大企业建设数据中心的不错选择。2、HBase的优缺点HBase的优缺点总结HBase的几个优点如下:可以动态增加列下面可以有很多列,也就是说列族下面的列可以动态增加或减少。非常好的写入性能HBase采用LSM类型的系统结构。写入是先写入内存,然后异步批量刷新到磁盘,所以写入性能非常好。而这个写性能很容易通过扩容机器来提升。海量存储HBase为海量存储而生。由于其优秀的架构设计,数据量不断增长,查询延迟不会下降特别多。因此,HBase在海量数据场景下优势明显。极易扩展HBase由于其架构的特点(后端采用HDFS存储,借助ZK相关特性),HBase极易扩展。通过增加节点,可以增加存储容量,提高写入性能,使HBase具有高度的可扩展性。HBase的缺点HBase的缺点总结如下:HBase原生不支持SQLHBase原生不支持SQL,业务访问HBase需要通过接口修改,一定程度上不友好。虽然目前有一些组件对HBase提供了一些接口支持,比如phoenix。但是在我们的测试中,稳定性仍然是个大问题。查询延迟比DB大。HBase有更多的应用程序使用廉价的PC服务器来构建海量存储服务。目前DB的标准配置基本都是SSD盘,DB的延迟可以达到0.x毫秒。构建的海量存储服务的延迟一般在几十毫秒到几百毫秒之间。当然HBase也可以使用SSD盘来搭建海量存储,但是成本比较高。目前HBase已经支持异构存储功能,可以将热数据存储到SSD,将冷数据存储到SATA,这是一个很好的解决方案。经历过RegionServer单点运维的同学可能深有体会。表的某个region只能分配给某个RegionServer机器。所以,当某个RegionServer出现异常时,肯定会影响到上面的Region,尤其是当一个RegionServer上有超过1000个region时,影响可能达到几分钟。这个单点问题还是比较大的硬伤。目前HBase2.0版本已经引入了RegionReplica的支持,但是由于需要更多的资源以及读一致性强的问题,业界很少有人真正在生产环境中使用这个功能。更多时候,集群容灾用于业务层的切换。目前,我们正在通过这种方式来降低单个RegionServer异常对业务的影响。3、HBase架构HBase的架构图如下:上面是一张比较经典的HBase架构图。如果你懒,就借用它。从图中可以看出HBase的架构层次还是很清晰的。这个架构可以分为三层(暂时忽略Zookeeper和Master):一层:客户端层客户端层主要是发起业务的地方。可以是编写发起端,也可以是业务查询端。这个比较好理解,就是HBase的调用者。第二层:RegionServer层RegionServer提供了接入层的所有功能。layer可以简单理解为路由层、缓存层、引擎层等,所有对HBase的读写请求都需要经过RegionServer层。三层:存储层HBase底层使用HDFS作为存储层,所有数据都存储在HDFS中。前面提到的HBase具有很强的可扩展性,这很大程度上得益于底层使用的HDFS存储。4、一个DBA能看懂的HBase使用场景上面说了这么多,那么HBase到底是怎么用的呢?其实HBase可以用在很多场景,比对消息顺序,定时DB,对象存储,推荐画像等等,这里说一个DB最能理解的使用场景,就是存储海量的历史数据,需要保存了很长时间。例如,对于财务数据,由于监管要求,需要至少保存5年。对于支付订单、配套流量等数据,本身数据量就非常大,同时也有历史数据的查询需求。如果将这种数据保存在关系型DB中,那么历史DB的扩容、迁移、维护和访问将是DBA们的噩梦。但是如果把这种数据保存在HBase中,会很方便。二、HB??ase跨机房迁移一、背景及挑战背景本次HBase跨机房迁移的背景是机房被撤销,HBase集群必须从被撤销的机房迁移到新机房内指定的时间。挑战对于本次HBase跨机房迁移,我们主要面临以下挑战:缺乏经验。我只是做了一些研究,并没有多少实战经验。只能摸着石头过河。业务不能中断。既然是金融业务,业务就不能中断。因此,需要保证迁移的顺利进行。数据一致性财务数据要保证数据的准确性和一致性,数据不能少、不能错。我们始终把数据一致性放在最重要的位置。数据量大本次迁移涉及10P+数据,不能影响现有业务,这本身就是一个不小的挑战。2.方案选择本次迁移,由于经验不足,研究了很多行业的一些迁移方案和案例,总结出以下方案。我们最终选择了SnapShot+cluster写的方案:下面我们来看一下各个方案的具体情况:Replication方案Replication类似于MySQL的同步方案。它还通过同步日志(WAL日志)实现HBase数据的增量同步。该方案主要基于增量数据的同步,与主从集群版本类似,开启复制功能也需要重启集群。我们这次迁移涉及的版本变化比较大(之前的集群版本比较老),有10P+的历史数据,而且这种方式不兼容我现在的集群双写方案,所以没有采用这种方案。Distcp方案Distcp通过MR拷贝HDFS底层文件实现数据迁移。由于不涉及RegionServer层,效率非常高,非常适合历史数据(不会再修改的数据)的迁移。对于实时表,需要停止写入以保证数据的一致性。CopyTable方案类似于Export/Import方案。CopyTable方案类似于Export方案。它们都是通过MR扫描表来实现的。不同的是,CopyTable通过MR扫描数据后,直接将数据写入另一个集群,实现数据迁移。导出扫描后保存为文件,转移到其他集群后再导入,实现数据迁移。这种数据扫描需要通过RegionServer层来完成。如果表很大,对在线读写的影响会比较大。这种方案比较适合小表的迁移。SnapShot方案SnapShot通过快照实现HBase数据一致性迁移。这样,创建快照时就创建了文件引用指针。传输时直接通过MR复制HDFS底层文件,创建非常快速高效,并且对线路影响很小,可以很好的保证数据的一致性。SnapShot是目前各committer推荐的数据迁移方式。另外这个方案完全兼容我们的集群双写方案,所以我们最终采用了这个方案。备注:对于SnapShot方案,需要特别注意的是hbase.hstore.time.to.purge.deletes设置的时间一定要长于表的整体迁移时间(包括做快照的总时间)、传输快照、导入快照),否则会导致数据冗余的问题。3.迁移架构图及详细流程迁移架构图的详细迁移流程如上图所示。详细迁移过程如下:将表结构从A机房同步到B机房;启用集群双写;为某个类的表创建一个SnapShot;SnapShot创建完成后,使用exportsnapshot工具将快照迁移到新集群;使用bulkload方法将快照涉及的HFile文件导入到新集群中;使用集群间数据比对工具验证表上的集群间数据;数据校验通过后,即可启动灰度切换服务。4.注意事项与对策大规模数据迁移的注意事项还是很多的。以下是需要注意的事项和我们的应对措施:数据一致性问题在迁移中,数据一致性问题是首先考虑的问题,而我们在迁移财务数据,一致性问题是我们考虑的重点。为了保证数据的一致性,我们的对策是:在制定迁移方案之前,将数据一致性列为重中之重,充分考虑数据一致性问题;方案制定后,进行各种场景测试,确保数据的一致性;集群双写保证增量数据的一致性,使用快照保证历史数据的一致性;使用集群间数据协调来保证数据的最终一致性。业务连续性问题针对业务连续性问题,我们对接口做了细粒度的改造,目前切换粒度支持表级切换。在切换的时候,我们也会根据业务的重要优先级和访问量,在接口层面进行跨机房的灰度切换,保证对业务的影响最小。流量控制问题对于这样大规模的数据迁移,我们更担心的是在跨机房传输快照时,会充分利用机房的带宽,导致其他业务受到影响。因此,我们有两种应对策略:在传输快照时,添加-bandwidth参数控制流量;与网络平台对接,同步迁移计划,关闭防火墙限流,密切关注机房流量,逐步灰度化任务,确保流量控制在60%以下。数据量大、表多的问题针对表数据量大、表多的问题,主要担心迁移时会出现遗漏,或者迁移任务失败后遗漏。所以,这里主要是任务管理。我们主要做两件事来保证项目的进度和任务:制定详细的迁移计划,细化到表的粒度;开发自动化迁移工具,实现任务的自动发起、查看、跟踪、重试。五、跨机房经验总结在HBase跨机房迁移的过程中,遇到了很多问题,积累了很多经验。总结列在这里,供大家学习。感兴趣的网友可以根据主题做相应的阅读:HBase金融大数据大转移www.jianshu.com/p/cb4a645dd66aHDFS异构存储实战www.jianshu.com/p/167d7677a050HBase隔离方案实战www.jianshu.com/p/04d56a2c8b5c玩转HBase快照www.jianshu.com/p/8d091591d872dfs.datanode.du.reserved引起的问题www.jianshu.com/p/508449d8f12cSSD耗尽问题www.jianshu.com/p/167d7677a050排错思路相关toMapReducewww.jianshu.com/p/ebd469da07d2三、HBaseSnapShot深入介绍1、SanpShot原理介绍HBase的SnapShot可以理解为指向原始数据的指针,包括表对应的元数据和相关信息文件。之所以在创建快照后,HBase可以根据这些数据的指针恢复快照时的数据,是因为HBase数据文件一旦放到磁盘上,就不允许就地修改。如果要修改,则必须附加到新文件。另外需要注意的是HBase本身也会修改HFile文件,因为涉及到文件的合并。这里HBase会在合并HFile文件之前,将对应的表复制到归档目录中,以保证HFile文件的完整性。2.SnapShot的详细过程由于HBase表相关的数据以Region的形式分布在多个RegionServer上,所以在进行快照时,必须保证快照要么成功,要么失败。不能出现部分RegionSever创建快照成功,部分RegionServer创建快照成功的情况。快照创建失败的情况。HBase使用两阶段提交的方式来创建快照,分别是准备阶段和提交阶段。当快照创建异常时,有一个abord阶段:Step1:client向master发起创建表快照的请求;Step2:prepare阶段,master会在zookeeper上创建/acquired-snapshotname(简称/acquired_sname)节点,记录表的相关信息;第三步:RegionServer检测/acquired_sname节点,根据上表信息确认RegionServer是否包含该Region,如果有则参与创建快照,如果没有则忽略;第四步:当RegionServer参与prepare阶段时,会先加一个全局锁。此时不允许这张表有数据写入、更新和删除,将memstore中的数据flush到文件中,并为涉及到的所有HFile文件创建引用指针。这些指针元数据是快照,将这些元数据和表相关信息写入临时目录;第五步:第四步完成后,会在/acquired_sname中新建一个RegionServer对应的子节点,表示RegionServer已经完成prepare阶段;第六步:当master发现所有涉及的RegionServer都完成了prepare阶段的工作,就会发起commit阶段的操作;第七步:在commit阶段,master会在zookeeper上创建/reached-snapshotname(简称/reached-sname)。表中涉及的RegionSever监听到事件后,会开始commit阶段的工作,将临时目录下的快照数据写入正式目录。操作完成后,会在/reached-sname中新建一个RegionServer对应的子节点;Step8:当master发现涉及的所有RegionServer都完成了commit阶段的工作后,master还需要进行一个summary操作。汇总操作完成后,整个快照的创建就完成了。Step9:如果前一阶段的部分regionserver在一定时间内没有完成相应的操作,则进入abort阶段。在abort阶段,master会在zookeeper上创建/abord_snapshotname(简称/abord_sname),涉及到的RegionServers会创建快照进程的回滚操作,删除临时文件夹的快照内容。3.SanpShot的实际快照使用比较简单。来看看实战:创建snapshotsnapshot'tableName','snapshotName'备注:在hbaseshell中执行。查看snapshotlist_snapshots查找以mapsnapshotlist_snapshots'map.*'deletesnapshotdelete_snapshot'snapshotName'migratesnapshotbaseorg.apache.hadoop.hbase.snapshot.ExportSnapshot\-snapshotsnapshot_src_table\-copy-fromhdfs://src-hbase-root-dir/开头的快照hbase\-copy-tohdfs://dst-hbase-root-dir/hbase\-mappers20\-bandwidth1024将快照表迁移到其他集群时使用该方法。使用MR复制数据速度非常快,使用时记得设置带宽参数,以免网络爆满导致线上业务失败。如果没有混合MR,需要搭建MR集群,需要在命令行中添加MR集群的相关参数。Restoresnapshotrestore_snapshot'snapshotName'备注:该方法需要先禁用表,然后才能执行restore_snapshot操作。如果数据还在写入中,需要通过bulkload导入。使用bulkload将快照导入hbaseorg.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles\-Dhbase.mapreduce.bulkload.max.hfiles.perRegion.perFamily=1024\hdfs://dst-hbase-root-dir/hbase/archive/datapath/tablename/filenametablename说明:该方法需要遍历所有文件,通过bulkload全部导入。以上只是文件导入。此方法不需要禁用表。Q&A:除了上面提到的业务灰度切换的过程,从开始迁移到数据检验的自动化部分,您还有更多的分享吗?A:除了业务灰度切换的过程之外,从开始迁移到数据检验其实也是一个代码实现的过程,比如我们先创建一个快照,这样代码实现起来就很容易了。成功后会启用exportsnapshot方法将快照从一个集群迁移到另一个集群,并传入快照的名称,直接通过参数传递。在程序中实现。bulkload的导入也是一样的。确认导入成功后,删除原来的快照进行数据校验比对。讲师介绍了网名飞鸿无痕的腾讯资深DBA张秀云。2007年进入职场后,一路升级打怪,从网管、Linux运维,到小公司DBA,再到腾讯金融DBA。目前负责腾讯金融DB和分布式HBase数据中心的运维和规划工作。丰富的数据库运维、分布式存储实践经验。个人简书:www.jianshu.com/u/9346dc2e9d3e