蚂蚁自研数据库OceanBase登顶TPC-H榜单，核心成员撰文讲述背后思考
蚂蚁自研数据库OceanBase登顶TPC-H榜单，核心成员撰文讲述背后思考
曾经一度濒临解散的 OceanBase 团队（专注分布式关系数据库），在 5 月 20 日这天再次迎来了自己的高光时刻：
国际事务处理性能委员会（TPC，Transaction Processing Performance Council）官网发布最新的数据分析型基准测试（TPC-H）榜单，其中，蚂蚁集团自主研发的分布式关系数据库 OceanBase 以 1526 万 QphH 的性能总分排名 30000GB 第一。
这是中国自研数据库的一次里程碑。
这意味着，OceanBase 成为唯一在事务处理和数据分析两个领域测试中都获得第一的中国自研数据库。
雷锋网注意到，去年的 5 月 20 日 OceanBase 同样破了一个记录：性能分数首次突破亿级大关达到 7.07 亿 tpmC，相比 2019 年提升近 11 倍。（雷锋网注：tpmC 值在国内外被广泛用于衡量计算机系统的事务处理能力，为"每分钟内系统处理的新订单个数"的英文缩写） 这一事件标志着 OceanBase 在当时成为全球最快数据库，实现了数据库这一基础技术的革命性突破，也是自研技术对世界 IT 技术作出的重要贡献。
一直以来，数据库与芯片、操作系统并列为全球技术三大件，也是企业 IT 系统必不可少的核心技术。OceanBase 由蚂蚁集团自主研发，历经阿里巴巴和蚂蚁集团大规模业务场景的长时间考验。
“OceanBase 是典型的‘用出来’的数据库，经过十余年不同场景的严苛打磨。” OceanBase 公司 CEO 杨冰表示，“原生分布式的 OceanBase 具有无单点瓶颈，可线性、在线扩展和收缩等特性，可以更好地解决业务扩展性难题，帮助机构快速实现数字化转型。”
数据分析型基准测试（TPC-H）自 2006 年公布以来很快被业界认可，是公认的衡量数据库数据分析能力的权威标准之一。TPC 官网显示，在数据分析型基准测试榜单的 30000GB 结果一栏，OceanBase 占据性能排行首位，其中代表着数据库核心性能的每小时执行请求数综合指标达到了 1526 万 QphH@30,000GB, 比第二名微软 SQLServer 的成绩高出 10 多倍。
此前，蚂蚁 OceanBase 在 2019 年和 2020 年均参与了事务处理型基准测试（TPC-C），并两度登顶。
很多人会好奇，OceanBase 不是拿过事务处理型基准测试（TPC-C）第一了么，为什么还要打 TPC-H 这样一个 AP 场景的榜单？
OceanBase 负责此次测试的核心成员陈萌萌撰文，讲述了背后的技术思考。以下 enjoy：
收到期盼了好几天的审计员最终邮件，告知测试结果已经挂到了官方网站。这意味着，测试小组的工作可以正式告一段落。接下来的 60 天，此次测试的报告将处于公示阶段，迎接全世界数据库专家的检视和挑战。
OceanBase TPC-H 项目组
对我个人来说，原本期待的兴奋感没有如期而至。更多的是平静。平静地把官网上的测试报告又从头到尾读了一遍。按说，前前后后来来回回几十封邮件的技术沟通，报告里面的内容已经烂熟。再读一次，既是出于技术人天生的谨慎，更是不想因为一个低级错误而让项目所有同学三个月的心血付诸东流。
关于为什么要冲击此次的榜单？简单来说，是因为今天的 OceanBase 已经升级为一款支持 HTAP 混合负载的企业级分布式数据库，同时具备事务处理和数据分析两类场景的处理能力。我们希望市场对我们有更多了解。权威中立机构的背书总好过“王婆卖瓜自卖自夸”。此外，从技术上说，这也是一件水到渠成的事情。只是，这个时间点跟 OceanBase 对数据库的理解，以及未来想做的事情有密切关系。
一、HTAP ，既是数据库的初心，也是数据库的未来
HTAP 数据库（Hybrid Transaction and Analytical Processing，混合事务和分析处理）就是能够将事务处理(On-Line Transactional Processing，以下简称 TP) 和数据分析 (On-Line Analytical Processing，以下简称 AP) 请求在同一个数据库系统中完成。
这个概念，由 Gartner 在 2014 年的一份报告中提出。分析师认为，这种架构具有显而易见的优势：不但避免了繁琐且昂贵的 ETL 操作，而且可以更快地对最新数据进行分析。这种快速分析数据的能力将成为未来企业的核心竞争力之一。
关系型数据库的英文缩写是 RDBMS，其中的M就是“管理”的意思，不管是 TP 还是 AP，数据库的存在就是为了“管理”数据，我认为这是数据库这个系统的初心。
天下大事，分久必合，合久必分。HTAP 本来也不能算是新概念。TP 和 AP 这两种需求在数据库的发展上已经历了漫长的混合-分离-再融合过程。
上世纪 70 年代末到 90 年代初是数据库从理论到实践逐渐成熟的黄金时代。1970 年，IBM 的E. F. Codd 提出了“关系型数据库”的概念。1974 年，IBM 着手研发 System R 数据库，极大地推动了关系型数据库概念的发展，并采用 SQL 作为标准的数据库语言。
70 年代末到 80 年代初，有“数据库先生”之称的图灵奖获得者 Jim Gray 奠定了事务处理的理论基础。同一时期，System R 系统的实现也催生了查询优化技术。Selinger 等人发表的“Access Path Selection in a Relational Database Management System”论文则被认为是基于代价的查询优化技术的开山之作。1988 年，IBM 的 Barry Devlin 和 Paul Murphy 提出了专门用来做数据分析的“数据仓库”（以下简称“数仓”）概念。1993 年，E. F. Codd 仿照“On-line Transaction Processing”的结构首次提出了“On-line Analytical Processing”的概念，一下子把数据分析的抽象和应用提升到了一个新的层面。可以说，在数据库远古大神一个个粉墨登场的年代，TP 和 AP 两种场景就像一对被他们细心呵护的孪生兄弟茁壮地成长着。
随着数据库使用场景的日益丰富，TP 和 AP 需求的矛盾逐渐显露。单机数据库的处理能力毕竟有限，分布式数据库的理论开始出现，工程实践也遇到很多问题。
怎么同时处理 TP 和 AP 请求？1988 年提出的“数仓”概念，背后隐藏的假设是 TP 和 AP 请求会放在不同的系统中处理。这样假设有业务发展和应用架构的必然性，但技术层面的限制也是不可回避的问题。毕竟在那个时代，作为分布式数据库系统的 Teradata，最大只能支持 1000 个核和 5TB 存储。而且，真正能够使用这样高端系统的用户寥寥无几。
当用户开始被迫地把 TP 或者是 AP 的请求分成不同系统时，专门处理 TP 和 AP 场景的数据库随之出现。针对不同场景，采用不同引擎技术，比如按行存储或是按列存储，确实能够大幅度提高特定场景下的数据库性能。
但不可否认，一个能同时处理 TP 和 AP 请求的数据库，对于用户来说是非常有价值的，除了能大幅度降低用户成本外，还能明显降低用户系统的复杂性和运维成本。
因此，很多成熟的商业数据库，如 Oracle、IBM DB2 等，在保持极强的 TP 处理能力之外，从来没有停止过对 AP 场景的支持和优化。如果大家看一下这些数据库巨头在顶级学术会议上发表的论文列表就会发现，面向 AP 场景的论文，数量甚至比事务处理方向的还多，而且每年都有更新。
2010 年前后，随着硬件能力越来越强，尤其是 SSD 固态盘、大容量内存和多核 CPU 等技术的普及，大大增加了数据库的设计可能，促使不少数据库研究人员重新思考在同一个数据库中处理 TP 和 AP 请求的可能，甚至包括当初缔造“数仓”概念的 Barry Devlin 都提出，应该“重新考虑将 TP 和 AP 分开这一设计理念”。今天，不少新的数据库也开始宣称支持 HTAP，我想也是顺应了整个技术的大趋势。
二、OceanBase 把 HTAP 写入基因
OceanBase 是 2010 年开始在阿里集团内部自主研发的分布式数据库。最开始基本就是在阿里、蚂蚁内部用，真正长得像一个数据库的样子，应该是从 2014 年启动 OceanBase 1.0 版本开始的。我也是在那个时候加入 OceanBase，跟着团队一步步走到了今天。
回想当初，数据库的很多技术都在悄悄发生着变化。一方面，以 Oracle 为首的传统数据库在 TP 场景似乎已经“独孤求败“，TPC-C 世界纪录已经多年未被打破，而像 OceanBase 这样的分布式数据库还没有看到挑战 Oracle 霸主地位的可能。
另外一方面，传统数据库的 AP 能力越来越跟不上数据规模和硬件的发展。SSD、大容量内存、超高核数的 CPU，这些理论上能带来巨大性能提升的硬件无一不在挑战传统的数据库软件设计。TPC-H 榜单上，Oracle、SQL Server 这种传统数据库被神秘的数据库厂商 Exasol 虐的找不着北。Exasol 具体怎么实现的我不是特别清楚，但向量化引擎、cache-aware、列存、及时编译（Just-in-Time compilation），大致总离不开这几个方向。但传统数据库不是这么设计的，内存能大到几百 GB 甚至上 TB？最初的数据库设计者想都不敢想，更别提充分利用了，“守着金山要饭吃”，当时的传统数据库看到硬件的发展就是这么一种感觉吧。
当时的我也在思考这个问题：一个能同时处理好 TP 和 AP 请求、并且能充分挖掘硬件能力的数据库到底应该是什么样的？“缝缝补补带不来真正的技术革新”。在一个现成的开源组件去打补丁，或者简单重构很难做出一个划时代的产品，因为我自己曾在一个面向 AP 的开源引擎上尝试过这件事儿，干到后面觉得比重写一个引擎难多了。2014 年 OceanBase 1.0 版本正在酝酿中，对我来说，做一个真正 HTAP 引擎的机会来了。
从时间上看，AP 场景的几项关键技术是随着产品丰富逐步完善起来的。2014 年做了基于代价的查询优化器。2016 年做了分布式运行一体化执行。2019 年和 2020 年分别做了向量化执行引擎和 TP、AP 的资源隔离。事实上，这些年，OceanBase 的 AP 能力一直在不断增强，只不过大家很少有机会了解。
如果知道这些来龙去脉，大家对 OceanBase 冲击 TPC-H 这件事儿，也许就没那么奇怪了。今天我们的用户场景和产品定位也都需要产品具备这样的能力，从这个角度上讲，OceanBase 正式进入到 HTAP 产品时代，也是市场的选择。
从 2017 年开始，我每年都会投入相当比例的时间拜访外部客户。在这个过程中，深刻感受到，对于 HTAP，不同客户有不一样的认知。
其中一部分用户使用的是典型的 TP、AP 独立架构。这类用户以互联网公司居多，受目前流行的解决方案影响。系统设计之初就将 TP 和 AP 系统分开，通过中间链路同步数据。这类用户一般有两个痛点，一个是实时性要求高的分析逻辑无法在 TP 数据库中原地完成，只能等数据同步到 AP 数据库中再做。另外就是系统难以运维，尤其是中小型的客户，运维人员得熟悉两套系统，还要时刻关注中间数据链路的稳定性，技术门槛很高。
另外一部分用户，一直使用的是像 Oracle 这样的传统的数据库，对于 TP 和 AP 的边界认知比较模糊，尤其是 Oracle 的处理能力很强，很多复杂查询扔到 Oracle 里面也能跑。在一次某大型客户的业务上线过程中，压测的最后阶段，我们发现了非常多的复杂查询。当我们询问客户为什么他们的 TP 系统中会有如此多 AP 请求时，客户的一句话把我们问懵了——“啥叫 TP、AP 请求？”我们在内部也有过讨论，发现即使是团队内部大家的看法也是不一样的。只能说有一些场景偏 TP 类型或者偏 AP 类型，但很难给出绝对答案。
越来越多的客户案例让我意识到，过去一直坚持的 HTAP 技术方向也是很多客户需要的。但今天在很多客户眼中，OceanBase 就是只支持 TP 处理的数据库，完全没想到我们还有很强的 AP 处理能力。“酒香也怕巷子深”，我们觉得这个时候打榜 TPC-H，既能让产品的能力进一步提高，大家也能更了解 OceanBase 的价值。
三、TPC-H 新世界纪录背后的“三座大山”
如果让 2014 年的我说 OceanBase 什么时候能够在 TPC-C、TPC-H 这样的榜单上露个脸，我还真不知道。
做数据库就像盖房子，今天 OceanBase 这座房子已经到了交付阶段，要给客户的体验是“拎包入住”，因此水、电、装修风格都要做好。而 2014 年就像在“打地基”的阶段，你说我将来要做某某内饰风格，至少当时没有想到那么具体的事情，但是我知道分布式一定是这个房子的“地基”，我们要盖的是一个摩天大楼，而不是一个独门小院。这个是打破传统数据库设计限制的前提，想通了这个事儿，后面的技术落地就比较自然了。
为什么分布式数据库是 HTAP 技术的未来？这个和 HTAP 的几大技术挑战有关。
首先，也是最重要的事情，这个系统的容量一定要足够大，扩展性足够强。
从数据容量上看，因为 AP 本身的分析要有价值，就需要聚集相当量的数据才有价值，这是以前的单机数据库做不到的。一台机器的容量，或者是几台机器的容量永远是受限的。十年前，世界上最大的 Oracle RAC 实际系统只有 20 来个节点。当时我在 Oracle 经历的一个重要项目是，将 RAC 的集群规模扩展到 128 台。而今天像 OceanBase 这样一个分布式数据库，做到几百台机器的集群规模是非常轻松的，这种规模上的区别带来技术上的想象空间是完全不同的。
而且在这次测试面向 AP 的场景中，又引入了一个 OceanBase 家族的新成员叫 OceanBase File System（简称 OFS）。这是一个分布式的共享存储系统，基于 OFS 的方案在存储容量上几乎是可以无限扩展，永远不用担心数据没地方存。这就解决了整个系统容量的扩展的问题。
另外，既然要将 TP 和 AP 放到同一个集群中处理，那么集群的处理能力也要有非常强的可扩展性。这里如果再讲多一些，处理能力的扩展性还能分为“水平”扩展和“垂直”扩展两个维度。
大家看过我们 TPC-C 的测试结果可能还有印象。当时，是用了 1554 台机器，把整个 TP 系统跑这么高的分数。这个体现的是 OceanBase 的水平扩展能力。
什么叫垂直扩展性呢？就是在一台机器内部通过硬件扩展（更多 CPU 核数、更大内存）而提升性能。为什么这个在 HTAP 下仍然有挑战？因为在 TPC-C 的扩展里面，更强调的是水平扩展，换句话说，数据库集群规模越大，性能分数就越高。但在 AP 场景下，用户同时也会关心能不能实现垂直扩展，比如说能不能让一个系统的几千个 CPU 核，几十台机器同时为一个查询服务。万事万物，只要涉及到“协同“，就有成本。把协同的成本降低到最低，考验的是系统整体的设计。
TPC-H 测试场景中，要求我们用 64 台机器的 5120 个 CPU 超线程，同时去服务每一个用户请求，把本来需要几十分钟才能完成的请求，在几秒内处理掉，这里涉及的 CPU 核数和整体性能数值都是整个 TPC-H 结果中最高的。
第二个方面是一个真正的 HTAP 系统需要在 TP 场景和 AP 场景都有很强的处理能力。
OceanBase 的 TP 处理能力在 TPC-C 打榜过程中已经得到了验证，背后的技术也有相关文章详细解读，这里不再赘述。那 AP 场景到底要求的是什么能力？
首先来说是查询优化的能力。AP 场景天然有很多复杂的用户查询，具体到 SQL 语句上就是大量的多表连接、复杂的表达式计算、多层嵌套的子查询、聚合函数等等，这些对引擎的查询优化能力要求门槛极高。
记得曾经一个同行半开玩笑的说，很多专注 TP 的数据库系统不是不想做 HTAP，只是“没有时间好好写一个查询优化器”。OceanBase 的 1.0 版本，重点重构了整个优化器的架构，引入了几十种逻辑改写和基于代价的计划选择，没有这个基础，我们不可能跑出今天 TPC-H 的这个性能。
其次，执行引擎的设计要求与 TP 天然不同，AP 系统要访问大量的数据，迭代数据的效率极为关键。这个领域也是近十年来数据库研究的重点，从“火山”模型到“数据流”模型、从“拉”数据到“推”数据、cache-aware、即时编译（Just-in-time compilation），各种技术令人眼花缭乱。
OceanBase 的最新 3.0 版本引擎与之前的最大不同在于引入了新的 cache-aware 向量化处理，在大数据量场景下有数倍的性能提升。当然，我们还要清醒的看到，OceanBase 的引擎性能距离很多优秀产品还有明显的差距，这个方向的工作才刚起步。
第三个挑战，在于 HTAP 里面的H，Hybrid，混合。AP 和 TP 是技术要求上天然不同的两类请求，典型的 TP 的场景是简单请求、小数据量、高并发，关注重点在系统的吞吐量。
而 AP 场景则是复杂查询居多，运行时间长，更多关注响应延迟。这就像是田径项目中的短跑和长跑，对运动员肌肉类型、反应速度、耐力都有不一样的要求。一个好的 HTAP 系统，能在一个系统里把很多 TP、AP 的请求同时解决掉，就相当于在培养一个运动员，既能跑一百米的短跑，又能跑一万米或者是马拉松。好比博尔特，100 米短跑的王者，但今天还要博尔特跑进一万米的世界决赛，难度可想而知。
因此，考验一个 HTAP 系统，往往不是一个单一的维度，而是看如何在去做技术的妥协，这个是考验我们整个技术的能力。OceanBase 今天已经应用在很多 TP 为主的核心场景，我希望做到的是 AP 能力的尽量能的延伸，我们今天在 TPC-H 测试中做了很多优化，但我们在 TP 场景的性能并没有出现回退。
另外，一旦将 TP 和 AP 的请求放在了同一个系统，意味着系统对于不同请求的资源使用要非常“合理”并且尽量互不影响。困扰数据库开发人员的一个难题是，当 TP 和 AP 请求混布时，两者之间的互相影响很难被“隔离”，今天“隔离”问题仍然是影响用户选择 HTAP 系统的一个重要挑战，我们将不同的资源在内部进行了虚拟化，并通过资源组的概念将 TP、AP 请求进行隔离，一定程度上解决了这个问题，但 HTAP 如何彻底的解决这些问题，还有很多有待探索的空间。
类似的问题还有很多，限于篇幅，只能先说这么多。但我认为任何一个真正的 HTAP 数据库，至少要能够比较好的解决上面提到的三个方面的挑战。
四、HTAP 的边界在哪里？未来 OceanBase 的方向在哪里？
过去大家提到 OceanBase，第一反应就是一个典型的 TP 处理系统，具有很强的高可用和线性扩展的能力。TPC-H 打榜成绩以后，身边的很多朋友都问过我这样一些问题：
作为一款 HTAP 数据库产品，OceanBase 未来有哪些是无法支持的？
OceanBase 会不会主张 One size fits all？
OceanBase 会不会走自己的路，让别人无路可走？
换句话说，HTAP 的产品边界到底在哪里？说实话，我对这个问题没有直接的答案。
但有几点想法想和同行、客户分享。
首先，一个既能处理 TP 又能处理 AP 的数据库系统，可以大大简化系统的复杂性，是有不可否认的客户价值的，这点是 HTAP 产品的立足之本，也是我们做产品的初心。
因此，一个 HTAP 系统如果本身的处理能力不足或者使用起来很复杂，也是不能满足用户期待的，OB 过去两年一直在尝试降低用户的使用成本，就是希望不管是大型客户还是中小型客户，是金融客户还是非金融客户，都能用的起，用的简单，甚至用的爽，这个方向很关键，未来也会继续坚持下去。
其次，每款 HTAP 产品都有自己的定位。尽管 OceanBase 拿到了还不错的 TPC-H 的成绩，但我们的 AP 处理能力距离世界顶级数据库还有不小的差距，未来还需要继续努力。
刚才也提到了，OceanBase 起步于企业核心场景的分布式数据库，TP 场景的处理能力将永远是 OceanBase 坚持的底线和优化方向。换句话说，我们不会以牺牲 TP 场景的能力为手段，提升 AP 场景的处理能力，这和很多以 AP 为核心场景的产品定位会有所不同。
最后，HTAP 数据库只能在技术层面解决 TP 和 AP 场景混合的问题，但 HTAP 的技术不能完全替代独立数据分析系统，比如当数据的源头来自于很多独立数据库系统甚至各种各样的日志、传感器等数据源时。
就像 Gartner 提到的，Hybrid Transaction/Analytical Processing (HTAP) is an emerging application architecture that breaks the wall between transaction processing and analytics. It enables more informed and in business real time decision making。说白了，这是一种架构选择，而只有给客户带来实实在在的商业价值，这个架构才算是真的成功。
对于 OceanBase 这样一款数据库产品，选择 HTAP 这样的技术方向意味着要克服更多困难。路还很长，好在 11 岁的 OceanBase 还很年轻，还有很多机会，很多希望。
来自: 雷锋网