HTAP是近些年來比較火的一個概念，本文將聊聊HTAP的前世今生及技術特點。

一、資料應用類別

根據資料的使用特徵，可簡單做如下劃分。在選擇技術平臺之前，我們需要做好這樣的定位。

1.1 OLTP 聯機事務處理OLTP（On-Line Transaction Processing）

OLTP是事件驅動、面向應用的，也稱為面向交易的處理過程。其基本特徵是前臺接收的使用者資料可以立即傳送到計算中心進行處理，並在很短的時間內給出處理結果，是對使用者操作的快速響應。例如銀行類、電子商務類的交易系統就是典型的OLTP系統。

OLTP具備以下特點：

直接面嚮應用，資料在系統中產生。
基於交易的處理系統。
每次交易牽涉的資料量很小；對響應時間要求非常高。
使用者數量非常龐大，其使用者是操作人員，併發度很高。
資料庫的各種操作主要基於索引進行。
以SQL作為互動載體。
總體資料量相對較小。

1.2 OLAP 聯機實時分析OLAP（On-Line Analytical Processing）

OLAP是面向資料分析的，也稱為面向資訊分析處理過程。它使分析人員能夠迅速、一致、互動地從各個方面觀察資訊，以達到深入理解資料的目的。其特徵是應對海量資料，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果，例如資料倉儲是其典型的OLAP系統。

OLAP具備以下特點：

本身不產生資料，其基礎資料來源於生產系統中的運算元據。
基於查詢的分析系統；複雜查詢經常使用多表聯結、全表掃描等，牽涉的數量往往十分龐大。
每次查詢設計的資料量很大，響應時間與具體查詢有很大關係。
使用者數量相對較小，其使用者主要是業務人員與管理人員。
由於業務問題不固定，資料庫的各種操作不能完全基於索引進行。
以SQL為主要載體，也支援語言類互動。
總體資料量相對較大。

1.3 OTHER

除了傳統的OLTP、OLAP類，近些年來針對資料的使用又有些新特點，我將其歸入了“其他”類。

1）多模

隨著業務“網際網路化”和“智慧化”以及架構 “微服務”和“雲化”的發展，應用系統對資料的儲存管理提出了新的標準和要求，資料的多樣性成為突出的問題。早期資料庫主要面對結構化資料的處理場景。後來隨著業務的發展，逐漸產生了對非結構化資料的處理需求，包括結構化資料、半結構化(JSON、XML等)資料、文字資料、地理空間資料、圖資料、音影片資料等。多模，正是指單一資料庫支援多種型別資料的儲存與處理。

2）流式

流式處理(實時計算)，是來源於對資料加工時效性的需求。資料的業務價值隨著時間的流失而迅速降低，因此在資料發生後必須儘快對其進行計算和處理。傳統基於週期類的處理方式，顯然無法滿足需求。

隨著移動網際網路、物聯網和感測器的發展導致大量的流式資料產生，相應地出現了專有的流式資料處理平臺，如Storm、Kafka等。近些年來，很多資料庫開始支援流式資料處理，例如MemSQL、PipelineDB。有些專有流式資料處理平臺開始提供SQL介面，例如KSQL基於Kafka提供了流式SQL處理引擎。

3）高階

隨著對資料使用的深入，資料的使用不再僅僅以簡單的增刪改查或分組聚合類操作，而對於其更為高階的使用也逐步引起大家的重視。例如使用機器學習、統計分析和模式識別等演算法，對資料進行分析等。

1.4 對比 — OLAP vs OLTP

二、資料處理模式

面對上述複雜多變的應用場景，資料應用的多種類別，是由單一平臺處理，還是由不同平臺來處理呢？一般來說，專有系統的效能將比通用系統效能高一到兩個數量級，因而不同的業務應採用不同的系統。但正如古人說“天下大勢、分久必合、合久必分”，在資料處理領域也有一種趨勢，由單一平臺來處理。

這裡選擇的核心在於如何來辯證看待需求和技術。它們是一對矛盾體，當這對矛盾緩和時，資料處理領域將更趨向於整合；而當這對矛盾尖銳時，資料處理領域將趨於分散。就軟硬體技術發展現狀和當前需求來看，未來整合的趨勢更為明顯。整合資料平臺將能滿足絕大多數使用者的場景，只有極少數企業需要使用專有系統來實現其特殊的需求。

2.1 分散式（專有平臺）

目前比較常規的方式，是採用多個專有平臺，來針對不同場景進行資料處理。因此是跨平臺的，有個資料傳輸的過程。這會帶來兩個問題：資料同步、資料冗餘。資料同步的核心是資料時效性問題，過期的資料往往會喪失價值。

常見的做法如下:

OLTP系統中的資料變化，透過日誌的形式暴露出來；
透過訊息佇列解耦傳輸；
後端的ETL消費拉取，將資料同步到OLAP中。
整個鏈條較長，對於時效性要求較高的場景是個考驗。

