阿里数据库最新版（帮助阿里省了几百个亿）

火客 2023-06-29 01:53:23 631

阿里数据库最新版（帮助阿里省了几百个亿）阳振坤对雷峰网说起这事，只是腼腆地笑着，操着稍带湖北口音的老家话，言语不紧不慢。事实上，OceanBase从在阿里立项之日起，就面临着夭折的危机。很多年前，他曾追随老师王选院士打造激光照排。现在他又创造了世界上第一个真正意义上的分布式数据库OceanBase。OceanBase创始人首席科学家：阳振坤（花名：正祥）

对中国的电商公司来说，1万亿元GMV意味着什么？

回到十年前，这个答案是：意味着他们要给IOE（IBM、Oracle、EMC）三家美国公司200亿元采购费，而且是每年都要给。这笔钱甚至会超过他们自身当年所能赚取的利润。

如果这件事真的发生，中国后来诸多巨无霸一样的互联网公司都会成为美国公司的打工人。

但是十年过去，现实并非如此，这一切都要从一位叫阳振坤的科学家说起。

很多年前，他曾追随老师王选院士打造激光照排。

现在他又创造了世界上第一个真正意义上的分布式数据库OceanBase。

阿里数据库最新版（帮助阿里省了几百个亿）(1)

OceanBase创始人首席科学家：阳振坤（花名：正祥）

一、一波三折的内部创业

事实上，OceanBase从在阿里立项之日起，就面临着夭折的危机。

阳振坤对雷峰网说起这事，只是腼腆地笑着，操着稍带湖北口音的老家话，言语不紧不慢。

但是，他很清楚这件事的重要性：“如果当时，我们没有做OceanBase，后来的其他公司要做数据库就只剩一条路，就是‘穿马甲’——把开源的东西拿过来，改成自己的‘马甲’，然后去做。”

在阿里之前的战略会上，“去IOE”这个战略方向曾经得到阿里首席技术官王坚博士的坚持，前文200亿元的说法就是他算出来的。

阿里数据库最新版（帮助阿里省了几百个亿）(2)

阿里巴巴集团技术委员会主席王坚（花名：博士）

阿里前CEO卫哲为雷峰网回忆过当日场景。

王坚为增加说服力，甚至拉上了已经退休的CTO吴炯，让他从技术的角度谈了亚马逊和谷歌的情况，作为整体铺垫；然后自己再从财务的精算，把1万亿元GMV折算成数据量，再折算成需要的IBM小型机数量、Oracle数据库量、EMC存储数量，最后换算成具体价格相加。

王坚算完之后，阿里执委会的所有人都服气了，算是从高管层面解决了这个问题。（当日现场讨论非常精彩，细节请看《沸腾十五年》修订版。）

但是，光说服上面的人是不够的，下面的执行者都是Oracle、EMC工程师，“去IOE”其实就是砸他们的饭碗，他们怎么会支持呢。

在阳振坤开启OceanBase项目之时，他听到的负面的、否定的声音，远多于支持的声音。

作为创新者，逆风而行是必须要承担的代价，如果不能到达彼岸，就会摔在地上，听到铺天盖地的讪笑。

两年，这是阿里给阳振坤的期限，也是阿里高管们能为他顶住压力的时间。两年内做出成绩，公司全力支持；做不出成绩，就只能卷铺盖走人。

背着这样的压力，阳振坤带着OceanBase团队出发了。

阳振坤想做的体系是原生分布式数据库。如果成功，OceanBase将有机会帮助企业构建新一代的核心系统。

在OceanBase之前，以Oracle为主导的巨头们使用的都是“集中式数据库”。如果将数据库的处理能力和容量类比为“马拉车”，集中式数据库的解决方案是把“马”做大，让单机实力更加强劲，带动数据的存储和处理。

但集中式数据库也存在问题。一方面，诞生于数十年前的集中式数据库太老，很难应对指数级增长的容量需求。当“马”的增长很难跟上“车”的速度，那么系统的崩溃就只是时间问题。企业仍然可以通过加大金钱投入，来增加数据库的能力，但成本却也将大大提升。

另一方面，集中式的数据库应对风险的防控能力很差。如果集中式数据库中的一台机器出现故障，那么整个系统都可能面临崩溃的风险，牵一发而动全身。

