HTAP(Hybrid Transaction and Analytical Processing)數(shù)據(jù)庫，也稱混合型關(guān)系數(shù)據(jù)庫，是能同時提供OLTP和OLAP的混合關(guān)系型數(shù)據(jù)庫。在互聯(lián)網(wǎng)浪潮出現(xiàn)之前，企業(yè)的數(shù)據(jù)量普遍不大，特別是核心的業(yè)務(wù)數(shù)據(jù)，通常一個單機(jī)的數(shù)據(jù)庫就可以保存。那時候的存儲并不需要復(fù)雜的架構(gòu)，所有的線上請求OLTP和后臺分析OLAP都跑在同一個數(shù)據(jù)庫實例上。

隨著互聯(lián)網(wǎng)的發(fā)展，企業(yè)的業(yè)務(wù)數(shù)據(jù)量不斷增多，單機(jī)數(shù)據(jù)庫的容量限制制約了其在海量數(shù)據(jù)場景下的使用。因此在實際應(yīng)用中，為了面對各種需求，OLTP、OLAP 在技術(shù)上分道揚鑣，在很多企業(yè)架構(gòu)中，這兩類任務(wù)處理由不同團(tuán)隊完成，同時部署的OLAP和OLTP通過ETL進(jìn)行銜接。為了提升OLAP的性能，需要在ETL過程中進(jìn)行大量的預(yù)計算，包括數(shù)據(jù)結(jié)構(gòu)的調(diào)整和業(yè)務(wù)邏輯處理。這樣的好處是可以控制OLAP的訪問延遲，提升用戶體驗。但是，因為要避免抽取數(shù)據(jù)對OLTP系統(tǒng)造成影響，所以必須在日終的交易低谷期才能啟動ETL過程。這樣一來， OLAP與OLTP的數(shù)據(jù)延遲通常就在一天左右，習(xí)慣上大家把這種時效性表述為T+1。其中，T日就是指OLTP系統(tǒng)產(chǎn)生數(shù)據(jù)的日期，T+1日是OLAP中數(shù)據(jù)可用的日期，兩者間隔為1天。

這個時候我們會發(fā)現(xiàn)，這個體系的主要問題就是OLAP系統(tǒng)的數(shù)據(jù)時效性，T+1太慢了。隨著大數(shù)據(jù)時代互聯(lián)網(wǎng)的高速發(fā)展，商業(yè)決策更加注重數(shù)據(jù)的支撐，大量應(yīng)用要求對海量數(shù)據(jù)進(jìn)行實時更新和查詢，這都要求OLAP系統(tǒng)更快速地反映業(yè)務(wù)的變化。另一方面，企業(yè)需要維護(hù)不同的數(shù)據(jù)庫以便支持兩類不同的任務(wù)，管理和維護(hù)成本高。

因此，能夠統(tǒng)一支持事務(wù)處理和工作負(fù)載分析的數(shù)據(jù)庫成為眾多企業(yè)的需求。在此背景下，由 Gartner 提出的 HTAP成為希望?；趧?chuàng)新的計算存儲框架，HTAP 數(shù)據(jù)庫能夠在一份數(shù)據(jù)上同時支撐業(yè)務(wù)系統(tǒng)運行和 OLAP 場景，避免在傳統(tǒng)架構(gòu)中，在線與離線數(shù)據(jù)庫之間大量的數(shù)據(jù)交互。

我們了解了OLAP 數(shù)據(jù)庫和 OLTP 數(shù)據(jù)庫之后，我們再來考慮：HTAP=OLTP+OLAP，是這樣嗎？

我們來仔細(xì)考慮考慮，OLTP系統(tǒng)多為行存儲，主打高并發(fā)、低延時和高穩(wěn)定性，能夠?qū)崿F(xiàn)復(fù)雜的查詢操作以秒鐘級的響應(yīng)，適合經(jīng)常寫入的小型業(yè)務(wù)；而OLAP主要用于大規(guī)模的復(fù)雜查詢，持續(xù)時間很長，性能開銷極大，主要以讀取內(nèi)容為主，且依賴豐富的索引，常常按列存儲；如果他們部署在一起，OLAP的臨時查詢開銷可能會影響OLTP的寫入延時，另外很多OLTP數(shù)據(jù)庫在執(zhí)行OLAP業(yè)務(wù)時，仍然需要將行存數(shù)據(jù)轉(zhuǎn)儲到列存表中，這樣也會大大的影響業(yè)務(wù)執(zhí)行效率。

