Hbase Replication 介绍

Hbase Replication 介绍

现状

     Hbase 的replication目前在业界使用并不多见，原因有很多方面，比如说HDFS目前已经有多份备份在某种程度上帮助HBASE底层数据的安全性，而且很多公司的集群规模比较小并且对数据重要程度并不是很高，比如一些日志系统或者是作为一个历史数据的第二个仓库，来分流大量的读请求。这样及时数据丢失了也可以在其他的地方（数据库集群）中找回来。对于这样的情况Replication的Slave集群变得可有可无，重要性根本得不到体现。故如果管理员把hbase只作为一个低安全级别和非重要业务的一个管理平台，那么下面对于Replication集群的讨论可以不用浪费时间来阅读。目前阿里集团有相当重要的应用存在于Hbase之上，包括在线和非在线的应用。那么Hbase数据的安全性也显得弥足重要。对于单集群的存在的问题通常来自以下几个方面：

• 数据管理人员的失误，不可逆的DDL操作。

• 底层HDFS文件BLOCK块corruption

• 短时间过度的读数据对集群造成的压力，增加服务器应对这种情况比较浪费资源。

• 系统升级，维护，诊断问题会造成集群不可用时间增长。

• 双写的原子性难以保证

• 不可预计的一些原因。（如机房断电，大规模硬件损坏，断网等）

• 离线应用的MR计算对在线读写造成的较大的延迟影响

如果为以上问题担忧的话，Replication构建主被集群则是一种很好的选择，我们也在这方面的做了一些简单的研究。下面简单说下我们的使用中遇到的问题和采取的方法

常用的在线备份方案及其比较

对于数据中心的数据冗余的备份方案，目前从一致性，事务性，延迟，吞吐量，数据损失，Failover几个角度来分析有一下几种方案。

•       简单备份模式通过定时不定时的Dump出集群数据保证数据的安全性，通常可以通过snapshot或设置时间戳来dump数据来实现这种方案，如果方案简介，设计优雅可以做到对在线数据中心低干扰或无干扰的数据备份。但这种方案缺点也是显而易见的，只是对时间点之前的数据安全性得到保障，如果发生突发事件会导致不可避免的整段时间的数据丢失，为很多人无法接受。

•       主从模式（Master-Slave）这种模式比起简单的备份模式多了很多优点，可以通过最终一致性保证数据的一致，数据从主集群到备集群延时较低，异步写入不会对主集群带来性能压力，基本不会产生多少性能的影响，突发事件来临时数据丢失很少，并且主集群的事务在备集群也可以得以保证。一般通过构造较好的Log系统加上check Point来实现，可以实现读写分离，主集群可以担当读写服务，但备集群一般只承担读服务。

•       主主模式 (Master-Master)原理总体类似于主从模式，不同的是2个集群可以互相承担写的分离，都可承担读写服务。

•       2阶段提交这种方案保证了强一致性和事务，服务器返回给客户端成功则表明数据一定已经成功备份，不会造成任何数据丢失。每台服务器都可承担读写服务。但缺点是造成集群延迟较高，总体吞吐下降。

•       Paxos算法基于Paxos算法的实现的强一致性方案，同一客户端连接的server能保证数据的一致性。缺点是实现复杂，集群延迟和吞吐随着集群服务器增加而边差。

我们可以通过下面的一个图标来说明简化一下上面各种模式的特点。

	备份	主从	主主	2PC	Paxos
数据一致性	差	保证最终一致性		强一致性