HTAP是近些年來比較火的一個概念眨补，下面就聊聊其前世今生及技術(shù)特點旗笔。
1. 數(shù)據(jù)應(yīng)用類別
根據(jù)數(shù)據(jù)的使用特征，可簡單做如下劃分斩箫。在選擇技術(shù)平臺之前吏砂，我們需要做好這樣的定位。
1).OLTP
聯(lián)機事務(wù)處理OLTP
（On-Line Transaction Processing）
OLTP是事件驅(qū)動乘客、面向應(yīng)用的狐血，也稱為面向交易的處理過程。其基本特征是前臺接收的用戶數(shù)據(jù)可以立即傳送到計算中心進行處理易核，并在很短的時間內(nèi)給出處理結(jié)果匈织，是對用戶操作的快速響應(yīng)。例如銀行類牡直、電子商務(wù)類的交易系統(tǒng)就是典型的OLTP系統(tǒng)缀匕。其具備以下特點：
- 直接面向應(yīng)用，數(shù)據(jù)在系統(tǒng)中產(chǎn)生碰逸。
- 基于交易的處理系統(tǒng)乡小。
- 每次交易牽涉的數(shù)據(jù)量很小饵史；對響應(yīng)時間要求非常高满钟。
- 用戶數(shù)量非常龐大，其用戶是操作人員胳喷，并發(fā)度很高零远。
- 數(shù)據(jù)庫的各種操作主要基于索引進行。
- 以SQL作為交互載體厌蔽。
- 總體數(shù)據(jù)量相對較小牵辣。
2).OLAP
聯(lián)機實時分析OLAP
（On-Line Analytical Processing）
OLAP是面向數(shù)據(jù)分析的，也稱為面向信息分析處理過程奴饮。它使分析人員能夠迅速纬向、一致、交互地從各個方面觀察信息戴卜，以達到深入理解數(shù)據(jù)的目的逾条。其特征是應(yīng)對海量數(shù)據(jù)，支持復雜的分析操作投剥，側(cè)重決策支持师脂，并且提供直觀易懂的查詢結(jié)果。例如數(shù)據(jù)倉庫是其典型的OLAP系統(tǒng)。其具備以下特點：
- 本身不產(chǎn)生數(shù)據(jù)吃警，其基礎(chǔ)數(shù)據(jù)來源于生產(chǎn)系統(tǒng)中的操作數(shù)據(jù)
- 基于查詢的分析系統(tǒng)糕篇；復雜查詢經(jīng)常使用多表聯(lián)結(jié)、全表掃描等酌心，牽涉的數(shù)量往往十分龐大
- 每次查詢設(shè)計的數(shù)據(jù)量很大拌消，響應(yīng)時間與具體查詢有很大關(guān)系
- 用戶數(shù)量相對較小，其用戶主要是業(yè)務(wù)人員與管理人員
- 由于業(yè)務(wù)問題不固定安券，數(shù)據(jù)庫的各種操作不能完全基于索引進行
- 以SQL為主要載體墩崩，也支持語言類交互
- 總體數(shù)據(jù)量相對較大
3).OTHER
除了傳統(tǒng)的OLTP、OLAP類侯勉，近些年來針對數(shù)據(jù)的使用又有些新特點鹦筹，我將其歸入了“其他”類。
- 多模 隨著業(yè)務(wù)“互聯(lián)網(wǎng)化”和“智能化”的發(fā)展以及架構(gòu) “微服務(wù)”和“云化”的發(fā)展址貌，應(yīng)用系統(tǒng)對數(shù)據(jù)的存儲管理提出了新的標準和要求铐拐，數(shù)據(jù)的多樣性成為突出的問題。早期數(shù)據(jù)庫主要面對結(jié)構(gòu)化數(shù)據(jù)的處理場景芳誓。后面隨著業(yè)務(wù)的發(fā)展余舶，逐漸產(chǎn)生了對非結(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ù)庫支持多種類型數(shù)據(jù)的存儲與處理政恍。
- 流式 流式處理(實時計算)汪拥，是來源于對數(shù)據(jù)加工時效性的需求。數(shù)據(jù)的業(yè)務(wù)價值隨著時間的流失而迅速降低篙耗，因此在數(shù)據(jù)發(fā)生后必須盡快對其進行計算和處理迫筑。傳統(tǒng)基于周期類的處理方式，顯然無法滿足需求宗弯。隨著移動互聯(lián)網(wǎng)脯燃、物聯(lián)網(wǎng)和傳感器的發(fā)展導致大量的流式數(shù)據(jù)產(chǎn)生。相應(yīng)地出現(xiàn)了專有的流式數(shù)據(jù)處理平臺蒙保，如Storm辕棚、Kafka等。近些年來，很多數(shù)據(jù)庫開始支持流式數(shù)據(jù)處理逝嚎，例如MemSQL扁瓢、PipelineDB。有些專有流式數(shù)據(jù)處理平臺開始提供SQL接口懈糯，例如KSQL基于Kafka提供了流式SQL處理引擎涤妒。
- 高階 隨著對數(shù)據(jù)使用的深入，數(shù)據(jù)的使用不再僅僅以簡單的增刪改查或分組聚合類操作赚哗，而對于其更為高階的使用也逐步引起大家的重視她紫。例如使用機器學習、統(tǒng)計分析和模式識別等算法屿储，對數(shù)據(jù)進行分析等贿讹。
對比 — OLAP vs OLTP
2. 數(shù)據(jù)處理模式
面對上述復雜多變的應(yīng)用場景，數(shù)據(jù)應(yīng)用的多種類別够掠，是由單一平臺處理民褂，還是由不同平臺來處理呢？一般來說疯潭，專有系統(tǒng)的性能將比通用系統(tǒng)性能高一到兩個數(shù)量級赊堪，因而不同的業(yè)務(wù)應(yīng)采用不同的系統(tǒng)。但正如古人說“天下大勢竖哩、分久必合哭廉、合久必分”，在數(shù)據(jù)處理領(lǐng)域也有一種趨勢相叁，由單一平臺來處理遵绰。這里選擇的核心在于如何來辯證看待需求和技術(shù)。它們是一對矛盾體增淹，當這對矛盾緩和時椿访，數(shù)據(jù)處理領(lǐng)域?qū)⒏呄蛴谡希欢斶@對矛盾尖銳時虑润，數(shù)據(jù)處理領(lǐng)域?qū)②呌诜稚⒊擅怠＞蛙浻布夹g(shù)發(fā)展現(xiàn)狀和當前需求來看，未來整合的趨勢更為明顯拳喻。集成數(shù)據(jù)平臺將能滿足絕大多數(shù)用戶的場景哭当，只有極少數(shù)企業(yè)需要使用專有系統(tǒng)來實現(xiàn)其特殊的需求。
1).分散式（專有平臺）
目前比較常規(guī)的方式舞蔽，是采用多個專有平臺荣病，來針對不同場景進行數(shù)據(jù)處理。因此是跨平臺的渗柿，因此是有個數(shù)據(jù)傳輸?shù)倪^程个盆。這之中會帶來兩個問題：數(shù)據(jù)同步脖岛、數(shù)據(jù)冗余。數(shù)據(jù)同步的核心是數(shù)據(jù)時效性問題颊亮，過期的數(shù)據(jù)往往會喪失價值柴梆。常見的做法如下:
OLTP系統(tǒng)中的數(shù)據(jù)變化，通過日志的形式暴露出來终惑；通過消息隊列解耦傳輸绍在；后端的ETL消費拉取，將數(shù)據(jù)同步到OLAP中雹有。整個鏈條較長偿渡，對于時效性要求較高的場景是個考驗。此外霸奕，數(shù)據(jù)在鏈條中流動溜宽，是存在多份的數(shù)據(jù)冗余保存。在常規(guī)的高可用環(huán)境下质帅，數(shù)據(jù)會進一步保存多份适揉。因此這里面隱藏了比較大的技術(shù)、人力成本以及數(shù)據(jù)同步成本煤惩。而且橫跨如此之多的技術(shù)棧嫉嘀、數(shù)據(jù)庫產(chǎn)品，每個技術(shù)棧背后又需要單獨的團隊支持和維護魄揉，如DBA剪侮、大數(shù)據(jù)、基礎(chǔ)架構(gòu)等什猖。這些都蘊含著巨大的人力票彪、技術(shù)红淡、時間不狮、運維成本。正是出于在滿足各種業(yè)務(wù)需求的同時在旱，提高時效性摇零，減低數(shù)據(jù)冗余、縮短鏈條等桶蝎，收斂技術(shù)棧就變得很重要驻仅。這也是通用類平臺解決方案，誕生的出發(fā)點登渣。
2).集中式（通用平臺）
用戶厭倦了為不同的數(shù)據(jù)處理采用不同的數(shù)據(jù)處理系統(tǒng)噪服，更傾向于采用集成數(shù)據(jù)處理平臺來處理企業(yè)的各種數(shù)據(jù)類型。對于融合了聯(lián)機事務(wù)處理和聯(lián)機實時分析的場景胜茧，也就是下面所談到的HTAP粘优。此類通用平臺方案具備下面優(yōu)點：
- 通過數(shù)據(jù)整合避免信息孤島仇味，便于共享和統(tǒng)一數(shù)據(jù)管理。
- 基于SQL的數(shù)據(jù)集成平臺可提供良好的數(shù)據(jù)獨立性雹顺，使應(yīng)用能專注于業(yè)務(wù)邏輯丹墨，不用關(guān)心數(shù)據(jù)的底層操作細節(jié)。
- 集成數(shù)據(jù)平臺能提供更好的實時性和更全的數(shù)據(jù)嬉愧，為業(yè)務(wù)提供更快更準的分析和決策贩挣。
- 能夠避免各種系統(tǒng)之間的膠合，企業(yè)總體技術(shù)架構(gòu)簡單没酣，不需要復雜的數(shù)據(jù)導入/導出等王财，易于管理和維護。
- 便于人才培養(yǎng)和知識共享裕便，無須為各種專有系統(tǒng)培養(yǎng)開發(fā)搪搏、運維和管理人才。
3. HTAP
HTAP數(shù)據(jù)庫（Hybrid Transaction and Analytical Process闪金，混合事務(wù)和分析處理）疯溺。2014年Gartner的一份報告中使用混合事務(wù)分析處理(HTAP)一詞描述新型的應(yīng)用程序框架，以打破OLTP和OLAP之間的隔閡哎垦，既可以應(yīng)用于事務(wù)型數(shù)據(jù)庫場景囱嫩，亦可以應(yīng)用于分析型數(shù)據(jù)庫場景。實現(xiàn)實時業(yè)務(wù)決策漏设。這種架構(gòu)具有顯而易見的優(yōu)勢：不但避免了繁瑣且昂貴的ETL操作墨闲，而且可以更快地對最新數(shù)據(jù)進行分析。這種快速分析數(shù)據(jù)的能力將成為未來企業(yè)的核心競爭力之一郑口。
1).技術(shù)要點
- 底層數(shù)據(jù)要么只有一份鸳碧，要么可快速復制，并且同時滿足高并發(fā)的實時更新犬性。
- 要滿足海量數(shù)據(jù)的容量問題瞻离，在存儲、計算都具有很好的線性擴展能力乒裆。
- 具有很好的優(yōu)化器套利，可滿足事務(wù)類、分析類的語句需求鹤耍。
- 具備標準的SQL肉迫，并支持諸如二級索引、分區(qū)稿黄、列式存儲喊衫、向量化計算等技術(shù)。
2).重點技術(shù) – 行列存儲
行存儲（Row-based）：對于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫杆怕，比如甲骨文的OracleDB和MySQL族购，IBM的DB2鼻听、微軟的SQL Server等，一般都是采用行存儲（Row-based）行联四。在基于行式存儲的數(shù)據(jù)庫中撑碴，數(shù)據(jù)是按照行數(shù)據(jù)為基礎(chǔ)邏輯存儲單元進行存儲的，一行中的數(shù)據(jù)在存儲介質(zhì)中以連續(xù)存儲形式存在朝墩。
列式存儲（Column-based）是相對于行式存儲來說的醉拓，新興的Hbase、HP Vertica收苏、EMC Greenplum 等分布式數(shù)據(jù)庫均采用列式存儲亿卤。在基于列式存儲的數(shù)據(jù)庫中，數(shù)據(jù)是按照列為基礎(chǔ)邏輯存儲單元進行存儲的鹿霸，一列中的數(shù)據(jù)在存儲介質(zhì)中以連續(xù)存儲形式存在排吴。
傳統(tǒng)的行式數(shù)據(jù)庫，是按照行存儲的懦鼠，維護大量的索引和物化視圖無論是在時間（處理）還是空間（存儲）面成本都很高钻哩。而列式數(shù)據(jù)庫恰恰相反，列式數(shù)據(jù)庫的數(shù)據(jù)是按照列存儲肛冶，每一列單獨存放街氢，數(shù)據(jù)即是索引。只訪問查詢涉及的列睦袖，大大降低了系統(tǒng)I/O珊肃，每一列由一個線來處理，而且由于數(shù)據(jù)類型一致馅笙，數(shù)據(jù)特征相似伦乔，極大方便壓縮。
3).重點技術(shù) – MPP
MPP (Massively Parallel Processing)董习，即大規(guī)模并行處理烈和，在數(shù)據(jù)庫非共享集群中，每個節(jié)點都有獨立的磁盤存儲系統(tǒng)和內(nèi)存系統(tǒng)阱飘，業(yè)務(wù)數(shù)據(jù)根據(jù)數(shù)據(jù)庫模型和應(yīng)用特點劃分到各個節(jié)點上斥杜，每臺數(shù)據(jù)節(jié)點通過專用網(wǎng)絡(luò)或者商業(yè)通用網(wǎng)絡(luò)互相連接虱颗，彼此協(xié)同計算沥匈，作為整體提供數(shù)據(jù)庫服務(wù)。非共享數(shù)據(jù)庫集群有完全的可伸縮性忘渔、高可用高帖、高性能、優(yōu)秀的性價比畦粮、資源共享等優(yōu)勢散址。簡單來說乖阵，MPP是將任務(wù)并行的分散到多個服務(wù)器和節(jié)點上，在每個節(jié)點上計算完成后预麸，將各自部分的結(jié)果匯總在一起得到最終的結(jié)果瞪浸。下面以典型的MPP產(chǎn)品Greenplum架構(gòu)為例。
4).重點技術(shù) – 資源隔離
OLTP吏祸、OLAP類兩者對資源的使用特點不同对蒲，需要在資源層面做好隔離工作，避免相互影響贡翘。常見的通過定義資源隊列的方式蹈矮，指定用戶分配隊列，起到資源隔離的作用鸣驱。
5).HTAP產(chǎn)品
下圖是網(wǎng)站找到的數(shù)據(jù)庫產(chǎn)品分類圖泛鸟，針對HTAP類的可參考對象線上的相關(guān)產(chǎn)品。當然這只是一家之言踊东，僅供參考北滥！
本文分享自微信公眾號 - 韓鋒頻道（hanfeng_channel），作者：韓鋒頻道
