简介： 2021年5月20日，据国际事务处理性能委员会（TPC，Transaction Processing Performance Council）官网披露，蚂蚁集团自主研发的分布式关系型数据库OceanBase在数据分析型基准测试（TPC-H）中，以1526万QphH的性能总分创造了新的世界纪录。同时，OceanBase也成为唯一在事务处理和数据分析两个领域测试中都获得过世界第一的中国自研数据库。
作者 | 陈萌萌
来源 | 阿里技术公众号
写在前面的话
2021年5月20日，据国际事务处理性能委员会（TPC，Transaction Processing Performance Council）官网披露，蚂蚁集团自主研发的分布式关系型数据库OceanBase在数据分析型基准测试（TPC-H）中，以1526万QphH的性能总分创造了新的世界纪录。
同时，OceanBase也成为唯一在事务处理和数据分析两个领域测试中都获得过世界第一的中国自研数据库。
我们特别邀请到OceanBase负责此次测试的核心成员陈萌萌撰文，讲述背后的技术思考。
以下为陈萌萌的自述。
收到期盼了好几天的审计员最终邮件，告知测试结果已经挂到了官方网站。这意味着，测试小组的工作可以正式告一段落。接下来的60天，此次测试的报告将处于公示阶段，迎接全世界数据库专家的检视和挑战。
对我个人来说，原本期待的兴奋感没有如期而至。更多的是平静。平静地把官网上的测试报告又从头到尾读了一遍。按说，前前后后来来回回几十封邮件的技术沟通，报告里面的内容已经烂熟。再读一次，既是出于技术人天生的谨慎，更是不想因为一个低级错误而让项目所有同学三个月的心血付诸东流。
关于为什么要冲击此次的榜单？简单来说，是因为今天的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成绩出来以后，身边的很多朋友都想了解未来OceanBase会成为一款什么样的数据库产品？对这个问题，我有几点想法想和同行、客户分享。
首先，一个既能处理TP又能处理AP的数据库系统，可以大大简化系统的复杂性，是有不可否认的客户价值的，这点是HTAP产品的立足之本，也是我们做产品的初心。
因此，一个HTAP系统如果本身的处理能力不足或者使用起来很复杂，也是不能满足用户期待的，OB过去两年一直在尝试降低用户的使用成本，就是希望不管是大型客户还是中小型客户，是金融客户还是非金融客户，都能用的起，用的简单，甚至用的爽，这个方向很关键，未来也会继续坚持下去。
其次，每款HTAP产品都有自己的定位。OceanBase起步于企业核心场景的分布式数据库，TP场景的处理能力将永远是OceanBase坚持的底线和优化方向。换句话说，我们不会以牺牲TP场景的能力为手段，提升AP场景的处理能力，这和很多以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.
说到底，HTAP架构是希望通过打破TP和AP的边界，最终带给客户实实在在的商业价值。对于OceanBase这样一款数据库产品，选择HTAP这样的技术方向意味着要克服更多困难。路还很长，好在11岁的OceanBase还很年轻，还有很多机会，很多希望。
本文为阿里云原创内容，未经允许不得转载。