現(xiàn)實情況是，對HTAP的需求，日常還是以O(shè)LTP為主，但也需要對數(shù)據(jù)進(jìn)行加工，以保證偶爾的OLAP工作負(fù)載，這里說的OLAP場景并不是真正意義上的OLAP，它只為了提升在OLTP系統(tǒng)中執(zhí)行復(fù)雜查詢的性能。所以大部分的HTAP并不完整包含OLAP的完整功能，且他們的OLAP功能整體比較弱，只是滿足偶爾提取一些需要用于分析的少量數(shù)據(jù)。

在實際的使用過程中，很多企業(yè)為了實現(xiàn)HTAP，是花了不少代價的。選型過程中功能需要考慮的因素包括：數(shù)據(jù)存儲格式、SQL引擎的效率、OLTP/OLAP的資源隔離與防干擾措施、數(shù)據(jù)有幾份備份、如何避免大型集群產(chǎn)生數(shù)據(jù)沼澤等等?？梢哉f綜合性能和成本來考量，對于很多企業(yè)，HTAP并不能是OLAP的替代方案。

在大數(shù)據(jù)不斷高速發(fā)展的時代，當(dāng)您的企業(yè)發(fā)現(xiàn)傳統(tǒng)的數(shù)據(jù)庫已經(jīng)不能滿足業(yè)務(wù)需求，需要選型OLAP或者HTAP來解決OLAP需求時，重要考慮哪些影響數(shù)據(jù)使用的因素呢？

1. SQL能力：是否具備完善的SQL標(biāo)準(zhǔn)和ACID特性，支持對接和兼容常用的開源組件，來保障用戶輕松實現(xiàn)不同數(shù)據(jù)基礎(chǔ)設(shè)施的平穩(wěn)遷移。
2. 實時性：在瞬息萬變的商業(yè)社會，要盡快的做出決策需要進(jìn)行實時的數(shù)據(jù)分析和數(shù)據(jù)服務(wù)。正如我們剛才分析的，HTAP要兼容OLAP和OLTP場景，往往很難保證全量數(shù)據(jù)T+0實時性。
3. 高并發(fā)：在需要大量使用高并發(fā)OLAP的場景，HTAP如何滿足；同時，還需要考慮高負(fù)載運行時對OLTP業(yè)務(wù)的影響。
4. 擴(kuò)展能力：當(dāng)計算和存儲需要擴(kuò)展時，不同的架構(gòu)的數(shù)據(jù)庫會有不同的擴(kuò)容方式，相對而言，存算分離的數(shù)據(jù)庫可以自由增減計算和存儲資源，按需付費節(jié)約成本。

按照上述的參考，您在選型OLAP或者HTAP時，如果希望獲得支持存算分離、分布式事務(wù)處理、SQL 兼容性、云化彈性供給、Hadoop 生態(tài)、性能優(yōu)化等關(guān)鍵特性的解決方案，以此來助力企業(yè)實現(xiàn)降成本、提性能、全融合的大數(shù)據(jù)建設(shè)目標(biāo)，建議選擇Snowflake、Databricks、OushuDB 這一類云原生數(shù)據(jù)平臺，它們突破了傳統(tǒng) MPP 和 Hadoop 的局限性，實現(xiàn)了上述的存算完全分離，計算和存儲可部署在不同物理集群，并通過虛擬計算集群技術(shù)實現(xiàn)了高并發(fā)，同時保障事務(wù)支持。近兩年，國內(nèi)也誕生了全實時 Omega 架構(gòu)的湖倉一體，甚至可以完成全量數(shù)據(jù) "T+0"的流處理和實時按需查詢，擺脫了"T+1"的傳統(tǒng)痛點，強(qiáng)大的云原生OLAP也有效解決了HTAP面對海量數(shù)據(jù)管理的問題。