每秒7亿次请求,阿里新一代数据库如何支撑?

阿里妹导读:Lindorm,就是云操作系统飞天中面向大数据存储处理的重要组成部分。Lindorm是基于HBase研发的、面向大数据领域的分布式NoSQL数据库,集大规模、高吞吐、快速灵活、实时混合能力于一身,面向海量数据场景提供世界领先的高性能、可跨域、多一致、多模型的混合存储处理能力。目前,Lindorm已经全面服务于阿里经济体中的大数据结构化、半结构化存储场景。

注:Lindorm是阿里内部HBase分支的别称,在阿里云上对外售卖的版本叫做HBase增强版,之后文中出现的HBase增强版和Lindorm都指同一个产品。

2019年以来,Lindorm已经服务了包括淘宝、天猫、蚂蚁、菜鸟、妈妈、优酷、高德、大文娱等数十个BU,在今年的双十一中,Lindorm峰值请求达到了7.5亿次每秒,天吞吐22.9万亿次,平均响应时间低于3ms,整体存储的数据量达到了数百PB。这些数字的背后,凝聚了HBase&Lindorm团队多年以来的汗水和心血。Lindorm脱胎于HBase,是团队多年以来承载数百PB数据,亿级请求量,上千个业务后,在面对规模成本压力,以及HBase自身缺陷下,全面重构和引擎升级的全新产品。相比HBase,Lindorm无论是性能,功能还是可用性上,都有了巨大飞跃。本文将从功能、可用性、性能成本、服务生态等维度介绍Lindorm的核心能力与业务表现,最后分享部分我们正在进行中的一些项目。

极致优化,超强性能

Lindorm比HBase在RPC、内存管理,缓存、日志写入等方面做了深度的优化,引入了众多新技术,大幅提升了读写性能,在相同硬件的情况下,吞吐可达到HBase的5倍以上,毛刺更是可以达到HBase的1/10。这些性能数据,并不是在实验室条件下产生的,而是在不改动任何参数的前提下,使用开源测试工具YCSB跑出来的成绩。我们把测试的工具和场景都公布在阿里云的帮助文件中,任何人都可以依照指南自己跑出一样的结果。

取得这么优异的性能的背后,是Lindorm中积攒多年的“黑科技”,下面,我们简单介绍下Lindorm内核中使用到的部分“黑科技”。

Trie Index

Lindorm 的文件LDFile(类似HBase中的HFile)是只读 B+ 树结构,其中文件索引是至关重要的数据结构。在 block cache 中有高优先级,需要尽量常驻内存。如果能降低文件索引所占空间大小,我们可以节省 block cache 中索引所需要的宝贵内存空间。或者在索引空间不变的情况下,增加索引密度,降低 data block 的大小,从而提高性能。而HBase中的索引block中存的是全量的Rowkey,而在一个已经排序好的文件中,很多Rowkey都是有共同前缀的。

数据结构中的Trie (前缀树) 结构能够让共同前缀只存一份,避免重复存储带来的浪费。但是传统前缀树结构中,从一个节点到下一个节点的指针占用空间太多,整体而言得不偿失。这一情况有望用 Succinct Prefix Tree 来解决。SIGMOD2018年的最佳论文 Surf 中提出了一种用 Succinct Prefix Tree 来取代 bloom filter,并同时提供 range filtering 的功能。我们从这篇文章得到启发,用 Succinct Trie 来做 file block index。

我们在线上的多个业务中使用了Trie index实现的索引结构。结果发现,各个场景中,Trie index可以大大缩小索引的体积,最多可以压缩12倍的索引空间!节省的这些宝贵空间让内存Cache中能够存放更多的索引和数据文件,大大提高了请求的性能。

ZGC加持,百GB堆平均5ms暂停

ZGC(Powerd by Dragonwell JDK)是下一代Pauseless GC算法的代表之一,其核心思想是Mutator利用内存读屏障(Read Barrier)识别指针变化,使得大部分的标记(Mark)与合并(Relocate)工作可以放在并发阶段执行。 这样一项实验性技术,在Lindorm团队与AJDK团队的紧密合作下,进行了大量的改进与改造工作。使得ZGC在Lindorm这个场景上实现了生产级可用,主要工作包括:

  1. Lindorm内存自管理技术,数量级减少对象数与内存分配速率。(比如说阿里HBase团队贡献给社区的CCSMap)。
  2. AJDK ZGC Page缓存机制优化(锁、Page缓存策略)。
  3. AJDK ZGC 触发时机优化,ZGC无并发失败。AJDK ZGC在Lindorm上稳定运行两个月,并顺利通过双十一大考。其JVM暂停时间稳定在5ms左右,最大暂停时间不超过8ms。ZGC大大改善了线上运行集群的RT与毛刺指标,平均RT优化15%~20%,P999 RT减少一倍。在今年双十一蚂蚁风控集群中,在ZGC的加持下,P999时间从12ms降低到了5ms。


