以下是现场速记。

 

OceanBase解决方案部泛互行业总经理 弓子介

 

弓子介：在座的各位嘉宾，我叫弓子介，是2015年加入阿里，OceanBase是一款技术产品数据库，今天又来了很多CIO，聊了很多数字化转型，我是2015年加入以后正好赶上阿里系内部的移动互联网Timing，所以今天想跟大家分享阿里系内部从原先的IOE单体架构，面临“双十一”在线高并发场景的思考。

 

大家一直都在谈数字化，坦白讲，技术都是为业务服务的。最近二十年，随着互联网的发展，刚才波士登的CIO也提到很多商业模式从线下的门店零售变成在线化。整个业务是不确定性的，很难预测明年或者下一个季度需要多少IT支撑才能满足业务，整个技术架构都是业务驱动的。最近十几年大家都在做企业IT数字化转型，整个IaaS层也是从原先采购硬件的主机到后来采用虚拟化的方式提升整个IT运营成本，现在大家的业务也分为稳态业务和敏态业务，一般敏态业务可以预测，上云投入产出比是最高的。最近五年的发展也是经过单体架构变成微服务化架构，再到最近的容器化，整个技术架构、中间数据架构一直没有一个很好的方法论。

 

今天结合OceanBase在蚂蚁的实践给大家做一个分享。

 

数据架构伴随应用架构和基础设施架构的演进，主要面临几个方面的问题：业务的不确定性，很难快速预估未来通过抖音投放和渠道投放需要多少硬件，这些对数据要有快速弹性的需求。现在已经不光是交易数据，尤其是很多创新业务，去做IoT、RFID，采集车端这些非结构化或者半结构化的数据，这些数据已经很难通过传统的商业数据库，包括Oracle、MySQL存储，衍生出来类似Mongo这些内存数据库，所以对企业来说数据库的种类会越来越多，管理成本也会变大。OceanBase认为，数据库回到本质就是帮助企业业务系统存储数据，只要有一款数据库既能满足联机交易，又能满足企业决策的报表查询，包括交易数据、IoT半结构化数据，都是可以放在一个数据库里面，那么对大家来说整个架构可以统一，其实也是2015年在蚂蚁内部希望能够统一技术栈的思考。

 

数据库的发展也是伴随业务的发展，Oracle到今天为止也有四十年了，但到2000年左右已经没有新的单机数据库或者集中式数据库品类的更新，因为2000年以后移动互联网和PC时代来临，面临数据的爆发式增长，单机数据库已经很难支撑海量存储，7×24小时联机交易场景，所以基础设施并没有赶上业务的商业模式创新，怎么办呢?只能去想一些妥协的、中间的解决方案，大家都听过分库分表，为什么要分?因为单机性能、容量很难满足联机改易和线上运营，不得不分而治之，所以架构在OceanBase看来只是中间态，原先IT存留人员还是之前传统数据库的年代，数据库的实力有了几何级的增长，所以对大家来说应该也都听说过，X86硬件故障率都有年化百分比，就是6%。

 

OceanBase数据库可以在应用程序微服务改造完成以后，把运维复杂度降为原来的集中式数据库，既支持联机交易，又支持现在新兴的车联网IoT数据，整个企业统一技术栈，这是我们以前在蚂蚁内部的思考方向。

 

刚才讲过，OceanBase数据库相比市场上其它大家听过的数据库，最大的区别在于，这款数据库是在阿里2010年立项，先解决自身阿里系内部数字化转型遇到的问题。OceanBase刚开始在阿里之前用的也是Oracle、IBM、EMC的存储，但在2009年首届“双十一”，这套架构就已经扛不住了。为什么?因为天生不是为了在互联网场景设计出来的，我们2010年立项以后在电商场景打磨数据库的弹性和高并发能力，2015年OceanBase在阿里系内部来到电商下游支付场景。

 

跟大家分享一个故事：2015年，支付宝出过一次比较大的舆情故障，就是杭州萧山光缆2015年5月27日被挖断了，那个时候还是有很大的社会舆情风险。因为当时的故障非常典型，就是传统数据库Oracle主备架构情况下网络出现中断，如果大家是支付宝的用户应该也知道，支付宝刚开始去付钱是要跳到网商银行，不去做帐务相关的处理，到了2014年有了余额宝，其实涉及到资金的交易，我们并不敢去做强行的切换，导致当时故障花了8个小时，等到网络恢复以后才恢复。其实这件事情也是加速OceanBase在蚂蚁集团的快速落地，在这之后，2015年到2019年，我们花了四年的时间把阿里包括蚂蚁内部的所有应用全部切换到OceanBase，包括借呗、花呗、余额宝都是跑在上面。

 

