以下是现场速记。

OceanBase解决方案和产品总经理 师文汇

 

师文汇：大家下午好!我是来自蚂蚁集团数据库的负责人，现在也在负责OceanBase解决方案和产品。今天会站在数据库的使用者和决策者的角度，以及数据库服务提供商的角度跟大家分享一下OceanBase在过去一段时间里是怎么助力企业进行数字化转型的。

 

在政策方面，“十四五”期间明确提出要加强数字化政府的转型。在行业方面，IDC2020年报告指出，中国Top1000企业里有70%的企业把数字化转型作为接下来核心的规划，其中50%以上的企业已经完成了一部分数字化转型的准备工作，10%~20%的企业已经开始用之前建设的数字化的基础设施指导企业一些运营和企业决策管理方面的事情。

 

数据库在企业数字化转型过程中，作为数据存储的纽带，在企业和CIO眼里需要兼顾成本、性能、稳定、效率、安全很多方面因素，在数字化转型过程中，企业对数据和数据库的依赖会越来越重要，在这一过程中，企业通常会遇到很多问题。因为要数字化转型，所以企业一般会建设自己的数据中台、营销中台、业财系统，还有很多制造企业会把生产制造系统也数据化，带到数据的平台上。其实来了非常大的数据量，对整个数据库的可扩展能力有非常高的要求。对于制造领域，可能这个要求会更高，如果数据库出现问题，意味着整个生产都会受到比较大的影响。

 

刚刚从行业角度来说整个转型对数据库的挑战。从全球数据发展的角度来看，在过去十年里，每年以30%左右的速度在积累数据，我在阿里巴巴集团和蚂蚁集团感触更深刻，因为我们每年积累的数据量要比30%高一些，尤其是在现在的社会下，数据库对于存储的可扩展性、复杂能力的支持、算力的支持和要求要比以前大非常多。在这种场景下，就会对原来很多数据库存储产生非常大的挑战。现在行业里用的大部分数据库诞生在上个世纪80和90年代，通常建立在存储和高端硬件上，现在很多金融企业以及政企里很多非常核心的业务还在使用这些数据库，其实在很大程度上，无论是从性能还是从可扩展性的角度，对整个业务都会有很大的制约。

 

我们有一个客户是一家非常大的银行，每周五都要做“红色星期五”的活动，业务系统放在传统的IBM大型机上，做这个活动时经常会因为大型机出现问题导致的抖动。我们还有一些伙伴也比较有意思，其中一家做跨境电商的，还有一家是快手，他们遇到的问题和挑战可能会更大一点，经常会说我有一个商品、有一个热定单品，每秒钟要处理几万甚至到十万的请求量，正是基于这些挑战，我们在整个业界里也开始有一些分布式数据库的解决方案不断涌现。

 

在我们过去合作的很多客户里，大概看到一个现象，很多企业最开始有80%的业务跑在传统的数据库存储上，很多企业在数字化转型过程中有80%的业务逐步切到了分布式数据库上面。

 

今天从整个企业和企业CIO角度来看，为了应对未来业务的发展，到底要帮助企业选择一个什么样的数据库，既自主可控，又能够帮助未来企业走得更远?这是一个讨论很久的话题，我站在蚂蚁的角度大概从两个角度来思考这一问题：

 

第一，我们选型的数据库要确实能够帮助我们业务的发展，确实为业务提供价值。这个价值可能是多方面的，一方面是有更高的稳定性、更好的数据质量、更好的数据安全，数据不会丢，也不会错，有更好的扩展性，因为小业务会变大，大业务会变小，不希望业务在这上面花费特别多的精力。昨天有一个CIO讲了一个词叫优化，站在CIO的角度，其实需要考虑整个企业的运行效率、运行成本，数据库基本占整个IT花费蛮高的，数据库要为整个企业提供持续的低成本的服务。

 

第二，现在很多企业已经有了自己的数据库体系，以及基于数据库的研发和运维体系，新选型的数据库其实要用最小的成本融入到这个体系里面，可能也有一些业务，如比较大的银行，现在业务遇到了容量问题，需要迁移到新的选型的数据库上，整个新选型的数据库的迁移成本要足够低。站在蚂蚁集团和阿里集团数据库负责人的角度，一直在思考这个问题，正是因为前面说到这些问题，所以在蚂蚁集团和阿里巴巴集团才会孕育出OceanBase这一数据库，这其实也是我们在过去的十年里建设数据中台以及数据库的基础设施里，孕育了蚂蚁和阿里最佳实践的数据库。

 

