完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
摘要: 基于时间线一致的高可用读(timeline-consistent High Available Reads),又称Region replica,为HBase带来了高可用读的能力。本文主要介绍region replica这个功能设计的背景,技术细节和使用方法,同时会仔细分析这个功能的优缺点并给出使用建议。前言基于时间线一致的高可用读(Timeline-consistent High Available Reads),又称Region replica。其实早在HBase-1.2版本的时候,这个功能就已经开发完毕了,但是还是不太稳定,离生产可用级别还有一段距离,后来社区又陆陆续续修复了一些bug,比如说HBASE-18223。这些bug很多在HBase-1.4之后的版本才修复,也就是说region replica功能基本上在HBase-1.4之后才稳定下来。介于HBase-1.4版本目前实际生产中使用的还比较少,把region replica功能说成是HBase2.0中的新功能也不为过。为什么需要Region Replica在CAP理论中,HBase一直是一个CP(Consistency&Partition tolerance)系统。HBase一直以来都在遵循着读写强一致的语义。所以说虽然在存储层,HBase依赖HDFS实现了数据的多副本,但是在计算层,HBase的region只能在一台RegionServer上线提供读写服务,来保持强一致。如果这台服务器发生宕机时,Region需要从WAL中恢复还缓存在memstore中未刷写成文件的数据,才能重新上线服务。
由于HBase的RegionServer是使用Zookeeper与Master保持lease。而为了不让JVM GC停顿导致RegionServer被master“误判”死亡,这个lease时间通常都会设置为20~30s,如果RegionServer使用的Heap比较大时,这个lease可能还会设的更长。加上宕机后,region需要re-assign,WAL可能需要 recoverlease和被replay操作,一个典型的region宕机恢复时间可能长达一分钟!这就意味着在这一分钟内,这个region都无法被读写。由于HBase是一个分布式系统,同一张表的数据可能分布在非常多的RegionServer和region里。如果这是一个大HBase集群,有100台RegionServer机器,那么宕机一台的话,可能只有1%的用户数据被影响了。但是如果这是小用户的HBase集群,一共就只有2台RegionServer,宕机一台意味着50%的用户数据都在1~2分钟之内无法服务,这是很多用户都无法忍受的。其实,很大一部分用户对读可用性的需求,可能比读强一致的需求还要高。在故障场景下,只要保证读继续可用,“stale read”,即读到之前的数据也可以接受。这就是为什么我们需要read replica这个功能。Region Replica技术细节Region replica的本质,就是让同一个region host在多个regionserver上。原来的region,称为Default Replica(主region),提供了与之前类似的强一致读写体验。而与此同时,根据配置的多少,会有一个或者多个region的副本,统称为 region replica,在另外的RegionServer上被打开。并且由Master中的LoadBalancer来保证region和他们的副本,不会在同一个RegionServer打开,防止一台服务器的宕机导致多个副本同时挂掉。 Region Replica的设计巧妙之处在于,额外的region副本并不意味着数据又会多出几个副本。这些region replica在RegionServer上open时,使用的是和主region相同的HDFS目录。也就是说主region里有多少HFile,那么在region replica中,这些数据都是可见的,都是可以读出来的。 region replica相对于主region,有一些明显的不同。 首先,region replica是不可写的。这其实很容易理解,如果region replica也可以写的话,那么同一个region会在多个regionserver上被写入,连主region上的强一致读写都没法保证了。 再次,region replica是不能被split和merge的。region replica是主region的附属品,任何发向region replica的split和merge请求都会被拒绝掉。只有当主region split/merge时,才会把这些region replica从meta表中删掉,建立新生成region的region的replica。replica之间的数据同步那么,既然region replica不能接受写,它打开之后,怎么让新写入的数据变的可见呢?这里,region replica有两种更新数据的方案:1. 定期的StoreFile Refresher这个方案非常好理解,region replica定期检查一下它自己对应的HDFS目录,如果发现文件有变动,比如说flush下来新的文件,文件被compaction掉,它就刷新一下自己的文件列表,这个过程非常像compaction完成之后删除被compact掉的文件和加入新的文件的流程。StoreFile Refresher方案非常简单,只需要在RegionServer中起一个定时执行的Chroe,定期去检查一下它上面的region哪些是region replica,哪些到了设置好的刷新周期,然后刷新就可以了。但这个方案缺点也十分明显,主region写入的数据,只有当flush下来后,才能被region replica看到。而且storeFile Refresher本身还有一个刷新的周期,设的太短了,list文件列表对NN的冲击太频繁,设的太长,就会造成数据长时间在region replica中都不可见2. Internal Replication我们知道,HBase是有replication链路的,支持把一个HBase集群的数据通过replication复制到另外一个集群。那么,同样的原理,可以在HBase集群内部建立一条replication通道,把一个Server上的主region的数据,复制到另一个Server的region replica上。那么region replica接收到这些数据之后,会把他们写入memstore中。对,你没看错,刚才我说了region replica是不接受写的,这是指replica不接受来自客户端的写,如果来自主region的replication的数据,它还是会写入memstore的。但是,这个写和普通的写有很明显的区别。第一个,replica region在写入来自主region的时候,是不写WAL的,因为这些数据已经在主region所在的WAL中持久化了,replica中无需再次落盘。第二个,replica region的memstore中的数据是不会被flush成HFile。我们知道,HBase的replication是基于复制WAL文件实现的,那么在主region进行flush时,也会写入特殊的标记Flush Marker。当region replica收到这样的标记时,就直接会把所有memstore里的数据丢掉,再做一次HDFS目录的刷新,把主region刚刚刷下去的那个HFile include进来。同样,如果主region发生了compaction,也会写入相应的Compaction Marker。读到这样的标记后,replica region也会做类似的动作。Internal replication加快了数据在region replica中的可见速度。通过replication方案,只要replication本身不发生阻塞和延迟,region replica中的数据可以做到和主region只差几百ms。但是,replication方案本身也存在几个问题:
比如说上图中,如果客户端是需要强一致读,那么客户端的请求只会发往主region,即replica_id=0的region,他就会读到X=3.如果他选择了Timeline consistency读,那么根据配置,他的读可能落在主上,那么他仍然会读到X=3,如果他的读落在了replica_id=1的region上,因为复制延迟的存在,他就只能读到X=2.如果落在了replica_id=2上,由于replication链路出现了问题,他就只能读到X=1。Region replica的使用方法服务端配置hbase.regionserver.storefile.refresh.period 如果要使用StoreFile Refresher来做为Region replica之间同步数据的策略,就必须把这个值设置为一个大于0的数,即刷新storefile的间隔周期(单位为ms)上面的章节讲过,这个值要不能太大,也不能太小。hbase.regionserver.meta.storefile.refresh.period 由于Meta表的region replica不能通过replication来同步,所以如果要开启meta表的region replica,必须把这个参数设成一个不为0的值,具体作用参见上一个参数,这个参数只对meta表生效。hbase.region.replica.replication.enabledhbase.region.replica.replication.memstore.enabled 如果要使用Internal replication的方式在Region replica之间同步数据的策略,必须把这两个参数都设置为truehbase.master.hfilecleaner.ttl 在主region发生compaction之后,被compact掉的文件会放入Achieve文件夹内,超过hbase.master.hfilecleaner.ttl时间后,文件就会被从HDFS删除掉。而此时,可能replica region正在读取这个文件,这会造成用户的读取抛错返回。如果不想要这种情况发生,就可以把这个参数设为一个很大的值,比如说3600000(一小时),总没有读操作需要读一个小时了吧?hbase.meta.replica.count mata表的replica份数,默认为1,即不开启meta表的replica。如果想让meta表有额外的一个replica,就可以把这个值设为2,依次类推。此参数只影响meta表的replica份数。用户表的replica份数是在表级别配置的,这个我后面会讲hbase.region.replica.storefile.refresh.memstore.multiplier 这个参数我在上面的章节里有讲,默认为4hbase.region.replica.wait.for.primary.flush 这个参数我在上面的章节里有讲,默认为true 需要注意的是,开启region replica之后,Master的balancer一定要用默认的StochasticLoadBalancer,只有这个balancer会尽量使主region和他的replica不在同一台机器上。其他的balaner会无区别对待所有的region。客户端配置hbase.ipc.client.specificThreadForWriting 因为当存在region replica时,当客户端发往主region的请求超时后,会发起一个请求到replica region,当其中一个请求放回后,就无需再等待另一个请求的结果了,通常要中断这个请求,使用专门的的线程来发送请求,比较容易处理中断。所以如果要使用region replica,这个参数要配为true。hbase.client.primaryCallTimeout.gethbase.client.primaryCallTimeout.multigethbase.client.replicaCallTimeout.scan 分别对应着,get、multiget、scan时等待主region返回结果的时间。如果把这个值设为1000ms,那么客户端的请求在发往主region超过1000ms还没返回后,就会再发一个请求到replica region(如果有多个replica的话,就会同时发往多个replica)hbase.meta.replicas.use 如果服务端上开启了meta表的replica后,客户端可以使用这个参数来控制是否使用meta表的replica的region。建表在shell建表时,只需在表的属性里加上REGION_REPLICATION => xx就可以了,如create 't1', 'f1', {REGION_REPLICATION => 2} Replica的份数支持动态修改,但修改之前必须disable表diable 't1'alter 't1', {REGION_REPLICATION => 1}enable 't1' 访问有replica的表如果可以按请求设置一致性级别,如果把请求的一致性级别设为Consistency.TIMELINE,即有可能读到replica上Get get1 = new Get(row);get1.setConsistency(Consistency.TIMELINE);...ArrayList 另外,用户可以通过Result.isStale()方法来获得返回的result是否来自主region,如果为isStale为false,则结果来自主region。Result result = table.get(get);if (result.isStale()) {...} 总结和建议Region Replica功能给HBase用户带来了高可用的读能力,提高了HBase的可用性,但同时也存在一定的缺点:
同时,云HBase2.0 在2018年6月6日将正式发布,点击了解更多: https://promotion.aliyun.com/ntms/act/hbase20.html原文链接 |
|
相关推荐
|
|
只有小组成员才能发言,加入小组>>
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-28 09:48 , Processed in 0.503117 second(s), Total 69, Slave 50 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号