To digitally transform the business, AI must be real-time. For AI to be real-time, we need real-time analytics.[1]
Hybrid transaction/analytical processing (HTAP) is an emerging application architecture that "breaks the wall" between transaction processing and analytics. It enables more informed and "in business real time" decision making.
——Defined by Gartner

背景篇-引言

自 StoneDB 開源的第一天，我們就說要做真正的 HTAP，那么究竟我們對 HTAP是怎么理解的？解讀一門技術，就要從其發展背景入手，本篇文章中我們將從 OLTP 和 OLAP 最近的發展介紹及各自遇到的問題為基礎，引出 HTAP 相關概念，

OLTP：特點、適用場景、遇到的問題、最新進展

對事務型資料進行處理稱為聯機事務處理 (On Line Transaction Processing, OLTP)，OLTP 系統其主要的使用場景為記錄日常運營中與業務系統之間的互動記錄，并且支持以該資料進行查詢分析以獲得分析結果，
事務資料是指一種資訊，用于跟蹤與組織活動相關的互動，常為：業務事務，例如：從客戶收到的付款、對供應商進行的付款、從庫存移動的產品、接受的訂單或交付的服務，表示事務本身的事務事件通常包含時間維度、數值等，
事務通常需要原子性和一致性，原子性意味著整個事務始終作為一個作業單元成功或失敗，永遠不會處于半完成狀態，如果無法完成某個事務，資料庫系統必須回退任何已完成的該事務的一部分作業，從而能夠保證整個作業要么完成，要么失敗，一致性意味著事務始終讓資料處于最終有效狀態，如果已將某個事務的一部分提交到資料庫，那么該源事務中所有其他作用域內操作也將處于最終有效狀態并提交到資料庫中，事務型資料庫可以使用各種鎖定策略（如悲觀鎖定）支持事務的強一致性，以確保所有用戶和行程的所有資料在業務的背景關系中具有強一致性，
事務型資料最常見的部署體系結構是三層體系結構，在該體系結構中，事務型資料在資料存盤層被使用，三層體系結構通常包含：表示層、業務邏輯層和資料存盤層，

適用場景

如果業務系統對資料完整性和實時性有約束要求，同時在業務的處理程序中需要保證資料的嚴格完整性，而且更改后的資料需要嚴格的持久性，此時OLTP 會是你的首要選擇，因為，OLTP 系統設計用于高效地處理和存盤事務，以及查詢事務資料，

面臨挑戰

實作和使用 OLTP 系統可能會帶來一些挑戰：
（1）OLTP 系統不是特別適合用于處理大量資料場景的復雜查詢，在大資料量復雜查詢場景下， OLTP 系統會消耗大量的計算資源和存盤資源，所以執行上可能較慢，而且如果此時其它事務也正在對某些復雜查詢的資料進行操作，往往會觸發系統中的鎖機制，這會導致整個系統性能的下降，
（2）在 OLTP 系統中，資料庫物件的命名約定通常簡潔而精煉，這對業務用戶專業素養要求較高，OLTP 系統中增強的規范化與簡潔的命名約定共同使得業務用戶在沒有 DBA 或資料開發者幫助的情況下難以執行查詢，
（3）歷史記錄以及在任何一個表中存盤太多資料都會導致查詢性能變慢，常見的解決方案是在 OLTP 系統中維護一個相關時間范圍（例如當前統計年度）并將歷史資料卸載到其他系統，例如：資料倉庫，

OLAP：特點、適用場景、遇到的問題、最新進展

聯機分析處理（英語：Online analytical processing），簡稱 OLAP，用來快速解決多維分析問題的一種方法，OLAP 是更廣泛的商業智能范疇的一部分，它還包括關系資料庫、報告撰寫和資料挖掘，
企業用來存盤其所有事務和記錄的資料庫稱為聯機事務處理 (OLTP) 資料庫，它們通常包含對組織有價值的大量資訊，OLTP 的資料庫不是為分析而設計的，因此，從這些資料庫中檢索答案從時間和作業量角度而言成本高昂，OLAP 系統設計用來以高性能方式從資料中提取商業智能資訊，這是因為 OLAP 資料庫針對高頻讀取和低頻寫入進行了優化，

適用場景

