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

那么到底什么才是真正的 HTAP，它對于使用者和開發(fā)者到底意味著什么？《對話 ACE》第五期便邀請到 OceanBase 互聯(lián)網(wǎng)&海外架構師負責人弓子介與 Oracle ACE，云和恩墨產(chǎn)品支持工程師吳偉龍，在直播中兩位老師就“HTAP 的真正含義”展開深入探討，為大家揭開 HTAP 的神秘面紗。

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

📣OceanBase 互聯(lián)網(wǎng)&海外架構師負責人弓子介

Q：OceanBase 的 HTAP 能力是通過什么樣的形式或架構實現(xiàn)的？

A：

了解過 OceanBase 的體系架構的同學應該都知道，OceanBase 自從 2015 年在螞蟻內(nèi)部 1.0 之后整體的技術架構就采用了 MPP 的架構，一直保留到了今天。擁有可以理論上無限橫向擴展的能力，這也是很多數(shù)倉數(shù)據(jù)庫選擇的架構類似于 GreenPlum，同時當時螞蟻內(nèi)部需要進行螞蟻核心鏈路的聯(lián)機交易 Oracle 替換工作，SQL 特點是典型的點查，點讀，小事務，高并發(fā)場景，所以我們做了大量的 TP 場景的優(yōu)化，包括優(yōu)化器，事務等，滿足 Mission Critical 場景的業(yè)務訴求，底層采用LSM存儲引擎具備完整的 ACID 事務屬性。

2019 年開始，在 OceanBase 的 MPP 架構下很自然的我們開始面向復雜查詢場景開始在 SQL 引擎執(zhí)行器部分引入分布式執(zhí)行框架可以利用MPP框架的計算伸縮性進行 DML,Query 的提速，存儲部分引入了數(shù)據(jù)庫編碼技術，在數(shù)據(jù)刷臟的時候按行存儲按列編碼，在一份數(shù)據(jù)上實現(xiàn)對業(yè)務透明的行列混合存儲。同時在 2020 年 OceanBase 的 3.X 上基于現(xiàn)代硬件的 SIMD 指令向量化的能力優(yōu)化，實現(xiàn)了 TPC-H 打榜第一的成績。

Q：HTAP的典型優(yōu)勢場景，您認為包含哪幾方面？

A：

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

現(xiàn)在流行的解決方案還是把 TP 的數(shù)據(jù)通過日志解析工具拖出一份到匯聚庫，在匯聚庫進行負責查詢，對于業(yè)務需要多份數(shù)據(jù)且要包裝容災，成本居高不下，這種場景就特別適合 HTAP，減少 IT 投入的同時降低后期運維成本。

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

A：

HTAP 數(shù)據(jù)庫需要能處理高并發(fā)海量寫入場景的同時，又能準實時的處理一些復雜查詢場景，譬如多表關聯(lián)，批量導入導出等場景， OceanBase 天生三副本 Paxos 協(xié)議實現(xiàn)無損容災，在實際業(yè)務場景需要能識別出聯(lián)機交易場景的 SQL，與復雜查詢場景的 SQL，利用OceanBase的多副本采用Hint的方式進行 SQL 分發(fā)減少 TP/AP 的資源爭搶，一些對于事務有強一致訴求的場景，可以采用 OceanBase 的 Rrsource Manager 能力，進行 SQL 打標，在主副本上進行資源隔離，確保負責查詢對于核心場景的抖動影響。

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

A：

原本 TP/AP 分開采用 ETL 進行數(shù)據(jù)傳輸?shù)募軜嬌?#xff0c;DBA 需要花費大量精力維護鏈路的穩(wěn)定性與時效性，切換至 HTAP 數(shù)據(jù)庫后，DBA 無需再花費精力進行鏈路維護，DBA 從原先的 Database Administrator 切換至Database architect，深入?yún)⑴c到業(yè)務的架構設計中，根據(jù)業(yè)務邏輯識別出最適合的業(yè)務架構與 HTAP 數(shù)據(jù)庫的結合。

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

Q：您認為集中式架構的HTAP和分布式架構的HTAP的核心區(qū)別在哪里？

A：

集中式的 HTAP 類似 Oracle SQLServer，本身設計就是面臨混合負載場景。可以把 HTAP 分為 small htap 或者 big htap，最大的區(qū)別還是橫向擴展能力，集中式數(shù)據(jù)庫在遇到性能瓶頸的時候主要的解決方案還是 scale up，分布式數(shù)據(jù)庫譬如 OceanBase 采用的是 Scale Out 方式。

集中式架構的 HTAP 和分布式架構的 HTAP 最大的區(qū)別是集中數(shù)據(jù)庫的 scale up 是有上限的，譬如 CPU 規(guī)格，譬如 IO 的吞吐與 IOPS 能力，所以小型規(guī)模業(yè)務可能用 Oracle/SQLServer 數(shù)據(jù)庫局夠了，如果隨著時間的推移數(shù)據(jù)量越來越大，通過橫向擴展提供更多的計算資源與 IO 資源可以很好的滿足業(yè)務數(shù)據(jù)量的增長。

📣云和恩墨產(chǎn)品支持工程師吳偉龍

Q：一份數(shù)據(jù)下，HTAP 到底能否真正地實現(xiàn) OLTP 和 OLAP 兩者兼得？

A：

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