注:图中的单位应该为us,平均GC在5ms

LindormBlockingQueue

上图是HBase中的RegionServer从网络上读取RPC请求并分发到各个Handler上执行的流程。HBase中的RPC Reader从Socket上读取RPC请求放入BlockingQueue,Handler订阅这个Queue并执行请求。而这个BlockingQueue,HBase使用的是Java原生的JDK自带的LinkedBlockingQueue。

LinkedBlockingQueue利用Lock与Condition保证线程安全与线程之间的同步,虽然经典易懂,但当吞吐增大时,这个queue会造成严重的性能瓶颈。因此在Lindorm中全新设计了LindormBlockingQueue,将元素维护在Slot数组中。维护head与tail指针,通过CAS操作对进队列进行读写操作,消除了临界区。并使用Cache Line Padding与脏读缓存加速,同时可定制多种等待策略(Spin/Yield/Block),避免队列为空或为满时,频繁进入Park状态。LindormBlockingQueue的性能非常突出,相比于原先的LinkedBlockingQueue性能提升4倍以上。

VersionBasedSynchronizer

LDLog是Lindorm中用于系统failover时进行数据恢复时的日志,以保障数据的原子性和可靠性。在每次数据写入时,都必须先写入LDLog。LDLog写入成功之后,才可以进行后续的写入memstore等操作。因此Lindorm中的Handler都必须等待WAL写入完成后再被唤醒以进行下一步操作,在高压条件下,无用唤醒会造成大量的CPU Context Switch造成性能下降。针对这个问题,Lindorm研发了基于版本的高并发多路线程同步机制(VersionBasedSynchronizer)来大幅优化上下文切换。

VersionBasedSynchronizer的主要思路是让Handler的等待条件被Notifier感知,减少Notifier的唤醒压力。经过模块测试VersionBasedSynchronizer的效率是JDK自带的ObjectMonitor和J.U.C(java util concurrent包)的两倍以上。

全面无锁化

HBase内核在关键路径上有大量的锁,在高并发场景下,这些锁都会造成线程争抢和性能下降。Lindorm内核对关键链路上的锁都做了无锁化处理,如MVCC,WAL模块中的锁。另外,HBase在运行过程中会产生的各种指标,如qps,rt,cache命中率等等。而在记录这些Metrics的“不起眼”操作中,也会有大量的锁。面对这样的问题,Lindorm借鉴了tcmalloc的思想,开发了LindormThreadCacheCounter,来解决Metrics的性能问题。

Handler协程化

在高并发应用中,一个RPC请求的实现往往包含多个子模块,涉及到若干次IO。这些子模块的相互协作,系统的ContextSwitch相当频繁。ContextSwitch的优化是高并发系统绕不开的话题,各位高手都各显神通,业界有非常多的思想与实践。其中coroutine(协程)和SEDA(分阶段事件驱动)方案是我们着重考察的方案。基于工程代价,可维护性,代码可读性三个角度考虑,Lindorm选择了协程的方式进行异步化优化。我们利用了阿里JVM团队提供的Dragonwell JDK内置的Wisp2.0功能实现了HBase Handler的协程化,Wisp2.0开箱即用,有效地减少了系统的资源消耗,优化效果比较客观。

全新Encoding算法

从性能角度考虑,HBase通常需要将Meta信息装载进block cache。如果将block大小较小,Meta信息较多,会出现Meta无法完全装入Cache的情况, 性能下降。如果block大小较大,经过Encoding的block的顺序查询的性能会成为随机读的性能瓶颈。针对这一情况,Lindorm全新开发了Indexable Delta Encoding,在block内部也可以通过索引进行快速查询,seek性能有了较大提高。Indexable Delta Encoding原理如图所示:

通过Indexable Delta Encoding, HFile的随机seek性能相对于使用之前翻了一倍,以64K block为例,随机seek性能基本与不做encoding相近(其他encoding算法会有一定性能损失)。在全cache命中的随机Get场景下,相对于Diff encoding RT下降50%

