关于数据:揭秘阿里实时数仓分布式事务Scale-Out设计

简介:Hybrid Transaction Analytical Processing(HTAP) 是驰名信息技术征询与剖析公司Gartner在2014年提出的一个新的数据库系统定义,特指一类兼具OLTP能力(事务能力)和OLAP能力(剖析能力)的数据库系统。

一 前言

Hybrid Transaction Analytical Processing(HTAP) 是驰名信息技术征询与剖析公司Gartner在2014年提出的一个新的数据库系统定义,特指一类兼具OLTP能力(事务能力)和OLAP能力(剖析能力)的数据库系统。在传统场景中,承当OLTP工作和OLAP工作的数据库是两个不同的零碎。典型的OLTP零碎包含MySQL、PostgreSQL、PolarDB等,典型的OLAP零碎包含Clickhouse、AnalyticDB等。在生产零碎中,业务原始数据通常存储在OLTP零碎中,而后通过离线导入、ETL、DTS等形式以肯定提早同步到OLAP零碎中,再进行后续的数据分析工作。

HTAP零碎的一个直观的长处是能够在一个零碎中实现OLTP和OLAP工作,节约用户的零碎应用老本。而且,HTAP零碎具备残缺的ACID能力,让开发者领有更多的数据写入形式,不论是实时插入、离线导入、数据单条更新,都能够轻松应答。另外,一个齐备的HTAP产品,同样是一个优良的ETL工具,开发者能够利用HTAP零碎解决常见的数据加工需要。HTAP零碎可能大大节约用户的应用老本和开发成本,并影响下层业务零碎的状态。目前,存储计算拆散、云原生技术和HTAP等技术,被业界公认为是数据库系统目前的重要演进方向。
AnalyticDB PostgreSQL版是阿里云的一款实时数仓产品(以下简称ADB PG)。ADB PG采纳MPP程度扩大架构,反对规范SQL 2003,兼容PostgreSQL/Greenplum,高度兼容 Oracle 语法生态,也是一款HTAP产品。ADB PG曾经通过了中国信息通信研究院组织的分布式剖析型数据库和分布式事务数据库性能和性能认证,是国内惟一一家同时通过这两项认证的数据库产品。ADB PG晚期版本主打OLAP场景、具备OLTP能力。随着HTAP的风行,ADB PG自6.0版本开始对OLTP性能在多个方面进行了大幅度优化,其中很重要的一个我的项目就是Multi-Master我的项目,通过Scale Out突破了原有架构的仅反对单个Master节点带来的性能瓶颈问题,让OLTP事务性能具备Scale out能力,更好地满足用户的实时数仓和HTAP需要。

Multi-Master我的项目在2019年启动后,经验了一写多读和多写多读2个演进阶段,极大的晋升了ADB PG零碎高并发能力、实时写入/更新/查问的能力,在阿里外部撑持了如数据银行等多个外围业务,也通过了阿里2020年双11、双12等大促的考验。目前,产品的稳定性和性能都曾经失去了宽泛验证。在本文的如下局部,咱们首先介绍ADB PG原有的Single-Master架构导致的性能瓶颈及其起因,并介绍Multi-Master的设计思路。而后咱们会具体介绍Multi-Master架构的具体设计。之后咱们会介绍咱们在Multi-Master我的项目中所解决的几个关键技术问题和外围解决方案。最初,咱们会对Multi-Master架构的性能体现进行测试。

二 Single-Master架构 vs. Multi-Master架构

在数仓零碎设计中,通常把零碎中的节点分为Master节点和Segment节点(计算节点),Master节点和计算节点承当不同类型的工作。以ADB PG为例,Master节点次要负责接管用户的申请、查问优化、工作散发、元信息管理和事务管理等工作。Segment节点负责计算工作和存储管理工作。对于查问申请,Master节点须要对用户提交的SQL进行解析和优化,而后将优化后的执行打算散发到计算节点。计算节点须要对本地存储的数据进行读取,而后再实现计算和数据shuffle等工作,最初计算节点把计算结果返回到Master节点进行汇总。对于建表、写入等申请,Master节点须要对元信息、事务等进行治理,并协调计算节点之间的工作。