OceanBase发展历程

 

从2010年开始建设这个数据库，第一个业务叫做淘宝的收藏夹业务，当时在传统的数据库上已经没办法支撑了，所以迁移到OceanBase上。到了2013、2014年，整个业务和整个集团发生了比较大的战略决策，即希望在未来数据化建设过程中，我们的数据库底盘和基础设施能够自主可控，彻底摆脱对商业数据库的依赖，我们发起了蚂蚁集团去商业数据库的行动。这一过程对OceanBase是很关键的，我们其实是把整个业务的发展以及去商业数据库自主可控这件事情融入到了OceanBase产品里。

 

在OceanBase发展第三阶段，是我们在阿里巴巴积累了这些数字化转型以及数据库基础设施的经验，也是希望赋能给行业里一些伙伴，让他们也能享受到我们以前积累的一些东西。从2017年开始，我们和行业里的很多伙伴做了很多讨论和共创，一起做了一些项目。在2017年到2019年的时间里，我们清楚认识到了一件事情，因为我们业界有很多MySQL、Oracle，需要帮助使用传统数据库的业务能够比较简单的使用OceanBase。

 

在这一阶段我们还做了一件事情，把整个数据库的基础架构做了很大的重构和改造，改造的结果是我们能够在数据库Top的benchmark里，2019年基于这一架构超越了Oracle，做到了现在的世界第一，有几十倍的差距。到了OceanBase4.0，在2020年OceanBase这家企业作为一个独立的公司开始商业化运营，在这个阶段，从金融走向了政企，走向了各行各业，看到了很多用户的需求，有大用户、小用户，有核心场景、非核心场景，支持这些用户过程中，我们开始逐步认识到了如何帮助用户去释放数据价值这件事情的重要性。数据其实一直都在数据库里，我们怎么样帮助用户把数据的价值最大、最快发挥出来，这是我们和客户一起讨论，要一起去解决的问题。所以OceanBase4.0叫做分布式一体化版本，很好支持在线交易业务和离线分析业务融合在一起，来支撑业务，进一步降低业务成本。

 

从OceanBase产品体系来看，现在OceanBase支持公有云部署、私有云部署，也支持混合云部署，还支持海外多云部署，我们支持市面上大部分硬件，比如ARM、x86、华为鲲鹏，大家甚至可以把OceanBase装在一个很小的Pad里。我们希望把所有简单都留给客户，一个OceanBase的集群既可以支持MySQL的语义，还可以支持Oracle的语义，后面可以方便做一些实时数据库的分析。

 

从OceanBase产品体系来看，我们不仅支持传统的关系数据库、KV数据库，还支持图数据库和持续数据库，这两款数据库诞生也是源于蚂蚁和阿里巴巴在某些业务领域的最佳实践，比如图数据库，广泛应用在蚂蚁集团风险防控领域里，我们用这个数据库把风险防控漏洞过率从十万分之一做到了百万分之一。

 

现在蚂蚁每天大概有接近上千个业务迭代，会有上千次业务发布，这里大概会有成千上万次的DDL和DML(音)，因为要改数据、改模型，因为蚂蚁集团有2万多个研发，支持这些工作的人只有1~2个，所有的东西基本都是被自动化完成的，我们有些伙伴也在基于这些体系做运维和研发流程。

 

对于一个数据库来说，我们觉得数据的安全、数据库的稳定性是在企业发展任何一个阶段都重要的事情，我们把数据库安全稳定防护分了6级4层，我们一直都坚持所有的数据都是要经过被充分校验的。第二层校验发生在OceanBase集群内部的，OceanBase支持多副本强一致同步，我们客户可能会把副本放在同一个城市的不同机房里，这些机房可能相距30、50公里，还有一些客户会把OceanBase不同副本放在不同城市里，比如网商银行放在相距1200公里不同的两个城市里面。这些数据副本是做强一致实时同步的，任何一个副本出现问题时，30秒可以切到另一个副本。第三层校验主备库，所有副本之间强一致同步其实是相关联的事件，如果出现bug或异常，所有副本可能出现同样的问题，但是主备库是相互独立的事件，两个同时出问题的概率非常小，所以蚂蚁集团所有的数据其实是被放了5份，既有强一致同步，也有主备库的同步。最上一层防护在我过去的实践里，帮我们挡住或发现了很多问题，这一层校验就是备份恢复，现在蚂蚁有几千个PB的数据，我在蚂蚁可以让业务回溯到线上14天内任意一个时间点，如果业务把数据写错了，可以回滚到线上业务任何一个时间点，这个事情在我们客户里也有发生，我们用这些能力帮他恢复数据。因为人的错误、软件的bug不可避免，很容易会把数据写错的。

 

