2018/6/7 15:58:51当前位置推荐好文阿里云教程浏览文章

一、HBase2.0和阿里云的前世今生

ApsaraDB for HBase2.0于2018年6月6日即将正式发布上线啦! 

ApsaraDB for HBase2.0是基于社区HBase2.0稳固版的更新,也是阿里HBase多年的实践经验和技术积累的持续延伸,全面处理了旧版本碰到的核心问题,并做了很多优化改进,附加HBase2.0 开源新特性,能说是HBase生态里的一个里程碑。 

HBase在2007年开始发布第一个“可使用”版,2010年成为Apache的顶级项目,阿里巴巴集团也在2010当年就开始研究,于2011年就已经开始把HBase投入生产环境用,并成为阿里集团主要的存储系统之一。那个时候HBase已经运行在上千台级别的大集群上,阿里巴巴能说算是HBase当时得到最大规模应使用的互联网公司之一。从最初的淘宝历史交易记录,到蚂蚁安全风控数据存储,HBase在几代阿里专家的不懈努力下,HBase已经体现得运行更稳固、性可以更高效,是功可以更丰富的集团核心存储产品之一。 

阿里集团自2012年培养了第一位“东八区” HBase Committer,到今天,阿里巴巴已经拥有3个PMC,6个Committer,阿里巴巴是中国拥有最多HBase Committer的公司之一。他们贡献了许多bug fix以及性可以改进feature等,很可可以你在使用的某个特性,正是出自他们之手。他们为HBase社区,也为HBase的成长贡献了一份宝贵的力量。当然,也孕育了一个更具备企业针对性的云上HBase企业版存储系统——ApsaraDB for HBase。 

ApsaraDB for HBase2.0是基于开源HBase2.0基础之上,融入阿里HBase多年大规模实战检验和技术积累的新一代KV数据库产品,结合了广大企业云上生产环境的需求,提供许多商业化功可以,比方 HBase on OSS、HBase云环境公网访问、HBase on 本地盘、HBase on 共享存储、冷热分离、备份恢复、HBase安全机制等等,是适合企业生产环境的企业级大规模云KV数据库。 

ApsaraDB for HBase2.0,源于HBase,不仅仅是HBase!

二、深入解读云HBase架构

      ApsaraDB for HBase2.0是建立在庞大的阿里云生态基础之上,重新定义了HBase云上的基础架构,对企业云上生产需求更有针对性,满足了许多重要的云上应使用场景。其中最常见的有:存储计算分离、一写多读、冷热分离、SQL/二级索引、安全等。下面针对这些场景简单详情一下ApsaraDB for HBase2.0的基础架构。

2.1 存储计算分离

早期存储和计算一般都是一起的,这样做带来的好处是数据本地化,不耗费网络资源。但是这会带来一个问题,给应使用企业对集群起初的规划带来肯定的难度,假如一开始用过大的存储、过大的计算资源,就是一种白费,但是假如开始规划存储、计算过小,后期运维更新扩展有变得非常复杂,甚至更新/扩展过程会出现故障等等问题,这些都不不企业业务发展规划不可忽略的问题。 

随着网络技术的发展,现在已经进入25G甚至100G以上时代,网络带宽已经不再是瓶颈。ApsaraDB for HBase2.0建立在阿里云之上,利使用阿里云强大基础技术,实现了云上HBase的高性可以存储计算分离的架构。

如上图所示,分布式region如上图所示,分布式region计算层负责HBase相关的数据库逻辑运算操作; 通过分布式HDFS&API接口读写远端底层分布式文件存储系统;其中远端读写质量和安全隔离由QOS层保障,QOS层利使用高性可以硬件加速远端读写性可以,保障了存储分离的性可以、安全要求;最终读写落到分布式存储层,分布式存储层通过副本形式保障数据安全可靠,能容忍单节点、单rack fail的数据可靠性。云上HBase计算存储分离架构的实现,使得使用户集群规划则变得简单很多,存储容量动态扩展,计算资源动态升配。基本不需要估算未来业务的规模了,真正做到按需用,帮助使用户在业务运行之初就开始尽可可以地降低成本,同时又能随时满足业务发展导致资源的弹性扩展的需要。

