過去一個月裡，堪稱國產資料庫又一高光時刻。

這邊廂PingCAP剛剛釋出面向企業級核心場景、具備完整 HTAP 能力的分散式資料庫TiDB 5.0 版本；那邊廂OceanBase也緊跟著推出3.0版本，主攻方向亦是HTAP分散式資料庫，在GitHub Oceanbase標註自己為“ The leading Scalable HTAP Database” , 並且又玩了一把TPC-H打榜第一的套路（後續：其成績很快被超過）。

可能有人會質疑TPC-C和TPC-H的測試價值，畢竟這是兩個歷史悠久的測試標準，參考價值成疑。OceanBase如果能在TPC-DS上取得好成績會更有說服力。不過OceanBase自帶阿里&螞蟻光環，屬於招黑體質，一舉一動都容易引來爭議，但敢於在國際舞臺亮劍，何嘗不是國產資料庫的榮耀，所以也無須過於苛刻。

閒言少敘，PingCAP和OceanBase把HTAP這個詞徹底帶火了。5月28日宣佈開源計劃的阿里雲PolarDB也談及HTAP，連Oracle上週都發了一篇HTAP的文章。PingCAP近年來一直都是HTAP信徒，大力宣傳無可厚非；而OceanBase從傳統意義上講，大家普遍認為它聚焦在OLTP資料庫領域，為何這次也大張旗鼓的喊出HTAP口號？

箇中玄機，還得從HTAP的歷史說起。

HTAP：魚和熊掌可兼得

HTAP（Hybrid Transaction and Analytical Processing，混合事務和分析處理）就是能夠將線上事務處理(On-Line Transactional Processing，簡稱OLTP) 和線上資料分析 (On-Line Analytical Processing，簡稱OLAP) 請求在同一個資料庫系統中完成。

正所謂天下大勢，分久必合合久必分。此話放在資料庫領域一樣適用。HTAP的確不是一個很新的概念，縱觀資料庫五十餘年的發展歷程，OLTP和OLAP兩種需求在其中經歷了漫長的融合-分離-再融合的過程。

2005年，Gartner正式提出了HTAP這一概念，並且迅速引起了一些企業的關注，被視為是未來資料發展的重要趨勢之一。轉眼到了2014年，Gartner又對HTAP資料庫給出了明確的定義：即需要同時支援OLTP和OLAP場景，基於創新的計算儲存框架，在同一份資料上保證事務的同時支援實時分析，省去費時的ETL過程。

彼時，正是大資料興起之際，人們對於資料及其價值有著重新的認識與認知；另一方面，多核處理器、快閃記憶體等硬體技術的高速發展，也讓人們逐漸意識到資料庫設計是時候重新設計了，在同一資料庫處理OLTP和OLAP請求的可行性大幅提升。

所以，作為國產資料庫的兩大代表，PingCAP和OceanBase齊刷刷瞄準HTAP，的確是摸準了時代的脈搏。但今天的HTAP已經與過去大不相同，資料資源、資料消費習慣以及資料架構的顛覆性變化，既賦予了HTAP新時代的內涵，也讓HTAP承擔起更重大的責任。

HTAP因數而變

為什麼HTAP會變得如此炎手可熱？

原因始終繞不開一個“數”字。如果仔細研究Gartner關於HTAP的定義，我們會發現“同時支援OLTP和OLAP、創新計算儲存框架、去掉ETL”這幾大關鍵詞都跟“資料”密切相關，其背後是資料資源、資料消費習慣以及資料架構顛覆性的改變。

首先，資料產生方式、規模、速度與過去大不同。以行為和機器產生的非結構化/半結構化資料正在成為資料增長的主力軍，這些資料無論是資料規模、密集度、產生速度都遠超交易型的結構化資料；這也直接驅動著HTAP場景在未來會更加豐富化。

其次，實時性的資料消費正在成為新常態，資料消費的人群規模、場景豐富程度迅速增加，無論是最終消費者，還是企業員工都有資料消費需求，驅動著OLTP場景與OLAP場景互相滲透，彼此之間的界限變得模糊。

例如，一個快消品的調研員，會透過手持終端裝置隨時隨地瞭解產品銷售情況和預測銷售趨勢，進而根據資料做出相應決策；一個基金經理往往需要隨時根據客戶資產淨值、交易頻次變化、金融產品銷售情況等一系列資料服務，來有針對性進行營銷決策……而這些決定常常需要幾分鐘甚至幾秒鐘內完成，實時性需求成為新一代HTAP的剛需。

過去，OLTP場景僅僅負責產生資料，資料往往需要搬運到資料倉儲或者機器學習平臺進行資料消費，資料消費人群也僅僅是資料倉儲管理員、決策層等少數人群；現在，在資料驅動型場景大幅增加的加持下，人人都是隨時隨地的資料消費者，極大推動OLTP場景與OLAP場景的融合。

第三，資料驅動型場景的井噴式出現，讓計算與資料兩個角色出現變化，過去一直都是以計算為核心，而資料驅動型場景則是以資料為核心，核心角色的轉變意味著資料架構將發生徹底改變。

