混合事務分析處理「HTAP」的技術要點分析

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

1、數據應用類別

根據數據的使用特徵，可簡單作以下劃分。在選擇技術平臺以前，咱們須要作好這樣的定位。

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、數據處理模式

面對上述複雜多變的應用場景，數據應用的多種類別，是由單一平臺處理，仍是由不一樣平臺來處理呢？通常來講，專有系統的性能將比通用系統性能高一到兩個數量級，於是不一樣的業務應採用不一樣的系統。但正如古人說「天下大勢、分久必合、合久必分」，在數據處理領域也有一種趨勢，由單一平臺來處理。

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

2.1 分散式（專有平臺）

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

常見的作法以下:

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

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

2.2 集中式（通用平臺）

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

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

3、HTAP

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

這種架構具備顯而易見的優點：不但避免了繁瑣且昂貴的ETL操做，並且能夠更快地對最新數據進行分析。這種快速分析數據的能力將成爲將來企業的核心競爭力之一。

3.1 技術要點

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

3.2 重點技術 – 行列存儲

1）行存儲（Row-based）

對於傳統的關係型數據庫，好比甲骨文的OracleDB和MySQL，IBM的DB二、微軟的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類的可參考對象線上的相關產品。固然這只是一家之言，僅供參考！

做者：韓鋒

首發於做者我的公號《韓鋒頻道》。

來源：宜信技術學院