2.2 冷热分离/分级存储

一般企业随着业务数据不断增长,数据量开始变大,这个时候就需要对数据进行冷热程度区分对待,以优化系统整体运行效率,并降低成本。举个例子,如:冷数据写入一次后,可可以很久才被访问一次,但是由于和热数据存储在一个数据块上,可可以读这个热数据的时候,冷数据也被顺带读到内存中,这可可以是没有必要的,我们更多希望被顺带读出来的也是即将被访问的热数据。另外,由于热数据的频繁升级写入,可可以会引起系统更多得split、compaction等动作,这个时候,冷数据也被顺带一起屡次读写磁盘了,实际上冷数据可可以不需要这么频繁地进行这种系统动作。再从成本考虑,业务上假如普遍能接受陈年旧事——冷数据被访问延时相对高一点点,那么即可以考虑把这些数据存储在成本较低的介质中。 

基于这种常见的企业场景需求,ApsaraDB for HBase2.0在阿里云基础体系之上,设计了云HBase冷热分离/分级存储架构,实现企业云上HBase应使用的冷热分离场景需求,提高系统运行效率的同时,又降低存储成本。

 如图所示,架构分两阶段,第一阶段实现分级存储,使用户能清晰的按照不同访问频度将数据存储到不同冷热级别的表上,从表级别上区分冷热数据,实现分级存储。第二阶段是同表数据冷热数据自动分离,使用户能按照访问频率或者者创立时间等条件,指定冷热数据判断标准依据,最终后台自动分离冷热数据分别存储。

2.3 一写多读/读高可使用

在旧版HBase运行的时候,当一台机器宕机的时候,这个机器所负责的region主要需要经历3个的解决流程才可以恢复读——发现宕机、重新分配此机器负责的region、上线region恢复。其中发现宕机可可以就需要几十秒,依赖于zookeeper的session timeout时间。在这个恢复过程中,使用户client是不能读这些region数据的。也就是此架构的读不是高可使用的,无法保证99.9%的延时都 <20ms。在某些应使用业务里,可可以更关心整体读高可使用、99.9%读延时,且允许读到旧数据的情况下,这就无法满足。 

ApsaraDB for HBase2.0是基于2.0最新稳固版,引入了region replicas功可以,实现一写多读,扩充了高可使用读的可以力。

如上图,开启这个功可以的表,region会被分配到多个RegionServer上,其中replicaId=0的为主region,其余的为从region,只有主region能写入,主region负责 flush memstore成为hfile,从region一方面根据hfile列表类读到数据,另一方面对于刚写入主region但还没有flush到hdfs上的数据,通过replication同步到从region的memstore。如上图所示,client1分别时间间隔内写入x=1、x=2、x=3,在同步数据的时候时,client2进行读x的值,它是能读任何一台server上的x值,这就保证了读的高可使用性,即便有机器挂了也能有 99.9%延时 <20ms保证。 

能看到这种架构读是高可使用的,合适一写多读的场景,数据只保存一份。n台机器挂了(n小于一个region的副本数),还能正常读数据。并且这里提供了两种读一致性模式,分别是strong和timeline-consistent模式。在strong模式下,只读取主region的数据返回结果;在timeline-consistent模式下,允许读任何一个region replica的数据返回,这对少量要求读高可使用的场景来说,体验是比较友好的。

2.4 SQL/二级索引/全文检索

HBase原生的设计只有按照rowkey的才可以快速查询检索,这对复杂的企业业务检索场景来说,是满足不了的。且随着业务的变化,开始设计的rowkey可可以已经不可以满足当下系统的某些业务检索需求了。这就要求对HBase的检索功可以进行增强。 