既然独木难支，为何不“众人拾柴”？本就对分布式颇有研究，阳振坤想到，可以动用许多“小马”，一起来拉动这辆“大车”。

这就是原生分布式数据库OceanBase灵感的来源，而在2010年，世界上都没有人提出过这种思路。阳振坤振臂一呼，可以说是“前无古人”。

相比传统的集中式数据库，分布式数据库可扩展性更强。面对飞速增长的需求，OceanBase不依赖单机，可以做到简单、便宜的扩容。同时，原先的小型机一台也要几十上百万，在OceanBase分布式的构想中，便宜的单机也可以拿来做服务器，从几十万到几万，OceanBase比Oracle便宜了不止一点半点。

分布式数据库容灾性也更强。由于OceanBase“不把鸡蛋放在一个篮子里”，当体系中某个单机出现问题时，数据库仍然能够稳定运行。“三地五中心，同城三机房”，蚂蚁的体系如此设计，只要大多数设备不同时宕机，系统的运行就不会受到影响。

HTAP（混合事务分析处理），这是OceanBase的又一大利器。

数据库的功能大致可以分为两类——OLTP和OLAP。

OLTP指“在线事务和交易处理”，也就是“记账”。买家的每一笔支出、商家的每一单销售，在平台上产生的每一条数据都要分门别类记载清楚。

OLAP指“在线分析处理”，也就是“数据分析”。分析用户偏好、分析运营数据等能力都位列其中。

数据库的用户既有“记账”的需求，又有“分析”的需求，但这两种需求却通常需要以两个不同的数据库系统来分别满足，市场上少有可靠的、一站式的解决方案。操作两种系统，成本和难度自然更高。

如同左脑和右脑，“记账”和“分析”是两种不同的数据处理方式。“记账”需要实时与系统交互，数据要“逐行”存储；而分析则需要纵向对比，数据要“逐列”存储。

OceanBase做的，就是把“左脑”和“右脑”合并了起来，形成了一站式的解决方案。方便，而且便宜。说起来简单，将“行存”和“列存”做到一起并非易事，而分布式的架构设计又为HTAP模式提供了技术上的可行之处。

体系设计虽好，但实话说，2年真的不太够用。

OceanBase在头两年的成果难说让人满意，阳振坤自然深知这一点。在2012年底的时候，功能还有许多没能实现，团队也不够完备。在产品的第一关，OceanBase就输了。

缺乏业务也是OceanBase遇到的又一个难题。阿里内部的各业务群也当然并非“一心同体”，业务老大们要背自己的业务指标，总部做决定也要考虑到他们的利益，数据库是底层系统，不能强制他们“说换就换”。在部门墙之下，OceanBase初来乍到，还没有与各业务部门建立起信任感，只能自下而上地“推销”自己的产品，自然事倍功半。

眼见2年之期将至，OceanBase面临着随时可能被公司关停的状况。

内外交困下，阳振坤还是获得了第二次机会。

传说中，还是阳振坤特意飞去杭州阿里总部，找到了他在微软的老同事王坚。王坚时任阿里CTO，当时也是他在阿里云最难的时候。他深知阳振坤在阿里从事科研的难度，也能看到OceanBase在未来数据库竞争中的潜力，于是在和相关领导协商后，发下了一纸调令。

不久后，OceanBase就被调整到了支付宝体系下。

但问及这段时间，阳振坤心中第一个想到的是现任阿里的CTO程立，花名鲁肃。在阳振坤和团队来到支付宝后，作为阿里技术人心中“神一样的人物”，鲁肃也看好原生分布式数据库的前景，于是帮助阳振坤在支付宝站稳了脚跟，这也为OceanBase在日后的崛起埋下了伏笔。

阿里数据库最新版（帮助阿里省了几百个亿）(3)

阿里巴巴CTO 程立（花名：鲁肃）

二、2014，逆袭的号角吹响

2014年，在支付宝，阳振坤和OceanBase终于等到了千载难逢的机会。

当年，双十一的交易量预期又将创下纪录。面对又一次大考，支付宝内部的数据库工程师如临大敌，又如火如荼地开始了数据库跑量的压力测试。

大敌当前，阳振坤和他的团队却还在坐冷板凳。多次主动请缨，支付宝却仅让OceanBase承担1%的业务流水。又是一年的失望，属于OceanBase的翻盘点似乎还遥不可及。