此外，資料在鏈條中流動，是存在多份的資料冗餘儲存。在常規的高可用環境下，資料會進一步儲存多份，因此這裡面隱藏了比較大的技術、人力成本以及資料同步成本。而且橫跨如此之多的技術棧、資料庫產品，每個技術棧背後又需要單獨的團隊支援和維護，如DBA、大資料、基礎架構等，這些都蘊含著巨大的人力、技術、時間、運維成本。正是出於在滿足各種業務需求的同時，提高時效性，減低資料冗餘、縮短鏈條等，收斂技術棧就變得很重要。這也是通用類平臺解決方案誕生的出發點。

2.2 集中式（通用平臺）

使用者厭倦了為不同的資料處理採用不同的資料處理系統，更傾向於採用整合資料處理平臺來處理企業的各種資料型別。對於融合了聯機事務處理和聯機實時分析的場景，也就是下面所談到的HTAP。此類通用平臺方案具備下面優點：

透過資料整合避免資訊孤島，便於共享和統一資料管理。
基於SQL的資料整合平臺可提供良好的資料獨立性，使應用能專注於業務邏輯，不用關心資料的底層操作細節。
整合資料平臺能提供更好的實時性和更全的資料，為業務提供更快更準的分析和決策。
能夠避免各種系統之間的膠合，企業總體技術架構簡單，不需要複雜的資料匯入/匯出等，易於管理和維護。
便於人才培養和知識共享，無須為各種專有系統培養開發、運維和管理人才。

三、HTAP

HTAP資料庫（Hybrid Transaction and Analytical Process，混合事務和分析處理）。2014年Gartner的一份報告中使用混合事務分析處理(HTAP)一詞描述新型的應用程式框架，以打破OLTP和OLAP之間的隔閡，既可以應用於事務型資料庫場景，亦可以應用於分析型資料庫場景，實現實時業務決策。

這種架構具有顯而易見的優勢：不但避免了繁瑣且昂貴的ETL操作，而且可以更快地對最新資料進行分析。這種快速分析資料的能力將成為未來企業的核心競爭力之一。

3.1 技術要點

底層資料要麼只有一份，要麼可快速複製，並且同時滿足高併發的實時更新。
要滿足海量資料的容量問題，在儲存、計算都具有很好的線性擴充套件能力。
具有很好的最佳化器，可滿足事務類、分析類的語句需求。
具備標準的SQL，並支援諸如二級索引、分割槽、列式儲存、向量化計算等技術。

3.2 重點技術 – 行列儲存

1）行儲存（Row-based）

對於傳統的關係型資料庫，比如甲骨文的OracleDB和MySQL，IBM的DB2、微軟的SQL Server等，一般都是採用行儲存（Row-based）行。在基於行式儲存的資料庫中，資料是按照行資料為基礎邏輯儲存單元進行儲存的，一行中的資料在儲存介質中以連續儲存形式存在。

2）列式儲存（Column-based）

列式儲存是相對於行式儲存來說的，新興的Hbase、HP Vertica、EMC Greenplum 等分散式資料庫均採用列式儲存。在基於列式儲存的資料庫中，資料是按照列為基礎邏輯儲存單元進行儲存的，一列中的資料在儲存介質中以連續儲存形式存在。

傳統的行式資料庫，是按照行儲存的，維護大量的索引和物化檢視無論是在時間（處理）還是空間（儲存）面成本都很高。而列式資料庫恰恰相反，列式資料庫的資料是按照列儲存，每一列單獨存放，資料即是索引。只訪問查詢涉及的列，大大降低了系統I/O，每一列由一個線來處理，而且由於資料型別一致，資料特徵相似，極大方便壓縮。

3.3 重點技術 – MPP

MPP (Massively Parallel Processing)，即大規模並行處理，在資料庫非共享叢集中，每個節點都有獨立的磁碟儲存系統和記憶體系統，業務資料根據資料庫模型和應用特點劃分到各個節點上，每臺資料節點透過專用網路或者商業通用網路互相連線，彼此協同計算，作為整體提供資料庫服務。非共享資料庫叢集有完全的可伸縮性、高可用、高效能、優秀的價效比、資源共享等優勢。

簡單來說，MPP是將任務並行的分散到多個伺服器和節點上，在每個節點上計算完成後，將各自部分的結果彙總在一起得到最終的結果。下面以典型的MPP產品Greenplum架構為例。

3.4 重點技術 – 資源隔離

OLTP、OLAP類兩者對資源的使用特點不同，需要在資源層面做好隔離工作，避免相互影響。常見的透過定義資源佇列的方式，指定使用者分配佇列，起到資源隔離的作用。

3.5 HTAP產品

下圖是網站找到的資料庫產品分類圖，針對HTAP類的可參考物件線上的相關產品。當然這只是一家之言，僅供參考！

作者：韓鋒

首發於作者個人公號《韓鋒頻道》。

來源：宜信技術學院

混合事務分析處理“HTAP”的技術要點分析