真正的HTAP對使用者和開發者意味著什麼？

簡介： Gartner 2016 年首次提出 HTAP(Hybrid Transaction / Analytical Processing，混合事務分析處理)並給出明確的定義：即同時支援 OLTP 和 OLAP 場景，需要創新的計算儲存框架，在一份資料上保證事務的同時支援實時分析，省去費時的 ETL 過程。在我看來，HTAP 代表了一種技術理想，但是落地的時候難免會遇到各種問題，包括：

從使用者角度談 HTAP 

資料庫的全稱是 DBMS(Database Management System)，早期是不區分 OLTP 與 OLAP 的，E.F.Codd 在 1970 年就提出了關係模型，Jim Gray 在 1976 年提出了事務模型。隨著資料庫的應用場景越來越豐富，單一資料庫的處理能力瓶頸越來越明顯，於是有人把複雜分析從資料庫中單獨拆分出來，Berry Devlin 和 Paul Murphy 在 1988 年提出了資料倉儲，1993 年 E.F.Codd 提出 OLAP，明確把 OLAP 與 OLTP 區分開來，並附帶 OLAP 的 12 條準則。OLAP 發展到今天有各種做法，包括我們常常聽到的 ROLAP(基於 MPP 架構的關聯式資料庫之上的 OLAP)、MOLAP(基於 Data Cube 的方案)、大資料(基於 Hadoop/Spark 的大規模分析方案)等等。

經典資料庫把業務分成 OLTP 和 OLAP，並透過 ETL 定期將資料從 OLTP 資料庫抽取到 OLAP 資料庫，這也是資料倉儲 T+1，T+n 的由來。這種方式帶來了兩個問題：一個是延遲、一個是複雜度，在實際生產系統中經常出現資料同步延遲或者同步出錯導致的線上故障。那麼，一種很自然的想法就是基於同一份資料同時做好事務處理和實時分析，從而讓應用變得簡單。

一種方式是在 OLTP 資料庫的基礎上擴充套件 OLAP 的能力，典型的代表是 Oracle 和 SQL Server。相比 MySQL 這種純粹用於 KV 類簡單查詢的 OLTP 系統，Oracle 和 SQL Server 一方面能夠處理複雜查詢，另外，透過 Oracle IMC(In-memory column store)和 SQL Server 列存/列索引等技術能夠很好地處理 OLAP。這種型別的混合負載叫做"real-time operational analytics"，先有 OLTP，再有 OLAP，且 OLTP 效能做到極致，這也是我認為的真正的 HTAP。OceanBase 採用的也是這種做法，不同點在於 OceanBase 的底層是原生分散式架構，相比 Oracle/SQL Server，能夠處理更大的資料量。

另外一種方式是在 OLAP 資料庫的基礎上引入實時寫入能力，典型的代表是一些專門用於實時 OLAP 的 MPP 資料庫。國內很多創業公司走的是這條路，這種型別的混合負載本質上是"real-time analytics"，往往是在資料倉儲的基礎上引入實時寫入，成為一個實時資料倉儲，但由於 OLTP 涉及核心業務門檻太高，不支援完整的事務處理能力，例如不支援跨伺服器強一致性，不支援大事務/長事務，不支援觸發器/外來鍵/約束，等等。

真正的 HTAP(real-time operational analytics)要求先有高效能的 OLTP，且能夠很好地支援實時分析。這種型別的 HTAP 系統天然具備實時數倉(real-time analytics)的能力，這也是為什麼 Oracle Exadata、SQL Server MPP 架構被廣泛用於實時數倉場景的原因。需要注意的是，雖然真正的 HTAP 系統能夠同時做 OLTP 和 OLAP，但由於工程複雜度和產品成熟度的原因，真正的 HTAP 系統也不可能在所有場景都具備優勢。例如，純粹的離線資料倉儲，專門的 OLAP 系統會比 HTAP 系統做得更好。

HTAP 的典型優勢場景包括：

1) 企業級混合負載。MySQL 這樣的開源資料庫只能處理簡單查詢，如果涉及到複雜查詢，往往是透過使用者修改業務的方式來繞過。經典的企業級工作負載一般都是混合負載，既有簡單的 Key-Value 查詢，也有更加複雜的跑批作業，甚至是實時分析出報表，需要用到大事務/長事務，以及觸發器、外來鍵、約束等嚴格資料校驗功能，例如企業 ERP 系統。

