HTAP（Hybrid Transaction / Analytical Processing，混合事務分析處理）在2014 年被首次提出並賦予明確的定義：即同時支援 OLTP 和 OLAP 場景，需要創新的計算儲存框架，在一份資料上保證事務的同時支援實時分析，省去費時的 ETL 過程。隨著全球進入數字化時代，數字化技術滲透到各行各業，同時產生海量資料，資料的儲存和應用成為企業決策的重要依據，業務場景的變化也掀起了一股 HTAP 浪潮。

那麼到底什麼才是真正的 HTAP，它對於使用者和開發者到底意味著什麼？《對話 ACE》第五期便邀請到 **OceanBase 網際網路&海外架構師負責人弓子介與 Oracle ACE，雲和恩墨產品支援工程師吳偉龍**，在直播中兩位老師就“HTAP 的真正含義”展開深入探討，為大家揭開 HTAP 的神秘面紗。

吳偉龍和弓子介兩位老師分別從自己的視角出發，對 HTAP 進行了深入探討，以下為對話實錄。以下為對話實錄：

### ?**OceanBase 網際網路&海外架構師負責人弓子介**

#### **Q：OceanBase 的 HTAP 能力是透過什麼樣的形式或架構實現的？**

**A：**

瞭解過 OceanBase 的體系架構的同學應該都知道，OceanBase 自從 2015 年在螞蟻內部 1.0 之後整體的技術架構就採用了 MPP 的架構，一直保留到了今天。擁有可以理論上無限橫向擴充套件的能力，這也是很多數倉資料庫選擇的架構類似於 GreenPlum，同時當時螞蟻內部需要進行螞蟻核心鏈路的聯機交易 Oracle 替換工作，SQL 特點是典型的點查，點讀，小事務，高併發場景，所以我們做了大量的 TP 場景的最佳化，包括最佳化器，事務等，滿足 Mission Critical 場景的業務訴求，底層採用LSM儲存引擎具備完整的 ACID 事務屬性。

2019 年開始，在 OceanBase 的 MPP 架構下很自然的我們開始面向複雜查詢場景開始在 SQL 引擎執行器部分引入分散式執行框架可以利用MPP框架的計算伸縮性進行 DML,Query 的提速，儲存部分引入了資料庫編碼技術，在資料刷髒的時候按行儲存按列編碼，在一份資料上實現對業務透明的行列混合儲存。同時在 2020 年 OceanBase 的 3.X 上基於現代硬體的 SIMD 指令向量化的能力最佳化，實現了 TPC-H 打榜第一的成績。

#### **Q：HTAP的典型優勢場景，您認為包含哪幾方面？**

**A：**

相比於純 TP 或者純 AP，HTAP 是 niche market，有真實的業務場景與訴求，最近有個比較火的名詞：實時數倉，上游的聯機交易採用了MySQL，業務需要實時根據 TP 的落地資料進行 C 端快速反饋，比如實時風控，交易歷史明細查詢，欺詐監測，千人千面等等，傳統的數倉 ETL 鏈路長，延遲大，很難滿足業務快速多變的訴求。

現在流行的解決方案還是把 TP 的資料透過日誌解析工具拖出一份到匯聚庫，在匯聚庫進行負責查詢，對於業務需要多份資料且要包裝容災，成本居高不下，這種場景就特別適合 HTAP，減少 IT 投入的同時降低後期運維成本。

####  **Q：HTAP 的架構體系，如何能更好地在實際業務場景中應用？**

**A：**

HTAP 資料庫需要能處理高併發海量寫入場景的同時，又能準實時的處理一些複雜查詢場景，譬如多表關聯，批次匯入匯出等場景， OceanBase 天生三副本 Paxos 協議實現無損容災，在實際業務場景需要能識別出聯機交易場景的 SQL，與複雜查詢場景的 SQL，利用OceanBase的多副本採用Hint的方式進行 SQL 分發減少 TP/AP 的資源爭搶，一些對於事務有強一致訴求的場景，可以採用 OceanBase 的 Rrsource Manager 能力，進行 SQL 打標，在主副本上進行資源隔離，確保負責查詢對於核心場景的抖動影響。

#### **Q：對於 DBA 和運維人員，面臨 HTAP 架構應用上，應注意哪些？**

**A：**

