不间断营业，腾讯10P+金融数据跨机房迁徙拭魅战
|
副问题[/!--empirenews.page--]
一、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必要通过接口做一些改革，这在必然水平上照旧不太友爱。固然今朝有一些组件也为HBase提供一些接口支持，好比phoenix。可是就我们的测试来看，不变性如故是一个很大的题目。
HBase较量多的应用是通过便宜的PC Sever构建海量存储处事，而今朝DB的标配根基都是SSD盘，DB的耽误可以做到0.x个毫秒，而基于便宜PC Server构建的海量存储处事的耽误一样平常在几十毫秒到上百毫秒之间。 虽然HBase也可以回收SSD盘来构建海量存储，但这种本钱就较量高。今朝HBase已经支持了异构存储成果，可以将热数据存储到SSD，冷数据存储到SATA，这是一个很好的方案。
运维过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方案 （编辑：河北网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