2) 實時資料中臺。很多場景會使用 MySQL 分庫分表，並將所有 MySQL 分庫的資料同步到一個專門的匯聚庫做實時分析。具備分散式能力的 HTAP 系統能夠同時接管 MySQL 交易庫和匯聚庫的工作負載。

3) 線上歷史資料統一處理。DBA 做資料庫規劃的時候往往會區分線上庫和歷史庫，透過線上庫做交易，定期將線上庫的冷資料遷移到歷史庫。HTAP 系統能夠將線上資料和歷史資料統一成一份資料，支援更加靈活的查詢方式，降低業務複雜度。

4) 面向使用者的實時分析。傳統的資料倉儲往往是面向企業內部人員的，實時性不強，隨著資料變得越來越重要，很多數倉場景需要直接面對終端使用者，需要提升系統的實時性和併發處理能力，例如淘寶實時分析每個廣告主/代理商的廣告推廣計劃/關鍵詞，支付寶對每一筆交易做實時風控，支付寶雙十一當天實時分析每個商家的銷售情況並根據分析結果快速調整營銷策略，等等。

 HTAP背後的權衡

真正的 HTAP 系統有一個要求是基於”一份資料”同時做好交易和分析。那麼，什麼叫做“一份資料”?想要回答這個問題，核心是要回答哪一種做法是對使用者最友好且價效比更高。我認為，資料的多個副本或者多種形態(列索引/ BTree 索引/ Bitmap 索引等)都可以被認為是”一份資料”，前提是能夠在滿足 HTAP 處理需求的前提下最大程度降低資料冗餘。例如，OceanBase 往往儲存多個副本( 3 個副本/ 5 個副本)，可以選擇讓其中一個備副本專門做 OLAP 查詢;Oracle IMC 支援對錶格在記憶體中建立列索引，SQL Server 支援對錶格在磁碟/記憶體中建立列索引，從使用者的角度仍然是“一個系統，一份資料”。

很多使用者都問我：OceanBase”一份資料”能否支援資源隔離?理解了”一份資料“這個概念之後，這個問題就很容易回答。對於 HTAP 混合負載，如果是 OLTP 負載為主，OLAP 負載佔比很少，那麼，可以在主副本同時支援 OLTP 和 OLAP 混合負載並在資料庫內部實現資源邏輯隔離;如果 OLAP 負載佔比很高，那麼，可以在主副本上做 OLTP，在專門的備副本或者只讀副本上做 OLAP 查詢，實現資源物理隔離。

業界還有一些兩套系統的方案，例如 OLTP 系統採用 RocksDB/MySQL，OLAP 系統採用 Spark 或者 ClickHouse，並在系統內部實現不同型別 SQL 的路由分發。這種方案並不符合“一份資料“的要求，不是真正的 HTAP。為什麼?因為採用兩個系統之後必然導致成本大幅上升，為了系統的高可用，OLTP 系統和 OLAP 系統需要有各自獨立的多副本容災架構，且兩個系統在理論上無法保證資料的一致性。

HTAP 是否意味著全公司一套系統?

HTAP 確實能夠很好地兼顧 OLTP 和 OLAP，但這並不代表 HTAP 是萬能的，也不代表全公司只有一套 HTAP 資料庫。這裡面既有技術因素，也有非技術因素。一個公司往往會有多個業務部門，應用也會做拆分，這就導致 OLTP 資料庫和 OLAP 資料庫的決策部門不同，即使是 OLTP 資料庫也會按照業務做拆分。全公司一套系統在大多數公司基本是不現實的，比較現實的做法是每個業務一套 HTAP 資料庫。例如交易業務一套 HTAP 資料庫，同時支援線上交易實時處理和歷史訂單的實時分析。

相比基於 MySQL/ClickHouse/Elastic Search/Presto/Kylin 等多個系統搭積木的做法，HTAP 確實能夠大大簡化應用。另外，即使 HTAP 系統足夠強大，資料倉儲往往也會單獨部署。一方面，實時業務和資料倉儲的決策部門不同，另一方面，實時業務往往是單一資料來源，而資料倉儲處理多個業務的多種資料來源。

HTAP 系統也不等於原生分散式架構。前面提到，Oracle / SQL Server 雖然採用集中式架構，但是具備 HTAP 能力，能夠同時處理 OLTP 和 OLAP 混合負載，Oracle Exadata 一體機也是經典的 HTAP 方案之一。當然，透過原生分散式架構，以 OceanBase 為代表的分散式 HTAP 資料庫具備處理大資料量的能力，大大拓寬了 HTAP 資料庫的應用場景。