如上图所示,ADB PG是由Greenplum演变而来,晚期的ADB PG版本和Greenplum一样,是一种单Master架构。也就是说,一个数据库实例只有一个Main Master在工作,配置一个或者多个Standby Master节点作为高可用备份,只有当Main Master节点宕机,才会切换到Standby Master进行工作。随着业务的倒退,尤其是实时数仓和HTAP场景需要的减少, Single Master的零碎瓶颈问题也逐步浮现。对于查问链路,有些查问的最初一个阶段须要在Master节点上进行最终的数据处理,耗费肯定的CPU/内存资源。对于写入场景,大量的实时插入/更新/删除的须要高性能保障。而且Single Master架构如何解决超大并发连接数也是个问题。以上问题能够通过进步Master节点的配置(Scale up)来缓解,然而无奈从根本上解决。

ADB PG在2019年启动了Multi-Master我的项目,指标是通过节点扩大(Scale out)的形式来解决Master层的资源瓶颈问题,更好地满足实时数仓及HTAP等业务场景的需要。上图是Multi-master架构的示意图,通过减少多个Secondary Master节点来实现性能的Scale out,同时保留原有的Standby Master来保障高可用能力。为了保障ADB PG的事务能力,Multi-master我的项目须要克服一些其余不反对事务的实时数仓不会遇到的艰难。一方面,ADB PG须要对分布式事务能力进行扩大,反对多个Master的场景。一方面,对于全局死锁解决、DDL反对以及分布式表锁反对方面,ADB PG须要进行算法的翻新和批改。最初,ADB PG须要对更新之后的新架构的集群容错能力和高可用能力进行设计。在本文的余下局部,咱们将对上述几个议题进行介绍。

三 Multi-Master 架构设计

绝对于原Single-Master架构,Multi-Master架构在Main Master/Standby Master的根底之上新增实现了Secondary Master的角色,Secondary Master(s)反对承接和Main Master一样的DDL,DML等申请,同时用户能够按需扩大来晋升零碎整体能力。上面是各个Master角色及对应次要能力的简略介绍。

  • Main Master:承接用户业务申请,并把工作散发到各个计算节点进行分布式解决。除此之外,Main Master还承当了GTM,FTS和全局元信息服务的角色,这些组件与Multi-Master的实现密切相关。
  • GTM:全局事务管理(Global Transaction Manager),保护了全局的事务id及快照信息,是实现分布式事务的外围组件。
  • FTS:容错服务(Fault-Tolerance Service), 检测计算节点及辅协调节点的衰弱状态,并在计算节点产生故障时进行计算节点的Primary与Mirror角色的切换。
  • Catalog:以零碎表Catalog等信息为代表的全局元信息存储。
  • Standby Master:和Main Master组成典型的主备关系,在原Main Master故障的时候能够接替成为新的Main Master。
  • Secondary Master:能够视为”弱化的Main Master”,和Main Master一样能够承接业务申请并将工作散发到各个计算节点进行解决。Secondary Master会通过GTM Proxy与Main Master上的GTM以及计算节点交互来实现分布式事务。
  • 须要留神的是,Main Master与Secondary Master通过下层的SLB来做基于权重的负载平衡治理。如果是在Main Master和Secondary Master雷同的规格配置下,Main Master会通过权重设置来承当绝对少的业务申请负载,从而为GTM,FTS等预留足够的解决能力。

    四 Multi-Master关键技术

    本章将对Multi-Master的一些关键技术点进行具体的介绍,次要包含分布式事务处理、全局死锁解决、DDL反对、分布式表锁反对、集群容错和高可用能力。

1 分布式事务管理

ADB PG的分布式事务实现

ADB PG的分布式事务是应用二阶段提交(2PC)协定来实现的,同时应用了分布式快照来保障Master和不同Segment间的数据一致性,具体实现实现要点如下。

分布式事务由Main Master发动,并通过2PC协定提交到Segments。2PC是分布式系统的经典协定,将整体事务的提交过程拆分成了Prepare和Commit/Abort两个阶段,如下面的简略示意图所示,只有参加事务的所有Segments都胜利提交整体事务才会胜利提交。如果在第一阶段有存在Prepare失败的Segment,则整体事务会Abort掉;如果在第二阶段有Commit失败的Segment,而且Master曾经胜利记录了PREPARED日志,则会发动重试来Retry失败的Commits。须要阐明的是,如果一个事务仅仅牵涉到1个Segment,零碎会优化为依照1PC的形式来提交事务从而晋升性能,具体来说就是将上图中Master参加协调的Prepare和Commit两个阶段合二为一,最终由惟一参加的Segment来保障事务执行的原子性。

Main Master上的GTM全局事务管理组件会保护全局的分布式事务状态,每一个事务都会产生一个新的分布式事务id、设置工夫戳及相应的状态信息,在获取快照时,创立分布式快照并保留在以后快照中。如下是分布式快照记录的外围信息:

