簡介：?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還很年輕，還有很多機會，很多希望。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的OceanBase再破纪录！核心成员陈萌萌：坚持HTAP就是坚持我们做数据库的初心的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。