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？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。