执行查问时,Main Master将分布式事务和快照等信息序列化,通过libpq协定发送给Segment上来执行。Segment反序列化后,取得对应分布式事务和快照信息,并以此为根据来断定查问到的元组的可见性。所有参加该查问的Segments都应用同一份分布式事务和快照信息判断元组的可见性,因此保障了整个集群数据的一致性。另外,和 PostgreSQL 的提交日志clog相似,ADB PG会保留全局事务的提交日志,以判断某个事务是否曾经提交。这些信息保留在共享内存中并长久化存储在distributedlog目录下。另外,ADB PG实现了本地事务-分布式事务提交缓存来帮忙疾速查到本地事务id(xid)和分布式全局事务id(gxid)的映射关系。上面让咱们通过一个例子来具体了解一下:

如上图所示,Txn A在插入一条数据后,Txn B对该数据进行了更新。基于PostgreSQL的MVCC机制,以后Heap表中会存在两条对应的记录,Txn B更新完数据后会将原来tuple对应的xmax改为本身的本地xid值(由0改为4)。尔后,Txn C和Txn D两个查问会联合本人的分布式快照信息来做可见性判断,具体规定是:

  1. 如果 gxid < distribedSnapshot->xmin,则元组可见
  2. 如果 gxid > distribedSnapshot->xmax,则元组不可见
  3. 如果 distribedSnapshot->inProgressXidArray 蕴含 gxid,则元组不可见
  4. 否则元组可见。如果不能依据分布式快照判断可见性,或者不须要依据分布式快照判断可见性,则应用本地快照信息判断,这个逻辑和PostgreSQL的判断可见性逻辑一样。

基于上述规定,Txn C查到两条tuple记录后,通过xid和gxid映射关系找到两条记录对应的gxid值(别离为100, 105),规定c会限定Txn B的更新对Txn C不可见,所以Txn C查问到的后果是’foo’;而Txn D基于规定则对Txn B更新后的tuple可见,所以查问到的是’bar’。

Multi-Master的分布式事务实现

Multi-Master的分布式事务实质是在原有分布式事务根底之上进行了加强。如上图所示,Postmaster是守护过程,Main Master的Backend业务解决过程和GTM Server之间通过共享内存通信,但Secondary Master是无奈间接通过共享内存与Main Master上的GTM Server通信的,为此,咱们在Secondary Master和Main Master之间新增了一条通道并实现了一套GTM交互协定。另外,为了缩小Secondary Master和Main Master之间的连贯并晋升网络通信效率,咱们新增实现了GTM Proxy来代理同一个Secondary Master上多个Backend过程的GTM申请。上面,本文将从GTM交互协定 、GTM Proxy和散布事务复原三个方面来零碎的论述一下Multi-Master分布式事务实现的技术细节。
(1)GTM交互协定
GTM交互协定是Secondary Master和Main Master之间事务交互的外围协定,具体协定的音讯和阐明如下表所示:

能够看到,音讯的外围还是在替换GXID,SNAPSHOT等信息,同时做BEGIN/PREPARE/COMMIT/ABORT等事务操作,此处就不再做一一阐明。值得特地指出的是,跨节点的音讯交互老本是很高的,思考到OLAP用户的特点和需要,咱们配合协定提供了不同的一致性选项,从而让用户能够在性能和一致性上进行衡量和抉择:

• 会话统一:同一个会话满足可预期的一致性要求,包含枯燥读,枯燥写,读本人所写,读后写的一致性。
• 强统一:线性一致性,一旦操作实现,所有会话可见。也基于不同的一致性模式进行了定制和精简。
如上表所示,如果用户须要更高的性能而对于一致性能够做出肯定斗争,则能够抉择会话统一模式,绝对强统一,会话统一对协定交互进行了大幅度精简,仅仅保留了 GET_GXID和 GET_GXID_MULTI :

(2)GTM Proxy的实现

在Multi-Master的实现中,GTM Proxy是作为Postmaster的子过程来治理的,这样做的益处是:1) 无需新增新的角色,配套管控更简略;2) GTM Proxy和Backend之间是人造认证和互信的;3) GTM Proxy能够通过共享内存和Backend过程通信,这样相比Tcp Loopback更高效,既能够缩小内存拷贝,也无Network Stack开销。