HTAP 技術上犧牲事務還是分析?

真正的 HTAP 要求先有高效能的 OLTP，然後在 OLTP 的基礎上支援實時分析。無論是 Oracle/SQL Server 這樣的集中式 HTAP 資料庫，還是 OceanBase 這樣的分散式 HTAP 資料庫，都有非常好的事務處理效能。業界有一些“HTAP 產品”的事務處理效能比較差，這並不是 HTAP 的問題，而是這類產品的設計實現問題。

HTAP 的“一份資料”可以是資料的多個副本或者多種形態，例如主副本採用行存，備副本採用列存，因此，理論上也能做到不犧牲分析能力。然而，真正的 HTAP 資料庫都是在 OLTP 的基礎上發展起來的，由於工程複雜度的問題，OLAP 的能力一般會弱於專門的 OLAP 系統。HTAP 適合 OLTP 或者 OLTP 與實時 OLAP 混合負載處理這兩類場景，不適合離線數倉或者大資料無結構化資料處理場景。

HTAP的核心技術

真正的 HTAP 是在 OLTP 資料庫的基礎上擴充套件 OLAP 的能力。經典的 OLTP 資料庫，無論是開源的 MySQL，還是商業資料庫 Oracle/SQL Server，都採用集中式架構，底層儲存引擎是面向磁碟設計的 B+ 樹。這種方案是為小資料量的實時事務處理量身定製的，讀寫效能很好但相比 LSM Tree 等新型資料結構儲存成本更高。以 OceanBase 為例，底層採用最佳化過的 LSM Tree 儲存引擎，在支付寶所有業務完全替換 Oracle/MySQL，儲存成本只有原來 B+ 樹方案的 1/3 左右。

為了讓 OLTP 資料庫具備 OLAP 的能力，尤其是大資料量 OLAP 的能力，思考如下：

首先，需要引入原生分散式架構和低成本儲存引擎，提升系統的大資料處理能力，從而使得系統不僅能夠處理最新資料的實時交易，也能處理更大規模歷史資料的全量分析。OceanBase 的底層採用了一個基於 LSM-Tree 的行列混合式儲存方案，大幅降低儲存成本，並在 OLTP 和 OLAP 二者效能取得很好的平衡。

其次，需要支援 OLTP 與 OLAP 之間的資源隔離。這裡面既有多個副本之間的物理隔離，也有一個副本內部的 CPU/網路/磁碟/記憶體的邏輯隔離，將 cgroup 整合到資料庫引擎內部做邏輯資源隔離是一個不錯的方案。

再次，需要很好地支援複雜查詢和大資料量查詢，涉及到最佳化器、並行執行、向量執行等核心技術。對於分散式資料庫，最佳化器不僅僅要考慮單機上的代價，還需要考慮多機上的代價，最佳化器的搜尋空間大幅增加;另外，如何處理並行執行和伺服器故障容錯的問題，如何實現高效的向量引擎，如何設計記憶體中的資料格式，等等。

最後，需要更好地支援 OLAP 的資料開發和建模能力。資料倉儲往往會將資料分成多個層次，包括：資料明細層，資料服務層，應用資料層。為了支援實時分析能力，HTAP 需要支援高效易用的物化檢視，外部表，快速資料匯入，並與各種資料開發工具和 BI 工具完成適配對接。

本人從事資料庫核心研發十幾年，最大的感受是經典資料庫博大精深浩如煙海，雖然我們今天探索的 HTAP 方案是一種創新，但是，其中大部分優秀的設計都可以從 Oracle/SQL Server 這樣的經典資料庫中借鑑，它們代表的是集中式架構的HTAP，我們要做的是分散式架構的 HTAP，從而進一步擴充 HTAP 的應用場景。

結語：

HTAP 不是萬能的，比較適合單個業務部門的 OLTP 和實時 OLAP 的混合負載處理。我認為終態 HTAP 方案一定是基於“一個系統，一份資料”同時處理交易和實時分析的高價效比方案，“一份資料”的多個副本可以儲存成多種形態(行存/列存)，用於不同的工作負載。

OceanBase 從 2010 年開始一直堅持做分散式 HTAP，雖然已經做了 12 年，但離產品完全成熟還需要很多年，接下來我們會有 HTAP 技術系列文章，把我們目前已經實現的 HTAP 技術方案和場景價值分享出來。雖然這些方案不一定很完善，但是可以作為和我們的開發者進一步探討的基礎。