前文也提到了，OceanBase的功能和结构都比Oracle要强劲很多，为什么支付宝没有全面推广OceanBase应用呢？

IOE体系就是数据库界的PUA。你明知它贵，你明知它不好用，你明知有更便宜、便捷的解决方案，但你愿意相信它。在ToB生意里，信任最为难能可贵。

“你如何保证OceanBase不弄丢支付宝用户的一分钱？”鲁肃的这句话也曾问懵过阳振坤。

IOE虽然种种不好，但IOE胜在稳健。许多技术负责人不愿用新的技术和产品，用老产品出问题可以怪产品，用新产品出问题就只能怪自己了。

归根结底，没信任就没有使用，没有使用也就没有信任。OceanBase就在这样一个死循环里苦苦挣扎。

就在OceanBase的未来仍不明确的时候，一个“坏”消息传来：Oracle崩了！

原来，在跑量测试时，一直在蚂蚁内处于主导地位的Oracle竟然屡次崩溃，可承压能力仅有预期的90%。

已经顾不上OceanBase是否可靠，在这时行不行都得上。技术团队不得不做出了一个艰难的决定：紧急启用OceanBase。

双十一的流量逐年都在增加，集中式的Oracle总会有一天跌落神坛。阳振坤早就在等着这一天，OceanBase逆袭的机会来了！

于是OceanBase临危受命，接下了支付宝2014年双十一10%的流量。

这是机遇，可又何尝不是重于泰山的压力？阳振坤深知，他和他的团队但凡出了一点差池，那么他和OceanBase在公司里就将永远失去信任，再没人敢用。哪怕后面能够给业务带来好处，也无济于事。

这一仗，OceanBase只许成功，不能失败。

双十一前夜，OceanBase全员枕戈待旦。蚂蚁集团的CEO彭蕾（花名Lucy）先前在阿里内部任首席人力官，知人善用。她连夜来到了OceanBase的办公室，既是动员，也是督战。

变动如此巨大，难说彭蕾的心里没有忐忑。她问阳振坤有没有信心，阳恰好站在窗边。他推开窗子，杭州11月已经开始转冷，办公楼下路人行色匆匆。阳振坤知道，他和OceanBase的前途全部取决于此，他说：

“出了问题，我们准备从这跳下去。”

7年后，OceanBase早已成为了国产数据库中的“头马”。谈及此事，阳振坤只说是个玩笑。而当年的压力、忐忑和“不成功便成仁”的决绝，都如同过眼云烟，成为了多年之后的笑谈。

三、开源——OceanBase的梦想、挫折和救赎

开源是许多程序猿的浪漫。

尽管在外界看来十分令人不解——把自己辛苦写的代码免费向社会公开，但OceanBase还是坚决地选择了开源。

抛开技术人的理想主义，OceanBase之所以选择开源，有如下这3大原因：

一方面，数据库需要跑量。在足够的测试与反馈的过程中，数据库才能发现运行问题，进行有机的调整。

OceanBase作为一个新概念的数据库产品，自然急需实际的测试和验证。开源，就是给了OceanBase不断“打怪升级”的机会。

另一方面，刚刚提到过，信任对于数据库产品来说是重要的壁垒，也是合作的基石。用户要把数据委托给数据库，几乎是要把自己重要的“家产”托付出去。

OceanBase把自己的代码和秘密全部公开，也是告诉用户自己值得信任。基于这种信任，OceanBase也期望能形成自己的开源社区，扩大用户群。

有人用，就有信任；有了信任，就有更多人用，也就自然能产生更多收益。

阳振坤有足够的信心，即使OceanBase开源供公众使用，他人也很难弄懂其中的奥秘和机理。前文也提到过，数据库本就是一项极度复杂的工程。如同芯片一样，即使能够拿到成品，但难以对其进行反向工程。即使开源，护城河也在。

著名的数据库MySQL开源20余年，核心技术就仍然掌握在开发团队的手中。这种技术壁垒映射到开源上，称得上是一种数据库的核心能力。

于是在2011年，当时还属于淘宝体系的OceanBase第一次开源，而这次开源的经历难称圆满。

这次开源对于OceanBase来说，颇有“赶鸭子上架”的意味。OceanBase在2014年前还是以单点写入的模式为主，两年后才正式完成了1.0版本。