• 需要快速執行復雜的分析和即席查詢，且不能對 OLTP 系統產生負面影響；
• 為業務用戶提供一種簡單的方式來基于資料生成報表；
• 提供大量聚合，這些聚合將使用戶能夠快速獲得回應結果，OLAP 適用于大量資料且查詢多為聚合計算的場景下，OLAP 系統針對高頻讀取應用場景（例如分析和商業智能）進行了優化，

面臨挑戰

OLAP 系統中的資料更新較少，具體取決于業務需求，這意味著 OLAP 系統更適用于戰略級業務決策，而非適用于立即對更改做出回應，另外，還需要規劃一定級別的資料清理和業務流程來使 OLAP 系統中的資料保持最新，

與 OLTP 系統中使用的傳統的規范化關系表不同，OLAP 的資料模型通常是多維的，在這種模型中，每個屬性映射到一個列，其難以或無法直接映射到物體關系或面向物件的模型，
**

OLTP VS OLAP

OLTP 和 OLAP 從不同維度之間的對比關系如下所示：

隨著時間的推移，越來越多的業務對于 AP 的要求越來越向著 TP 的指標看齊，例如：要求 AP 系統能夠實時反映出當前 TP 系統中的實際資料，同時，AP 系統可以支持資料的更新等等，總之，TP 系統和 AP 系統之間的邊界在業務層面和用戶層面上也越來越模糊,市場上迫切希望能夠出現一種新的架構或者稱之為者解決方案，能夠同時滿足業務對于 TP 負載和 AP 負載的需求，因此，HTAP 的概念隨之而誕生，2014年 Gartner 給出了 HTAP 的明確概念：Systems that can support both OLTP (On-line transaction processing) as well as OLAP (on-line analytics processing) within a single transaction.[4]

HTAP：HTAP概念引入的目的，定義，適用場景介紹，HTAP的商業驅動力——問題的源動力？

商業上的驅動力

當前市場上對于資料的處理方式越加的注重多種型別的負載混合進行，即對于用戶或者業務端來說，有一個統一的處理邏輯或者架構，如對于廣告計算，用戶畫像，分控，物流，地理資訊等商業場景下，原有的處理方式為在海量的歷史資料中通過 AP（分析型處理）資料庫或者自建的大資料平臺，完成對于歷史資料的計算，然后將 AP 計算的結果作為 TP（事務型處理）的輸入結構，完成對于實時計算需求，
因此，在原有的架構環境下，對于此類的應用需要部署兩套環境分別應對 AP 和 TP 兩類負載，從而造成整個架構變得復雜，中間涉及到的組件較多，無法及時將 TP 資料實時更新到 AP 系統中，從而影響 BI 等應用的時效性，
" 陳舊的報告、缺失的資料、缺乏高級分析以及完全缺乏實時分析對于任何需要新見解以在商業客戶時代保持競爭力的企業來說都是一種無法忍受的狀態，"[2]

架構1：異構架構模式

商業上的驅動力，其原動力來自業務端的需求，沒有業務端的需求變化，不會導致商業上的驅動力，由于現在市場中無論是互聯網企業還是其他傳統型企業，在其早期業務的發展程序中通常會采用架構一的方式來往滿足業務需求；但該種架構在后期的使用程序中存在著各種各樣的問題，如 AP 模塊和 TP 模塊之間的資料同步問題，運維的問題等等，而著會導致巨大的運營成本，
隨著業務需要的發展和資料庫技術的發展，使得資料庫產品同時具有處理 AP 和 TP 的能力，且在處理 AP 負載的時候并不會對 TP 負載造成太大的性能波動，更重要的一個特性是在 TP 資料和 AP 資料可以做到“準”（或者實時）實時更新，因此，基于資料庫的此項能力，業務端即可將原有的 AP 處理模塊及 TP 處理模塊進行合并，統一的交由該資料庫進行處理，從而可以簡化業務系統的架構，

架構2：統一架構

HTAP 則為上述問題提供了另外一個解法和思路，將 AP 和 TP 的能力由統一的系統對外提供，由此構成的業務架構簡單化，同時具有一定的擴展特性，產生 HTAP 用戶側的需求或者訴求如下：

1. 事務資料及歷史資料的集成，
2. 理解用戶需求的超維度資料分析的需要；全域視角來看資料，方能看清事物的本質，（例如：從手機的位置資訊，用戶的填表所獲得資訊，社交媒體所獲得富媒體資訊，）
3. 企業運行所需的商業分析的實時性需求，

技術上的驅動力