2020年以后，我们的数据库产品也是被业务倒逼往前走，前十年都是在阿里系内部面对互联网场景，但随着国内的信创走进各行各业，包括金融、政府。我们在做传统客户的时候发现，这些架构还是停留在原先的Oracle和MySQL，以前大家去跑业务的时候并不会像互联网一样严格区分联机交易还是分析查询，包括报表查询的服务，会在一个实例上去跑，但在互联网场景打磨的数据库走向传统企业会发现一开始水土不服，云厂商提供的数据库只能做联机交易，稍微复杂的查询就跑不出来了，可能会推荐去用一款数据库，中间通过数据的传输解决原来可能Oracle一个数据库就能解决的问题。

 

我们2020年发布OceanBase3.0版本，主要面向国内各行各业的企业客户，数据库引擎既可以满足互联网场景的高并发、点查点读，也可以支撑原先可能在Oracle X Data运行的复杂查询。去年我们发布4.0版本，其实也是被业务倒逼的，因为我们走出阿里以后发现很多CIO对分布式数据库的认知，觉得我们的体量还没到，现在我们用MySQL和Oracle也还好，并没有急着去换分布式数据库。4.0版本更多的是希望降低我们数据库的使用门槛和起步成本，可以做一些创新业务的时候能够直接体验OceanBase。随着业务越来越大，伴随着业务一起成长，不是分布式数据库只有到一个超大体量才能去用。

 

这些就是整个OceanBase四个版本解决的主要痛点，今天参会的很多CIO企业已经在使用。就像刚才主持人介绍的，我们在金融行业主要是以信创国产化作为切入点，但在当前OceanBase走出蚂蚁、走向社会也是从金融行业走向各行各业，现在OceanBase服务的非金融行业已经超过金融行业客户的数量。

 

OceanBase相比其它友商提供的数据库最大的区别就是刚才提到的，当前国内的数据库OceanBase是唯一一款由自研、自用到外部客户输出的数据库，不会像其它厂商可能会基于开源直接在云上提供对外服务，可能有这种踩坑的过程，需要企业一起进行。OceanBase从第一天起就是在蚂蚁严苛的Mission-critical去做全场景打磨。

 

OceanBase之所以叫做分布式数据库，主要就是解决互联网场景稳态业务和敏态业务的冲突。因为我们开发一个新的业务上线投产，并不会知道这个业务未来发展的天花板有多高，一开始去做整个IT评估，可能评估多了，也有可能评估少了，这个时候可能就会面临运营侧流量激增，一下子IT基础设施没有扛住。我们的数据库可以通过Scale Out的方式，以前用云主机和MySQL性能上线就是这台PC机能够提供的计算能力，单机上限就是整个系统的吞吐量上限。OceanBase可以通过追加机器横向地往一个集群堆叠更多的机器，理论上性能是可以快速伴随业务的突变随时调整。

 

因为OceanBase本身就是在蚂蚁内部解决集中式数据库这种主备架构脑裂的问题，之前应该也有一些报道，云厂商去年年底在某些Region出过大的故障，一个机房挂了整个Region八个小时都没有办法服务，当时只有OceanBase对外提供服务，其它机房都有出现故障。虽然是小概率事件，但在金融场景和对连续性要求很高的业务场景都是必选项。

 

OceanBase4.0发布的新特性就是单机分布式一体化，伴随业务从小到大。因为我们每年都会做一些创新的业务尝试，新的业务不可能起步就使用特别大的规格去做业务创新，所以针对敏态创新型的业务，4.0可以在单机使用，如果业务未来有爆发式的增长也可以快速通过追加机器实现3台机器、6台机器的线性增长，并不需要起步很高的配置、很高的规格才能使用分布式数据库。

 

HTAP这个名词比较偏技术术语，因为我们走进传统企业，发现一个业务系统无法严格区分是在线联机交易还是复杂查询，一般都是混合Workload，无论是国产信创还是成本经济效益考虑，很难迁移到一款数据库，如果是其它云厂商的话。OceanBase希望把简单留给客户，把复杂留给自己，想要去做一个分布式Oracle，解决原先的应用，包括DB2、Oracle迁移到OB，或者一个产品替换到另一个产品，不是为了做数字化转型，一款产品需要八款产品才能解决原先一个数据库解决的场景问题，整个成本只要一份数据就能够满足业务需求。

 