ApsaraDB for HBase2.0支持更完善的SQL接口、二级索引以及全文索引,使用户能用熟习的SQL语句操作HBase系统;并且支持二级索引的创立、全量重建索引,以及增量数据自动同步索引的功可以;2.0版本还将支持全文索引检索功可以,弥补了HBase不可以模糊检索的缺陷,把全文检索的功可以引入HBase系统当中。

  如上图,ApsaraDB for HBase2.0体系内置solr/phoenix内核引擎,进行了深度改造与优化,支持SQL/API方式操作数据库,二级索引支持:全局索引、本地索引、全文索引等。索引支持全量重建、增量数据自动同步升级。在检索查询的时候,索引对使用户透明,HBase内部根据索引元信息自动探测使用户查询能否需要利使用索引功可以,加强了HBase系统检索可以力,有利于企业在云HBase业务上构建更复杂的检索场景。

2.5 安全体系

在使用户用数据库的时候,都习惯于传统的类型MySQL的账户密码体系,而大数据Hadoop/HBase生态当中,默认却没有一套完整且统一的认证受权体系,组件内置的身份认证仅支持Kerberos协议,而权限控制依赖于每个生态组件自身的控制。 

ApsaraDB for HBase2.0基于Alibaba&Intel 合作项目Hadoop Authentication Service (HAS) 开发了一套属于云HBase的认证受权体系,兼容了Hadoop/HBase生态的Kerberos协议支持,并用人们熟习的账户密码管理方式,允许对使用户访问HBase的权限进行管理,兼容默认ACL机制。

如上图,ApsaraDB for HBase2.0安全体系基于HAS开发,用Kerby替代MIT Kerberos服务,利使用HAS插件式验证方式建立一套人们习惯的账户密码体系,使用户体验更友好。

2.6 备份恢复

      大数据时代,重要的信息系统中数据就是财富,数据的丢失可可以会造成不可估量的损失。对于这种数据重要级别较高的场景,应该要构建一套灾难备份和恢复系统架构,防止人为操作失误、自然灾害等不可避免的偶然因素造成的损失。ApsaraDB for HBase2.0构建在云体系下,支持全量、增量备份,同城/异地灾备功可以。

      如上图,架构能允许使用户进行冷数据备份,备份数据保存在共享存储中,成本低,需要时能对备份数据读取复原插入到系统中。同时也支持热备份,集群之间通过全量HFile和增量HLog进行跨集群备份,最终做到同城/异地灾备,业务client能在访问当下集群不可使用时,自动切换到备使用集群进行数据访问业务。

三、2.0版本内核解读

开源HBase在2010年正式成为Apache顶级项目独立发展,而阿里巴巴同步早在2010年初已经开始步入HBase的发展、建设之路,是国内最早应使用、研究、发展、回馈的团队,也诞生了HBase社区在国内的第一位Committer,成为HBase在中国发展的积极布道者。过去的8年时间,阿里累积向社区回馈了上百个patch, 结合内部的阿里巴巴集团“双十一”业务等的强大考验,在诸多核心板块的功可以、稳固性、性可以作出积极重大的改进和突破,孕育了一个云上HBase企业版KV数据库ApsaraDB for HBase。 

ApsaraDB for HBase发展至今,已经开始进入了2.0 时代。ApsaraDB for HBase是基于开源HBase2.0版本,结合阿里HBase技术和经验的演进过来,其完全兼容HBase2.0,拥有HBase2.0的所有新特性的同时,更享受阿里专家&HBase Committer们在源码级别上的保驾护航。2.0相比1.x之前版本在内核上有了许多改进,内核功可以更稳固、高效、延时更低,功可以更丰富。下面我们来详情一下这些重要的功可以特性。