每个GTM Proxy过程会和GTM server建设一个网络连接,并会服务多个本地的backend过程,将它们的GTM申请转发给GTM server。GTM Proxy还针对性的做一些申请优化解决,如:

• Backends间共享Snapshot,从而缩小Snapshot申请数
• 合并和批处理Backends的并发GTM申请
• 批量获取gxid(会话统一)
GTM Proxy是缩小Secondary Master和Main Master之间连贯并晋升网络通信效率的要害。事实上,在实现中,如果用户开启了强统一模式,咱们在Main Master上会默认开启GTM Proxy来代理Main Master上多个Backend过程与GTM Server之间的申请,从而进一步升高GTM Server的压力。

(3)分布式事务的复原

在很多状况下零碎都须要做分布式事务的复原解决,比方零碎/Master重启,Main Master/Standby Master切换等,当不思考Multi-Master,分布式事务的复原能够简略划分为如下3大步骤:

  1. Main Master回放xlog,找出所有曾经Prepared然而尚未Committed的事务;
  2. 命令所有Segments提交所有须要Committed的事务;
  3. 收集所有Segments上未Committed而且不在“Main Master”须要提交的事务列表中的事务,Abort掉这些事务。
    下面的流程如果进一步思考Multi-Master,那么一些新的问题就引入了进来,外围须要解决的有:1)Secondary Master发动的事务的复原;2) Segments和Secondary Master上残留Prepared阶段的事务在Secondary Master或者Master重启等状况下的复原/清理等等。为此,针对Multi-Master,咱们对二阶段事务的提交和分布式事务的复原流程都做了加强,如下次要讲一下二阶段事务提交的加强和Secondary Master被删除及第一次启动时对应的清理流程:

此外,Main Master/Secondary Master重启的流程也进行了加强,这外面和原Main Master重启复原的次要差异是须要辨别出属于本人发动的分布式事务,具体的辨别是通过加强GXID来实现的。咱们在本来GXID的根本信息之上增加了masterid信息,这样{GXID}-MasterID联合起来,就能够基于GXID来辨别出具体的Master了。

2 全局死锁检测

ADB PG 4.3版本是通过对表加写锁来防止执行UPDATE和DELETE时呈现全局死锁。这个办法尽管防止了全局死锁,然而并发更新的性能很差。ADB PG从6.0开始引入了全局死锁检测。该检测过程收集并剖析集群中的锁期待信息,如果发现了死锁则杀死造成死锁的过程来解除死锁,这样极大地提高了高并发状况下简略查问、插入、删除和更新操作的性能。ADB PG 6实现全局死锁检测的要点如下:
• 全局死锁检测服务过程(GDD)运行在Main Master上
• GDD会周期性获取所有segment上的分布式事务的gxid及其期待关系
• GDD结构全局的事务期待关系图,检测是否成环,如果成环,则回滚环中一个事务,破解死锁
ADB PG Multi-Master的全局死锁检测整体也是ADB PG 6.0版本的实现来加强的,如下图所示:

ADB PG Multi-Master的GDD也运行在Main Master之上,次要新增了两个Master-to-Master的RPC调用来采集由Secondary Master发动的分布式事务gxid列表以及告诉Secondary Master去破解负责分布式事务的死锁。
• Get_gxids: 从每个secondary master获取gxid列表,以判断导致死锁的事务各属于哪些master
• Cancel_deadlock_txn: 如果导致死锁的事务属于某个secondary master,则申请该master回滚掉该事务

3 DDL反对

在ADB PG的原生实现中,Main Master对DDL的反对和与Segments上Catalog的批改同步是通过2PC的形式实现的,ADBPG Multi-Master扩大了这一实现来反对对Secondary Master上Catalog的同步。

此外, Secondary Master也反对解决DDL,简略说来,咱们在Secondary Master外部实现了一个简略的代理,Secondary Master如果收到DDL申请,会将申请转发给Main Master来解决。具体如下图所示:

DDL的实现非常复杂,实在的落地其实要比下面简单很多,也牵涉到很多细节,比方VACCUM/CLUSTER/ANALYZE等绝对非凡的DDL解决,但整体的实现计划都根本听从下面的准则。

4 分布式表锁

家喻户晓,在数据库的实现里,为反对对表数据的并发拜访,个别都会通过锁来实现。ADB PG的锁模型和PostgreSQL是兼容的,具体如下表所示:

