文章轉(zhuǎn)載自： 淺談“HTAP”，僅用于學(xué)習(xí)，如有侵權(quán)，請(qǐng)聯(lián)系刪除。

HTAP是近些年來(lái)比較火的一個(gè)概念，下面就聊聊其前世今生及技術(shù)特點(diǎn)。

1. 數(shù)據(jù)應(yīng)用類(lèi)別

根據(jù)數(shù)據(jù)的使用特征，可簡(jiǎn)單做如下劃分。在選擇技術(shù)平臺(tái)之前，我們需要做好這樣的定位。

1.1 OLTP

聯(lián)機(jī)事務(wù)處理OLTP（On-Line Transaction Processing），OLTP是事件驅(qū)動(dòng)、面向應(yīng)用的，也稱(chēng)為面向交易的處理過(guò)程。其基本特征是前臺(tái)接收的用戶(hù)數(shù)據(jù)可以立即傳送到計(jì)算中心進(jìn)行處理，并在很短的時(shí)間內(nèi)給出處理結(jié)果，是對(duì)用戶(hù)操作的快速響應(yīng)。例如銀行類(lèi)、電子商務(wù)類(lèi)的交易系統(tǒng)就是典型的OLTP系統(tǒng)。其具備以下特點(diǎn)：

• 直接面向應(yīng)用，數(shù)據(jù)在系統(tǒng)中產(chǎn)生。
• 基于交易的處理系統(tǒng)。
• 每次交易牽涉的數(shù)據(jù)量很小；對(duì)響應(yīng)時(shí)間要求非常高。
• 用戶(hù)數(shù)量非常龐大，其用戶(hù)是操作人員，并發(fā)度很高。
• 數(shù)據(jù)庫(kù)的各種操作主要基于索引進(jìn)行。
• 以SQL作為交互載體。
• 總體數(shù)據(jù)量相對(duì)較小。

1.2 OLAP

聯(lián)機(jī)實(shí)時(shí)分析OLAP（On-Line Analytical Processing），OLAP是面向數(shù)據(jù)分析的，也稱(chēng)為面向信息分析處理過(guò)程。它使分析人員能夠迅速、一致、交互地從各個(gè)方面觀察信息，以達(dá)到深入理解數(shù)據(jù)的目的。其特征是應(yīng)對(duì)海量數(shù)據(jù)，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢(xún)結(jié)果。例如數(shù)據(jù)倉(cāng)庫(kù)是其典型的OLAP系統(tǒng)。其具備以下特點(diǎn)：

• 本身不產(chǎn)生數(shù)據(jù)，其基礎(chǔ)數(shù)據(jù)來(lái)源于生產(chǎn)系統(tǒng)中的操作數(shù)據(jù)
• 基于查詢(xún)的分析系統(tǒng)；復(fù)雜查詢(xún)經(jīng)常使用多表聯(lián)結(jié)、全表掃描等，牽涉的數(shù)量往往十分龐大
• 每次查詢(xún)?cè)O(shè)計(jì)的數(shù)據(jù)量很大，響應(yīng)時(shí)間與具體查詢(xún)有很大關(guān)系
• 用戶(hù)數(shù)量相對(duì)較小，其用戶(hù)主要是業(yè)務(wù)人員與管理人員
• 由于業(yè)務(wù)問(wèn)題不固定，數(shù)據(jù)庫(kù)的各種操作不能完全基于索引進(jìn)行
• 以SQL為主要載體，也支持語(yǔ)言類(lèi)交互
• 總體數(shù)據(jù)量相對(duì)較大

1.3 OTHER

除了傳統(tǒng)的OLTP、OLAP類(lèi)，近些年來(lái)針對(duì)數(shù)據(jù)的使用又有些新特點(diǎn)，我將其歸入了“其他”類(lèi)。

1) 多模