3.1 新版Region分配器AMv2——稳固性提高

      在早期版本,HBase Server端很多执行业务过程都是用handler线程实现的,而一个业务线程需要执行的逻辑可可以要经历几个步骤。用handler线程实现的这套机制最大的问题在于不支持异常回滚,没有灾难恢复机制,执行过程中出现异常,那么HBase可可以会处在任务的中间状态,引起常见的Region-In-Transition,可可以就需要人为去清除。如:用户端调使用一个createTable RPC请求,服务端需要创立HDFS目录,写入meta表,分配region,等待region上线,标记region上线完成等等系列步骤,假如handler解决线程中间被中断了,就导致系统残留一下中间状态的数据。

如上图,region信息写入meta表后进程被中断了,而client认为任务已经完成了,实际上整个任务是失败的。在进程恢复后,没有很好的解决这个灾难问题回滚或者者继续恢复执行剩下的步骤。 

      针对这类问题,ApsaraDB for HBase2.0内核做了两个核心的改动,一个是引入ProcedureV2,处理诸如上述分布式多步骤流程解决的状态最终一致性问题;二个是基于ProcedureV2基础上,改造了AssignmentManager,使其在region上线过程被异常或者灾难中断后,进程恢复时能自动回滚中间残留状态信息,重试中断步骤并继续执行。最终避免了相似RIT的问题,实现“NO more HBCK, NO more RIT”,提供稳固性,降低运维成本。

      首先我们来看看ProcedureV2的原理,如下图:

 它用ProcedureExecutor调使用执行使用户提交的procedure队列,并在执行procedure状态变化的时候,用ProcedureStore记录procedure的状态持久化到WAL中,如此反复。当procedure执行过程当中进程被中断了,在下一次进程恢复时,即可以根据之前持久化的procedure状态恢复到指定步骤,并做必要的rollback步骤,再重试中断的步骤继续下去。


如上图,最常见的就是状态机Procedure,定制每次状态在继续向下执行的时候,应该做哪些操作,以及在中断恢复后,应该解决的rollback工作。回想上面创立表的例子,假如我们同样在"add regions to META"的时候失败了,那么我们在恢复之后,即可以根据这个状态信息,继续执行剩下的步骤,只有当这个procedure 完成的时候,这个create table的procedure 才算完成。当然,client判断能否创立表成功也不再是用 “MetaReader.hasTable”来利使用中间状态得到结果,而是直接根据createTable的procedure Id来查询能否任务完整执行结束。能看出,在用ProcedureV2和之前的线程解决有了很大的改进,更灵活的解决业务进程被中断时的各种异常情况。 

再来看看AMv2的改进特性,正如上面所述,AssignmentManager V2(简称AMv2)是基于ProcedureV2实现的新版region分配管理器。得益于ProcedureV2的设计实现,AMv2在进行region分配上下线时,能在被各种情况中断的情况下,自动恢复回滚执行,使得region的状态最终是自动恢复一致性的。除此之外,AMv2还重新设计了region信息保存和升级的逻辑。 

      在旧版的AssignmentManager实现,是借助Zookeeper协同功可以,Master与RegionServer共同完成的region状态维护,代码逻辑相对复杂、效率低。region状态保存在3个地方:Zookeeper、meta表、Master内存,当一个分配流程过程中一端被异常中断时,就容易出现集群状态不一致的现象。如client 访问时报的NotServingRegionException一种可以就是region状态不一致,Master认为是分配到这个server上,而实际在这个server并没有上线,此时client rpc请求访问,就会收到这个异常。

      下图为旧版AssignmentManager的region assign复杂流程:

如上图流程显示,第1、2、3条线是Master进程的不同线程,第4条是zk,第5、6条是RegionServer上的线程,第7条线是META表。Master和RegionServer都能升级Zookeeper中region的状态,RegionSever又能升级 meta表中的 assignment 信息。Master 在将 region assign 给 RegionServer 之前也会升级region 状态信息,Master也能从 Zookeeper和meta 表中获取 region状态升级。这导致很难维持region处于一个正常的状态,特别是一端处于异常灾难中断的时候。 