其他

相比社区版HBase,Lindorm还有多达几十项的性能优化和重构,引入了众多新技术,由于篇幅有限,这里只能列举一部分,其他的核心技术,比如:

  • CCSMap
  • 自动规避故障节点的并发三副本日志协议 (Quorum-based write)
  • 高效的批量组提交(Group Commit)
  • 无碎片的高性能缓存—Shared BucketCache
  • Memstore Bloomfilter
  • 面向读写的高效数据结构
  • GC-Invisible内存管理
  • 在线计算与离线作业架构分离
  • JDK/操作系统深度优化
  • FPGA offloading Compaction
  • 用户态TCP加速
  • ……

丰富的查询模型,降低开发门槛

原生的HBase只支持KV结构的查询,虽然简单,但是在面对各项业务的复杂需求时,显的有点力不从心。因此,在Lindorm中,我们针对不同业务的特点,研发了多种查询模型,通过更靠近场景的API和索引设计,降低开发门槛。

WideColumn 模型(原生HBase API)

WideColumn是一种与HBase完全一致的访问模型和数据结构,从而使得Lindrom能100%兼容HBase的API。用户可以通过Lindorm提供的高性能原生客户端中的WideColumn API访问Lindorm,也可以通过alihbase-connector这个插件,使用HBase客户端及API(无需任何代码改造)直接访问Lindorm。同时,Lindorm使用了轻客户端的设计,将大量数据路由、批量分发、超时、重试等逻辑下沉到服务端,并在网络传输层做了大量的优化,使得应用端的CPU消耗可以大大节省。像下表中,相比于HBase,使用Lindorm后的应用侧CPU使用效率提升60%,网络带宽效率提升25%。


注:表中的客户端CPU代表HBase/Lindorm客户端消耗的CPU资源,越小越好。

在HBase原生API上,我们还独家支持了高性能二级索引,用户可以使用HBase原生API写入数据过程中,索引数据透明地写入索引表。在查询过程中,把可能全表扫的Scan + Filter大查询,变成可以先去查询索引表,大大提高了查询性能。

TableService模型(SQL、二级索引)

HBase中只支持Rowkey这一种索引方式,对于多字段查询时,通常效率低下。为此,用户需要维护多个表来满足不同场景的查询需求,这在一定程度上既增加了应用的开发复杂性,也不能很完美地保证数据一致性和写入效率。并且HBase中只提供了KV API,只能做Put、Get、Scan等简单API操作,也没有数据类型,所有的数据都必须用户自己转换和储存。对于习惯了SQL语言的开发者来说,入门的门槛非常高,而且容易出错。

为了解决这一痛点,降低用户使用门槛,提高开发效率,在Lindorm中我们增加了TableService模型,其提供丰富的数据类型、结构化查询表达API,并原生支持SQL访问和全局二级索引,解决了众多的技术挑战,大幅降低普通用户的开发门槛。通过SQL和SQL like的API,用户可以方便地像使用关系数据库那样使用Lindorm。下面是一个Lindorm SQL的简单示例。

-- 主表和索引DDL
create table shop_item_relation (shop_id varchar,item_id varchar,status varchar
constraint primary key(shop_id, item_id)) ;
create index idx1 on shop_item_relation (item_id) include (ALL);   -- 对第二列主键建索引,冗余所有列
create index idx2 on shop_item_relation (shop_id, status) include (ALL);  -- 多列索引,冗余所有列
-- 写入数据,会同步更新2个索引
upsert into shop_item_relation values('shop1', 'item1',  'active');
upsert into shop_item_relation values('shop1', 'item2',  'invalid');
-- 根据WHERE子句自动选择合适的索引执行查询
select * from shop_item_relation where item_id = 'item2';  -- 命中idx1
select * from shop_item_relation where shop_id = 'shop1' and status = 'invalid'; -- 命中idx2

相比于关系数据库的SQL,Lindorm不具备多行事务和复杂分析(如Join、Groupby)的能力,这也是两者之间的定位差异。相比于HBase上Phoenix组件提供的二级索引,Lindorm的二级索引在功能、性能、稳定性上远远超过Phoenix,下图是一个简单的性能对比。


注:该模型已经在阿里云HBase增强版上内测,感兴趣的用户可以联系云HBase答疑钉钉号或者在阿里云上发起工单咨询。

FeedStream模型