示例，数据库怎么保障数据安全和数据正确

 

2018年的一个企业，SSD静默错误导致整个企业全部数据丢失。

 

硬件厂商都会发生一些批次性故障，要么静默数据丢失，要么SSD掉盘。因为我们每年大概有几十万片到上百万片SSD的采购，这些问题是经常会出现和发生的，在去年我经历了我印象非常深刻的一件事情，我们采购了大概十几万片的SSD，SSD大概有80%的概率会出现磁盘的静默错误，写进去的数据是1，读出来是0，告诉你这个数据写成功了。在去年8、9月份时，非常密集的这些磁盘基本上会在同一时刻出现问题。可能今天A磁盘说这个数据坏了，明天B磁盘数据坏了，因为我们前面做了很多底层的校验，在业务上能发现，发现以后会重新定向正确的副本上，包括不会失败。其实这是非常有危险的。大概因为这个事情，OceanBase架构，每天都会把所有的数据做checksum。

 

我们从软件上保证数据是正确的，因为数据库是一个状态级，会把状态变迁做好checksum，把主表数据、索引数据、视图数据、主表数据做checksum，会保证任何一刻或任何一个时间点出现错误，能第一时间发现。

 

如何建设数据中台?通常典型的场景是所有业务的数据分布在不同的数据库里，通过CDC、ETL，把所有数据回流到计算集群里，在上面构建业务数仓业务原型做分析。数据会存储两份，计算也会有两份，有很大的成本。海底捞最开始也是这样的，在线数据要同步到离线数据，再做运算，他说能不能让在线数据和离线数据一起算?因为数据本身就在那里，数仓是否可以基于实时在线模型去做一些运算?我们思考了很久，觉得可以，OceanBase4.0也是朝着这个架构去做的。我们所有的数据会放在OceanBase不同的租户里，在线请求和离线请求同时在这份数据上做计算，中间会有一些隔离保证在线的请求不会被离线的请求所影响。

 

为了更好支持HTAP在线的数据计算，我们做了行列混存，在学术里叫PAX，能给我们带来非常大的好处，我们的数据能够以原来1/10的成本存储在磁盘上。蚂蚁所有的业务，支付宝、花呗、借呗、农场小鸡所有的数据都是放在OceanBase上的，原来都是放在MySQL，这个数据迁过来，节省了2/3的成本，对一家企业来说这个成本是非常可观的。

 

在整个企业数字化转型过程中或在整个企业生长发展过程中一定遇到很多问题，大家一定会有很多创新的想法，而这个想法开始可能只是原型，未来可能会变得很大。过去几十年我看到很多这样的业务，也有因为业务发展原因或战略原因，开始逐步收缩。我们在过去的实践里花费了非常大的精力去帮助技术能够实现业务上的skill，这个投入非常大。蚂蚁和阿里巴巴在2015、2016年前，大部分技术都在做这个事情，我希望我们在蚂蚁和阿里积累的这方面经验能够平滑地迁移到我们行业里面，行业的同学只需要关注行业，发展好业务就可以了。

 

OceanBase是支持副本的，天生可以做一件事情，我和伙伴们交流，他们新引进一个硬件，硬件出现一大堆问题，或者企业想换一个OS，不知道这个东西对我的数据库稳定性到底有多大影响?我们提供这种能力，可以帮助大家灰度验证新硬件、操作系统，验证以后做大批量推广覆盖，对整个业务来说没有任何感知。

 

经过几年的打磨，有两个数据分享给大家：

 

1.现在最大的节点规模大概有1000台。

 

2.现在最大的集群应该有15PB，也是在做数据中台的业务，所有数据大概有15PB，上面有非常多的计算。

 

我们非常注重生态和伙伴的建设，特别想说两点：

 

