阳振坤:当我们在谈论金融级分布式数据库的时

  当我们 2010 年前后开始做分布式数据库,也就是设计 OceanBase 架构的时候,一开始瞄准的目标,就是要把它做成一个通用的关系数据库产品,而不是一个仅仅在公司内部使用的产品。2017 年,让我们团队最高兴的是,通过 8 年研发抗战,我们不仅做到了承担蚂蚁金服「双十一」全部核心业务的重压,还在 6 家商业银行落地,成为他们互联网金融类新业务系统的数据核心。

  我是 1965 年生人,在做分布式系统和数据库的研发之前,跟着老师王选,做了十多年的激光照排,亲身经历了北大方正激光照排系统从无到有,从小到大的过程,也看到了王选老师的创新对媒体出版产业、对亿万大众的信息消费产生了多么巨大的影响。王选老师的一句话让我铭记至今:「高科技产业应实现『顶天立地』模式。『顶天』就是不断追求技术上的新突破;『立地』就是把技术商品化,并大量推广应用。」这让我清楚地知道,如果要做一个好的创新,不仅要技术上牛,更要真正应用到生产和生活的实际场景中去。就像 CPU 的国产自主研发,我们十几年前就能做出来「狗剩」(Godson),如今更有寒武纪,但都还没有机会得到大规模商用化,这是让人扼腕叹息的事情。

  所以当我们 2010 年前后开始做分布式数据库,也就是设计 OceanBase 架构的时候,一开始瞄准的目标,就是要把它做成一个通用的关系数据库产品,而不是一个仅仅在公司内部使用的产品。2017 年,让我们团队最高兴的是,通过 8 年研发抗战,我们不仅做到了承担蚂蚁金服「双十一」全部核心业务的重压,还在 6 家商业银行落地,成为他们互联网金融类新业务系统的数据核心。

  站在这样一个有纪念意义的时间点上顾盼今昔,我发现,虽然数据库已是一个看起来不那么性感的研发领域,但当我们看看,在企业级系统里,和数据库分不开的服务器和操作系统的演进后,就会知道,分布式数据库引发的创新变革,尤其是金融服务领域的变革,或许才刚刚开始。

  当年研究分布式系统的时候,对一篇 2005 年 Google 首席工程师 Luiz André Barroso 发表在美国计算机学会学报上的论文印象颇深,那篇文章就叫做《ThePriceofPerformance》,所以我这篇文章的标题也是向他致敬。在该文里,Luiz 的主要观点就是表达了,Google 作为当时全球最大规模计算基础架构的技术平台,需要在设计基础架构的时候,更好地平衡性能和价格,而他作为首席工程师,首先必须回答的问题就是:对于业务部门所需要的计算能力,在经济上是否能够承受?他开发出一套思路,能深入理解计算的总体成本,并且不断地寻找合适的硬件/软件设计来优化每个成本单位的性能。Luiz 将 Google 计算基础设施的 TCO(总体拥有成本)分解为四个组件:硬件成本、能源消耗、数据中心的建设及运营成本,以及软件成本。在云还没有诞生的年代,最昂贵的 TCO 组件是软件,Luiz 将 TPC-C 测试中使用的系统价格进行粗略分解后发现,平均到每个 CPU,操作系统和数据库引擎的成本约为 4000~20000 美元,如果再算上其他操作系统组件、应用和管理软件的授权费用,成本还得增加许多。性能第二大的代价是能源消耗,根据 Luiz 测算,Google 自行组装的贴牌 PC 服务器,TCO 的 40% 来自电能消耗,即使他明明知道有 70% 以上的 CPU 时间是被浪费掉的。至于硬件采购成本和 IDC 的运营成本,相比前两个单项,只占到 10% 不到的比例,都可以忽略。

  所以,当我们一开始想做 OceanBase,这个从架构上就和 Oracle、DB2 完全不一样的「分布式」数据库的时候,首先想实现的也是帮助业务部门降低 TCO,尤其是在更加便宜的分布式硬件+操作系统上,用最低的代价,实现最高级别金融级数据库的性能和可用性。

  这个想法在当时,被许多同行看成是异想天开,因为这和我们在大学里学过的数据库基本常识违背,分布式系统怎么可能实现 CAP 的要求呢?而且那个时候,大多数金融机构,包括阿里自己用的都是 IOE 架构,虽然当时 IOE 架构的并发交易处理能力已经不能满足「双十一」的需求,但胜在稳健;虽然 IOE 架构临时扩容收费的都是天文数字,但胜在阿里挣得更多,支付得起。所以我们要干这件事情,先不说成功的概率有多大,而是它重不重要,紧不紧急?

  为了回答这些问题,我们不仅和业务部门做了两周的紧急调研,确认了这件事情的重要性,也看到了一些行业的大趋势——从 2004 年开始,全球每年约 450-500 亿美元规模的服务器市场,已经从 x86+Windows/Linux 与 RISC&大型机+AIX/HP-UX/Solaris/Mainframe 各占一半销售额,快速变换为 2010 年的 x86 占据 80% 以上份额,出货量更是相差两个数量级;而早在 2006 年,就已经有建设银行这样的国有大银行,已经在尝试「总行用主机+省行用小机」的尝试,而且表示不排斥在关键业务系统里用 Linux,前提是得有成熟的、兼容性好的应用。作为互联网公司,我们更不应该落后于传统金融行业的老大哥。

  所以,不管是内部要求,还是外部环境,在当时都发生了一些微妙的变化,这也给了我们一些信心,能够做出一个先满足内部业务需求,进而满足金融行业需求的数据库产品。

  光有信心没用,还得撸起袖子加油干。正如李国杰院士所说:Database 之所以难,不只是难在 Data 上,而是难在后面的 Base 上。OceanBase 能做成金融级数据库,主要是做了五个关键创新。

  第一点,我们做到了 CAP 的最佳平衡。单机数据库要做到既满足事务 ACID 特性,又可扩展已经非常困难了,而 OceanBase 则是在做三个库或者五个库的时候,要多台机器同时来做,在具备高可用、高可扩展的同时,追求数据强一致,保证事务 ACID,这个是 OceanBase 系统里面最复杂的部分之一,也是今天其他人很难在这块领域出彩的原因。

  第二点,我们重新设计了数据存储模式。数据库有两种性能,一种读,一种写,读可以缓存而写是无法缓存的,即使是固态硬盘,随机写的能力也是受到限制的。所以 OceanBase 在关系数据库领域首创了把写操作放到内存中,改几个字节就记录几个字节,再把日志放到硬盘上,如果出现类似电脑掉电重启的情况,只需要回放日志做恢复就可以了。因为日志在硬盘上是顺序写入,所以性能不是问题。因为不需要在硬盘上随机写,用能够随机读的廉价硬盘就可以,最终结果就是把性能提高一半以上,同时把成本又降一半。但有人会问,内存那么贵,你用来做数据库是不是太奢侈,还谈什么降低一半成本?的确,受制于内存成本和 IDC 机架的功耗限制,我们没有把全部写操作都放到内存里,而是采用内存与硬盘都用的折中方案,只把一些最常用的数据和最近的修改数据保存在内存里面,这样既维持了一个适当的成本,又得到一个很好的性能。

  第三点,我们实现了变长数据块存储。传统数据库的块是定长块,块的大小从几个 KB 到十几个 KB 不等,并且是原地修改,如果修改后的数据总长度超过块大小,需要链接到新的块,后续对该记录的访问就会跨块,会有性能损失;如果一页剩余空间不足以存下一行,就只能空闲。而 OceanBase 的块大小是 2MB,在块内,记录是顺序存放的,由于没有原地更新,数据紧凑存放,空间利用率会更高。还有一点就是,数据库其实也是 CPU 占用率很高的应用系统,它的业务在高峰期的时候,CPU 是没有多少空闲的,所以只能用一些很简单的压缩算法,而 OceanBase 因为第二点的优势,白天不做大规模写入,到夜里再会把数据写入硬盘,可以更加充分、均衡的利用 CPU 和硬盘,这样做的效率比商业数据库的数据库效率要高一倍以上,而且是一次性写入,出错的几率也会降低很多。

  第四点,我们用校验和的方式,做到了高一致性。蚂蚁金服和银行一样,最关键的业务就是交易系统,也就是记账和转账。作为记账系统的核心基础,OceanBase 的账本不能出错。对此,我们做了个类似 CRC 的「校验和」机制,每天晚上对每一条数据、每一台机器进行大合并,合并完了之后,检查这个「校验和「是不是一样,如果不一样肯定有问题了。我们对「事务」也加了这个校验和,因为事务中包含的对数据表的修改也是一种数据,把这些数据每次都累计生成一个校验和,在备机回放日志的时候,一旦发现这个校验和不对,我们的系统就会报警。在新版本的 OceanBase 里,校验和做的更严格,会对每张表的每一行都做一个校验,每一列也做一个校验,整个表再做个校验,一旦有任何一点的不一致,就会被发现,这样的操作能让业务部门充分放心。

  第五点,我们做到了数据库主库故障后数据无损(RPO=0)。单机数据库通常是一主一备,最大的问题就是没有仲裁,数据库主库要是出问题了,服务器产商和数据库提供商会不惜代价救回主库,实在救不回来了,银行要开会决策用不用备库,因为备库数据是有损的,损失要由银行自行承担,所以银行都有自己的人工对账系统用来应对这种紧急情况。OceanBase 采用了 Paxos 协议(一种分布式一致性协议),即使用了三个都有可能出错的库,但通过多数派赢的表决的方式,对外提供稳定可靠的服务,很好地兼顾了数据一致性与服务可用性。所以,当支付宝和首批六家合作银行用了 OceanBase 之后,容灾演习就不再需要人工对账系统。

  金融级分布式数据库能够在行业生产场景中真正用起来,需要天时、地利和人和。

  天时,就是随着互联网,尤其是移动互联网的爆发式增长,对金融行业的在线事务并发处理能力、数据处理能力和系统弹性提出了再上一个数量级的要求。举个例子,网点最多的中国工商银行号称是「你身边的银行」, 也不过几万个网点,每个网点一般 10 多个服务柜台,每天能服务的企业和个人客户是相对有限的,所以在那个时代,大型主机足以满足业务需求,一个分行的 TPS、IOPS 一般在几百,峰值一两千就够了,数据量级一般在若干 GB;但到了 PC 网银时代,网络开户、交易和转账的需求就多了一个数量级,这个时候就有一些省级分行或者城市商业银行开始尝试小型机+Unix 的方案,数据库的 TPS、IOPS 在三四千到一万左右,数据量上升到 TB 级,系统整体成本就比用大型主机便宜很多了。到了 2010 年之后的移动互联网大爆发时代,大型主机或小型机+Unix+传统商业数据库就都 hold 不住了——且不说能不能处理动辄百万、千万的并发请求,就算能完成,在传统架构上获得千万级并发处理能力、PB 级数据库管理能力、一天之内系统扩容百倍并在业务高峰期后立即释放,要获得这样的性能,又该付出怎样的代价?放眼全球金融行业,我们还没有看到任何一个这样的先例。

  地利,就是从淘宝到蚂蚁金服的内部环境。数据库跟手机不同,只要有一次死机就没人用了,所以超高的要求和复杂的系统都是阻碍。而 OceanBase 从淘宝收藏夹到承载蚂蚁金服 100% 业务的每一步进展,让一个新产品,从不是特别重要的应用场景开始尝试,一步步地将这个数据库做成了关键系统。而且从互联网公司做出来的产品,和传统数据库有一个特别大的有点就是性价比高,理由就是我们特别关注「性能的代价」,我们利用高性价比的 PC 服务器和 Linux,便可实现金融级业务需求。相对于一台几十万到几百万的小型机,甚至几千万、几亿的银行总部用大型机,用 5% 的成本,做到了商业数据库性能。

  人和方面,就是人才和人心都正当时。人才正当时,是说能做分布式系统研发、运维和调优的人才已经遍地开花,不再是很高门槛的高精尖。正如开头提到的,2005 年玩好了分布式系统,有了自己的方法论和工程经验,写篇论文都是可以上 ACM 的;如今的互联网公司里,还有核心业务不是分布式架构的吗?那些勇于创新并尝到甜头的金融机构新业务部门里,还有不是分布式架构的吗?人心正当时,是说金融行业客户的心理需求也产生了变化,比如南京银行就是期望通过打造互金平台,将交易与消费和生活场景结合,提升用户量和活跃度,更加普惠,更加服务民生,这跟蚂蚁金服要做「助力普惠金融的科技公司「的愿景是高度一致的,所谓「独行快,众行远「,和价值观相同的同事和客户谋事,才更容易彼此成就,走得更远。

  在谈论 OceanBase 未来的时候,我想先聊聊上面这三张图。这是 Gartner 的魔力象限图,对最近三年操作型数据库管理系统的分析。有意思的是,2015 年收录了 31 家公司,其中一大堆领导者;第二年还有 21 个,基本上领导者就只剩下微软 SQLServer,Oracle,SAP,亚马逊和 IBM 了,去掉了一半不赢利(死掉)的;到了 2017 年,只剩下 11 家,微软和 Oracle 仍然稳如磐石,亚马逊继续上升,SAP 落到第四,IBM 与前三名差距拉大。因为推出了 Spanner,谷歌从一招鲜玩家杀入到远见者。因为不赢利,MongoDB 居然都能被干掉。从上面可以看到,在数据库这样一个非常成熟的细分领域里,最近三年居然产生了如此剧烈的变化,这意味着什么?会不会像当年分布式计算和虚拟化催生了云计算一样,数据库领域也会产生类似的变化?这一现象背后的趋势,值得我们深思。

  特别想说说 Spanner,谷歌认为 Spanner 是一个具备跨数据中心、跨全球事务处理能力的数据库平台,但问题是 Spanner 不兼容 ANSI/ISOSQL 标准,导致兼容性和行业普及会成问题。其实心情很复杂,一方面,做了这么多年分布式数据库,好不容易找到一个有共鸣的 Google,有他乡遇知音的感觉。但或许是 Google 的业务部门过于强势,数据库的设计开发应用基本是为满足自身需求,所以有上面的问题存在,如果 Spanner 商用前景不好,那也是很让人痛心的。

  整体来说,OceanBase 走的是基于互联网场景,加上金融交易数据库类型,支持标准数据库接口、标准数据库语言的标准化研发道路,也通过这些年在容灾、业务流程、零故障的表现,受到蚂蚁金服内部和各大银行的认可,我们还是有信心走得更快、更远。

  最后放两张图,与同事、同行、客户共勉,但愿若干年后,经过我们的共同努力,也能达到 HPC 领域里联想、曙光、浪潮、华为这样的地位,成为数据库领域里的 TopTier!

  ▲截至 2017 年 12 月,HPCTop500 供应商计算性能份额排名

  公司地址:北京市朝阳区酒仙桥路4号751 D·Park正东集团院内 C8座105室 极客公园

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。