现代互联网架构中,消息队列承担了非常重要的职责,可以极大的提升核心系统的性能和稳定性。其典型的应用场景有包括系统解耦,削峰限流,日志采集,最终一致保证,分发推送等等。常见的消息队列包括RabbitMq,Kafka以及RocketMq等等。这些数据库尽管从架构和使用方式和性能上略有不同,但其基本使用场景都相对接近。然而,传统的消息队列并非完美,其在消息推送,feed流等场景存在以下问题:

  • 存储:不适合长期保存数据,通常过期时间都在天级
  • 删除能力:不支持删除指定数据entry
  • 查询能力:不支持较为复杂的查询和过滤条件
  • 一致性和性能难以同时保证:类似于Kafka之类的数据库更重吞吐,为了提高性能存在了某些状况下丢数据的可能,而事务处理能力较好的消息队列吞吐又较为受限。
  • Partition快速拓展能力:通常一个Topc下的partition数目都是固定,不支持快速扩展。
  • 物理队列/逻辑队列:通常只支持少量物理队列(如每个partition可以看成一个队列),而业务需要的在物理队列的基础上模拟出逻辑队列,如IM系统中为每个用户维护一个逻辑上的消息队列,用户往往需要很多额外的开发工作。

针对上述需求,Lindorm推出了队列模型FeedStreamService,能够解决海量用户下的消息同步,设备通知,自增ID分配等问题。

FeedStream模型在今年手机淘宝消息系统中扮演了重要角色,解决了手机淘宝消息推送保序,幂等等难题。在今年双十一中,手淘的盖楼和回血大红包推送都有Lindorm的身影。手淘消息的推送中,峰值超过了100w/s,做到了分钟级推送全网用户。


注:该模型已经在阿里云HBase增强版上内测,感兴趣的用户可以联系云HBase答疑钉钉号或者在阿里云上发起工单咨询。

全文索引模型

虽然Lindorm中的TableService模型提供了数据类型和二级索引。但是,在面对各种复杂条件查询和全文索引的需求下,还是显得力不从心,而Solr和ES是优秀的全文搜索引擎。使用Lindorm+Solr/ES,可以最大限度发挥Lindorm和Solr/ES各自的优点,从而使得我们可以构建复杂的大数据存储和检索服务。Lindorm内置了外部索引同步组件,能够自动地将写入Lindorm的数据同步到外部索引组件如Solr或者ES中。这种模型非常适合需要保存大量数据,而查询条件的字段数据仅占原数据的一小部分,并且需要各种条件组合查询的业务,例如:

  • 常见物流业务场景,需要存储大量轨迹物流信息,并需根据多个字段任意组合查询条件
  • 交通监控业务场景,保存大量过车记录,同时会根据车辆信息任意条件组合检索出感兴趣的记录
  • 各种网站会员、商品信息检索场景,一般保存大量的商品/会员信息,并需要根据少量条件进行复杂且任意的查询,以满足网站用户任意搜索需求等。

全文索引模型已经在阿里云上线,支持Solr/ES外部索引。目前,索引的查询用户还需要直接查询Solr/ES再来反查Lindorm,后续我们会用TableService的语法把查询外部索引的过程包装起来,用户全程只需要和Lindorm交互,即可获得全文索引的能力。

更多模型在路上

除了上述这些模型,我们还会根据业务的需求和痛点,开发更多简单易用的模型,方便用户使用,降低使用门槛。像时序模型,图模型等,都已经在路上,敬请期待。

零干预、秒恢复的高可用能力

从一个婴儿成长为青年,阿里HBase摔过很多次,甚至头破血流,我们在客户的信任之下幸运的成长。在9年的阿里应用过程中,我们积累了大量的高可用技术,而这些技术,都应用到了HBase增强版中。

MTTR优化

HBase是参照Gooogle著名论文BigTable的开源实现,其中最核心特点是数据持久化存储于底层的分布式文件系统HDFS,通过HDFS对数据的多副本维护来保障整个系统的高可靠性,而HBase自身不需要去关心数据的多副本及其一致性,这有助于整体工程的简化,但也引入了"服务单点"的缺陷,即对于确定的数据的读写服务只有发生固定的某个节点服务器,这意味着当一个节点宕机后,数据需要通过重放Log恢复内存状态,并且重新派发给新的节点加载后,才能恢复服务。

当集群规模较大时,HBase单点故障后恢复时间可能会达到10-20分钟,大规模集群宕机的恢复时间可能需要好几个小时!而在Lindorm内核中,我们对MTTR(平均故障恢复时间)做了一系列的优化,包括故障恢复时先上线region、并行replay、减少小文件产生等众多技术。将故障恢复速度提升10倍以上!基本上接近了HBase设计的理论值。

