TiDB、OceanBase都在談的HTAP，為何如此燚？_風聞

過去一個月裏，堪稱國產數據庫又一高光時刻。

這邊廂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這樣的大鱷，未來競爭必然會愈發激烈。對於中國數據庫廠商而言，路很長、未來很遠，砥礪前行，且行且珍惜。