"May the force be with you." ——Star War.

作為一個新技術產生的另外一個重要的來源：技術驅動力，這才是實作人們想象力的基石，下面我們從技術的發展角度來看看，推動 HTAP 發展的另一個重要的源動力：in-memory， scale-out技術使得我們的架構可以進行擴展，使得我們可以在一個架構內滿足不同負載需要變為可能，列存技術的發展則是我們實作 HTAP 的基石，分層存盤架構為我們在成本和性能之間找到了一個平衡點，

1. 列存技術

面向列存的資料，最早可以追溯到 1970 年，隨著轉置檔案(transposed files)的出現，在面向時間的資料庫（Time oriented Database）中使用轉置檔案進行醫療資料記錄，Cantor 被稱為是最早的一個與現代列存資料庫相似的系統，例如：在現代列存資料庫中所常用的壓縮技術，delta 編碼等都可在 Cantor 中尋找到身影，
磁盤頁中資料所采用的兩種資料存盤模型：NSM（row-store， N-array Storage Model）和DSM（column-store, Decomposition Storage Model），

通常資料庫的資料物理上以行，頁，段等方式進行分級管理的，表中的一行資料由 N 個資料屬性構成，N 條資料構成一個頁面，多個頁面又構成了一個段，如此將眾多的記錄高效管理起來，以上便是我們所熟知的行存（Row-based）模型，當前，絕大多數資料庫為行存資料庫，對應行存的優點這里我們不在贅述，我們來談談其優點的另一面，缺點，拋開應用場景談某個事務的優缺點本身就是一件奇怪的事情，
對應行存方式組織資料，我進行以分析型業務為主的系統中，分析所涉及的資料量通常非常多，即，將會有大量的記錄會參與到分析計算中，而這些大量的記錄需要從磁盤中讀取到我們資料庫的快取中，由于資料是以行的方式組織，而我們的分析計算只需要特定的幾個屬性，例如：在一條包含：產品 Id，產品產地，產品銷量，銷售時間的記錄，分析計算可能只需要產品 ID 和產品銷量，這兩個屬性便可以得到我們需要的分析結果，對于產品的產地和銷售時間，我們并不關心，由此可以看出，當我們將這條記錄由磁盤讀取到資料庫的快取中，產品產地，產品銷量這兩個屬性資料便屬于無效作業，其會導致我們這部分的資料屬性所對應的 IO 資源和其在資料庫快取中的記憶體資源被浪費，而這兩部分資源在資料庫中又屬于非常寶貴的系統資源，
為了解決上述問題，在 1985 年，Copeland 和 Khoshafian 提出了 DSM 模型，而這也促成了列存資料庫的發展，與行存的方式不同，DSM 模型中，表中的資料已按屬性（列）的方式進行組織，由上圖中 DSM page 模型可以看出，該種方式下，每個屬性資料組織在一起構成一個子的關系并獨立于其它屬性，由于按屬性為單獨進行資料組織，那么在磁盤上進行存盤這些資料的時候，我們可以對其進行壓縮處理，
該種資料存盤模型下，我們只需要讀取分析計算所需的屬性資料即可，從而可以節約寶貴的 IO 和 memory 資源，同時，DSM 模型也屬于 CPU Cache 友好型，但是，DSM 有一個問題是：其在將結果回傳用戶的時候，或者在上層算子進行計算的時候需要重構記錄，因為，此時我們獲得的資料是不完整的，而需要回傳用戶時候需要一個完整的記錄，

針對上述問題的探索，學術界在 1990 左右進行了積極的嘗試，MonetDB專案應運而生，當然在隨后的歲月里也產生了 C-Store 和 VectorWise 等，到了 2000 年底的時候，列存資料庫百花齊放，涌現出諸如：Vertica, Ingres VectorWise, Paraccel, Infobright, Kickfire等等，當然商業資料庫公司也通過收購，自研等方式在各自的產品中提供了列存能力，例如：IBM BLU， SAP HANA，SQL-Server等，

2. in-memory技術(包括：distributed in-memory)

隨著記憶體價格未來的下降，越來越多的個人和組織可以以更加低廉的成本獲得由于技術發展帶來的技術紅利：in-memory 技術，從下表可以看出無論是 PC 上的 DRAM 還是服務器端的 DRAM 價格在已每季度 3-10% 下降，