为了维持region处于一个正常的状态,再加上各种异常中断的情况考虑,HBase内部用了很多复杂的逻辑,这就大大添加了维护难度,对开发新功可以、提升性可以的优化工作添加了复杂性。 

      新版AssignmentManager V2 ,不仅基于ProcedureV2之上以支持各种中断回滚重试,还重新设计了region分配逻辑,不再用Zookeeper来保存region的状态信息,region只持久化在meta表,以及Master的内存中,并且只有Master去维护升级,这就简化了状态升级的一致性问题。而且,代码逻辑较之前也清晰简洁了,稳固性提高了,维护的复杂性降低,性可以也提高了。

  如上图,从测试结果来看,2.0中的 region assign 速度比V1提高非常快。综合看,这个AMv2是个非常有重要的改进。

3.2  Netty Rpc Server和Client——添加吞吐,降低延时

在之前的版本中,HBase的RPC Server用的是基于Java NIO实现的一套框架。在这套框架中有一个Listener线程负责accept来自Socket的连接请求,并将对应的Connection注册到NIO的Selector上。同时,有若干个Reader线程来负责监听这个selector上处于Readable状态的Connection,将请求从Connection中读出,放入对应的Callqueue中,让handler线程来执行这些请求。尽管HBase社区对这套RPC框架进行了诸多优化,包括去掉少量同步锁,减少复制等等,但因为其线程模型的限制,以及Java NIO本身的瓶颈,在大压力测试中,这套框架仍显得力不从心。 

而Netty是一个高性可以、异步事件驱动的NIO框架, 在业界有着非常广泛地应使用,其稳固性和性可以都得到了多方面地印证。抱着“把专业的事情交给专业的人去做”的思想,在HBase2.0中,引入了Netty做为其服务器的RPC框架。引入Netty的工作由来自阿里巴巴的committer binlijin完成,并做了相应的测试。完成后HBase的RPC框架如图所示:

从网络上读取请求和写入response都由Netty来负责,因为HBase的绝大部分请求涉及了较多的IO和CPU操作,因而依然需要一个Handler线程池来做请求的执行,而和网络相关的操作,完全交给了Netty。用了Netty服务器后,HBase的吞吐增长了一倍,在高压力下的推迟从0.92ms降到了0.25ms,更多的信息能看下根据binlinjin在一次公开演讲中的展现[附录1]。目前Netty服务器已经是HBase2.0的默认RPC选项。

3.3  读写链路offheap——降低毛刺率,QPS添加

GC一直是java应使用中探讨的一个话题,尤其在像HBase这样的大型在线KV数据库系统中,GC停顿会对请求推迟产生非常大的影响。同时,内存碎片不断恶化从而导致Full GC的发生,成为了HBase用者们的一大痛点。 

在HBase的读和写链路中,均会产生大量的内存垃圾和碎片。比方说写请求时需要从Connection的ByteBuffer中拷贝数据到KeyValue结构中,在把这些KeyValue结构写入memstore时,又需要将其拷贝到MSLAB中,WAL Edit的构建,Memstore的flush等等,都会产生大量的临时对象,和生命周期结束的对象。随着写压力的上升,GC的压力也会越大。读链路也同样存在这样的问题,cache的置换,block数据的decoding,写网络中的拷贝等等过程,都会无形中加重GC的负担。而HBase2.0中引入的全链路offheap功可以,正是为理解决这些GC问题。大家知道Java的内存分为onheap和offheap,而GC只会整理onheap的堆。全链路Offheap,就意味着HBase在读写过程中,KeyValue的整个生命周期都会在offheap中进行,HBase自行管理offheap的内存,减少GC压力和GC停顿。全链路offheap分为写链路的offheap和读链路的offheap。其中写链路的offheap功可以在HBase2.0中默认开启,读链路的offheap功可以依然在完善中,即将在后续的小版本中开启。 

