曾經一度瀕臨解散的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的EF 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年，EF Codd仿照“On-line Transaction Processing”的結構首次提出了“On-line Analytical Processing”的概念，一下子把數據分析的抽象和應用提升到了一個新的層面。可以說，在數據庫遠古大神一個個粉墨登場的年代，TP和AP兩種場景就像一對被他們細心呵護的孿生兄弟茁壯地成長著。

隨著數據庫使用場景的日益豐富，TP和AP需求的矛盾逐漸顯露。單機數據庫的處理能力畢竟有限，分佈式數據庫的理論開始出現，工程實踐也遇到很多問題。

怎麼同時處理TP和AP請求？1988年提出的“數倉”概念，背後隱藏的假設是TP和AP請求會放在不同的系統中處理。這樣假設有業務發展和應用架構的必然性，但技術層面的限制也是不可迴避的問題。畢竟在那個時代，作為分佈式數據庫系統的Ter ADATA，最大隻能支持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還很年輕，還有很多機會，很多希望。