11 月 16 日，2023 OceanBase 年度发布会上，OceanBase CEO 杨冰对外正式宣布：将持续践行“一体化”新战略，为关键业务负载打造一体化数据库。同时，发表《砥砺自研，为“关键业务负载”打造的一体化数据库》主题演讲。
以下为演讲全文：
各位领导、嘉宾、媒体朋友和线上的朋友们，大家上午好，欢迎来到 2023 OceanBase 年度发布会。
今天，我的演讲要从砥砺自研开始。13 年前，如何解决从未遇到过的海量数据问题，有两个选择：一条基于开源，一条完全自研。开源起步会很快，门槛更低，并且在初期的能力还更完善。但当到了企业需求的深水区，如果要从根本上解决分布式的问题，还是需要打破原来的架构完全重写。因为分布式的复杂度绕不过去并且不会消失，要么被数据库消化掉，要么被转移到业务代码中。
OceanBase 选择了自研之路，刚开始的时候举步维艰，但当我们完成了支付宝账务核心系统的切流，用现在流行的说法就叫“轻舟已过万重山”。
自那以后，我们自研的分布式框架基本成型，当遇到更加多变的需求以及更加复杂的场景时，OceanBase 的发展速度反而更快。正所谓“逢山开路、遇水搭桥”，我们对代码完全的掌控力和掌控权是我们最大的底气，也是我们厚积薄发的根基。
一、基于自研，打磨承载“关键业务负载”的核心能力
数据库是用出来的，OceanBase 过去十多年的发展，得益于飞速发展的移动互联网场景。这些年，从互联网支付核心到全场景金融核心，再到政企民生、运营商核心场景，以及新零售和新制造的核心场景，OceanBase 在千行百业的“关键业务负载”中再次深度完善、快速迭代。也正是这些“关键业务负载”，倒逼了分布式数据库技术的再次突破、创新和成熟。
对基础软件的发展而言，这是一条极为特殊的成长路径，也是最好的成长路径，在全球都很难复制，这是我们的幸运，身上也不由有了一种时代的使命感。
OceanBase 产品从 1.x 发展到今天的 4.x，能力得到了飞跃式的发展，但聚焦到“关键业务负载”，最关键的还是在高性能、高可靠、高兼容和高性价比这四个维度上的持续突破和深度打磨。这些基本功，也是 OceanBase 最大的核心竞争力和我们投入最大的方向。
简单回顾过去这些年，我们在以下四个方向的核心进展：
（一）深度强化稳定性和安全性
对于一个“关键业务负载”的数据库来说，最看重的一定是稳定性和安全性，OceanBase 在这方面投入最多，也一直在推动行业的发展。OceanBase 最早提出 RTO<30s，目前已经是行业标配，这个切换还是数据库层面的自动切换时间，为了给连续性要求更高场景的业务系统留出更多时间，经过努力，我们将其降到了8s 内。
在 IDC 和云上，跨机房的网络带宽受限或者成本较高是普遍现象，我们在 4.x 版本中将带宽降了近一半，极大降低了享受分布式带来的高可用红利的成本。我们最早期的客户四川农信身处中国西部，由于要跨越地震带建立高可用架构，机房距离比较远网络带宽的成本比较高，得益于 4.x 版本这方面的优化，客户能用更低的成本来构建多地多活的高可用架构。
一致性和安全性，往往是事无巨细、润物无声的工作，我们在这个方向上还有很多进步的空间。OceanBase 在数据块、事务、副本级都会做实时和定期的校验，使得数据不丢不错，在各种合规认证和国密认证中也持续完善，做了大量工作，确保企业级数据的可靠性。
（二）持续打造分布式数据库高性能
强劲的性能是承载“关键业务负载”最核心的能力，这也是 OceanBase 的传统优势。这些年在传统核心业务落地中，我们也发现分布式架构在工程实现上的一些挑战，我们集中力量突破超大事务限制、海量分区限制，目前 OceanBase 已经在分布式架构上比较完美地解决了这些问题，能更好地支持集中式架构下的复杂场景和复杂用法。
去年，我们发布了单机分布式一体化的能力，今年 OceanBase 在单机形态 4C 小规格场景下，性能超越了 MySQL，写入性能是 MySQL 的 1.5 倍，这能让很多传统核心系统能在与集中式一样的单机模式下运行，随着业务需求可以再逐步扩展至分布式架构。
很多关键业务是混合负载，尤其在数据量没那么大的传统核心系统上。为了更好支撑这些场景， OceanBase 在 3.x 版本发布并行引擎后，在 TPC-H 和 TPC-DS 维度的性能上分别提升了 6 倍和 3.4 倍，同时具备更强的 SQL 隔离性。这些都是已经具备的能力。今天，我们将发布一体化数据库的首个长期支持版本 4.2.1 LTS，给大家带来更多惊喜，相比 3.2.4 LTS 版本，在兼容性、性能、容灾能力、易用性等方面均有大幅度提升，欢迎大家阅读《OceanBase 4.2.1 LTS 发版 | 一体化数据库首个长期支持版本》了解详情。
（三）深度完善平滑迁移方案，上下兼容和适配
我们过去做的大量关键业务都是升级替换的过程，让这个过程更稳妥、更低风险是我们不断追求的目标。
向上兼容方面，OceanBase 用同一个引擎支持两种语法，Oracle 兼容度经过多年打磨已经比较完善，今年又增加并完善了 DBLink、JSON/XML/GIS/LOB 等大颗粒的功能。MySQL 5.x 也接近全兼容状态，还增加了对 MySQL 8.0 主流功能的兼容；在 OLAP 方向常用到的复杂数据类型，如 Nchar、Nvarchar 等，也有了更好的支持。向下兼容方面，OceanBase 完成了基本全部主流芯片和服务器的适配，包括 7 款主流芯片和 10 多家整机厂商的适配。
核心系统迁移是一个极为精细而复杂的工作，像心脏搭桥手术一样。首先，除了要保障整个过程的可靠外，还必须要做到可评估、可并跑、可回切。同时，核心系统往往也是整个数据架构里的中心枢纽，需要让新的数据库能融入原来的数据架构。OceanBase 这些年不断打磨这套迁移平台，目前，向上游适配方面，具备 MySQL、Oracle、PG、DB2 四大类源端数据库的对接解析能力，其中包括了 10 多款云上云下的数据库产品；向下游适配方面，则通过 Canel、Flink、DTS 等比较常见的数据同步工具打通上下游数据处理软件，同时支持 20 多款常见数据处理平台，可以无缝地跟原有的数据架构进行对接。
（四）深度优化多租户和高压缩，充分利用每一份资源
对“关键业务负载”而言，也许成本是放在最后一位的，但一般承载“关键业务负载”的数据库也会成为企业绝大多数业务系统的主流数据库。当一个数据库承载的业务量变大、规模变大、系统数变多后，如何高效利用好每一份资源是非常重要的目标。
凭借高压缩比的分布式存储引擎，在同一业务的数据存储量下，OceanBase 仅为 MySQL/Oracle 数据库的 1/4-1/3，能有效降低 70%-90% 的存储成本；为满足客户多样化的需求，OceanBase 在内存、CPU、IOPS 中用 Linux cgroup 技术做到硬隔离的水平，多租户能力具备资源隔离、数据隔离、弹性调整的特点，每个应用的租户都拥有专属的资源池，真正把虚拟化实例演进到与物理隔离实例一样的能力。
走到商业化的第四年，已经有不少大大小小的客户选择 All in OceanBase，或者七成以上的系统都跑在 OceanBase 上，这些客户都非常看重 OceanBase 的多租户和高压缩能力，这是在海量大规模集群下的最佳解决方案，也是在蚂蚁集团的大集群中做得最好用的功能。正是这套解决方案，让客户越用 OceanBase 越省成本。
回看十三年一路走来的历程，今天的我们得益于最初的决定——走完全自研的路线，得益于中国独特的场景——移动互联网爆发，带来前所未有的对海量数据、高并发的数据处理需求，以及这几年大量企业的核心系统升级，带来复杂业务场景下处理海量数据的需求。这些独特的场景使得 OceanBase 能够始终坚持创新探索，穿越无人区。也借助这些中国的场景，让我们有幸能够推动并树立分布式数据库的四项新标准：
○ 性能新标准：对于分布式数据库的性能来说，更重要的并不是跑得更高，而是在高并发场景下可以按需实现不停机、不改应用的弹性扩充。OceanBase 用一个引擎刷新了 TPC-C、TPC-H 两个榜单，也证明在分布式数据库领域中 HTAP 或者混合负载引擎是一个可行的，也是必须的能力。
○ 容灾新标准：打造“三地五中心”自动无损容灾，无论是结合应用，还是不结合应用，都有不同的实现方案，可以更好地应对城市级容灾。
○ 高可用新标准：相比传统数据库，OceanBase 的高可用是自动切换的。与此同时，我们也进一步刷新了RTO，进一步将 RTO 降低到小于 8 秒，这也是目前业内 RTO 做得最好的水准。
○ 架构新标准：架构层面，我们提出了单机分布式一体化，这是业内首次突破分布式数据库的单机性能瓶颈，使得数据库可以在现代数据架构下适应企业成长的全生命周期。
二、携手 1000+ 客户共同推动数字化升级
相比于三年前，我们只有 18 个客户，现在已经有 1000 余家客户携手同行；相比于三年前，大家可能只敢用在周边系统，到后来越来越多客户敢用在核心系统，再到今天很多客户已经选择 All in OceanBase。在此，我要真心感谢每一位客户给予我们宝贵的信任。谢谢大家！
这几年，我最大的感受是，数据库真的是一个承载信任的基础软件。客户数量级的变化意味着我们会遇到更多复杂且极其核心的场景，这与以往“双 11”的挑战完全不一样，OceanBase 在千锤百炼的场景中快速迭代进化，而且这些年的进化速度比过去十年都要快。
（一）OceanBase 正在成为分布式数据库领导者
在我们快速发展的过程中，也给大家分享一些数据。这一年来，我们的专有云稳步发展，公有云略快一些，达到了 150% 的增长，这种变化下客户结构也稍有变化，非金融客户反而达到 60%，稍稍超过金融客户的数量。而且在大小、客户比例上，中小客户也从去年的 70% 走到了今天的 75%。得益于单机分布式一体化的发展，让我们可以服务于更多客户。
无论是从产品技术上的认可，还是从客户层面上的认可，在赛迪顾问《2022-2023 年中国平台软件市场研究年度报告》中，OceanBase 凭借分布式领域的成熟产品，成为中国分布式数据库领域的领导者，并且在中国金融行业分布式数据库销售额中居国内厂商第一位置。非常感谢市场和客户对我们的认可。
（二）OceanBase 正在成为核心系统升级首选
过去这一年，我们参与了大量核心系统的升级过程。尤其在金融行业，资产规模达到千亿以上的银行有 100 多家，我们覆盖了 70%；在证券、保险、基金行业的头部 Top20 资产规模企业中，我们的覆盖率也非常高，分别达到 75%、65%、45%。根据赛迪顾问《2022-2023 年中国平台软件市场研究年度报告》、《中国金融业数据库市场研究报告》显示，核心系统升级中 OceanBase 在金融行业处于第一。
在政企行业。运营商领域 OceanBase 已经拥有全国 1/5 的移动客户，包括：山东移动、浙江移动、江苏移动、辽宁移动、福建移动、湖北移动等。中国联通核心系统和电信翼支付核心系统也在今年完成切流上线。人社领域目前也覆盖了全国 1/4 省份，包括：江西人社、重庆人社、海南人社、吉林人社、北京人社、黑龙江人社等。
除了金融、政企行业外，我们发现有很多产业互联网的行业，包括新制造、新零售、企业级 SaaS 等也都加入到核心系统升级转型的浪潮中，用来应对未来海量数据的冲击。分布式数据库正成为架构的新选择。
根据赛迪顾问《2023 核心数据库升级选型参考》显示，在中国部署的数据库当中，OceanBase 在中国本土品牌排名第一，在未来部署数据库产品的预期排名当中也是第一。客户的选择是 OceanBase 前进最大的动力，这份动力推动着我们做好承载“关键业务负载”的重要工作和重要使命。
（三）OceanBase 正在变得越来越流行
2021 年，OceanBase 完成 300W+ 行核心代码的开源，我们希望通过这样的方式能够让更多企业接触到、享受到在流量洪峰场景下孵化出来的技术红利。
今年，是我们开源的第二年，发展得非常快，目前已经有接近 500 个客户敢于把社区版的 OceanBase 用在生产系统上，在我们社区的“老司机”也越来越多，他们用课余时间传道授业，我们非常感动。当然也非常犀利地给我们提出了非常好的发展建议。
今年，我们也联合了非常多的企业举办“走进企业”系列活动，感受到了企业对我们的热情，交流过程当中，我们也发现我们的产品真的能够帮助他们解决问题，这也让我们倍感鼓舞。
唯有把产品做好，把社区做好，才能有更好的回报。这一年，我们在开源的社区版上做了很多工作，包括很多周边工具也在陆陆续续开源。随着 OceanBase 的开源流行，OceanBase 也与国内一家领先的数据库服务公司——爱可生，基于 OceanBase 的开源内核推出了商业的发行版 ActionDB。ActionDB 继承了 OceanBase 所有的能力，同时在企业级的安全性、应用性、平台工具等方面进行了大量的增强，为客户提供了更好的本地服务，以此服务更多的客户。
从只有一个客户「支付宝」，到现在突破 1000 家客户，OceanBase 这一路走来的初心未变，就是“用技术让海量数据的管理和使用更简单”。
三、持续践行“一体化”产品战略
我们在不断解决各种场景问题，尤其是关键业务的数据存储、处理、使用过程中，摸索出分布式架构数据库的最佳实践，逐步形成了“一体化”的解决思路。
（一）产品思考：一体化设计是抵消分布式架构熵增的最佳路径
如下图所示，表达了 OceanBase 在一家企业里逐步被使用深入的过程，无论是在蚂蚁集团内部还是外部，都非常类似，都是越用越核心、越用越多、越用越复杂的过程。
以 OceanBase 最早年为例，当时还是外围但如今已经是非常核心的系统「淘宝收藏夹」遇到扩展性、存储成本等问题，我们就用分布式架构来去解决，上图中「外围👉核心」左侧就是当时 OceanBase 的架构，有 SQL 引擎、存储引擎、管控节点，采用全架构分布式设计和最朴素的分而治之思想来搭建分布式数据库，用大量的远程调用来实现系统内部的协同和数据交换。问题解决之后，大家很开心，但是有一个团队不开心，就是 DBA 团队。DBA 团队说这比传统的主备库数据库复杂得多，就像是一个复杂的应用系统，有很多角色，有做协调的、做存储的、做网络解析的、做 SQL 解析的等等，是一个有状态的、非常复杂的分布式系统，必须把每个部分都搞明白，否则不敢扩容和切换，风险极高。
分布式架构的复杂度是存在的，并没有消失，只是从一个地方转嫁到另外一个地方，我称其为分布式的“熵增”。
外围系统还好，但当我们走到了支付宝的会员核心、交易核心、账务核心的时候，这个场景除了可扩展和成本，最关心的还是稳定性和性能。这时，背后复杂的分布式多角色，分而治之的架构设计开始捉襟见肘。每次用户请求都需要在数据库内部耗费多次远程调用来实现，请求量一大，毛刺、稳定性、响应时间、吞吐量等问题陆续出现，怎么办？
减少分布式设计带来的开销，能走进程内的，就走进程内的通讯，但还是得能扩展，得有分布式能力。于是就有了 OceanBase 历史上第一次大重构：从复杂的多进程分布式系统，变成“一体化”单进程的分布式系统。可以看上图中「外围👉核心」的右侧，SQL、事务、存储，包括协调管控元数据等都装进了一个进程，并以这个进程为最小单位，进行扩展。
这样，极大减少了远程通信，性能和稳定性瞬间提升上来，同时还能扩展以解决海量请求和海量数据的问题。正因此，我们当年成功地支持了第一次“双 11”。这就是 OceanBase 第一次用“一体化”的思路设计，很好地抵消了分布式带来的开销和复杂度，性能好、扩展性好还很稳定。如此一来，支付宝业务团队很开心，DBA 团队也很开心，“工程一体化”+“分布式对等架构”，一个进程所有角色都在里面，运维更简单，性能不够扩容即可。
随着往后继续深入，当 OceanBase 支撑好了核心系统，客户有信心大规模推广的时候，如果用分布式的方式管理每个大大小小的应用集群，每次一个三副本成本很高，运维复杂度也很高。这个场景又倒逼我们进化出来多租户能力，很好地平衡了分布式带来的成本和效率的问题，对 DBA 而言无论微服务系统怎么增加，还是可以用几个一体化管理的大集群中统一管理、统一做资源分配，特别适合微服务架构。
分布式系统的复杂度不会消失，而且在企业内部使用过程中，会随着时间的推移、场景的变大，变得越来越复杂。我们认为“一体化”的设计是管控和抵消这个复杂度的最佳路径。
后来「单场景👉多场景」、「IDC/Cloud 👉Hybrid Infra」的发展。当从单场景扩展到多场景，无论是 OLTP 负载还是 OLAP 负载，或者是 MySQL 语法还是 Oracle 语法，甚至是少量的非结构化数据 JSON/XML 的存储，再到后面云上、云下场景下，数据存储的统一和用户体验的统一，我们都在践行“一体化”设计。
再到后来，非常普遍的场景是，OceanBase 在企业内越用越广，场景从核心走到了更多中长尾的覆盖，客户希望统一技术栈，但又希望用单机来解决问题；还有一个普遍的场景是，很多中小企业有明确的未来高速增长需求，但起步阶段又希望用更轻量的单机。于是，我们发布了 4.0 版本，推出业内首个单机分布式一体化架构，完成分布式到单机的融合，这又是 OceanBase 历史上的一次重大重构升级。不难发现，所有这些的本质都是一样的，OceanBase 都在用“一体化”的方式来解决问题。
（二）一个数据库，解决 80% 问题
在这里我想展开阐述“一体化”包含的理念，包含两个方面：
第一，首先是“一体化”的体验。在实际的应用中，数据库是解决数据存储、处理问题的手段，应用系统真正关心的、要解决的是业务需求，而不应该花太多精力在关心分布式带来的成本复杂度问题、处理各种数据结构带来的存储的差异性、不同数据库操作语法带来的好处、不同的负载或者基础设施带来的差异性等。我们在用“一体化”设计来打造产品，让用户回归到关注业务，让数据库使用尽可能简单。虽然在这条路上我们还没有走得非常完美，但会一直坚信这个理念。
第二，遵循二八原则，解决 80% 的问题。“一体化”不是变成全功能，也不是简单的拼装组合，而是在一个具备承接“关键业务负载”的 OLTP 底座上做扩展。本质上，OceanBase 还是一个具备“关键业务负载”支撑能力的 OLTP 数据库，核心能力还是高可用、高安全、高性能以及高性价比。我们认为，在企业的绝大部分数据处理场景中，只要成本合理，这些都是必须的能力，我们希望能在这个强劲的底座上，尽可能满足 80% 的需求。但在极其专业的场景，还是需要用专门的数据引擎。就像今天的智能手机，可以很好地满足普通人对电话、聊天、游戏、听音乐和看电影的需求，但是针对一些专业用户，专业的游戏机是更好的选择，电影院是更好的选择。
从 OceanBase 整个演进来看，“一体化”的设计就是 OceanBase 产品的 DNA，未来 OceanBase 将持续践行“一体化”的产品战略，用“一体化”的架构解决分布式数据库的使用复杂问题，用“一体化”的产品满足 80% 的客户需求，持续打造能够承载“关键业务负载”的分布式数据库。更多关于 OceanBase 对“一体化”理念的思考与探索，欢迎大家阅读我们 CTO 杨传辉的文章《从一体化架构，到一体化产品，为关键业务负载打造一体化数据库》。
四、OceanBase 三大产品解读
接下来，通过面向不同群体的三个产品，我来快速为大家解读一下 OceanBase 如何为“关键业务负载”打造一体化数据库，以及在各个场景中的核心特色。
（一）OceanBase 企业版：核心系统升级的理想选择
首先是企业版，通过数据统计，我们总结出企业级客户最关心的五个特性。核心场景复杂，在分布式架构下遇到全新问题，代码的完全掌控力是我们解决任何问题的底气，自主研发才能从根本上解决问题。
稳定可靠也是 OceanBase 最大的投入和基本功，无论是在内部的蚂蚁集团和阿里巴巴集团，还是在外部的大量客户中，我们都在参与大量核心系统的建设。所以在这方面的积累，我们有非常丰富、完整的经验来应对各种需求。此外，还有技术领先，支持国密的高安全性，以及支持“一库多芯”的平滑迁移能力，这些都是基本功。
这三年来，我们参与到各行各业的核心升级过程当中，刚刚的开场视频可以看到已经有不少客户的核心系统已经稳定运行好几年。不同行业有不同特征，中国的金融行业拥有类型最为丰富的客户，从银行，到保险、基金，从头部的国有银行和大型保险公司，到大量中小银行、保险、基金，对关键业务负载的要求非常不一样。OceanBase 可以为头部金融机构提供异地多活单元化的完整分布式架构方案，也可以为中小机构提供偏向保留集中使用模式的无侵蚀的一站式方案。同时，也提供丰富的 ISV 适配和完整的培训体系，让更依赖外部厂商的中小机构，应对未来大规模使用后顾无忧。
中国的运营商无论是移动、联通，还是电信，都非常复杂，属于又复杂又庞大的系统。尤其是广东、江苏、山东省等，OceanBase 高度的兼容能力，让核心系统的升级变更平稳，风险更低。完整的迁移方案和丰富的工具体系也确保了整个迁移过程中可评估、可并跑、可回切。
在国计民生的行业中，现在正涌现出要把大量的数据孤岛汇聚到一个数据库上，把不同独立的系统能够统筹管理、统一运维。OceanBase 的海量处理以及低成本存储，以及基于多租户的管理是最佳的解决方案。江西省人力资源和社会保障厅、浙江省人民政府都通过升级至 OceanBase 取得了非常好的效果。
（二）OB Cloud 云数据库：面向多基础设施的一体化数据库
OB Cloud 云数据库是我们上线了一年多的版本，目前已经有数百家客户。我们也通过数据统计，总结出云数据库客户最关心的五个特性。
第一个是多级弹性扩缩容，弹性比普通的云上数据库的垂直水平扩展，多了像基于租户的弹性分配资源，以及从单机到分布式的弹性，非常灵活；第二在企业角度，大量客户希望降本，我们能够实现规模化降本，经过大量业务实践证明，在业务规模超过 30C 场景下，TCO 相比通用 RDS 降低 30% 以上，为海量数据的规模化降本提供更出色的选择。此外，还有领先的业务连续性、HTAP 实时分析等能力，这些特性无论是在云上还是云下，还是不同的云基础设施，OceanBase 都可以支持。
目前为止，我们已经在 3 大洲、6 大公有云、30 可用区部署了大量的集群。我们提供两种方式：（1）DBass 模式，即全托管模式，由 OceanBase 提供高 SLA 保障的免运维数据库云服务，无云厂商绑定。（2）MaaS 模式，OceanBase 集群云资源归属用户所有，用户完全掌控，更安全可信。企业可以用最灵活的方式，在不同的云上使用 OceanBase。
随着云计算的成熟，混合云已经是非常明显的趋势，我们的很多客户都处于这种状态。混合云部署模式下，最为复杂的问题莫过于有状态数据的同步、迁移、切换等，而 OceanBase 相比 MySQL 最大的价值在于用“一体化”的方式解决数据同步等方面的问题，这也是 OceanBase 独特的价值。
因为国内各种场景的锤炼，也逐步让 OceanBase 被海外客户所认可。在学术上，我们把近年来的很多经验写成论文，在数据库国际顶会上发表并被接受。OceanBase 提出的“原生分布式”、“三地五中心”、“单机分布式一体化”，都在国际顶会上得到了专家们非常高的评价。
在市场上，我们以东南亚为第一个征程，聚焦在金融科技上，用 OceanBase 已经打磨出来最成熟的经验和产品，解决东南亚金融科技企业当下正面临的问题，让这些企业少走弯路，快速进入数字化发展的快车道。
例如，印尼国民电子钱包 Dana，用了 OceanBase 后，平稳支撑客户量从千万级到亿级；菲律宾国民电子钱包 GCash，其用户数量增长近 4 倍，现在已经涨到 8000 多万，自从用了 OceanBase 后没有做过大的数据架构调整，而且架构还可以扩展；还有非洲国民电子钱包 PalmPay，虽然上线 OceanBase 不到一个月，但也享受到了扩展性以及降本的红利，同时还可以部署到不同的公有云上。
（三）OceanBase 社区版：为现代数据架构打造开源分布式数据库
OceanBase 的企业版和社区版最大的区别在于我们把一部分 Oracle 兼容能力，和一部分企业级安全的特性，留在了企业版里，其他大部分都是开源的，包括在社区最为关心的能力，几乎可以称之为“双 11”同款。
OceanBase 社区版的目标就是为现代数据架构打造开源分布式数据库，正是因为有这样的开放性，已经有越来越多的企业用来去解决 MySQL 无法解决的问题。我们拥有非常庞大的社区，不仅仅面向OceanBase的社区版，而是面向所有 OceanBase 的用户，相信很多企业版的客户也在用。
借鉴了 CNCF 的 Landscape 大图的形式，我们基于 OceanBase 画了一张“周边工具生态”图，包括 APaaS、DBPaaS、IaaS 三大板块，每个格子中展现了已经跟 OceanBase 完成适配对接的工具和驱动，有开源社区的，也有商业公司的产品。有些小格子的右上角有 OceanBase 自己的工具，很多都已经开源或者正在准备开源的过程中。仅仅两年时间，这张图发展得非常快，要感谢所有社区伙伴和商业技术生态伙伴对 OceanBase 的支持。今天在会场长廊也有很多伙伴在展示他们的产品。
我们这个社区也许没有 CNCF 那么大，也没有云厂商的社区生态那么包罗万象，但是我们够专注、够专业。我相信，在这里的都是关心数据库的伙伴，希望大家在这个社区里面有收获、有成长，以及合作共赢。
五、以伙伴能力为核心，助力伙伴业务成长
去年，我们发布了“珊瑚计划”，助力伙伴成长，今天很高兴给大家汇报一下进展。我们与头部最流行的 100+ISV 打造了 340 个联合解决方案，并且已经有 20 多个已经在行业中大量进行批量复制。
在经销商中，我们希望三年达到 60 个经销商，今年我们速度起得很快，已经有 50 个经销商。而且在专有云中，伙伴的签约额已经占我们的营收达 55%，增长非常快。公有云虽然刚刚起步，伙伴贡献的商机对应消费额占比也达到了 15%。
与此同时，OceanBase 也积极在参与人才的培养，我们跟大量的高校建立了合作，孵化出的“数据库大赛”里用的 MiniOB 已经支持 20 多家学校的数据库实验教学实践，触达了 5000 多名的学生。今年，我们在办的第三届 OceanBase 数据库大赛，已经升级为国赛，现在已经有 200 多家高校的学生参与，这次还有海外的学生报名。
中国数据库的发展离不开人才的培养，OceanBase 在人才培养上面的投入，与我们坚持自研的决心是一脉相承的，只有更多人才投入，才有可能在数据库领域打造出世界一流的产品。
随着客户数的增加，我们出现了大量高频重复的场景以及共性需求。所以，在服务上，我们今年也做了迭代升级，推出了基于场景的服务，为此适配了更多产品。随着客户用到深水区，要的是更多高阶的咨询能力，在这个方向我们投入了更多人，但是远远不够，明年还会在这个方向继续增强。
我们的服务生态也发展得非常快，今年技术服务伙伴增长了 100%，服务生态专业交付人员增长了 151%，目前已经有快速成长的百人规模队伍帮助我们一起服务客户。为了快速培养伙伴，在商业人才的培养、认证方面，我们也下了非常多的功夫，如今，认证培训体系已经升级到 3.0 版本，而且已经推出了全英文版本，在东南亚地区已经开始伙伴培训。这中间也涌现出非常多具备很强实操能力 OBCP、OBCE 大师，他们懂 OceanBase，懂分布式，而且非常懂数据库，给我们提出了很多宝贵的建议。
六、坚持自研，持续创新硬核科技能力
OceanBase 在十年磨一剑的 0 到 1 的过程中总结了一个公式：场景✖️资金✖️时间＝核心技术，这条不可复制的成长之路给了我们这样的历史机遇，也帮助我们沉淀了核心竞争力。
在近些年从 1 到 N 的商业化、产品化的过程中我们也总结了一个公式：（自研+创新+开放）✖️长期主义=厚积薄发，跨越深水区。自研和创新本质上是在一起的，需要基于第一性原理从根本上解决问题，而不是在已有的架构上拼拼凑凑、修修补补。创新背后的根基是自研，要掌握所有核心代码，知其然知其所以然。要足够开放，持续培育生态。这一切都要持续投入足够长的时间，才能形成厚积薄发之势，跨过深水区，真正穿越周期。
这张图的背景，放了我非常敬佩的三家企业产品，他们在这几年的技术突破和产品打造上都做出了举世瞩目的成绩，我相信他们走的这条路一定也是一条厚积薄发的技术创新之路。我们相信穿越深水区的过程不会孤单，我们期望能与所有的客户、伙伴一起携手同行，破浪向前，一同跨越数字化转型深水区，真正完成核心系统的攻坚。
在接下来的日子，OceanBase 将继续坚持自研，持续创新硬核科技能力。期待与每一位同行者，一起努力为“关键业务负载”打磨越来越好的“一体化”数据库，共同助力企业跨越深水区。
