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

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

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

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

我們了解了OLAP 數(shù)據(jù)庫(kù)和 OLTP 數(shù)據(jù)庫(kù)之后，我們?cè)賮?lái)考慮：HTAP=OLTP+OLAP，是這樣嗎？

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

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

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

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

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

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