写链路的offheap包括以下几个优化: 

1. 在RPC层直接把网络流上的KeyValue读入offheap的bytebuffer中 

2. 用offheap的MSLAB pool 

3. 用支持offheap的Protobuf版本(3.0+) 

4. 更精确的Memstore size计算和更好的flush策略 

读链路的offheap主要包括以下几个优化: 

1. 对BucketCache引使用计数,避免读取时的拷贝 

2. 用ByteBuffer做为服务端KeyValue的实现,从而使KeyValue能存储在offheap的内存中 

3. 对BucketCache进行了一系列性可以优化 

来自阿里巴巴的HBase社区PMC Yu Li将读链路offheap化运使用在了阿里巴巴内部用的HBase集群中,用读链路offheap后,相应集群的读QPS增长了30%以上,同时毛刺率更加低,请求曲线更加平滑,成功应对了2016年天猫双十一的峰值[附录2]。

3.4 In-Memory Compaction——减轻GC压力,减少写放大

回顾HBase的LSM结构,HBase为每个region的每个store在内存中创立一个memstore,一旦内存达到肯定阈值后,就会flush到HDFS上生成HFile。不断的运行写入,HFile个数就会变多,这个时候读性可以就会变差,由于它查询一个数据可可以需要打开所有存在这个行的HFile。处理这个问题就需要定期后端运行Compaction操作,将多个HFile合并。但是这样做会使得同一份数据,因屡次compaction而会被写入屡次hdfs,引起了写入放大的问题。能看到,要想减少这个compaction的频率的话,能通过降低HFile的产生速度,同样的内存尽可可以多的保存数据,并且在内存中预先进行compaction操作,提高后期hfile的compaction效率。In-Memory Compaction应运而生。 

hbase2.0引入In-Memory compaction技术,核心有两点:一是用 Segment 来替代 ConcurrentSkipListMap ,同样的 MemStore 能存储更多的数据,减少flush 频繁,从而也减轻了写放大的问题。同时带来的好处是减少内存 GC 压力。二是在 MemStore 内存中实现compaction操作,尽量减少后期写放大。 

先来说说其如何高效实使用内存。在默认的MemStore中,对cell的索引用ConcurrentSkipListMap,这种结构支持动态修改,但是其中会存在大量小对象,内存碎片添加,内存白费比较严重。而在CompactingMemStore中,因为pipeline里面的segment数据是只读的,即可以用更紧凑的数据结构来存储索引,这带来两方面好处:一方面只读数据块能降低内存碎片率,另一方面更紧凑的数据结构减少内存用。代码中用CellArrayMap结构来存储cell索引,其内部实现是一个数组,如下图:

      再来说说其如何降低写放大。旧版Default MemStore是flush时,将active的store 进行打快照snapshot,而后把snapshot flush到磁盘。新版的CompactingMemStore是以segment为单位组织,一个memstore中包含多个segment。数据写入时写到active segment中,active segment到肯定阈值后触发in-memory flush 生成不可修改的segment放到pipeline中。pipeline最后会对这些多个segment进行in-memory compaction合并为一个更紧凑的大segment,在肯定程度上延长数据在内存的生命周期能减少总的I/O,减少后期写放大。

内存compaction目前支持Basic,Eager,Adaptive 三种策略。Basic compaction策略和Eager compaction策略的区别在于如何解决cell数据。Basic compaction不会清除多余的数据版本,这样就不需要对cell的内存进行拷贝。而Eager compaction会过滤重复的数据,并清除多余的版本,这意味着会有额外的开销。Adaptive策略则是根据数据的重复情况来决定能否用Eager策略。在Adaptive策略中,首先会对待合并的segment进行评估,方法是在已经统计过不重复key个数的segment中,找出cell个数最多的一个,而后使用这个segment的numUniqueKeys / getCellsCount得到一个比例,假如比例小于设定的阈值,则用Eager策略,否则用Basic策略。