原本 TP/AP 分開採用 ETL 進行資料傳輸的架構上，DBA 需要花費大量精力維護鏈路的穩定性與時效性，切換至 HTAP 資料庫後，DBA 無需再花費精力進行鏈路維護，DBA 從原先的 Database Administrator 切換至Database architect，深入參與到業務的架構設計中，根據業務邏輯識別出最適合的業務架構與 HTAP 資料庫的結合。

舉個例子攜程的 DBA 基於 OceanBase 的開源版本，在深刻理解業務邏輯的基礎上，改造了 OBProxy，透過獨立部署不同的 proxy 實現業務無需業務程式碼侵入訪問不同的 proxy 實現 TP/AP 的分離，這就是很典型的例子。

#### **Q：您認為集中式架構的HTAP和分散式架構的HTAP的核心區別在哪裡？**

**A：**

集中式的 HTAP 類似 Oracle SQLServer，本身設計就是面臨混合負載場景。可以把 HTAP 分為 small htap 或者 big htap，最大的區別還是橫向擴充套件能力，集中式資料庫在遇到效能瓶頸的時候主要的解決方案還是 scale up，分散式資料庫譬如 OceanBase 採用的是 Scale Out 方式。

集中式架構的 HTAP 和分散式架構的 HTAP 最大的區別是集中資料庫的 scale up 是有上限的，譬如 CPU 規格，譬如 IO 的吞吐與 IOPS 能力，所以小型規模業務可能用 Oracle/SQLServer 資料庫局夠了，如果隨著時間的推移資料量越來越大，透過橫向擴充套件提供更多的計算資源與 IO 資源可以很好的滿足業務資料量的增長。

### ?**雲和恩墨產品支援工程師吳偉龍**

#### **Q：一份資料下，HTAP 到底能否真正地實現 OLTP 和 OLAP 兩者兼得？**

**A：**

在Gartner 2014 年首次提出HTAP（Hybrid Transaction / Analytical Processing，混合事務分析處理）概念中給出明確的定義：即同時支援 OLTP 和 OLAP 場景，需要創新的計算儲存框架，在一份資料上保證事務的同時支援實時分析，省去費時的 ETL 過程。HTAP模式確實能夠很好地兼顧 OLTP 和 OLAP；但 HTAP 並不代表它是萬能的，也不代表一個組織只有一套HTAP資料庫。這裡面既有技術因素，也有非技術因素。一個組織會有多個不同的業務部門，相關的應用會做拆分，這就導致 OLTP 資料庫和 OLAP 資料庫的決策部門不同，即使是 OLTP 資料庫也會按照業務做拆分。全公司一套系統在大多數公司基本是不太現實的，比較容易現實的做法是每個業務一套 HTAP 資料庫。例如交易業務一套 HTAP 資料庫，同時支援線上交易實時處理和歷史訂單的實時分析。

#### **Q：您覺得 HTAP 更多會應用在哪些行業內，對於這些行業選擇 HTAP 的業務痛點是什麼？**

**A：**

HTAP 由於它本身的特點是既可以應用於事務型資料庫場景，也可以應用於分析型資料庫場景；特別適用於複雜、多模、時效性高這些應用場景；資料不需要從操作型資料庫匯入到決策類系統；比如電商，金融行業訂單，付款資訊需要實時同步到結算庫的庫存資料進行結算對賬，各渠道交易資料統計，精準資損防控，這些資訊實際上就需要實現快速的資料同步，傳統的 ETL 它無法做到這麼快速。

#### **Q：您認為 HTAP 如何才能保持資料一致性？**

**A：**

在資料庫中的兩個技術概念：“快照隔離級別（Snapshot）”和“多版本併發控制（Multi VersionConcurrency Control，簡稱MVCC）”。這兩種技術的意思是：透過維護資料庫中的不同版本號（即多個不同的快照），當資料被修改的時候，可以利用不同的版本號區分出正在被修改的內容和修改之前的內容，以此實現對同一份資料的多個版本做併發訪問，避免了經典實現中“鎖”機制引發的讀寫衝突問題。傳統的資料庫都是這麼做的，例如 Oracle通常是以分配 SCN(system change number) 作為版本號。不同的 SCN 代表了資料在不同時間點的“已提交版本（Committed Version）”，由此實現了資料的快照隔離級別。

**那麼，分散式資料庫業界有兩種實現方式：**

1）利用特殊的硬體裝置，如 GPS 和原子鐘（Atomic Clock），使多臺機器間的系統時鐘保持高度一致，誤差小到應用完全無法感知的程度。在這種情況下，就可以繼續利用本地系統時間戳作為版本號，同時也能滿足全域性範圍內的外部一致性。