而2011年为了迎合淘宝系统全面开源的潮流，也是技术人的一腔热情，OceanBase匆匆宣布开源，而实际公开的只是一个“半成品”。这个版本当时还以单点写入为主，还完全不是团队理想中的样子。

而通过这次开源，另外一个问题也随之映射出来：OceanBase的定位究竟是什么？究竟要做蚂蚁业务的一个支持部门，还是一个通用化的工具？

做支持，OceanBase需要更多面向公司内部的需求。一些“量身定制”的需求，甚至可能超出常规数据库的功能范围。如果被这种需求牵着走，则很可能造成工期上的损耗，也容易把自己的路走窄。

阳振坤和团队想做的，一直都是一个通用化的工具。但认知上的鸿沟，让首次开源的OceanBase无法获得业务团队足够的支持，开发团队则要把主要精力投入到产品1.0版本的开发中，很难分出人手去维护开源版本的持续更新。

难说谁对谁错，只是立场不同。

无人可用，首次开源的OceanBase终于不再更新，而这次尝试也终于不了了之。

而在这之后，潜心投入开发的OceanBase团队终于见到了回报。

在支付宝内部，OceanBase逐渐全部接管了Oracle先前的“生意”。为了让“去Oracle”的进程更加“丝滑”，OceanBase力求让这个过程可以“不改代码”。

2015年3月15日，阳振坤在他的微博上自豪地宣布：“从上周五开始，淘宝/天猫/聚划算在支付宝上的交易，100%都在OceanBase上了。你可能没有什么感觉。”

一年后，OceanBase也终于全部接管账务数据库。在一次采访中，阳振坤表示：“这……是标志着，OceanBase真正地在金融系统里面站住了脚。”

取得了如此斐然成绩，在阿里内部也是拿奖拿到手软，但阳振坤和团队的志向却不愿意在此止步。又过了一年，凭借着支付宝成功案例的光鲜背书，OceanBase首次对外商用，第一个客户就是南京银行。

阿里的高层们也终于看到了OceanBase原生分布式数据库的优势，看到了既能做交易、也能做分析的HTAP模式颠覆行业的可能。他们正式同意OceanBase作为一个单独的公司独立运营，这也是OceanBase发展一个重要的分水岭。

2020年6月1日，北京奥星贝斯科技有限公司正式成立。蚂蚁集团前金融科技产品技术总监杨冰任CEO，阳振坤任首席科学家，与他一起进入OceanBase创业至今的杨传辉（花名：日照）任CTO。

不久，“出走”刚刚12个月的OceanBase再一次选择了开源。在进行了数月工作文档和代码的梳理后，2021年6月，OceanBase再次向全网开源。

阿里数据库最新版（帮助阿里省了几百个亿）(4)

2021年6月1日 OceanBase正式开源

不同于遮遮掩掩式的“公关式开源”，OceanBase这次放了狠招：他们一次公开了自己全部内核。他们把心沉下来，只想如何用开源的方式去满足客户需求。遵循指示，一个初学者可以在30分钟内将OceanBase的数据库完成装配。

OceanBase做的是用户价值，这是他们开源的重要理念。

从最早先屈指可数的几个客户，到今天400多家全行业的客户；大到支付宝、网商银行，小到占总比66%的小型企业，从蚂蚁独立出来的奥星贝斯仍然在帮助全社会的各行各业。

“让天下没有难做的生意”依然流淌在他们每个人的基因里。

结语：

尽管已经年近花甲，阳振坤仍然没有半点停滞的意思。在技术驱动创新的路上，OceanBase的目标是做“无限扩展、永远在线”，意在创造一个不被扩展和故障所限制的数据库系统，而这项成果则可能永远地颠覆数据库，乃至互联网行业。

做技术的人大多是简单的。阳振坤和OceanBase十余年走来，风风雨雨，终于至今。有时他总能想起自己的老师，两院院士王选，当代中国的“毕昇”，颠覆了中国印刷业的科学家。

33年前，阳振坤成为了王选的弟子。

那年，阳振坤22岁，青春写意；王选52岁，也正是当打之年。而今天，王选早已溘然长逝，阳振坤也把自己三十余年的青春献给了科研。

当年，我憧憬你；今天，我仍在以你为灯塔前行。