3.5 支持高效对象存储

ApsaraDB for HBase2.0支持Medium-Sized Object (MOB) 主要目的是在HBase中,可以高效地存储那些100k~10M 中等大小的对象。这使得使用户能把文档、图片以及适中的对象保存到HBase系统中。在MOB之前,常见有两个设计方案,第一种是直接保存中等对象到HBase中,另一种是用HBase中只保存对象数据在HDFS的路径,中等对象以file形式存在HDFS中。这两个现有方案业务方案都有弊端。 

通常人们直接存储在HBase中时,分两个列簇存储,一个保存普通信息,另一个使用来保存中等对象数据。而通常中等对象一般都是几百KB到几MB大小的KV,这些数据直接插入memstore,会使得flush更频繁,可可以几百条几千条数据就引起一次flush,产生更多的hfile后,compaction也会被触发得更频繁,I/O 也会随之变的很大,影响到整个系统的运行。 

为了降低MOB中等对象直接存储导致的split、compaction、flush问题,人们开始用另一种方案,把MOB对象数据存储到HDFS文件上,只在HBase保存MOB对象数据的文件路径。如下图:

这样能减少split/compaction的影响,但是一致性时由用户端来保证的。另一方面,MOB对象一般是100k~10M的数据,此方案就是每个MOB对象在HDFS上保存一个文件,会产生非常多的小物件,很可可以系统很快就用完了文件句柄打开数。假如优化一下,把许多MOB写到HDFS序列文件上,hbase记录保存着MOB对象的文件路径和数据offset,的确处理了小文件问题,但是有带来另一个问题,那就是很难维护这些MOB对象数据的一致性,并且很难维护删除操作。 

HBase2.0 MOB功可以相似上述的第二种功可以,hbase+HDFS文件的方式实现。不同的是,这些都是在server端完成,不需要client去维护数据的一致性。并且保存的HDFS文件不是简单的hdfs序列文件,而是HFile。这样它即可以有效管理这些MOB数据,并且和普通hfile一样解决deleted数据。 

MOB数据的读流程是: 

1. seek cell in HBase Table find the MOB file path 

2. find the MOB file by path 

3. seek the cell by rowkey in the MOB file 

读一个MOB的流程总是只open一个MOB file,所以不论有多少MOB file,是不会影响这个读性可以的。所以split、compaction也并不是必要的。当然系统会设计compaction策略来定期删除掉那些deleted的数据,以腾出空间来。MOB的实现,使得使用户在保存中等对象时,不必自己维护数据的一致性,更兼容了现在的HBase api操作MOB hfile。

3.6 异步client ——提高用户端并发/吞吐

HBase 2.0 前 HBase 的 Client 是同步调使用的,HBase2.0后实现了异步的Client。异步用户端有两个好处: 

1. 在单个线程中,异步用户端是非阻塞的,不需要等上一个请求的返回,即可以继续再发送多个请求,可提高用户端吞吐。 

2. 可肯定程度上处理故障放大问题,如由于某个业务的多个解决线程同时访问HBase 某个卡住的 RegionServer (GC起因,HDFS 访问慢,网络起因等)时,这部分的的业务的解决线程都会被卡住,此时业务的可使用性要低于HBase 的可使用性(HBase 其它的 RegionServer 可可以是正常的)。

3.7 异步DFSClient——提高服务端性可以

      之前HBase 访问HDFS 都是同步的,经常发生由于HDFS 访问慢,而阻塞handler的情况。例如当前的解决HBase RPC的handler为100个,恰好这100个handler访问某个DataNode被阻塞。此时 RPC Server则无法解决前台请求,只可以等访问HDFS数据返回或者者超时才可以释放hanlder 响应新的请求。而异步DFS Client 则不需要等待。可大大提高系统性可以以及可使用性。