可调的多一致性

在原来的HBase架构中,每个region只能在一个RegionServer中上线,如果这个region server宕机,region需要经历Re-assgin,WAL按region切分,WAL数据回放等步骤后,才能恢复读写。这个恢复时间可能需要数分钟,对于某些高要求的业务来说,这是一个无法解决的痛点。另外,虽然HBase中有主备同步,但故障下只能集群粒度的手动切换,并且主和备的数据只能做到最终一致性,而有一些业务只能接受强一致,HBase在这点上望尘莫及。

Lindorm内部实现了一种基于Shared Log的一致性协议,通过分区多副本机制达到故障下的服务自动快速恢复的能力,完美适配了存储分离的架构, 利用同一套体系即可支持强一致语义,又可以选择在牺牲一致性的前提换取更佳的性能和可用性,实现多活,高可用等多种能力。

在这套架构下,Lindorm拥有了以下几个一致性级别,用户可以根据自己的业务自由选择一致性级别:


注:该功能暂时未在阿里云HBase增强版上对外开放

客户端高可用切换

虽然说目前HBase可以组成主备,但是目前市面上没有一个高效地客户端切换访问方案。HBase的客户端只能访问固定地址的HBase集群。如果主集群发生故障,用户需要停止HBase客户端,修改HBase的配置后重启,才能连接备集群访问。或者用户在业务侧必须设计一套复杂地访问逻辑来实现主备集群的访问。阿里HBase改造了HBase客户端,流量的切换发生在客户端内部,通过高可用的通道将切换命令发送给客户端,客户端会关闭旧的链接,打开与备集群的链接,然后重试请求。

 

云原生,更低使用成本

Lindorm从立项之初就考虑到上云,各种设计也能尽量复用云上基础设施,为云的环境专门优化。比如在云上,我们除了支持云盘之外,我们还支持将数据存储在OSS这种低成本的对象存储中减少成本。我们还针对ECS部署做了不少优化,适配小内存规格机型,加强部署弹性,一切为了云原生,为了节省客户成本。

ECS+云盘的极致弹性

目前Lindorm在云上的版本HBase增强版均采用ECS+云盘部署(部分大客户可能采用本地盘),ECS+云盘部署的形态给Lindorm带来了极致的弹性。

最开始的时候,HBase在集团的部署均采用物理机的形式。每个业务上线前,都必须先规划好机器数量和磁盘大小。在物理机部署下,往往会遇到几个难以解决的问题:

  • 业务弹性难以满足:当遇到业务突发流量高峰或者异常请求时,很难在短时间内找到新的物理机扩容。
  • 存储和计算绑定,灵活性差:物理机上CPU和磁盘的比例都是一定的,但是每个业务的特点都不一样,采用一样的物理机,有一些业务计算资源不够,但存储过剩,而有些业务计算资源过剩,而存储瓶颈。特别是在HBase引入混合存储后,HDD和SSD的比例非常难确定,有些高要求的业务常常会把SSD用满而HDD有剩余,而一些海量的离线型业务SSD盘又无法利用上。
  • 运维压力大:使用物理机时,运维需要时刻注意物理机是否过保,是否有磁盘坏,网卡坏等硬件故障需要处理,物理机的报修是一个漫长的过程,同时需要停机,运维压力巨大。对于HBase这种海量存储业务来说,每天坏几块磁盘是非常正常的事情。而当Lindorm采用了ECS+云盘部署后,这些问题都迎刃而解。

ECS提供了一个近似无限的资源池。当面对业务的紧急扩容时,我们只需在资源池中申请新的ECS拉起后,即可加入集群,时间在分钟级别之内,无惧业务流量高峰。配合云盘这样的存储计算分离架构。我们可以灵活地为各种业务分配不同的磁盘空间。当空间不够时,可以直接在线扩缩容磁盘。同时,运维再也不用考虑硬件故障,当ECS有故障时,ECS可以在另外一台宿主机上拉起,而云盘完全对上层屏蔽了坏盘的处理。极致的弹性同样带来了成本的优化。我们不需要为业务预留太多的资源,同时当业务的大促结束后,能够快速地缩容降低成本。

一体化冷热分离

