HTAP是近些年來比較火的一個概念，下面就聊聊其前世今生及技術特點。

1. 數據應用類別

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

1).OLTP

聯機事務處理OLTP

（On-Line Transaction Processing）

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

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

2).OLAP

聯機實時分析OLAP

（On-Line Analytical Processing）

OLAP是面向數據分析的，也稱為面向信息分析處理過程。它使分析人員能夠迅速、一致、交互地從各個方面觀察信息，以達到深入理解數據的目的。其特征是應對海量數據，支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果。例如數據倉庫是其典型的OLAP系統。其具備以下特點：

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

3).OTHER

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

• 多模 隨著業務“互聯網化”和“智能化”的發展以及架構 “微服務”和“云化”的發展，應用系統對數據的存儲管理提出了新的標準和要求，數據的多樣性成為突出的問題。早期數據庫主要面對結構化數據的處理場景。后面隨著業務的發展，逐漸產生了對非結構化數據的處理需求。包括結構化數據、半結構化(JSON、XML等)數據、文本數據、地理空間數據、圖數據、音視頻數據等。多模，正是指單一數據庫支持多種類型數據的存儲與處理。
• 流式 流式處理(實時計算)，是來源于對數據加工時效性的需求。數據的業務價值隨著時間的流失而迅速降低，因此在數據發生后必須盡快對其進行計算和處理。傳統基于周期類的處理方式，顯然無法滿足需求。隨著移動互聯網、物聯網和傳感器的發展導致大量的流式數據產生。相應地出現了專有的流式數據處理平臺，如Storm、Kafka等。近些年來，很多數據庫開始支持流式數據處理，例如MemSQL、PipelineDB。有些專有流式數據處理平臺開始提供SQL接口，例如KSQL基于Kafka提供了流式SQL處理引擎。
• 高階 隨著對數據使用的深入，數據的使用不再僅僅以簡單的增刪改查或分組聚合類操作，而對于其更為高階的使用也逐步引起大家的重視。例如使用機器學習、統計分析和模式識別等算法，對數據進行分析等。

對比 — OLAP vs OLTP

2. 數據處理模式

面對上述復雜多變的應用場景，數據應用的多種類別，是由單一平臺處理，還是由不同平臺來處理呢？一般來說，專有系統的性能將比通用系統性能高一到兩個數量級，因而不同的業務應采用不同的系統。但正如古人說“天下大勢、分久必合、合久必分”，在數據處理領域也有一種趨勢，由單一平臺來處理。這里選擇的核心在于如何來辯證看待需求和技術。它們是一對矛盾體，當這對矛盾緩和時，數據處理領域將更趨向于整合；而當這對矛盾尖銳時，數據處理領域將趨于分散。就軟硬件技術發展現狀和當前需求來看，未來整合的趨勢更為明顯。集成數據平臺將能滿足絕大多數用戶的場景，只有極少數企業需要使用專有系統來實現其特殊的需求。

1).分散式（專有平臺）

目前比較常規的方式，是采用多個專有平臺，來針對不同場景進行數據處理。因此是跨平臺的，因此是有個數據傳輸的過程。這之中會帶來兩個問題：數據同步、數據冗余。數據同步的核心是數據時效性問題，過期的數據往往會喪失價值。常見的做法如下:

OLTP系統中的數據變化，通過日志的形式暴露出來；通過消息隊列解耦傳輸；后端的ETL消費拉取，將數據同步到OLAP中。整個鏈條較長，對于時效性要求較高的場景是個考驗。此外，數據在鏈條中流動，是存在多份的數據冗余保存。在常規的高可用環境下，數據會進一步保存多份。因此這里面隱藏了比較大的技術、人力成本以及數據同步成本。而且橫跨如此之多的技術棧、數據庫產品，每個技術棧背后又需要單獨的團隊支持和維護，如DBA、大數據、基礎架構等。這些都蘊含著巨大的人力、技術、時間、運維成本。正是出于在滿足各種業務需求的同時，提高時效性，減低數據冗余、縮短鏈條等，收斂技術棧就變得很重要。這也是通用類平臺解決方案，誕生的出發點。

2).集中式（通用平臺）

用戶厭倦了為不同的數據處理采用不同的數據處理系統，更傾向于采用集成數據處理平臺來處理企業的各種數據類型。對于融合了聯機事務處理和聯機實時分析的場景，也就是下面所談到的HTAP。此類通用平臺方案具備下面優點：

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

3. HTAP

HTAP數據庫（Hybrid Transaction and Analytical Process，混合事務和分析處理）。2014年Gartner的一份報告中使用混合事務分析處理(HTAP)一詞描述新型的應用程序框架，以打破OLTP和OLAP之間的隔閡，既可以應用于事務型數據庫場景，亦可以應用于分析型數據庫場景。實現實時業務決策。這種架構具有顯而易見的優勢：不但避免了繁瑣且昂貴的ETL操作，而且可以更快地對最新數據進行分析。這種快速分析數據的能力將成為未來企業的核心競爭力之一。

1).技術要點

• 底層數據要么只有一份，要么可快速復制，并且同時滿足高并發的實時更新。
• 要滿足海量數據的容量問題，在存儲、計算都具有很好的線性擴展能力。
• 具有很好的優化器，可滿足事務類、分析類的語句需求。
• 具備標準的SQL，并支持諸如二級索引、分區、列式存儲、向量化計算等技術。

2).重點技術 – 行列存儲

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

列式存儲（Column-based）是相對于行式存儲來說的，新興的Hbase、HP Vertica、EMC Greenplum 等分布式數據庫均采用列式存儲。在基于列式存儲的數據庫中，數據是按照列為基礎邏輯存儲單元進行存儲的，一列中的數據在存儲介質中以連續存儲形式存在。

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

3).重點技術 – MPP

MPP (Massively Parallel Processing)，即大規模并行處理，在數據庫非共享集群中，每個節點都有獨立的磁盤存儲系統和內存系統，業務數據根據數據庫模型和應用特點劃分到各個節點上，每臺數據節點通過專用網絡或者商業通用網絡互相連接，彼此協同計算，作為整體提供數據庫服務。非共享數據庫集群有完全的可伸縮性、高可用、高性能、優秀的性價比、資源共享等優勢。簡單來說，MPP是將任務并行的分散到多個服務器和節點上，在每個節點上計算完成后，將各自部分的結果匯總在一起得到最終的結果。下面以典型的MPP產品Greenplum架構為例。

4).重點技術 – 資源隔離

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

5).HTAP產品

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

總結

以上是生活随笔為你收集整理的HTAP与OLAPOLTP之间的关系的全部內容，希望文章能夠幫你解決所遇到的問題。

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