PolarDB分布式版:与云融合的分布式数据库发展新阶段
内容介绍:
一、分布式数据库发展新阶段
二、零售中台的建设背景
三、分布式和零售平台的关系介绍
四、展望
主要阐述分布式产品在过去一年的最新进展以及对于分布式数据库发展的最新展望。
一、分布式数据库发展新阶段
分布式数据库并非作为一个新名词,相对于传统式的数据库,其发展时间并非久远,在真正应用到实际生产场景,大规模化应用的时间不过十几年,Polar DB分布式从2010年开始,在阿里云集团逐步应用到核心的电商业务,逐步发展到云上的分波数据库。该阶段,即分布式数据库发展,经历了主要的三个阶段:
第一阶段,实际上是分布式的中间这个阶段。这个架构较为简单,我们的应用在数据库的一层,原来用单机数据库,由于单机数据库扩展性不足,不能满足业务的快速拓展的需求。因此我们用多个数据库节点,加上分布式中间件去达到分布式数据库做横向拓展。分布式中间件更多的是发挥十二点的数据分片以及做数据的路由分发的作用,那么对于这种业务,尤其是业务特点比较清晰。
例如基于用户ID的完美拆分时,是较为适合中间的解决方案。更多的是一种解决方案去做分库分表的最佳应用实践,那么到这个阶段时,其实更多的应用不仅仅是业务很难去完美的应用数据水平拆分,就能做到业务清晰的拆分,更多业务需要在做跨表或画库的这种访问时,需要做分布式事务时,第一阶段的这种分布式中间件很难满足其需求,因为当其处理分布式事务时,必然会带来很多的问题。
在第二阶段,分布式数据库,一体化分布式数据库架构,是Polar DB分布式产品的1.0阶段,演进成分布式中间件(DRDS),演进成一个一体化分布式数据库。
在第三阶段,随着云计算的发展,分布式数据库作为云的产品,如何与云基础设施做充分的融合。我们的架构把分布式架构在云平台上,充分利用云资源的弹性能力,进一步把扩展性提升为这种实时、快速、弹性的能力。以及利用云资源规模化的特点,去提升资源共享和隔离的能力,此为第三阶段,即云原生的分布式数据库的阶段。
1.云资源能为分布式数据库带来什么?
主要为以下四个方面:
一是由原来分布式数据库着重去解决扩展性问题变成更加具有弹性,不仅能够弹声音,也能弹其他,这是它更强的伸缩能力带来的。
二是利用云规模化的资源池,带来更高的性价比数据库的能力。
三是由于云服务实际分散在全球各个地域地区以及各个机房,其规模化的云基础设施能够提供这种灵活的高可用策略。能够带来用不停机的数据库服务,我们认为其在云上面能更好的去提供或更有效的提供高可能的服务的能力。
四是带来更好的隔离能力。云上的数据库,尤其是分布式数据库,由于解决的是一个规模化使用数据库的问题,它更多的是面对一些超级大客户的大应用。其数据是非常海量的。此外,其业务覆盖地域非常的广泛,用户广泛。
它需要在全球多个点都需要提供不间断的服务,那么它不同的业务类型或者不同的用户类型,对于数据库的使用方式以及对资源的需求是不一样的,那么如何更好的去充分使用该资源,利用其业务的负载特征、不同类型的业务负载特征去做资源的共享以及隔离。我认为这也是云资源池能够加上分布式技术,能够给此数据库用户,尤其是企业级的数据库用户提供的更好的一个特性。
2.为何分布式数据库跟原生融合能够发展到新阶段?
云是一个非常好的载体,跟分布式技术是非常正交的一个体系,可以认为云上的所有系统都是分布式的,不过云能够进一步把资源的解耦做到更加极致和广泛。可从以下几方面来阐述:
首先,分布式首先要解决的问题是扩展性,云带来的是从高可燃性到这个高度的弹性。那么Polar DB 如何去做此弹性,我们认为,分布式数据库不仅是解决大体量、大规模数据量的用户,还要去解决小规模客户。Polar DB分布式引入了一个非常弹性、灵活的架构,即集中分布式一体化。有两个形态,一是标准版,二是企业版。标准版和企业版实际上是一个无缝升降的一个过程。
可以从标准版原地升级到分布式版,这里无需数据的搬迁,也无需应用的改造。此外,也可从分布式版弹降到集中式版,其中间是一个非常透明、灵活的转换的一个过程。其中应用是可以带具体的做迁移,对于应用来说是零感知的过程,而这给用户带来了一个非常低的入门门槛。当业务在不断的发展过程中,我们的体系或者整个架构都可以随着业务的使用规模去匹配使用的负载去变更它的形态,在变更的过程中,既不需要应用去改造,也不需要数据做迁移。
其次,是对于想要达到集中分布式的一体化,这里解决的关键问题就是分布式数据库能否像集中式数据库提供一样的能力、语义以及一样的按比例资源的弹性性能的提升。其中比较关键的几点是,不是说把数据做简单的分区和扩展,就是达到了分布数据库的效果。这里面有比较多的问题,例如,在单击时,单表变成了分区表,其中数据有一个分布的问题,Polar DB分布式有auto模式,可自动将数据做一个分布以避免用户去操心,用户要去设定自己的分区件、分区规则等,可自动去做分布。
此外,比较重要的是,数据分布在各节点后,那么跨节点事务从原来的单机事务变成了分布式事务,分布式事务对于数据库的性能具有较大的影响,由于它比较执行一个两阶段事务提交的过程。这里也根据数据的亲和性,比如会把在事务上的相关行的表组成表组的概念,然后去做分布式事务的优化,我们把两个阶段优化成一个阶段的提交,以减少分布式事务带来的开销。
另外,在原来单机数据库上,为了加速查询去做的二级索引,二级索引的优化到了分布式事务或者分布式数据库,实际上是一个带分区的全局二级索引,其本身涉及到更多的性能问题。比如在写单表时,写主表必然涉及到索引表同步的写入,那索引表达必然时跨节点的,也就引发分布事务,也就必然会拖慢写的性能。
此外,在二级索引的选择时,如果要做回表,那么你要在各个分片上去做查询,那一样会拖慢速度。那我们在全局二级索引里做了大量优化。首先一个比较重要的优化是不仅有全局索引,还有局部的二级索引,也就是说,我们在全局二级索引做回表时,可以利用局部二级索引进一步的进行加速,以避免全局二级索引在做回表查询上带来的巨大的开销。
再者,对于单机事务的日志。日志很重要的原因在于数据库作为一个数据系统不仅是管生产、消费,还有分析,它在跟上下游的数据库工具进行对接的过程中,不可避免的需要数据库的日志继续的同步。那么在分布式系统里,每个数据节点都可能产生数据变更的日志,那么为了维护数据库,它作为一个跟单机数据库保有的一致信号,必须要有一个全局事务日志。就需要把单点的事务日志去做合并、整流、排序来给外面提供一个兼容的一致性的分布式事务的日志。我们通过CDC组件能够对外提供一个一致的数据库的一个整合的日志流。做以上这些工作是为了达到一个目标,是希望分布式数据库最终对外的形态,从用户视角来看的话,是一个一体化集中式的数据库。用户使用时无需关心数据库具体如何分布,它还像原来使用集中式数据库去使用分布式数据库。那实际上来说,如果业务可以通过某一业务的维度,例如我们通过用户的ID去做区分,那么你的业务都是不去跨用户的,我们的所有业务都是围绕用户的为读去做查写入,是比较容易做区分的,但实际上,现在的业务当中,很难存在如此完美区分的应用。
因此,分布式为了解决这样的问题,做了很多的这种机制,尤其是在集中分布式一体化里,不是所有的表都要去做数据的分区,拿这里有很多的模式,比如说原来的单表,很多单表都可以去做分布式,对于应用去做业务的水质拆分。那么对于一些大表,也可以做数据水平的拆分去达到扩展的目的。此外还有表组的机制以及二期所有人的机制去做混合的处理,也就是说根据业务的适用性去做针对性的处理以保证全局性做到最佳。那么其中存在一些解决方案,垂直的拆分业务如何去做垂直拆分以及水平拆分的一些混合应用。
在这个像实货,很多零售的saas的业务做了一些应用,原来有一些单机的应用,然后拓展到分布式的过程中。我们尽量去把一些大表打散去做分布式的形态,另外一个是很多的saas应用,其实有很多的用户和商家需要共用大的数据库集群。在这里面,也设计了很多租户机制,面对多租户,最重要的是资源能否做到有效隔离,因此我们做了一个数据的locity,称为分区的locity的一个特性,能够把一些分区表与某些资源池做一个绑定。
例如,一个业务里有很多租户,租户ABC 是中小型租户,租户D是大租户,为了保障租户D的资源,我们会与其一个专用的资源池做绑定,另外一些中小租户,会与其另外的资源池进行绑定,大小租户之间没有业务的负载,互不干涉,所以可以达到资源的隔离的目标。在saas行业中,多租户的隔离实际是做到一个比较广泛的应用,根据它的业务特点,这样最大的好处就是各租户可共用一套表的schema,无需去占多张表。共用一张表可以做到航级,多租户的特点去做租户资源的隔离。
此外,今年着重推出了行列混合的一体化查询能力。首先,Polar DB分布式架构引入了一个名为内存水头节点及内存副本的足建,实际上我们跟我们的航程是做到一个实时的同步,在负载非常高的情况下,同步延时小于三秒。整个同步,是用CDC统一的日流组件去做到实时的同步,实时同步,保证事务的一致性,即在查询的过程中,不会查询到部分的事物,而是查询到完整的事物。
那么引入内存索引,在内存组件里,实际可以通过sql语句Create一个class的column的index。来根据需要针对复杂分析的场景或者特定的表或者列去做内存索引的创建。在创建索引后,数据结构是用类似RPC的格式去做高度的压缩,然后采用insert delete这种模型去做内存索引的创建,索引链的构建是一个实时一体化的架构,整个查询亦是一体化。
即优化器会自动根据查询的类型,然后自动漏油到行存、或行列混合的存储去保证最优的查询功能。在TPCH的benchmark上跑了一个基于内存加速的100G的查询,可以看到相比行存,query的平均性能提升是非常巨大的6.4倍。实际上在3×16C的这个节点规格上能够做到20多秒的成绩,其实基本上在很多分析类的分析式数据库的查询功能是差不多的。另外也做了clickbench性能的优化,包括一些向量化的查询引擎技术能够把key bench优化到接近50秒的高水平,那我们在电商平台也做了在大数据场景下的混合查询的实践。实际上不论是否利用内存指头节点,它可以透明的去开内存指头节点去做行业混合的HI type应用的实践。
另外是如何利用云基础设施在多个region、AZ分布来提供一个高可用服务的能力。实际在很多时候,高可用级别对成本以及高可用需求来综合的一个考量。我们提供多种高可用级别,例如对于单AZ的多个节点的高可用、多个可用区的高可用的容灾以及跨地域的地域级的容灾。这种模式决定了整个RTO和RPO的一个指标。在多节点和多可用区,实际上都可以在做到RTO等于零、RPO等于零的情况下,RTO也就是切换的不可服务的时间,例如小于八秒。那么在地域级的容灾,即整个城市级的灾难性的故障时,仍然可以做到秒级的IPO,以及分钟级的LTO的故障切换的一个能力。那么同时在公有云和混合云上都可以做到这样的能力,这取决于在公有云上。
实际上我们的标准都是三A这部署,我们默认是3AZ这部署在混合云上,取决于客户的机房的一个条件,有的客户,例如3AZ,以及不具备3AZ部署条件的同事,还可以去做两AZ的部署。我们利用PS协议的一致性算法,同样可做到RPO等于零,从3AZ角度,不管是标准版还是企业版,默认的是跨可用区的保障的容灾级别,即在公有云上,可选跨AZ或3AZ的部署方式,也可选单一的附属商会,其实成本一致,我们默认是3AZ的部署保障。
另外,我们在跨高可用、跨地域的一个容灾,有一个典型的像金融行业的实践,比较多的两地三中心的三副本的模式,那么在单个地域单个AC故障时,实际是不影响RPO,它可以做实时的切换,也是秒级切换,只有当城市的主数据中心或主要城市群的两个A级都挂了,才会缺到两个异地数据中心的异构集群上,如此才需要去有一个分钟级的切换。基于分布式的多变,也可以减少故障爆炸的半径。
其次还做了更加规模更高级别的异地容灾和多活的机制,有全球数据库网络GDN机制以经营异地转储备份去做容灾。如此,例如在3D,像上海、深圳以及北京三个机房去建三个独立集群,然后去做实时复制以及高可用故障的切换。那在中石化等大规模的国企、央企的零售众泰,应用异地多活的技术去保障,由于其服务网点遍布全国,那么每一地域都会有容灾的需求,对于实时服务以及他们是至关重要。应用容灾多活机制,同样在金融行业,某头部银行也是应用两地三中心的标准容灾架构去保障银行业务的数据可靠性和服务可靠性。
由于Polar DB是一个开源产品,基于商业版本和开源版本去做多云部署以避免有些客户对其数据的担忧,它希望在多个云上做部署,而不仅依赖于某单有的公有云。
最后,云资源池对分布式数据库带来的超低成本。在其中,分布式2.0里推出了TTL,即航机自动数据归档的2.0版本,TTL的主要功能是用户无需关心数据失效的规则,通过制定指定的一个日期字段,我们会自动把数据做归档,这个过程无需数据,需要用户去做干预,我们把数据归档到临时表,在归档到归档OSS存储上,然后用内存高度压缩的方式把数据成本降低到20倍的效果。
同时用内存存储节点做归档存储能带来很多好处,首先归档是实时的,其次是归档表的查询和行的查询时完全等同的,再者是可在归档表上同样做DDL。如此极大的拓展了历史数据于在线数据的统一查询的应用场景。即,无需关心数据是在归档表、归档存储还是在线数据里,都可用一套方式去查询和维护。由于加入了一个高频的快乐的查询的新能力,我们几乎可以利用内存的能力去做几乎无限闪回的查询,即可查询任意过去时间点的快照上面的数据。
二、零售中台的建设背景
首先,在国家层面,国务院早在2020年9月印发关于加快国有企业数字化转型的通知,将数字化转型作为提升传统动能培育发展新动能的一个重要手段,因此,为快速响应国家数字化转型战略,集团提出数字化赋能、数字化优化、产业再造三阶段的转型方针。万能数字作为中国石化销售公司下数字化转型赋能的科技公司,因此要肩负起数字化转型的使命。
其次,集团和销售公司多年来也统建很多的信息系统,各省市也自建了很多系统,但由于历史等原因,很多系统之间是烟囱式,导致数据共享信息不通,造成很多的信息孤岛。因此为解决该问题,新零售平台应运而生。
1.零售平台的建设目标
首先,增强核心竞争力。中石化下拥有三亿家用户,每天订单式上千亿级,因此必须以客户为中心来提升用户的体验,提高运营效率,对现有的程序系统进行融合升级。必须统一客户体系、营销体系、支付体系来建设满足油气新电服务的全业务业的新零售平台。
其次,提升数字决策力,通过搭建数据中台来实现数据集中以提升数据分析能力和挖掘能力。二是通过建设业务中台来实现能力复用,降低现有系统之间的耦合,防止重复造轮子的问题,从而实现系统的互通,打破系统之间的壁垒。
再者,形成薪资生产力。近两年过来宿舍也陆续上线了一些像新能源系统的充电,全国很多开车也知晓我们有很多充电桩,目前我们以全国推广。还有是汽服系统,包括洗车以及正在推广的应付平台,一级商城门店运营系统,这就是目前在零售中台的一个架构全景。
2.新零售平台的介绍
由于采用了新理念、新架构、新技术,因此称为新零售平台。采用的是最新的分布式微服务架构,结合云原生技术来作为新零售中台。
此处重点介绍业务中台和数据中台。
何为业务中台?个人理解业务中台就是企业核心业务能力的整体沉淀和平台化的解决方案。通俗说,即所有前台应用的通用化能力的抽象。既然要通俗化,那复用性则很强、耦合性必须很低,此外又有较强的扩展性。因此根据销售公司的统一规划和设计,我们这里新建了16个能力中心,单目前已远超过16个能力中心,主要是客户营销、商品、订单支付等能力中心。根据这些能力中心的系统建设,就是实现一体化客户管理、一体化营销、一体化支付体系。再结合能力开放平台,为前台应用提供标准化的API能力和此服务的编排能力。数据中台主要解决数据的汇聚和整合。通过制定统一的数据标准实现数据的统一管理,提高数据质量,沉淀数据资产。
通过多福一中台的架构,结合离线加实时计算体系,为企业提供更全面的数据视角,从而做出更全面更科学的决策,促进企业从经验决策驱动向数据决策转变。并且提供丰富的数据挖掘和分析工具。然后从海量的数据里体验有价值信息,例如分析用户形成用户画像,为用户提供更精确更个性化的一些服务。
临时中台主要是围绕提升运营效率,增强用户体验,实现数据驱动决策以及促进业务的灵活性和创新性。
新零售平台作为现代业务的核心系统,支撑线上线下的商品管理库存。同步订单处理、会员服务以及促销活动、数据分析等一系列的关键功能,对于整体业务的连续性,所以说要求是非常高的,是高可用的。我们也通过各种手段,例如单元化跨机房部署,甚至是跨地域部署,包括未来一体化多活,也是一个重要方向。这些技术可能主要是解决或抵御大面积故障,然而在日常过程中,往往面临的都是一些局部问题,例如某一结点异常或发布一些不严谨的业务收口,导致其他业务受到影响。所以我们要考虑如何规划到平台,当出现某一节点或某一模块异常时,它尽可能带来较小的影响。
因此此处的库级别的隔离就是数据库。刚才所提的数据库级别的隔离或库级别的隔离,甚至是精确到行级别的隔离,也是我们的一个重要诉求。同时,由于我们的订单每天都是千万级,每年有百亿级的订单量,包括用户级也是三亿+,所以对性能的要求肯定是很高的。每年有各种大促销,我们的重量级、数据量非常庞大,所以高性能低延迟是最基本的一个诉求。
最后是应用性,虽然很多人力中心都是从零到一的新建,但是我们的是在现有的基础设施上来完成的。因此,一定要去考虑上下游业务的 兼容性问题。整个平台的建设周期非常短,并且迭代速度非常快,所以我们对开发效率的追求是极致的。我们不希望在引入新架构或新技术的同时,带来太多的学习或使用成本,这是比较关键的。
因此结合目前中台的核心需求,最终选择了数据库,即PDP方式版本或仓作为数据库,同时,PDB仓也是零售经验,淘宝零售经验的一些输出,所以在整个零售行业的沉淀对我们有很大的帮助和启发。同时获得多个容器部署以及其强一致协议。所以说天然满足了对高可用容灾的诉求。不仅多机房部署的同时,还能保证数据不丢失,包括前一段时间发布的基因能力,也是对未来异地容灾、异地多活设计有非常大的帮助。
此外,DP差对数据分布非常友好,不想传统意义上的分布分表可人为的去指定数据的存储位置。无论单表还是分区表,它都可以。我们随意去指定数据存储到哪一个节点,即便在同一个数据库实例里,我们也可以按照自己的想法去做模块之间、表之间、甚至是分区与分支之间、分区之间的隔离。这对整体业务的连续性设计有很大的帮助。
最后是兼容性。这里不仅是指代码层面,或者是sql语法层面和mysql的高度兼容。很多其他同类型数据产品,做的也很好,但想体现的是,例如和白色周边配套也是兼容的,同步的是否卡消费,这一点对我们是比较重要的。由于很多下游系统,例如它的宾格式与其一模一样,我们的下游系统基本上完全不用修改,拿来就可使用,这样大大降低了使用成本。
三、分布式和零售平台的关系介绍
分布式和零售中台的关系,之前在很多场景有讨论过,可能按照之前的很多观点,由于业务中台的数据量、访问量很大,要去应对各种流量洪峰,所以必须用分布式数据库。
就个人观点,还存在另外一半原因,即满足高可用。由于核心数据被分布在很多独立的存储节点上,每个存储节点都有独立的CPU和内存资源,这样即便在某一任何一个节点异常了,整体业务的受损面积是可控的,不会出现最害怕的流量跌倒零的情况,所以这是我们今天选择这个分布式数据库的一个重要原因。
再结合,或者因为它提供跨机房部署甚至是跨地域的容灾能力,我们相信在地域的坚持下,应该可以帮助三六九业务的可用性。
1.使用分布式数据库后遇到的问题或解决哪些问题
首先,遇到的是异动查询。例如,对非拆分组件进行高密化DNS的查询操作,举两个实际性的问题,一是用户表需要根据用户的手机号或根据用户的账号去登陆,那选择哪一个分区件,二是交易系统,订单表又需要根据买家ID甚至根据卖家ID去做订单查询,那如何查询分区线。
在与技术团队针对该问题进行交流时,我们了解到,淘宝很早就面临该问题,并且针对该问题已经迭代过诸多解决方案。目前最新的解决方案是全局二级索引,通俗来说,即全局的map表。表中的不同字段决定着map表的查询维度。
在使用map表时,人们疑惑如何确保其与主表数据的一致性,包括在执行地点操作时,二级索引是否有影响,二级索引的回表查询的代价有多大,RT响应是否有影响。首先破仓通过分布式事务来确保全局二级索引和主表数据的一致性,并且通过多年优化,解决了从索引的创建数据的写入,索引的扫描的全流程的一致性问题。所以说真正做到数据的一致。
关于DBA的兼容性问题,支持它时通过加密复制数据修改源数据映射的方式,结合快速增加力的特性支持,即全局二级索引,它不锁表列类型的变更。所以DBA在执行字段变更时完全可以复制全局二级索引属性的存在这一性能,它可以通过索引增加字段来做到减少回表的操作,从而提升整体性能。刚才所提,通过全局二级索引来实现高效异构查询。
2.分布式数据库针对海量数据的存储
之前提及我们每年有上百亿订单,零售中台最重要的一个能力中心就是订单中心,我们在全国拥有三万多家加油站以及二十二点八万的门店系统,所以加油付费和便利店购物会形成很多的订单。我们和淘宝的区别在于,从订单创建到交易完成,可能我们在几分钟内完成,但是淘宝存在的物流关系,这个过程可能需要几天甚至几周的时间。
我们的历史订单量很大,并且由于国家监管的要求,需要做到实时查询。
所以给我们的系统设计带来一些难题,因此,采用破裂的数据,历史数据归档,即按需把历史数据归档到对象存储里,既节省存储空间,又减少图表体积。一定程度上优化它的性能。关键是在线数据和历史数据,可做到同意查询入口。我们无需其他连接方式,通过一条搜索就可实现离线数据的查询,因此这是极为方便的。
四、展望
主要阐述零售中台下一代的建设方向。
首先要考虑容灾多、集资提效以及AI。由于中石化面向的C端用户非常庞大,所以目前要构建一个高可用高配发零故障的零售中台,以保障三个九甚至是以后要做到四个九。目前已经实现同城双核,下一步要考虑异地多活,通过负载均衡加数据同步以实现跨地域的机房部署,确保当系统出现故障时可自动实现流量切换,同时采用实时,包括数据恢复的技术,确保数据安全性和完整性。
集资提效意味着我们可能提高临时仲裁的运行效率,减少不必要的资源浪费。即后面可能会引入阿里云的SAE等技术做到弹性。通过优化系统架构减少这些容易组建,通过几次提效技术,可提高临时中台的处理能力,满足不断增长的业务需求。
AI加持意味着需要利用人工智能技术提升中台的智能化水平,通过进行深度学习实现对用户行为的深度理解。提供更精确的个性化推荐,我们该可以利用资源等技术实现对用户需求的理解,为用户提供便捷服务。