那麼 Google Spanner 就是典型的 GPS 時鐘和原子鐘來實現資料的一致性，且支援多種不同的事務。Spanner 中支援三種事務，分別為快照讀，只讀事務，讀寫事務。

2）版本號不再依賴各個機器自己的本地系統時鐘，所有的資料庫事務透過集中式的服務獲取全域性一致的版本號，由這個服務來保證版本號的單調向前。這樣一來，分散式架構下獲取版本號的邏輯模型和單點架構下的邏輯模型就一樣了，徹底消除了機器之間時鐘差異的因素。

那麼分散式資料庫 OceanBase 在實現全域性（跨機器）一致的快照隔離級別和多版本併發控制時會面臨分散式架構所帶來的技術挑戰。為了應對這些挑戰，OceanBase 資料庫在 2.0 版本中引入了“全域性一致性快照”技術。

有了“全域性一致性快照”技術之後，OceanBase 資料庫便具備了在全域性（跨機器）範圍內實現“快照隔離級別”和“多版本併發控制”的能力，可以在全域性範圍內保證“外部一致性”，並在此基礎之上實現眾多涉及全域性資料一致性的功能，比如全域性一致性讀、全域性索引等。

這樣一來，和傳統單點資料庫相比，OceanBase 在保留分散式架構優勢的同時，在全域性資料一致性上也沒有任何降級，應用開發者就可以像使用單點資料庫一樣使用 OceanBase，完全不必擔心機器之間的底層資料一致性問題。可以說，藉助“全域性一致性快照”技術，OceanBase 資料庫完美地實現了分散式架構下的全域性資料一致性！

#### **Q：我們知道真正的 HTAP 對於事務和分析能力的要求都很高，但真正實現會有一定難度。那麼關於事務和分析，我們首先選擇哪個會比較好？**

**A：**

HTAP 正是為滿足事務和分析這兩種高要求場景而設計的；如果說談到價值的更大化，我相信 OLTP 場景下選擇 HTAP 它會是更好；因為交易資料它是組織中快速變化的高價值資料，這些資料如果透過傳統的 ETL 去抽取，一旦出現問題，可能就會影響整個企業的業務，這是我們組織無法承受的。

組織需要的 HTAP 能力它可以不必完全覆蓋資料倉儲業務，僅僅需要對核心業務需要的線上分析能力做一定的提升就可以了。因此在 HTAP 資料庫中需要儲存的就是 OLTP 系統本身的資料以及部分分析必須的從外部提取過來的高價值資料。

#### **Q：您認為 HTAP 如何能與雲更完美的結合？**

**A：**

現在幾乎所有資料庫大廠和雲服務巨頭都在佈局 HTAP。“新一代 HTAP + 雲”正在成為資料庫市場重要的潮流。雲資料庫不再是以往傳統資料庫部署、運維、擴充套件等難題，以雲的方式提供服務可以讓資料庫使用更加簡單；另外一個原因是，隨著雲端計算的普及，雲上使用者群體持續增加，來自雲上使用者群體的需求反饋無時無刻都在發生，對於資料庫產品的進化與迭代至關重要。

### **Q&A**

#### **Q：做備庫查詢，是不是需要額外新增一份副本？**

**A：**

目前有很多廠商都在做 HTAP 資料庫，每家廠商的實現方式並不完全一樣。在 TP 是三副本的情況下來做複雜查詢，就可能會引入像 ClickHouse 或其他的這種技術棧，再去透過行轉列的方式將複雜 SQL 放於這種列存資料庫。

站在 OceanBase 的角度來講，這並不是真正的 HTAP 資料庫。不管是面向 TP 還是面向 AP，都是採用的一份資料三份副本，在這樣的情況下它不需要新增容災的成本。

#### **Q：如果不新增副本，那如果出主節點故障因為一個備節點壓力大會影響切換嗎？**

**A：**

以 OceanBase 為例，舉一個最典型的場景，當主叢集去做連線交易，兩個備副本去做複雜查詢進行讀寫分離；當主叢集中 HT 的副本出現故障時，由於 OceanBase 採用的是 Paxos 協議，因此它會在剩下的兩個副本里面自動的選出一個升任為新的 leader，這個過程不需要人工干預，並且保障資料的不丟失。

以上為兩位老師的精彩分享，大家有什麼問題也可以文末留言探討，我們下一期 OceanBase 《對話 ACE》再見！

對話ACE第五期：到底什麼才是真正的HTAP？

相關文章