3.8 Region多副本——读高可使用,降低延时

      ApsaraDB for HBase2.0引入region多副本机制,当使用户对某个表开启此功可以时,表的每个region会被分配到多个RegionServer上,其中replicaId=0的为主region,其余的为从region,只有主region能写入,从region只可以读取数据。主region负责 flush memstore成为hfile;从region一方面根据hfile列表类读到数据,另一方面对于刚写入主region但还没有flush到hdfs上的数据,通过replication同步到从region的memstore。

如上图所示,client1分别时间间隔内写入x=1、x=2、x=3,在同步数据的时候时,client2进行读x的值,它是能读任何一台server上的x值,这就保证了读的高可使用性,即便有n台机器挂了(n小于一个region的副本数)也能有 99.9%延时 <20ms保证。能看到这种架构读是高可使用的,合适一写多读的场景。 

这里还提供了两种读一致性模式,分别是strong和timeline-consistent模式,strong模式下,只读取主region的数据返回结果;timeline-consistent模式下,允许读任何一个region replica的数据返回。

四、展望

ApsaraDB for HBase2.0 是基于开源HBase2.0之上,融入了阿里HBase多年大规模实战检验和技术积累的新一代KV数据库产品。结合了广大企业云上生产环境的特定需求,定制了许多商业化功可以,比方:oss、公网、本地盘、共享存储、冷热分离、备份恢复、安全等等。 

接下来,我们在不断完善ApsaraDB for HBase2.0架构基础功可以上,会陆续开放与完善更统一高效的SQL平台,并增强云HBase的生态建设,开放图数据库、时空数据库、cube数据库-Kylin等。

如上图所示,在接入层上,ApsaraDB for HBase2.0 陆续支持更多云产品链路直通访问,如:blink、CDP、LogService、emd、物联网套件等,开放HBase上生态组件,如:图数据库、时空、cube数据库等,让企业在云上完成数据库业务架构闭环。 

网络层继续支持经典网/VPC专有网络选择,并支持弹性公网开关服务,方便了云上生产/云下开发调试使用户需求。 

中间件层继续支持并优化SQL 二级索引的创立与用,支持多语言服务,thrift/rest服务化;ApsaraDB for HBase2.0陆续开放更强大的检索功可以,包括全文检索、图检索、空间检索等,满足企业更复杂的业务检索需求。 

在HBase内核层+存储层上,ApsaraDB for HBase2.0 采使用的最新版的2.0内核,结合阿里HBase多年的技术积累经验,针对企业上云继续完善、优化更多商业化功可以。例如: 

1. 本地盘:服务器直通本地盘读写,效率高,成本低,相比高效云盘降低5倍。20T起购买。 

2. 共享存储:实现HBase共享存储,动态增加容量包,用灵活,成本低。 

3. 冷热分离:冷热数据分别存储不同介质 

4. 备份恢复:支持增量、全量备份恢复,支持跨集群跨机房容灾备份。 

5. 企业安全:基于Intel&alibaba合作Hadoop Authentication Service安全项目, 兼容hadoop/hbase生态kerberos认证。 

6. 离线弹性作业:为hbase批解决业务运行离线作业的弹性计算平台,使得hbase存储计算分离,把系统compaction、备份恢复、索引构建以及使用户作业单独启动弹性计算资源进行离线解决,计算完后立刻释放,弹性伸缩。 

7. SQL二级索引:支持phoenix二级索引,优化索引构建与查询功可以。 

8. 全文检索:支持solr全文索引,满足复杂的检索功可以。 

      综合来说,ApsaraDB for HBase2.0是围绕企业HBase上云的用环境,从内核功可以到性可以,从自动运维到专家坐诊,从开发效率到生产成本,完善的HBase生态体系,都为使用户业务轻松上云稳固保驾护航。

本文作者:天斯

阅读原文

本文为云栖社区原创内容,未经允许不得转载。

网友评论