所以這就涉及到一個核心問題：即在OLTP場景和OLAP場景加速融合的趨勢下，在架構層到底是Move Data還是Move Code。過去，OLTP場景產生資料之後，往往需要透過ETL將資料匯入到資料倉儲，然後在資料倉儲中建模、ODS、建立報表，如果涉及到需要應用到機器學習，還需要將資料匯入到機器學習平臺，資料移動次數已經足夠頻繁。現在，OLTP場景和OLAP場景加速融合，BI呈現和AI操作服務實時化，資料互相移動將更加頻繁，這無疑對於資料架構帶來極大挑戰。

關於資料移動，AWS有一個經典的描述：AWS認為隨著資料量的不斷增加，資料的往來移動操作變得越來越困難，稱之為“資料重力”現象。要想解決“資料重力”現象，AWS的做法類似Move Data，針對每個場景有專用資料庫，並且整合Athena、Glue等工具集，讓ETL等移動操作更加整合化、自動化和高效化。這種模式比較適合大型網際網路企業，擁有比較強大的技術團隊。

另一種則是Move Code，透過HTAP這種融合的資料平臺，在一份資料上同時支撐業務系統執行並實現OLAP 場景，縮短資料移動路徑，讓資料不再搬家，就地實現OLTP場景和OLAP場景的融合。這個更符合大多數企業，尤其是企業數字化轉型的需求。

本質上，HTAP的做法更具變革性，打破了OLTP場景和OLAP場景之間過去傳統的分界線，大幅提升大資料體系下資料實時處理和分析計算能力；另一方面，透過分散式架構，也徹底解決了過去困擾傳統資料庫、資料倉儲多年的效能、擴充套件性，實時性等難題。

但HTAP雖好，但實現起來卻沒有那麼簡單。這裡不能不提PingCAP，其在HTAP上的戰略佈局顯然更快人一步，隨著TiDB 5.0的釋出，也標誌著國產資料庫廠商在HTAP領域佔領先機。

都是HTAP，哪些趨勢不能忽視

事實上，不光是PingCAP和OceanBase在搞HTAP，Oracle、GreenPlum這些傳統資料庫時代的大咖也在聚焦HTAP。

都是HTAP，哪些才是真正代表著HTAP的趨勢呢？

其一，產品架構上需要對未來做好準備，HTAP本質上已經開始逐漸演變成一體化資料服務平臺，其多元化場景決定了絕非是OLTP和OLAP簡單疊加，如果透過OLTP架構外擴實現OLAP，顯然只能算權宜之計，不能代表面向未來的架構。使用者在分散式資料庫和大資料技術的融合也產生了廣泛意義的HTAP的需求，長遠來看，HTAP會成為數字化時代一種普遍性的需求。

以PingCAP為例，其TiDB 4.0就是一款為HTAP而設計的分散式資料庫，到了5.0版本，在TiFlash引入MPP模式與多項企業級特性的增加，使得TiDB 5.0發展為“一棧式資料服務平臺”。

其二，開源生態決定基礎，資料庫作為重要的基礎軟體，HTAP資料庫未來需要在成百上千的場景中打磨，過去那種封閉模式不管是技術迭代還是使用者增長都是舉步維艱，走向開放開源的生態之路已經是大勢所趨。比如，TiDB5.0釋出會“TiDB+FIink”的混合架構突破了狹義HTAP的範圍，開啟了“分散式資料+大資料技術棧”的HTAP生態模式。

未來，將開源戰略作為核心戰略、構建高度活躍的開源社群將會是HTAP資料庫的長遠目標。

其三，擁抱雲是未來，需要支援雲原生架構，充分利用雲原生技術輕量化、松耦合、靈活度高等優勢，另外還實現跨雲與多雲部署。

同樣，TiDB 5.0在這方面也做出了榜樣，基於雲原生架構的TiDB 5.0能夠充分發揮雲資源的能力，PingCAP在海外市場推出了TiDB Cloud服務，堅定擁抱雲路線。國內也有很多客戶在雲原生架構中採用TiDB構建雲原生技術棧。

HTAP將是新藍海

既然HTAP如此火熱，那麼它會取代以Oracle為代表的關係型資料庫或者傳統資料倉儲麼？

在筆者看來，HTAP雖然不是一個很新的概念，卻是一個新的藍海市場，它代表著資料驅動型場景井噴之後，使用者在資料處理、消費整個需求的迭代升級，HTAP的興起意味著一個新的資料庫藍海市場正在逐步形成。

因此，單純的談論HTAP點對點的取代關係型資料庫或者傳統資料倉儲其實並無太大意義，HTAP也不應該成為國產化替代的一個“藉口”，它更像一條新的資料庫賽道，給予了像PingCAP、OceanBase這些後起之秀更多市場機會，讓它們看到了抓住新需求的機遇，以及打破資料庫市場壟斷局面的希望。

從更大的範圍來看，新一代HTAP，正在成為分散式資料庫與大資料棧融合的明珠，我們甚至可以預見，未來的HTAP不再是資料庫的一個技術術語，而是成為一種以融合簡化方式構建資料棧的一種方式。

總體來看，HTAP現在很火，市場既有像PingCAP這樣具有前瞻性的新銳資料庫創新企業，也有OceanBase這種自帶光環的明星資料庫公司，還有Oracle這樣的大鱷，未來競爭必然會愈發激烈。對於中國資料庫廠商而言，路很長、未來很遠，砥礪前行，且行且珍惜。