Multi-Master对ADB PG的表锁协定进行了加强和适配,总结起来,咱们定义了一套新的分布式表锁协定来标准Main Master及Secondary Master上加锁的程序和规定:
任意Master上的过程申请1-3级锁
• 本地申请该表锁
• 在所有Segments上申请该表锁
• 事务完结时所有节点开释锁
Main Mater上的过程申请4-8级锁
• 本地申请该表锁
• 在所有Secondary master上申请该表锁
• 在所有Segments上申请该表锁
• 事务完结时所有节点开释锁
Secondary Master上的过程申请4-8级锁
• 在Main Master上申请该表锁
• 本地申请该表锁
• 在所有其余Secondary Master上申请该表锁
• 在所有Segments上申请该表锁
• 事务完结时所有节点开释锁

基于上述规定,咱们能够实现任何的表锁申请会最终在某个Master或者Segment失去裁决,从而保障了对ADB PG的原表锁协定的兼容。

5 集群容错与高可用

ADB PG是通过复制和监控来实现容错和高可用的,次要包含:1)Standby Master和Mirror Segment别离为Main Master和Primary Segment提供正本(通过PG流复制实现);2)FTS在后盾负责监控与主备切换。如上图中的流程:

  1. Main Master到Standby Master的流复制;
  2. Primary Segment到Mirror segment的流复制;
  3. Main Master的FTS Probe过程发包探活Primary Segment;
  4. Main Master的FTS Probe过程发包探活Secondary Master;
  5. Main Master重启后,其FTS Probe过程向GTM Server通报所有Master;
  6. Secondary Master的FTS Probe发包探活Main Master,获取最新集群配置和状态信息并存在本地;
  7. Secondary Master的FTS Probe无奈连贯Main Master后尝试探活Standby master,若胜利则更新其为新的Main Master;否则持续探活原Main Master。
    简略说来,ADBPG Multi-Master在原ADB PG的容错和高可用根底之上进行了加强,让零碎可能进一步对Secondary Master进行兼容。另外,Secondary Master如果故障,则会进一步由管控零碎看护并做实时修复。

五 Multi-master 扩大性能评测

ADB PG单Master实例在高并发点查、导入等偏OLTP的场景往往会存在单Master瓶颈,而Multi-Master的引入很好的解决了问题。为了验证Multi-Master在OLTP负载下横向扩大的能力,本章节对ADB PG Multi-Master在默认的会话统一模式下的TPC-B/C两种典型负载进行了性能测试。

1 TPC-C性能测试

TPC-C是事务处理性能委员会(TPC)旗下一的一个支流性能测试Benchmark汇合,次要是测试数据库系统的事务能力。TPC-C测试过程中,会实现多种事务处理并发执行、在线与离线事务混合执行等形式,可能比拟全面地考查数据库系统的事务能力。咱们采纳的测试环境是基于阿里云ECS的ADB PG实例,具体参数如下:
• Master(Main Master/Secondary Master):8c64g
• 节点规格(segment):4C32G
• 节点数量(segment): 32
• 存储类型:ESSD云盘
• 节点存储容量(segment): 1000GB

能够看到,在只有1个Master时,当并发数达到64时,TPC-C的性能根本达到峰值,无奈再随着并发数减少而减少,然而当有4个Masters时,随着并发数的减少TPC-C的性能仍旧能够十分好的线性扩大。

2 TPC-B性能测试

TPC-B是TPC旗下另一个性能测试Benchmark汇合,次要用于掂量一个零碎每秒可能解决的并发事务数。咱们采纳的测试环境是基于阿里云ECS的ADB PG实例,具体参数如下:

• Master(Main Master/Secondary Master):8c64g
• 节点规格(segment):4C32G
• 节点数量(segment): 32
• 存储类型:ESSD云盘
• 节点存储容量(segment): 1000GB

能够看到,和TPC-C相似,在只有1个Master时,当并发数达到64时,TPC-B的性能根本达到峰值,无奈再随着并发数减少而减少,然而当有4个Masters时,随着并发数的减少TPC-B的性能仍旧能够十分好的线性扩大。

六 总结

ADB PG Multi-Master通过程度扩大Master节点很好的冲破了原架构单Master的限度,配合计算节点的弹性,零碎整体能力尤其是连接数及读写性能失去进一步晋升,能够更好的满足实时数仓及HTAP等业务场景的需要。
原文链接

本文为阿里云原创内容,未经容许不得转载。

【腾讯云】云产品限时秒杀,爆款1核2G云服务器,首年99元

阿里云限时活动-2核2G-5M带宽-40-100G SSD服务器,特惠价86元/年(原价724元/年,限时99元续购三次),速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

You may also like...

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据