隨著業(yè)務(wù)“互聯(lián)網(wǎng)化”和“智能化”的發(fā)展以及架構(gòu) “微服務(wù)”和“云化”的發(fā)展，應(yīng)用系統(tǒng)對(duì)數(shù)據(jù)的存儲(chǔ)管理提出了新的標(biāo)準(zhǔn)和要求，數(shù)據(jù)的多樣性成為突出的問(wèn)題。早期數(shù)據(jù)庫(kù)主要面對(duì)結(jié)構(gòu)化數(shù)據(jù)的處理場(chǎng)景。后面隨著業(yè)務(wù)的發(fā)展，逐漸產(chǎn)生了對(duì)非結(jié)構(gòu)化數(shù)據(jù)的處理需求。包括結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化(JSON、XML等)數(shù)據(jù)、文本數(shù)據(jù)、地理空間數(shù)據(jù)、圖數(shù)據(jù)、音視頻數(shù)據(jù)等。多模，正是指單一數(shù)據(jù)庫(kù)支持多種類(lèi)型數(shù)據(jù)的存儲(chǔ)與處理。

2) 流式

流式處理(實(shí)時(shí)計(jì)算)，是來(lái)源于對(duì)數(shù)據(jù)加工時(shí)效性的需求。數(shù)據(jù)的業(yè)務(wù)價(jià)值隨著時(shí)間的流失而迅速降低，因此在數(shù)據(jù)發(fā)生后必須盡快對(duì)其進(jìn)行計(jì)算和處理。傳統(tǒng)基于周期類(lèi)的處理方式，顯然無(wú)法滿(mǎn)足需求。隨著移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)和傳感器的發(fā)展導(dǎo)致大量的流式數(shù)據(jù)產(chǎn)生。相應(yīng)地出現(xiàn)了專(zhuān)有的流式數(shù)據(jù)處理平臺(tái)，如Storm、Kafka等。近些年來(lái)，很多數(shù)據(jù)庫(kù)開(kāi)始支持流式數(shù)據(jù)處理，例如MemSQL、PipelineDB。有些專(zhuān)有流式數(shù)據(jù)處理平臺(tái)開(kāi)始提供SQL接口，例如KSQL基于Kafka提供了流式SQL處理引擎。

3) 高階

隨著對(duì)數(shù)據(jù)使用的深入，數(shù)據(jù)的使用不再僅僅以簡(jiǎn)單的增刪改查或分組聚合類(lèi)操作，而對(duì)于其更為高階的使用也逐步引起大家的重視。例如使用機(jī)器學(xué)習(xí)、統(tǒng)計(jì)分析和模式識(shí)別等算法，對(duì)數(shù)據(jù)進(jìn)行分析等。

1.4 對(duì)比 — OLTP vs OLAP

2. 數(shù)據(jù)處理模式

面對(duì)上述復(fù)雜多變的應(yīng)用場(chǎng)景，數(shù)據(jù)應(yīng)用的多種類(lèi)別，是由單一平臺(tái)處理，還是由不同平臺(tái)來(lái)處理呢？一般來(lái)說(shuō)，專(zhuān)有系統(tǒng)的性能將比通用系統(tǒng)性能高一到兩個(gè)數(shù)量級(jí)，因而不同的業(yè)務(wù)應(yīng)采用不同的系統(tǒng)。但正如古人說(shuō)“天下大勢(shì)、分久必合、合久必分”，在數(shù)據(jù)處理領(lǐng)域也有一種趨勢(shì)，由單一平臺(tái)來(lái)處理。這里選擇的核心在于如何來(lái)辯證看待需求和技術(shù)。它們是一對(duì)矛盾體，當(dāng)這對(duì)矛盾緩和時(shí)，數(shù)據(jù)處理領(lǐng)域?qū)⒏呄蛴谡?#xff1b;而當(dāng)這對(duì)矛盾尖銳時(shí)，數(shù)據(jù)處理領(lǐng)域?qū)②呌诜稚ⅰ＞蛙浻布夹g(shù)發(fā)展現(xiàn)狀和當(dāng)前需求來(lái)看，未來(lái)整合的趨勢(shì)更為明顯。集成數(shù)據(jù)平臺(tái)將能滿(mǎn)足絕大多數(shù)用戶(hù)的場(chǎng)景，只有極少數(shù)企業(yè)需要使用專(zhuān)有系統(tǒng)來(lái)實(shí)現(xiàn)其特殊的需求。

2.1 分散式（專(zhuān)有平臺(tái)）