在海量大数据场景下,一张表中的部分业务数据随着时间的推移仅作为归档数据或者访问频率很低,同时这部分历史数据体量非常大,比如订单数据或者监控数据,降低这部分数据的存储成本将会极大的节省企业的成本。如何以极简的运维配置成本就能为企业极大降低存储成本,Lindorm冷热分离功能应运而生。Lindorm为冷数据提供新的存储介质,新的存储介质存储成本仅为高效云盘的1/3。

Lindorm在同一张表里实现了数据的冷热分离,系统会自动根据用户设置的冷热分界线自动将表中的冷数据归档到冷存储中。在用户的访问方式上和普通表几乎没有任何差异,在查询的过程中,用户只需配置查询Hint或者TimeRange,系统根据条件自动地判断查询应该落在热数据区还是冷数据区。对用户而言始终是一张表,对用户几乎做到完全的透明。

ZSTD-V2,压缩比再提升100%

早在两年前,我们就把集团内的存储压缩算法替换成了ZSTD,相比原来的SNAPPY算法,获得了额外25%的压缩收益。今年我们对此进一步优化,开发实现了新的ZSTD-v2算法,其对于小块数据的压缩,提出了使用预先采样数据进行训练字典,然后用字典进行加速的方法。我们利用了这一新的功能,在Lindorm构建LDFile的时候,先对数据进行采样训练,构建字典,然后在进行压缩。在不同业务的数据测试中,我们最高获得了超过原生ZSTD算法100%的压缩比,这意味着我们可以为客户再节省50%的存储费用。

HBase Serverless版,入门首选

阿里云HBase Serverless 版是基于Lindorm内核,使用Serverless架构构建的一套新型的HBase 服务。阿里云HBase Serverless版真正把HBase变成了一个服务,用户无需提前规划资源,选择CPU,内存资源数量,购买集群。在应对业务高峰,业务空间增长时,也无需进行扩容等复杂运维操作,在业务低谷时,也无需浪费闲置资源。

在使用过程中,用户可以完全根据当前业务量,按需购买请求量和空间资源即可。使用阿里云HBase Serverless版本,用户就好像在使用一个无限资源的HBase集群,随时满足业务流量突然的变化,而同时只需要支付自己真正使用的那一部分资源的钱。

面向大客户的安全和多租户能力

Lindorm引擎内置了完整的用户名密码体系,提供多种级别的权限控制,并对每一次请求鉴权,防止未授权的数据访问,确保用户数据的访问安全。同时,针对企业级大客户的诉求,Lindorm内置了Group,Quota限制等多租户隔离功能,保证企业中各个业务在使用同一个HBase集群时不会被相互影响,安全高效地共享同一个大数据平台。

用户和ACL体系

Lindorm内核提供一套简单易用的用户认证和ACL体系。用户的认证只需要在配置中简单的填写用户名密码即可。用户的密码在服务器端非明文存储,并且在认证过程中不会明文传输密码,即使验证过程的密文被拦截,用以认证的通信内容不可重复使用,无法被伪造。

Lindorm中有三个权限层级。Global,Namespace和Table。这三者是相互覆盖的关系。比如给user1赋予了Global的读写权限,则他就拥有了所有namespace下所有Table的读写权限。如果给user2赋予了Namespace1的读写权限,那么他会自动拥有Namespace1中所有表的读写权限。

Group隔离

当多个用户或者业务在使用同一个HBase集群时,往往会存在资源争抢的问题。一些重要的在线业务的读写,可能会被离线业务批量读写所影响。而Group功能,则是HBase增强版(Lindorm)提供的用来解决多租户隔离问题的功能。 通过把RegionServer划分到不同的Group分组,每个分组上host不同的表,从而达到资源隔离的目的。

例如,在上图中,我们创建了一个Group1,把RegionServer1和RegionServer2划分到Group1中,创建了一个Group2,把RegionServer3和RegionServer4划分到Group2。同时,我们把Table1和Table2也移动到Group1分组。这样的话,Table1和Table2的所有region,都只会分配到Group1中的RegionServer1和RegionServer2这两台机器上。

同样,属于Group2的Table3和Table4的Region在分配和balance过程中,也只会落在RegionServer3和RegionServer4上。因此,用户在请求这些表时,发往Table1、Table2的请求,只会由RegionServer1和RegionServer2服务,而发往Table3和Table4的请求,只会由RegionServer3和RegionServer4服务,从而达到资源隔离的目的。

Quota限流