刚才提到的就是OceanBase的优势，站在CIO的角度去做整个数据库的替换决策成本还是挺高的，因为换数据库无异于给非常换发动机引擎，业务不能停，过程还需要尽量低成本。OceanBase在数据库内核层面兼容Ocacle11.2以上的版本以及MySQL8.0，相比其它厂商最大的区别是什么?因为现在很多厂商也说兼容Oracle，可能基于PostGre，OceanBase是原生层面兼容Oracle，就像大家了解Java和C的区别，Java需要解释虚拟机的翻译，因为内核是开源PostGre，上面封装的性能远远不如底层数据库内核层面实现兼容。为了尽量减少整个异构数据迁移的决策成本，我们把蚂蚁内部去O的最佳实践沉淀了一款迁移工具，叫做OMS，可以端到端地帮助大家在整个异构数据迁移过程中，所有的风险都是可以通过这款工具一键完成。

 

OceanBase在阿里系内部就是面对这种规模化的运维，蚂蚁内部有上万个OceanBase实例，规模化场景中成本也是公司考量IT部门和整个数据库部门的一个重要的指标，我们从原来的MySQL、Oracle迁移过来，公司希望能够以更低的成本完成这件事情。我们在OceanBase内部自研编码以及高压缩比，原先Oracle应用、MySQL应用迁移过来，存储至少比原先节省70%。

 

刚才提到微服务化改造以后，服务进行了拆分，底层数据实例会有一个指数级的膨胀，导致运维的复杂度上升，整体资源密度的下降。OceanBase内部做了微服务化改造以后，MySQL实例上涨10倍，迁移到OceanBase以后，我们通过多租户概念，可以在一个大集群把原来零散的MySQL、Oracle整合到一套OceanBase集群，整体计算密度大约有50%的上升，可以降低整体运维复杂度。

 

前面介绍的都是OceanBase的内核能力，除了内核以外，数据库本身使用对象包含开发和运维，针对不同的使用群体，我们也有配套一些管理工具以及开发工具，可以像原先使用MySQL、Oracle一样使用OceanBase，并不会增加太多的学习成本。

 

OceanBase的公有云也是对外正式发布，因为发现随着疫情的变化，很多企业也开始走出国门，开始走向海外，所以OceanBase能够提供线下部署，也能够提供公有云部署，未来企业如果有跨境出海的需求也可以直接使用OceanBase，我们现在是在AWS和GCB均已经开服。

 

前面讲的都是OceanBase的产品特性，后面跟大家分享一些案例。

 

因为我们是源于蚂蚁，蚂蚁之所以使用OceanBase看重的也是OceanBase的底层核心能力。我们提出的理念就是统一技术栈，现在蚂蚁的应用数据都是跑在OceanBase上面。

 

随着信创的推进，运营商需要去做原先技术栈的架构转型。OceanBase帮助山东移动把原来的CRM系统从传统的IOE架构平迁到OceanBase上来，不光是原来技术栈的升级，也包括未来主机、芯片的全栈国产化。

 

海底捞是去年因为疫情，整个国内门店需要降本增效，OceannBase高压缩比以及多租户整合，帮助整个海底捞原先的IT的TCO投入降低大概35%左右。

 

理想汽车不光是供应链端的系统，包括车联网端的整个IoT数据，现在是全面跑在OceanBase上来，看重的是金融级的高可用。车间智能制造，如果系统宕机，可能直接影响到出货量，其实是OceanBase给理想汽车带来的价值。

 

携程也是如此，因为很难预测分布式业务未来的增长，很多业务都有自己的周期性，携程就是最典型的例子。春运购买火车票，日常业务是跑在自己的机房，可以用自己的IDC内部的基础设施承载，但春运这种突增的业务高发流量，单机房是很难承载的，采用OceanBase以后可以快速地在春运前购买云主机，通过OceanBase的弹性能力弹到云上，等到春运抢火车票结束以后再缩回自己的IDC。

 

总结一下，这些是我们在国内的头部咖啡品牌，因为原先的技术站是基于虚拟化的VMWare架构，需要整体数字化转型，包括应用侧的微服务化，其实面临整体数据库实例的膨胀，包括原来的PostGre、MySQL、Oracle可以通过OceanBase整合到一个技术栈，这是我们当时做这个项目带来的最大价值。

 

OceanBase是从蚂蚁孵化带有天生的互联网高并发和海量数据的解决方案，我们走出蚂蚁，走向各行各业，也会被业务场景打磨，现在可以支持头部客户，也可以支持Startup和创新场景。未来大家如果有些创新业务场景，可以考虑先使用OceanBase，随着业务变大，OceanBase也可以从容地、慢慢地通过扩缩容的方式伴随业务一起成长。

 

我们既可以支持线下IDC，又可以支持各种云，包括国内的云厂商以及海外主流的云厂商。客户那里如果有多云战略，OceanBase可能是你的首选，包括理想和一些客户，底层云的Vendor是多家，可以通过OceanBase屏蔽不同云厂商的产品差异，PaaS层提供统一的管理和监控。