目前比較常規(guī)的方式，是采用多個(gè)專(zhuān)有平臺(tái)，來(lái)針對(duì)不同場(chǎng)景進(jìn)行數(shù)據(jù)處理。因此是跨平臺(tái)的，因此是有個(gè)數(shù)據(jù)傳輸?shù)倪^(guò)程。這之中會(huì)帶來(lái)兩個(gè)問(wèn)題：數(shù)據(jù)同步、數(shù)據(jù)冗余。數(shù)據(jù)同步的核心是數(shù)據(jù)時(shí)效性問(wèn)題，過(guò)期的數(shù)據(jù)往往會(huì)喪失價(jià)值。常見(jiàn)的做法如下:

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

2.2 集中式（通用平臺(tái)）

用戶(hù)厭倦了為不同的數(shù)據(jù)處理采用不同的數(shù)據(jù)處理系統(tǒng)，更傾向于采用集成數(shù)據(jù)處理平臺(tái)來(lái)處理企業(yè)的各種數(shù)據(jù)類(lèi)型。對(duì)于融合了聯(lián)機(jī)事務(wù)處理和聯(lián)機(jī)實(shí)時(shí)分析的場(chǎng)景，也就是下面所談到的HTAP。

此類(lèi)通用平臺(tái)方案具備下面優(yōu)點(diǎn)：

• 通過(guò)數(shù)據(jù)整合避免信息孤島，便于共享和統(tǒng)一數(shù)據(jù)管理。
• 基于SQL的數(shù)據(jù)集成平臺(tái)可提供良好的數(shù)據(jù)獨(dú)立性，使應(yīng)用能專(zhuān)注于業(yè)務(wù)邏輯，不用關(guān)心數(shù)據(jù)的底層操作細(xì)節(jié)。
• 集成數(shù)據(jù)平臺(tái)能提供更好的實(shí)時(shí)性和更全的數(shù)據(jù)，為業(yè)務(wù)提供更快更準(zhǔn)的分析和決策。
• 能夠避免各種系統(tǒng)之間的膠合，企業(yè)總體技術(shù)架構(gòu)簡(jiǎn)單，不需要復(fù)雜的數(shù)據(jù)導(dǎo)入/導(dǎo)出等，易于管理和維護(hù)。
• 便于人才培養(yǎng)和知識(shí)共享，無(wú)須為各種專(zhuān)有系統(tǒng)培養(yǎng)開(kāi)發(fā)、運(yùn)維和管理人才。

3. HTAP

HTAP數(shù)據(jù)庫(kù)（Hybrid Transaction and Analytical Process，混合事務(wù)和分析處理）。2014年Gartner的一份報(bào)告中使用混合事務(wù)分析處理(HTAP)一詞描述新型的應(yīng)用程序框架，以打破OLTP和OLAP之間的隔閡，既可以應(yīng)用于事務(wù)型數(shù)據(jù)庫(kù)場(chǎng)景，亦可以應(yīng)用于分析型數(shù)據(jù)庫(kù)場(chǎng)景。實(shí)現(xiàn)實(shí)時(shí)業(yè)務(wù)決策。這種架構(gòu)具有顯而易見(jiàn)的優(yōu)勢(shì)：不但避免了繁瑣且昂貴的ETL操作，而且可以更快地對(duì)最新數(shù)據(jù)進(jìn)行分析。這種快速分析數(shù)據(jù)的能力將成為未來(lái)企業(yè)的核心競(jìng)爭(zhēng)力之一。

3.1 技術(shù)要點(diǎn)

• 底層數(shù)據(jù)要么只有一份，要么可快速?gòu)?fù)制，并且同時(shí)滿(mǎn)足高并發(fā)的實(shí)時(shí)更新。
• 要滿(mǎn)足海量數(shù)據(jù)的容量問(wèn)題，在存儲(chǔ)、計(jì)算都具有很好的線(xiàn)性擴(kuò)展能力。
• 具有很好的優(yōu)化器，可滿(mǎn)足事務(wù)類(lèi)、分析類(lèi)的語(yǔ)句需求。
• 具備標(biāo)準(zhǔn)的SQL，并支持諸如二級(jí)索引、分區(qū)、列式存儲(chǔ)、向量化計(jì)算等技術(shù)。

3.2 重點(diǎn)技術(shù) – 行列存儲(chǔ)