隨著記憶體價格的下降，我們可以在系統的設計時候，使用更為激進的方式——大量使用記憶體，甚至是全量記憶體的方式，
我們從經典的存盤層次架構圖中知道，DRAM 的訪問速度遠大于本地磁盤，但價格遠比磁盤貴，早期，受限制于 DRAM 高昂的價格，DRAM 都作為高速快取保存由磁盤中所讀取的資料，例如: Buffer Pool，隨著記憶體價格的持續下降使得in-memory 資料庫不再是陽春白雪般的存在，慢慢的進入尋常百姓家，GB 級，TB 級的記憶體資料庫也時常可見，

當需要執行Analytical Processing（AP）的時候，可以將 AP 所需資料加載記憶體中，甚至可以將所需的表的資料全部加載至記憶體中，從而獲得急速的處理速度，同時，可以持續的將 TP 引擎中的資料變化實時的同步到 AP 引擎中，從而滿足商業分析的實時性要求，
最后，為了保證系統 crash 的時候可以正確且快速的完成 recovery，需要將記憶體中的資料持久化至磁盤中，

3. 可擴展的架構：（scale-out architect）: 水平擴展架構的發展，分布式鎖技術的成熟，記錄的分布式管理

為了滿足更大資料量的處理能力，在單節點的基礎上，通過水平擴展的方式將單節點的系統擴展為分布式多節點的系統，利用多節點的系統資源能力來解決，在大資料量場景下的計算能力不足的問題，與單節點系統不同，分布式系統通常由多個節點構成，通過網路進行通信、為了完成共同的任務而協調作業的計算機節點組成的系統，分布式系統的出現是為了用廉價的、普通的機器完成單個計算機無法完成的計算、存盤任務，其目的是利用更多的機器，處理更多的資料，無論是當前通過中間件的方式來實作的分庫分表，還是分布式式資料庫系統所采用的將資料通過某種分布策略（例如通過主鍵或者分布鍵將資料通過 hash 的方式進行分布或者其它的方式）將資料分布至 N 個資料節點上，由此使得單節點的處理資料量減少，
可擴展的架構并不算一個陌生的技術，尤其現在分布式計算已然大量的應用在生產系統中，無論是分布式框架技術，分布式檔案系統，分布式事務等等都已形成了一套成熟的理論并且在工程上也已日益成熟，
對具有可擴展能力的架構來說，做到業務無感知的動態節點的擴縮其方案也日益成熟，例如：一致性 hash 演算法可以完成負載在分布式環境下的均衡，現在，對于分布式框架的水平擴展能力，無論是在理論上和工程上都有成熟的方案，
隨著具有可水平擴展的分布式架構的發展，分布式系統的能力越來越多的運用在資料庫領域，除了，作為基礎的分布式框架外，分布式事務的發展是使得我們能夠處理跨節點的事務，由此，資料庫系統可以充分的利用多節點的計算能力來實作對于大資料業務場景下的實時性的要求，
對于 HTAP，來說由于其涉及到兩個不同的存盤模型（或稱之為：格式），那么我們在事務處理方面對于 row-base 和 columnar-base 兩類資料有著不同的處理方式，對于事務的支持這部分需要我們給出仔細的考慮，同時對于 HTAP 所需要的分布式架構其帶來的分布式事務處理這里也是一個點，好在當前市面上對于分布式事務處理相關技術相對成熟，
最后，當然分布式對于 HTAP 來說，只是一個充分條件，而非必要條件，不考慮用戶實際情況的一上來有最小節點部署要求的解決方案都是“耍流氓”，

4. 資料壓縮（data compression）

考慮到AP場景下，通常所需要處理的資料量巨大，從成本的角度考慮，同時也從IO效率的角度出發，對于資料進行有效的壓縮，將為系統帶來較多的收益，隨著壓縮演算法對于資料型別的支持和壓縮比的提升，對資料進行壓縮，已變為AP系統來一個標準做法，

5. 分層存盤架構（tiered storage）

考慮到用戶的計算資源的情況和資料量的實際業務場景下，通常所需要處理的資料量遠遠大于系統所擁有的計算資源，我們知道越靠近 CPU 的存盤，其單價會越高，為了能夠以最大的性價比的方式對用戶提供搞性能，分層存盤架構應運而生，例如：我們可以使用 DRAM，NVME，SSD，HDD 來構成分層存盤架構，將對于計算實時性有要求的資料加載至 DRAM 中進行計算，以獲得實時計算結果，如果計算程序復雜，中間結果集較大，可將中間結果集保存至 NVME 中，這樣既可以保證資料的實時性，又可以支持更大的資料量，以獲得較高的性價比，同樣，SSD 和 HDD 的也起著同樣的作用，