阳振坤知道，和自己的恩师一样，自己的这一生都将要献给中国的科研事业，但他从没有半分悔意，也没有半分退意。

2022年1月，在由CSDN主办、OceanBase承办的DC 2021分布式数据库开发者大会后，雷峰网采访了阳振坤，并与他进行了一番深谈。以下是我们整理的访谈实录：

数据库技术的发展历程

雷峰网：我们知道技术在历史中，发展都存在着不同的阶段。数据库也应该不例外，可以根据技术的突破划分为几个阶段，您可以为我们回顾一下吗？

阳振坤：在最开始，它其实是跟账有关系。最早的数据库叫层次数据库，功能比较简单。而也是因为其功能比较单一，大家有接触大概几年以后，就发明了一种网状的数据库。最大的代表其实就是 IBM 的这一套系统。

到了 60 年代末或者 70 年代的时候，关系模型横空出世。曾经两个这个图灵奖的获得者专门有一次是ACM（国际计算机学会）开大会，两派的人争执不下：一派的人说这个未来一定是关系模型，因为关系模型有更强的表述能力。另一派说关系模型不实用。结构上的复杂性，会导致性能会很差。

此后关于这个问题一直没有定论。所以，关系模型从1970年发表，一直到整个70年代，其实都没有过产品。

到70年代末80年代初，关系型数据库才开始产品化。此后这个模式就一直被沿用，直到差不多互联网之前。集中式，本质上是个单机的系统。一个很关键原因还是因为它太复杂。

雷峰网：为了解决这个难题，科学家做出了哪些努力？

阳振坤：对数据库来说，它有一个特殊之处：人们很难用一个自然的语言，来操作数据库。所以后来，就有人开发出了一种数据库专用的语言，叫SQL（结构化查询语言）。

这个SQL不是告诉数据库干什么的，这个太难描述了；它告诉数据库说我要什么，你怎么干是你的事。

Oracle 算是最早的那批数据库，就是 Oracle 、DB2，SQL Server，还有像对后面是 PGSQL 跟 MySQL。在之后的 20 多年的时间里，都没有如此体量的数据库面世。数据库到今天都是个非常大的挑战，也导致这么多年格局大致不变，一个新的数据库的研发特别困难。

而互联网时代，有许多很新的、完全不一样的需求也随之而来。那我们OceanBase今天才有这机会。

分库分表不是分布式数据库

雷峰网：OceanBase将自己定义为“原生”分布式数据库，这个“原生”要怎么理解？

阳振坤：我会讲一个很明确的观点：分库分表不是分布式数据库。我们认为一个原生分布式数据库，它是一个单一的数据库，看起来像使用单台机器的集中式数据库，能够在一套数据库里面又做交易又做分析。分库分表的话，它其实还是说在多个单机数据库上面加了一个中间件。

但是这种方案它其实没有办法保证这多台数据库之间的一致性。举个例子，第一个数据库是我，第二个数据库是你。我给你转账，有可能出现我给你转出去了，但你没有收到的情况。分库分表式的数据库有可能有这种情况，但我们的原生分布数据库是没有这种情况的。OceanBase保证强一致的，是一个单一的数据库，既能处理交易，又能处理分析。

雷峰网：OceanBase在支付宝体系下已经度过了许多个寒暑，应用OceanBase的前后，支付宝产生了哪些变化？

阳振坤：其实从2014年之后，公司就也看到了我们的业务价值，主要还是支付宝的数据库体量太大了。就算你的硬件能做到尽量稳定，它最终也会出问题。少数几台不要紧；你有几百台，几千台的时候它一定会出问题。同时集中式数据库维护和维修的代价很大，工作人员要到最早的网关去把信息捞出来，来做对照。

那用了OceanBase之后，我们部署了三个副本。即使坏掉一台机器，剩下的机器保证还有正确的数据，就能够自动的恢复。以前只要主库坏了，他们都得去做人工对账。不管几点坏的，工作人员都要在几分钟之内起来，否则系统里，用户看的数据就全不对了。但OceanBase可以做到系统自动，这台机器坏了，还有其他机器能工作，我们系统就可以继续运转。所以这一个对业务来讲，给到很大的帮助。

这样的体系对工作人员的舒适度就提升很多，以前只要出问题，不管几点都要来应急。现在的双十一，工作人员已经有时间坐下来喝一杯茶了。这就是我看到最大的变化。