OceanBase再破紀錄！核心成員陳萌萌：堅持HTAP就是堅持我們做資料庫的初心

寫在前面的話

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

2021阿里雲峰會暨開發者大會