雖然分層存盤架構看似有著非常誘人和廣闊的使用場景，但是其同樣存在著以下幾個挑戰，使得我們在使用該種方案的時候需要格外小心，

• 首當其沖的，就是在不同層級之間的資料一致性的問題，這個問題比較好理解，在分層存盤架構下，資料通常分布在不同的存盤層級之間，資料的改寫必然導致資料的不致的問題，在內部分層存盤時，可以采用寫穿透(write through)策略或者寫回(write back)策略，而不同的方法也有各自優缺點，這里就不再贅述，但是外部分層存盤與內部分層存盤有一個最大的不同是，記憶體儲最終資料需要寫到記憶體中，而外分層存盤中，則不是必須的，當然也可以設計成這樣的實作方案，但是這樣話，分層存盤的性能優勢則必定會受到影響，
• 其次，如何快速的由分層存盤中獲取相應的資料也將是一個不小的挑戰，由于按照分層存盤的架構，越是層級越低其存盤容量越大，訪問速度越慢，如何在這些海量資料中快速定位到所需資料，將給資料的組織，資料的索引等提出挑戰，最后，是性能和成本之間的 trade-off，如何選擇每個分層中的存盤介質，從而能夠保證整體性能優秀，同時又不至于導致存盤成本飆升，

總結

綜上，本文對 HTAP 的產生背景做了詳細的分析，并提煉出商業和技術上的驅動力，顯而易見，一個新型的技術得到追捧，一定離不開技術的成熟、市場的需要和商業的成功，HTAP 就是誕生在這樣的背景下，
那么，如果我們從 HTAP 的定義及其核心技術出發，一款真正的 HTAP 產品要具備哪些能力？構建真正的 HTAP 時會遇到什么核心問題？這些核心問題都有哪些解決方案？這些問題的答案將在我們的接下來的文章中揭曉，
可以提前劇透的是：在下一篇文章中，我們將指出，真正的 HTAP 并不應該是簡單地將 TP 和 AP 相加：TP + AP ≠ HTAP，HTAP 一定是將 TP 和 AP 進行高度融合的產物，
將 TP 系統通過簡單的資料同步方式，例如通過 Binlog 等，將 TP 中的資料同步到 AP 系統，然后由 AP 系統進行處理的方式，雖然該種方式從用戶的角度來看似乎其獲得同時處理 TP 和 AP 的能力，但是從本質上來看，我們并不認為其是一個 HTAP 產品，
此文是《什么是真正的 HTAP》系列文章的第一篇，后續我們將持續更新此系列文章，敬請關注，

參考資料

[1]AI must be real-time: https://splicemachine.com/blog/how-to-measure-an-htap-data-platform-for-ai-applications/
[2]Forrester: Emerging Technology: Translytical Databases Deliver Analytics At The Speed Of Transactions.
[3]_https://docs.microsoft.com/zh-cn/azure/architecture/data-guide/relational-data/online-transaction-processing_?
[4]https://www.gartner.com/en/documents/2657815
StoneDB 是國內首款基于 MySQL 的一體化實時 HTAP 開源資料庫，內核引擎完全自研，我們將在開源資料庫領域持續耕耘，不斷與各個開源資料庫社區、企業合作共建，共創國產開源資料庫良好生態，

StoneDB 在6月29日已宣布正式開源，如果您感興趣，可以通過下方鏈接查看 StoneDB 原始碼、閱讀檔案，期待你的貢獻！

StoneDB 開源倉庫

https://github.com/stoneatom/stonedb

作者：李浩
StoneDB 首席架構師、StoneDB PMC
曾在華為、愛奇藝、北大方正從事資料庫內核核心架構設計，超過10年資料庫內核開發經驗，擅長查詢引擎，執行引擎，大規模并行處理等技術，擁有數十項資料庫發明專利，著有《PostgreSQL查詢引擎原始碼技術探析》，

編輯 &校對：李明康、王學姣

標籤：其他

上一篇：my2sql工具之快速入門

下一篇：開源公開課丨ChunJun資料傳輸模塊介紹