1.我们在行业方面的伙伴，我们和政企、金融行业大概有TOP40家企业做了深度融合，深度产品层面的融合，简单来说就是我在数据库里帮他定制很多feature，帮助这些业务解决以前在传统商业数据库或者单体数据库很难解决的问题。

 

2.OceanBase这家公司一直在做相关人才的建设，现在有1

 

万多注册工程师，每年大概会投入几千万和校企做联合、做大学生的培养。

 

从金融到现在，走向全球各行各业，有400多个客户，比较有特点，基本上OceanBase在里面做的都是核心系统，比如银行的贷记核心、借记核心，运营商领域的CRM和BOS核心，这里可能有很多logo大家都很熟悉，这些logo可能都很大，但是有很多logo很小，有很多logo是和OceanBase一起成长起来的。

 

做基础设施出身的人非常容易做一件事情，老是觉得这个技术不太行，升级一下。我现在有一个非常大的转变，不管做什么，要适应业务发展的需要。过去三年多，OceanBase完成了非常大的转身，不只是可以在蚂蚁或工商银行、建设银行、交通银行这样非常大的场景里运行，也可以在非常小的场景里运行，比如我们之前做了很多小区门口小的闸机。

 

案例分享

 

案例1，中石化在全中国有2亿张加油卡，每天有3000万笔交易量，由于历史原因，中石化架构有点奇怪，有22个省用Sybase建设的，其他的用Oracle来建设的。需要把二三十个不同的数据库迁移到SybaseIQ上做分析。这20~30个省有写业务量大、有些业务量小，有非常大的浪费。因为是一个分散化的架构，每一个不同的省市可能用了不同版本的业务，造成一个问题，我是从杭州来的，要去北京或四川加油，业务逻辑非常复杂，先到北京的业务，再到四川的业务。

 

在这里还有一个比较大的挑战可能更麻烦，其实每天有3000万笔交易量，如果出问题，对所有开车的朋友影响还是比较大的，整个石化一直想做业务异地容灾，分散在很多省里，要做这件事情的成本非常高，基本不可能。我们和石化的小伙伴做了很多交流和讨论，也把我们以前在蚂蚁和阿里的一些经验放到他们的异地灾备和单元化多活方案里。最终方案也比较简单，他们北京有一个中心、南京有一个中心，每个中心会承担一部分省市的业务数据，但是这两个中心是多活的，每个中心有一个OceanBase的数据库，数据在这两个中心通过我们一个产品做实时的同步，一个中心出现故障，可以快速切到另外一个中心。除此之外，是HTAP能力。

 

案例2，运营商业务，山东省是运营商的第二大人口省，每天大概要处理130亿条数据，数据量挺大。随着5G和IoT的发展，运营商在很多用户增长比较快的地方以及新的场景上遇到了瓶颈，因为系统很早建造的，是基于Oracle，就面临两个选择，一是把所有的运营商业务重构，基于新的数据库系统做一次建设;二是找一个能够水平可转的数据库解决当下的问题。在运营商领域业务非常复杂，有很多复杂的查询，还有很多Oracle的高阶特性，对任意数据库的挑战都很大，我们做了很多次沟通，最终觉得可以一起尝试一下，把Oracle平滑迁移到OceanBase，解决业务遇到的容量问题。最终这个业务经过大概几个月的努力，花了一个小时就完成了整个业务的切割，切割以后，BOS详单查询效率提升了30%，存储成本降低了90%，变成了原来的1/10。这个项目获得了工信部2002年网络安全技术示范奖。

 

案例3，致欧家居，现在跨境电商比较火爆，我们合作伙伴致欧现在是亚马逊亚洲最大的电商伙伴，进入了50多个国家，它的业务部署在私有云、公有云，包括阿里云和AWS上，他想做任何一件事情都很困难，因为很多业务系统是采购的，它利用OceanBase混合云和多租户的架构，把所有的数据都汇聚到了香港阿里云的OceanBase上，把它在欧洲、北美所有的AWS数据库迁移到OceanBase，我们帮它做了一个一体化的数仓。

 

案例4，理想汽车，L9MES系统是基于OceanBase的，MES系统对稳定性的要求非常高。

 

OceanBase走过来大概有十年时间，我们一直坚持一件事情是希望把复杂的东西留给我们自己，让用户可以比较简单地做创新，让用户更好地去发掘数据的价值。

 

谢谢大家!