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

寫在前面的話

​

2021年5月20日，據國際事務處理性能委員會（TPC，Transaction Processing Performance Council）官網披露，螞蟻集團自主研發的分布式關系型資料庫OceanBase在資料分析型基準測試（TPC-H）中，以1526萬QphH的性能總分創造了新的世界紀錄。

同時，OceanBase 也成為唯一在事務處理和資料分析兩個領域測試中都獲得過世界第一的中國自研資料庫。

我們特别邀請到 OceanBase 負責此次測試的核心成員陳萌萌撰文，講述背後的技術思考。

以下為陳萌萌的自述

收到期盼了好幾天的審計員最終郵件，告知測試結果已經挂到了官方網站。這意味着，測試小組的工作可以正式告一段落。接下來的60天，此次測試的報告将處于公示階段，迎接全世界資料庫專家的檢視和挑戰。

對我個人來說，原本期待的興奮感沒有如期而至。更多的是平靜。平靜地把官網上的測試報告又從頭到尾讀了一遍。按說，前前後後來來回回幾十封郵件的技術溝通，報告裡面的内容已經爛熟。再讀一次，既是出于技術人天生的謹慎，更是不想因為一個低級錯誤而讓項目所有同學三個月的心血付諸東流。

關于為什麼要沖擊此次的榜單？簡單來說，是因為今天的 OceanBase 已經更新為一款支援 HTAP 混合負載的企業級分布式資料庫，同時具備事務處理和資料分析兩類場景的處理能力。我們希望市場對我們有更多了解。權威中立機構的背書總好過“王婆賣瓜自賣自誇”。此外，從技術上說，這也是一件水到渠成的事情。隻是，這個時間點跟 OceanBase 對資料庫的了解，以及未來想做的事情有密切關系。

01

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，我想也是順應了整個技術的大趨勢。

02

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 的價值。

03

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資料庫，至少要能夠比較好的解決上面提到的三個方面的挑戰。

04

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