Lindorm内核中内置了一套完整的Quota体系,来对各个用户的资源使用做限制。对于每一个请求,Lindorm内核都有精确的计算所消耗的CU(Capacity Unit),CU会以实际消耗的资源来计算。比如用户一个Scan请求,由于filter的存在,虽然返回的数据很少,但可能已经在RegionServer已经消耗大量的CPU和IO资源来过滤数据,这些真实资源的消耗,都会计算在CU里。在把Lindorm当做一个大数据平台使用时,企业管理员可以先给不同业务分配不同的用户,然后通过Quota系统限制某个用户每秒的读CU不能超过多少,或者总的CU不能超过多少,从而限制用户占用过多的资源,影响其他用户。同时,Quota限流也支持Namesapce级别和表级别限制。

最后

全新一代NoSQL数据库Lindorm是阿里巴巴HBase&Lindorm团队9年以来技术积累的结晶,Lindorm在面向海量数据场景提供世界领先的高性能、可跨域、多一致、多模型的混合存储处理能力。对焦于同时解决大数据(无限扩展、高吞吐)、在线服务(低延时、高可用)、多功能查询的诉求,为用户提供无缝扩展、高吞吐、持续可用、毫秒级稳定响应、强弱一致可调、低存储成本、丰富索引的数据实时混合存取能力。Lindorm已经成为了阿里巴巴大数据体系中的核心产品之一,成功支持了集团各个BU上千个业务,也多次在天猫双十一“技术大团建”中经受住了考验。阿里CTO行癫说过,阿里的技术都应该通过阿里云输出,去普惠各行各业数百万客户。

双12来袭!500元淘宝红包、iPhone11等你拿。
https://www.aliyun.com/1212/2019/home?utm_content=g_1000092611

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

 

 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/517225.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

拼不过 GO?阿里如何重塑云上的 Java

阿里妹导读:Java 诞生于20年前,拥有大量优秀的企业级框架,践行 OOP 理念,更多体现的是严谨以及在长时间运行条件下的稳定性和高性能。反观如今,在要求快速迭代交付的云场景下,语言的简单性似乎成了首要的要…

android studio打包纯H5项目(集成5+SDK)

下载地址 http://ask.dcloud.net.cn/docs/#//ask.dcloud.net.cn/article/103 我们下载5SDK直接复制demo出来 可以自行修改名字,上面两个dome都可以使用 使用Android Studio打开后 默认目录结构如下 替换HTML文件 找到目录下app/src/main/assets/apps/HelloH5/www…

Apache Flink CEP 实战

本文根据Apache Flink 实战&进阶篇系列直播课程整理而成,由哈啰出行大数据实时平台资深开发刘博分享。通过一些简单的实际例子,从概念原理,到如何使用,再到功能的扩展,希望能够给打算使用或者已经使用的同学一些帮…

图神经网络(AliGraph)在阿里巴巴的发展与应用

背景 为什么做GNN? 在大数据的背景下,利用高速计算机去发现数据中的规律似乎是最有效的手段。为了让机器计算的有目的性,需要将人的知识作为输入。我们先后经历了专家系统、经典机器学习、深度学习三个阶段,输入的知识由具体到抽象&#xf…

实用!五款新型 Linux 命令行工具

作者 | Ricardo Gerardi译者 | 弯月,责编 | 屠敏出品 | CSDN(ID:CSDNnews)在Linux/Unix系统的日常使用中,我们需要使用很多命令行工具来完成工作,以及理解和管理我们的系统,例如使用du来监视磁盘…

从零开始入门 K8s | 手把手带你理解 etcd

导读:etcd 是用于共享配置和服务发现的分布式、一致性的 KV 存储系统。本文从 etcd 项目发展所经历的几个重要时刻开始,为大家介绍了 etcd 的总体架构及其设计中的基本原理。希望能够帮助大家更好的理解和使用 etcd。 一、etcd 项目的发展历程 etcd 诞生…

minio 单机安装、部署 centos7环境

文章目录一、默认模式下载运行1. 下载2. 访问minio控制台3. 创建目录3. 上传文件二、企业自定义模式2.1. 指定用户密码2.2. 配置目录2.3. 控制台端口2.4. 启动2.5. minio控制台登录2.6. 效果图一、默认模式下载运行 1. 下载 官网地址:https://docs.min.io/docs/ …

Kubernetes 日志查询分析实践

准备工作 为了完成后续的相关操作,我们需要准备一个 K8s 集群,操作步骤如下: 登陆容器服务控制台。创建一个标准托管集群(杭州区域),在向导中勾选上【使用 EIP 暴露 API Server】 和【使用日志服务】。集…

