安阳网站关键词优化,三国网页游戏排行榜前十名,wordpress强制安装插件,wordpress dux5.3摘要#xff1a; ApsaraDB for HBase2.0于2018年6月6日即将正式发布上线啦#xff01; 它是基于社区HBase2.0稳定版的升级#xff0c;也是阿里HBase多年的实践经验和技术积累的持续延伸#xff0c;全面解决了旧版本碰到的核心问题#xff0c;并做了很多优化改进#xff0…摘要 ApsaraDB for HBase2.0于2018年6月6日即将正式发布上线啦 它是基于社区HBase2.0稳定版的升级也是阿里HBase多年的实践经验和技术积累的持续延伸全面解决了旧版本碰到的核心问题并做了很多优化改进附加HBase2.0 开源新特性可以说是HBase生态里的一个里程碑。
一、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个PMC6个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相关的数据库逻辑运算操作; 通过分布式HDFSAPI接口读写远端底层分布式文件存储系统其中远端读写质量和安全隔离由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上其中replicaId0的为主region其他的为从region只有主region可以写入主region负责 flush memstore成为hfile从region一方面根据hfile列表类读到数据另一方面对于刚写入主region但还没有flush到hdfs上的数据通过replication同步到从region的memstore。如上图所示client1分别时间间隔内写入x1、x2、x3在同步数据的时候时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基于AlibabaIntel 合作项目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功能类似上述的第二种功能hbaseHDFS文件的方式实现。不同的是这些都是在server端完成不需要client去维护数据的一致性。并且保存的HDFS文件不是简单的hdfs序列文件而是HFile。这样它就可以有效管理这些MOB数据并且和普通hfile一样处理deleted数据。 MOB数据的读流程是 1. seek cell in HBase Table and 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上其中replicaId0的为主region其他的为从region只有主region可以写入从region只能读取数据。主region负责 flush memstore成为hfile从region一方面根据hfile列表类读到数据另一方面对于刚写入主region但还没有flush到hdfs上的数据通过replication同步到从region的memstore。 如上图所示client1分别时间间隔内写入x1、x2、x3在同步数据的时候时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. 企业安全基于Intelalibaba合作Hadoop Authentication Service安全项目 兼容hadoop/hbase生态kerberos认证。 6. 离线弹性作业为hbase批处理业务运行离线作业的弹性计算平台使得hbase存储计算分离把系统compaction、备份恢复、索引构建以及用户作业单独启动弹性计算资源进行离线处理计算完后立刻释放弹性伸缩。 7. SQL二级索引支持phoenix二级索引优化索引构建与查询功能。 8. 全文检索支持solr全文索引满足复杂的检索功能。 综合来说ApsaraDB for HBase2.0是围绕企业HBase上云的使用环境从内核功能到性能从自动运维到专家坐诊从开发效率到生产成本完善的HBase生态体系都为用户业务轻松上云稳定保驾护航。五、申请试用 ApsaraDB for HBase2.0 于2018年6月6号正式发布并开通公测申请欢迎大家申请试用点击了解更多原文链接本文为云栖社区原创内容未经允许不得转载。