Q：您覺得 HTAP 更多會應用在哪些行業(yè)內(nèi)，對于這些行業(yè)選擇 HTAP 的業(yè)務痛點是什么？

A：

HTAP 由于它本身的特點是既可以應用于事務型數(shù)據(jù)庫場景，也可以應用于分析型數(shù)據(jù)庫場景；特別適用于復雜、多模、時效性高這些應用場景；數(shù)據(jù)不需要從操作型數(shù)據(jù)庫導入到?jīng)Q策類系統(tǒng)；比如電商，金融行業(yè)訂單，付款信息需要實時同步到結算庫的庫存數(shù)據(jù)進行結算對賬，各渠道交易數(shù)據(jù)統(tǒng)計，精準資損防控，這些信息實際上就需要實現(xiàn)快速的數(shù)據(jù)同步，傳統(tǒng)的 ETL 它無法做到這么快速。

Q：您認為 HTAP 如何才能保持數(shù)據(jù)一致性？

A：

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

那么，分布式數(shù)據(jù)庫業(yè)界有兩種實現(xiàn)方式：

1）利用特殊的硬件設備，如 GPS 和原子鐘（Atomic Clock），使多臺機器間的系統(tǒng)時鐘保持高度一致，誤差小到應用完全無法感知的程度。在這種情況下，就可以繼續(xù)利用本地系統(tǒng)時間戳作為版本號，同時也能滿足全局范圍內(nèi)的外部一致性。

那么 Google Spanner 就是典型的 GPS 時鐘和原子鐘來實現(xiàn)數(shù)據(jù)的一致性，且支持多種不同的事務。Spanner 中支持三種事務，分別為快照讀，只讀事務，讀寫事務。

2）版本號不再依賴各個機器自己的本地系統(tǒng)時鐘，所有的數(shù)據(jù)庫事務通過集中式的服務獲取全局一致的版本號，由這個服務來保證版本號的單調(diào)向前。這樣一來，分布式架構下獲取版本號的邏輯模型和單點架構下的邏輯模型就一樣了，徹底消除了機器之間時鐘差異的因素。

那么分布式數(shù)據(jù)庫 OceanBase 在實現(xiàn)全局（跨機器）一致的快照隔離級別和多版本并發(fā)控制時會面臨分布式架構所帶來的技術挑戰(zhàn)。為了應對這些挑戰(zhàn)，OceanBase 數(shù)據(jù)庫在 2.0 版本中引入了“全局一致性快照”技術。

有了“全局一致性快照”技術之后，OceanBase 數(shù)據(jù)庫便具備了在全局（跨機器）范圍內(nèi)實現(xiàn)“快照隔離級別”和“多版本并發(fā)控制”的能力，可以在全局范圍內(nèi)保證“外部一致性”，并在此基礎之上實現(xiàn)眾多涉及全局數(shù)據(jù)一致性的功能，比如全局一致性讀、全局索引等。

這樣一來，和傳統(tǒng)單點數(shù)據(jù)庫相比，OceanBase 在保留分布式架構優(yōu)勢的同時，在全局數(shù)據(jù)一致性上也沒有任何降級，應用開發(fā)者就可以像使用單點數(shù)據(jù)庫一樣使用 OceanBase，完全不必擔心機器之間的底層數(shù)據(jù)一致性問題?？梢哉f，借助“全局一致性快照”技術，OceanBase 數(shù)據(jù)庫完美地實現(xiàn)了分布式架構下的全局數(shù)據(jù)一致性！

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

A：

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

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

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

A：

現(xiàn)在幾乎所有數(shù)據(jù)庫大廠和云服務巨頭都在布局 HTAP?！靶乱淮?HTAP + 云”正在成為數(shù)據(jù)庫市場重要的潮流。云數(shù)據(jù)庫不再是以往傳統(tǒng)數(shù)據(jù)庫部署、運維、擴展等難題，以云的方式提供服務可以讓數(shù)據(jù)庫使用更加簡單；另外一個原因是，隨著云計算的普及，云上用戶群體持續(xù)增加，來自云上用戶群體的需求反饋無時無刻都在發(fā)生，對于數(shù)據(jù)庫產(chǎn)品的進化與迭代至關重要。

Q&A

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

A：

目前有很多廠商都在做 HTAP 數(shù)據(jù)庫，每家廠商的實現(xiàn)方式并不完全一樣。在 TP 是三副本的情況下來做復雜查詢，就可能會引入像 ClickHouse 或其他的這種技術棧，再去通過行轉列的方式將復雜 SQL 放于這種列存數(shù)據(jù)庫。

站在 OceanBase 的角度來講，這并不是真正的 HTAP 數(shù)據(jù)庫。不管是面向 TP 還是面向 AP，都是采用的一份數(shù)據(jù)三份副本，在這樣的情況下它不需要新增容災的成本。

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

A：

以 OceanBase 為例，舉一個最典型的場景，當主集群去做連接交易，兩個備副本去做復雜查詢進行讀寫分離；當主集群中 HT 的副本出現(xiàn)故障時，由于 OceanBase 采用的是 Paxos 協(xié)議，因此它會在剩下的兩個副本里面自動的選出一個升任為新的 leader，這個過程不需要人工干預，并且保障數(shù)據(jù)的不丟失。

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

總結

以上是生活随笔為你收集整理的对话ACE第五期：到底什么才是真正的HTAP？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。