行存儲(chǔ)（Row-based）：對(duì)于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，比如甲骨文的OracleDB和MySQL，IBM的DB2、微軟的SQL Server等，一般都是采用行存儲(chǔ)（Row-based）行。在基于行式存儲(chǔ)的數(shù)據(jù)庫(kù)中，數(shù)據(jù)是按照行數(shù)據(jù)為基礎(chǔ)邏輯存儲(chǔ)單元進(jìn)行存儲(chǔ)的，一行中的數(shù)據(jù)在存儲(chǔ)介質(zhì)中以連續(xù)存儲(chǔ)形式存在。

**列式存儲(chǔ)（Column-based）**是相對(duì)于行式存儲(chǔ)來(lái)說(shuō)的，新興的Hbase、HP Vertica、EMC Greenplum 等分布式數(shù)據(jù)庫(kù)均采用列式存儲(chǔ)。在基于列式存儲(chǔ)的數(shù)據(jù)庫(kù)中，數(shù)據(jù)是按照列為基礎(chǔ)邏輯存儲(chǔ)單元進(jìn)行存儲(chǔ)的，一列中的數(shù)據(jù)在存儲(chǔ)介質(zhì)中以連續(xù)存儲(chǔ)形式存在。

傳統(tǒng)的行式數(shù)據(jù)庫(kù)，是按照行存儲(chǔ)的，維護(hù)大量的索引和物化視圖無(wú)論是在時(shí)間（處理）還是空間（存儲(chǔ)）面成本都很高。而列式數(shù)據(jù)庫(kù)恰恰相反，列式數(shù)據(jù)庫(kù)的數(shù)據(jù)是按照列存儲(chǔ)，每一列單獨(dú)存放，數(shù)據(jù)即是索引。只訪問(wèn)查詢(xún)涉及的列，大大降低了系統(tǒng)I/O，每一列由一個(gè)線(xiàn)來(lái)處理，而且由于數(shù)據(jù)類(lèi)型一致，數(shù)據(jù)特征相似，極大方便壓縮。

3.3 重點(diǎn)技術(shù) – MPP

MPP (Massively Parallel Processing)，即大規(guī)模并行處理，在數(shù)據(jù)庫(kù)非共享集群中，每個(gè)節(jié)點(diǎn)都有獨(dú)立的磁盤(pán)存儲(chǔ)系統(tǒng)和內(nèi)存系統(tǒng)，業(yè)務(wù)數(shù)據(jù)根據(jù)數(shù)據(jù)庫(kù)模型和應(yīng)用特點(diǎn)劃分到各個(gè)節(jié)點(diǎn)上，每臺(tái)數(shù)據(jù)節(jié)點(diǎn)通過(guò)專(zhuān)用網(wǎng)絡(luò)或者商業(yè)通用網(wǎng)絡(luò)互相連接，彼此協(xié)同計(jì)算，作為整體提供數(shù)據(jù)庫(kù)服務(wù)。非共享數(shù)據(jù)庫(kù)集群有完全的可伸縮性、高可用、高性能、優(yōu)秀的性?xún)r(jià)比、資源共享等優(yōu)勢(shì)。簡(jiǎn)單來(lái)說(shuō)，MPP是將任務(wù)并行的分散到多個(gè)服務(wù)器和節(jié)點(diǎn)上，在每個(gè)節(jié)點(diǎn)上計(jì)算完成后，將各自部分的結(jié)果匯總在一起得到最終的結(jié)果。下面以典型的MPP產(chǎn)品Greenplum架構(gòu)為例。

3.4 重點(diǎn)技術(shù) – 資源隔離

OLTP、OLAP類(lèi)兩者對(duì)資源的使用特點(diǎn)不同，需要在資源層面做好隔離工作，避免相互影響。常見(jiàn)的通過(guò)定義資源隊(duì)列的方式，指定用戶(hù)分配隊(duì)列，起到資源隔離的作用。

3.5 HTAP產(chǎn)品

下圖是網(wǎng)站找到的數(shù)據(jù)庫(kù)產(chǎn)品分類(lèi)圖，針對(duì)HTAP類(lèi)的可參考對(duì)象線(xiàn)上的相關(guān)產(chǎn)品。當(dāng)然這只是一家之言，僅供參考！

總結(jié)

以上是生活随笔為你收集整理的浅谈“HTAP”的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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