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 還很年輕，還有不少機會，不少但願。