“编程能力差,90%是输在这点上!”谷歌AI开发专家:逆袭并没那么难!

Google 人工智能开发者专家彭靖田老师说——超90%的程序员在初学Python 人工智能时,都会遇到下面3个问题:1.想入门人工智能,但不知从何学起,也不知道该选择什么方向...2.Python语法、机器学习/深度学习框架、算法都能看懂&#xf…

这群程序员疯了!他们想成为IT界最会带货的男人

随着网红主播越来越火,通过直播带货种草的形式也成了今年双12的热点。 不过,网红主播带货早已见怪不怪,但你们见过程序员直播带货吗!? 近日,趁着阿里云双12年末采购节,阿里云邀请了一波程序员GG来为大家直播带货&am…

Minio Docker 单机安装(二种模式) linux

文章目录一、默认单机启动1. docker安装启动2. minio 镜像拉取和启动3. minio登录二、minio纠删码模式2.1. 简述2.2. 启动2.3. minio登录2.4. 总览2.5. 上传文件测试一、默认单机启动 1. docker安装启动 # 在线安装docker yum install docker# 启动docker systemctl start do…

阿里巴巴 Service Mesh 落地的架构与挑战

导读:云原生已成为整个阿里巴巴经济体构建面向未来的技术基础设施,Service Mesh 作为云原生的关键技术之一,顺利完成在 双11 核心应用严苛而复杂场景下的落地验证。本文作者将与大家分享在完成这一目标过程中我们所面临和克服的挑战。 部署架…

看完这篇 HashMap ,和面试官扯皮就没问题了

来源 | Java 建设者责编 | Carol封图 | CSDN 下载自视觉中国(如果你没有时间细抠本文,可以直接看 HashMap 概述,能让你对 HashMap 有个大致的了解)HashMap 是 Map 接口的实现,HashMap 允许空的 key-value 键值对&#…

除了快,5G 有哪些关键技术?

阿里妹导读:5G不仅仅只是网速更快,更多的是生活方式的颠覆,对各行各业都会起到催化作用。5G里不仅仅只有大带宽,而是会有很多与B端用户(企业)相结合的点。接下来,跟阿里大文娱的梓烁一起了解5G的…

聚水潭是如何基于AnalyticDB for PostgreSQL 构筑海量实时数仓平台的

聚水潭数据仓库业务介绍 上海聚水潭网络科技有限公司成立于2014年。聚水潭创建之初,以电商SaaS ERP切入市场,凭借出色的产品和服务,快速获得市场领先地位。随着客户需求的不断变化,如今聚水潭已经发展成为以SaaS ERP为核心&#…

sqlite3的编译和使用

编译环境准备 这个是nw官网的环境搭建教程,一般需要python2.7、visual studio 2013、node-gyp、 node-pre-gyp,环境这块的文章很多自己可以百度http://docs.nwjs.io/en/latest/For Users/Advanced/Use Native%2 0Node%20Modules/ 编译好之后&#xff0…

阿里巴巴的 Kubernetes 应用管理实践经验与教训

导读:本文整理自孙健波在 ArchSummit 大会 2019 北京站演讲稿记录。首先介绍了阿里巴巴基于 Kubernetes 项目进行大规模应用实践过程中遇到的问题;随后会逐一介绍解决这些问题的现有实践及其本身存在的局限性;最后会介绍阿里巴巴目前正在进行…

Minio 分布式集群部署

文章目录一、分布式存储可靠性常用方法1. 概述2. 冗余3. 校验二、分布式Minio优势2.1. 数据保护2.2. 高可用2.3.一致性三、运行分布式Minio3.1. 启动方案简述3.2. 案例说明3.3. 制作分布式启动脚本3.4. 制作伪分布式启动脚本3.5. 登录minio四、分布式Minio负载均衡4.1. nginx安…

数据分析:为什么说Python比Excel更简单高效 ?

日本最大的证券公司之一野村证券首席数字官马修汉普森,在Quant Conference上发表讲话:“用Excel的人越来越少,大家都在用Python。”甚至直接说:“Python已经取代了Excel。”事实上,为了追求更高的效率和质量&#xff0…

快速搭建 Serverless 在线图片处理应用

简介 首先介绍下在本文出现的几个比较重要的概念: 函数计算(Function Compute):函数计算是一个事件驱动的服务,通过函数计算,用户无需管理服务器等运行情况,只需编写代码并上传。函数计算准备计…