HTAP系統(tǒng)誕生的初衷，是要打破事務(wù)處理和分析處理的界限，使企業(yè)能通過HTAP系統(tǒng)更好地發(fā)現(xiàn)市場(chǎng)反饋，獲得更好的創(chuàng)新。但如何讓OLTP和OLAP在系統(tǒng)運(yùn)行的過程中相互干擾最小，卻成了HTAP系統(tǒng)面臨的難題。
總體來看，HTAP系統(tǒng)架構(gòu)的實(shí)踐可以分成兩類：一類是改革，另一類是改良。前者采用One size fits all的策略，用一個(gè)大而全的系統(tǒng)同時(shí)滿足OLTP和OLAP的需求，后者采用One size doesn’t fit all模型，將OLTP和OLAP兩種系統(tǒng)組合起來，通過CDC的方式把OLTP上產(chǎn)生的數(shù)據(jù)以增量的方式導(dǎo)入到數(shù)倉進(jìn)行分析。
本期DB·洞見，將由騰訊云數(shù)據(jù)庫專家工程師朱閱岸來為大家重點(diǎn)分享HTAP系統(tǒng)的技術(shù)實(shí)現(xiàn)相關(guān)路線。以下是分享實(shí)錄：
1、HTAP的定義與挑戰(zhàn)
我們先來解釋HTAP的定義與挑戰(zhàn)是什么。下圖是經(jīng)典的數(shù)據(jù)處理框架，我們?cè)诶锩鎰澐殖鰞煞N數(shù)據(jù)庫系統(tǒng)：一種是事務(wù)型的系統(tǒng)，這是數(shù)據(jù)源頭產(chǎn)生的地方；另一種是分析型的系統(tǒng)，是我們的數(shù)倉。數(shù)據(jù)會(huì)定期從交易型數(shù)據(jù)庫中借助ETL的方式流入到數(shù)倉.然后在數(shù)據(jù)倉庫做分析處理，產(chǎn)生相應(yīng)的報(bào)表和報(bào)告。企業(yè)的經(jīng)營決策者能夠通過分析報(bào)告和決策報(bào)表去觀察企業(yè)的經(jīng)營行為，從而觀察到未來的發(fā)展趨勢(shì)。這是數(shù)據(jù)寶貴之處的體現(xiàn)之一。不少公司都在數(shù)據(jù)基礎(chǔ)設(shè)施上投入人力物力，期待在數(shù)據(jù)變現(xiàn)上獲得更好的回報(bào)。
下圖右上角是部分研究機(jī)構(gòu)做的調(diào)查。研究表明，這些樣本公司在每13美金的投入中就有1美金投入到數(shù)據(jù)分析里，有74%的公司想成為一個(gè)數(shù)據(jù)驅(qū)動(dòng)型的公司，如果一個(gè)公司采用更為先進(jìn)的數(shù)據(jù)分析手段，那它超越競爭對(duì)手的可能性將達(dá)到兩倍。
數(shù)據(jù)分析具備巨大的商業(yè)價(jià)值。但在目前的數(shù)據(jù)處理框架中，OLTP和OLAP兩類系統(tǒng)是割裂開的，主要是通過ETL把數(shù)據(jù)從交易型數(shù)據(jù)庫導(dǎo)入到分析型數(shù)據(jù)庫，而ETL的時(shí)延比較大，可以達(dá)到數(shù)十分鐘到幾小時(shí)，甚至是幾天。上圖右下角的圖片顯示，數(shù)據(jù)的商業(yè)價(jià)值會(huì)隨著時(shí)間的流逝而下降。數(shù)據(jù)產(chǎn)生再經(jīng)過ETL導(dǎo)入到數(shù)倉，在數(shù)倉里進(jìn)行分析，然后做決策，執(zhí)行相應(yīng)的動(dòng)作。在這時(shí)，數(shù)據(jù)的商業(yè)價(jià)值就會(huì)大打折扣。
因此最理想的情況是在數(shù)據(jù)產(chǎn)生后就能迅速對(duì)其進(jìn)行分析。為了解決這個(gè)問題，HTAP系統(tǒng)應(yīng)運(yùn)而生，它的初衷就是要打破事務(wù)處理和分析處理的界限，使企業(yè)能夠通過HTAP系統(tǒng)更好地發(fā)現(xiàn)市場(chǎng)反饋，獲得更好的創(chuàng)新。這么先進(jìn)的數(shù)據(jù)處理技術(shù)，為什么近年來才引起人們的關(guān)注呢？我個(gè)人認(rèn)為，這主要得益于現(xiàn)代列存儲(chǔ)技術(shù)的發(fā)展，HTAP系統(tǒng)的出現(xiàn)才成為了可能。
以前客戶用SQL Server做查詢分析處理，需要十多個(gè)小時(shí)以上。在這種技術(shù)能力下是無法達(dá)到實(shí)現(xiàn)HTAP系統(tǒng)要求的。后來SQL Server采用列存儲(chǔ)技術(shù)，耗時(shí)十幾個(gè)小時(shí)的分析可以降到幾分鐘，甚至可以在秒級(jí)時(shí)間內(nèi)把結(jié)果運(yùn)行出來。列存儲(chǔ)技術(shù)及背后的向量查詢引擎的發(fā)展，使得HTAP登上了歷史舞臺(tái)。
HTAP能讓數(shù)據(jù)產(chǎn)生后馬上就可以進(jìn)入分析場(chǎng)景。但它面臨最大的問題是如何把OLTP和OLAP兩類工作負(fù)載更好放在一個(gè)系統(tǒng)上運(yùn)行，畢竟這兩類工作負(fù)載本質(zhì)上是互斥的。交易型的事務(wù)是短事務(wù)，以寫為主；分析型的事務(wù)是長事務(wù)，以讀為主，經(jīng)常需要做全表掃描，在掃描的基礎(chǔ)上做統(tǒng)計(jì)、聚合等操作。這種情況下，OLAP的事務(wù)經(jīng)常需要獨(dú)占系統(tǒng)資源，使交易型的事務(wù)吞吐量下降。有研究表明，把OLTP和OLAP放在一個(gè)系統(tǒng)里調(diào)度，OLTP的吞吐量可能會(huì)下降到原本的1/3到1/5。所以如何讓OLTP和OLAP在系統(tǒng)運(yùn)行的過程中相互干擾最小，就成為HTAP系統(tǒng)設(shè)計(jì)的難題。
從過去十多年的發(fā)展來看，主要有兩種實(shí)現(xiàn)HTAP的方案：
1.第一種是改良的方式，在現(xiàn)有業(yè)務(wù)系統(tǒng)上延伸擴(kuò)展，打造一個(gè)HTAP的系統(tǒng)來滿足業(yè)務(wù)的需要；
2.第二種是從頭開始設(shè)計(jì)一個(gè)具有顛覆性的系統(tǒng).當(dāng)然第二種方式會(huì)產(chǎn)生更多有價(jià)值的技術(shù)，也會(huì)涉及到比較多技術(shù)難題，包含技術(shù)突破、業(yè)務(wù)適配等。
從現(xiàn)在來看很難說哪種更好，今天的分享我們也不說哪一條路線更好，我們會(huì)在這兩條路線上挑選典型的具有鮮明技術(shù)特色的系統(tǒng)，來和大家分享，同時(shí)會(huì)在最后給出最近十年來HTAP系統(tǒng)技術(shù)的演變過程和發(fā)展趨勢(shì)。
2、HTAP系統(tǒng)的架構(gòu)實(shí)踐
2.1 HTAP系統(tǒng)的類別
總體來看，HTAP系統(tǒng)架構(gòu)的實(shí)踐可以分成兩類：一類是改革，另一類是改良。前者采用One size fits all的策略，用一個(gè)大而全的系統(tǒng)同時(shí)滿足OLTP和OLAP的需求，后者采用One size doesn’t fit all模型，將OLTP和OLAP兩種系統(tǒng)組合起來，通過CDC的方式把OLTP上產(chǎn)生的數(shù)據(jù)以增量的方式導(dǎo)入到數(shù)倉進(jìn)行分析。
第一類下又分為兩個(gè)子類：
1.第一個(gè)子類是單拷貝系統(tǒng)，在一個(gè)系統(tǒng)里用一種數(shù)據(jù)格式滿足兩種業(yè)務(wù)需求，通常是采用PAX存儲(chǔ)。系統(tǒng)整體來看是采用行存儲(chǔ)，但是當(dāng)它把數(shù)據(jù)打包存儲(chǔ)到某個(gè)頁面時(shí)轉(zhuǎn)換成列存儲(chǔ)的形式；
2.另一種是雙拷貝系統(tǒng)，一個(gè)系統(tǒng)里同時(shí)存在行存儲(chǔ)和列存儲(chǔ)，行存儲(chǔ)上的更新會(huì)定期導(dǎo)入到列存儲(chǔ)里轉(zhuǎn)換成列存儲(chǔ)格式。在列存儲(chǔ)上進(jìn)行分析，行存儲(chǔ)上執(zhí)行更新。這在某種程度上降低了它們的競爭。第二類可以分為共享存儲(chǔ)和獨(dú)立存儲(chǔ)兩個(gè)子類。
下圖右上角就是這四種類型的系統(tǒng)實(shí)現(xiàn)HTAP特征時(shí)的比較，可以從兩個(gè)維度來刻畫，一是數(shù)據(jù)新鮮度，二是工作負(fù)載干擾程度。
One size fits all策略把OLTP和OLAP兩種工作負(fù)載放在一個(gè)系統(tǒng)上，如圖1左上角，就干擾程度而言，OLTP和OLAP相互干擾最強(qiáng)，而單系統(tǒng)單拷貝方式尤為明顯，其次就是單系統(tǒng)雙拷貝的方式。這兩種實(shí)現(xiàn)方式的缺點(diǎn)是OLTP/OLAP的干擾比較大會(huì)導(dǎo)致事務(wù)工作負(fù)載的吞吐嚴(yán)重下降，但優(yōu)點(diǎn)是數(shù)據(jù)可見度高，因?yàn)椴恍枰鰯?shù)據(jù)的同步導(dǎo)入導(dǎo)出或數(shù)據(jù)轉(zhuǎn)換。
One size doesn’t fit all即松耦合模型也有兩種類別，橙色橢圓代表共享存儲(chǔ)下的松耦合系統(tǒng)，目前還沒有有商業(yè)化的產(chǎn)品，只有IBM出了一個(gè)DEMO；另一種是采用類似proxy方式把TP與AP兩種獨(dú)立系統(tǒng)組合起來的松耦合系統(tǒng)。這兩類系統(tǒng)中，OLTP和OLAP分別在兩個(gè)獨(dú)立的系統(tǒng)上進(jìn)行，可以把干擾降到最小，但數(shù)據(jù)需要同步，交易型數(shù)據(jù)庫更新的數(shù)據(jù)要通過CDC的方式同步到分析型系統(tǒng)上，數(shù)據(jù)的延遲會(huì)比較大。
上圖右上角也列出了幾個(gè)典型的HTAP工作負(fù)載對(duì)時(shí)延的需求。系統(tǒng)監(jiān)控的延遲在20毫秒，在線游戲、個(gè)性化廣告推薦、商品價(jià)格監(jiān)控，則是在100-200之間。
2.2單系統(tǒng)單拷貝之Hyper
接下來我們從四類系統(tǒng)實(shí)踐中挑選部分代表性的系統(tǒng)來看HTAP技術(shù)如何具體實(shí)現(xiàn)。首先是Hyper。Hyper是很典型的系統(tǒng)，它原本是德國慕尼黑工業(yè)大學(xué)的Thomas Neumann教授團(tuán)隊(duì)開發(fā)的原型產(chǎn)品，但是性能與創(chuàng)新性實(shí)在太好，后來被美國tableau公司收購，從學(xué)術(shù)型的產(chǎn)品變成了商業(yè)化的產(chǎn)品，不論從技術(shù)與經(jīng)歷都具有較高的代表性。
Hyper的查詢執(zhí)行模式很有考究。OLTP是串行執(zhí)行，不需要加鎖。這是因典型OLTP數(shù)據(jù)庫把大部分時(shí)間都消耗在加鎖、緩沖區(qū)管理、日志管理上，這些操作消耗了系統(tǒng)80%左右的資源。在Hyper中沒有這些開銷，事務(wù)串行執(zhí)行，去除維護(hù)事務(wù)隔離性等開銷。一個(gè)事務(wù)串行執(zhí)行的耗時(shí)只有微秒級(jí)別，這個(gè)是可以接受的。VoltDB是類似的一個(gè)系統(tǒng)，事務(wù)執(zhí)行同樣不需要加鎖，串行地執(zhí)行（通過分片達(dá)到并行執(zhí)行的效果）。OLAP則通過fork產(chǎn)生子進(jìn)程在事務(wù)一致性的拷貝上運(yùn)行查詢。更新時(shí)再把相關(guān)的數(shù)據(jù)頁拷貝出來，讓交易型事務(wù)在不同的數(shù)據(jù)頁上進(jìn)行更新（Copy-on-Write）。
此外通過區(qū)分冷熱數(shù)據(jù)的方式，把數(shù)據(jù)分成熱數(shù)據(jù)、冷數(shù)據(jù)和溫?cái)?shù)據(jù)。上圖右下角就是通過硬件的方式即MMU的內(nèi)存管理單元去區(qū)分?jǐn)?shù)據(jù)的訪問熱度。熱數(shù)據(jù)放在正常頁面即小頁面上，冷數(shù)據(jù)是壓縮存儲(chǔ)，放在4M的大頁面上。這種做法的好處是更新代價(jià)比較小，同時(shí)在做OLAP查詢的時(shí)候，在大頁面上會(huì)有比較好的性能。
Hyper的查詢引擎也是相當(dāng)優(yōu)秀的，它利用向量化的查詢引擎，用LLVM生成可執(zhí)行的機(jī)器碼。這個(gè)技術(shù)非常具有代表性，連著名的Spark也參考了它的代碼生成技術(shù)。
2.3單系統(tǒng)單拷貝之SAP HANA
HANA也是采用單系統(tǒng)單拷貝實(shí)現(xiàn)HTAP。它不太像一個(gè)數(shù)據(jù)庫系統(tǒng)，反而像是一個(gè)支持多引擎多工作負(fù)載類型的統(tǒng)一數(shù)據(jù)管理平臺(tái)。HANA系統(tǒng)的分層結(jié)構(gòu)做得很好，總體來看可以分為編譯層和執(zhí)行層，上層又可以分為查詢的解析，生成抽象語法樹AST，再映射到計(jì)算圖模型，接著對(duì)計(jì)算圖模型進(jìn)行物理優(yōu)化。此后由分布式執(zhí)行框架去構(gòu)建實(shí)際的數(shù)據(jù)流，將具體的物理執(zhí)行算子分發(fā)到特定的引擎執(zhí)行。因?yàn)镠ANA支持多個(gè)工作引擎，比如數(shù)據(jù)倉的查詢引擎、文本、圖等，它向上提供了針對(duì)這些特定引擎的物理算子，比如關(guān)系操作算子、圖計(jì)算的算子等。
執(zhí)行引擎下又有統(tǒng)一的表模型。它向上提供一個(gè)統(tǒng)一的接口，類似于MySQL下的handler接口，下面的存儲(chǔ)引擎負(fù)責(zé)實(shí)現(xiàn)具體的存儲(chǔ)，上面的查詢執(zhí)行器只要實(shí)現(xiàn)handler接口就可以對(duì)接到系統(tǒng)里去。里面的存儲(chǔ)分成三級(jí)：首先是L1-delta，對(duì)應(yīng)的是熱數(shù)據(jù)和無壓縮的行存儲(chǔ)；其次是L2-delta，對(duì)應(yīng)的是輕量級(jí)壓縮的列存儲(chǔ)，比如字典壓縮；最后是L3-main store，對(duì)應(yīng)的是重度壓縮列存儲(chǔ)。更新發(fā)生在L1-delta，數(shù)據(jù)會(huì)定量地導(dǎo)入到Main store里。Main store是讀友好的實(shí)現(xiàn)方式，滿足AP類型的查詢，而L1-delta是寫優(yōu)化的實(shí)現(xiàn)。通過這種方式來滿足HTAP的需求。
它會(huì)定期地執(zhí)行合并操作，把數(shù)據(jù)定期地合并到Main store里。在合并操作的過程中會(huì)生成Main2和Delta2，這時(shí)讀操作就在Main1、Delta1和Delta2進(jìn)行?？截愅瓿梢院驧ain1和Delta1最終會(huì)合并到Main2，最后切換過來，在Main2上進(jìn)行讀操作，寫操作發(fā)生在Delta2。數(shù)據(jù)加鎖的行為只是發(fā)生在緩沖區(qū)切換階段。L1-delta采用redo日志保持持久性，Main store采用影子頁技術(shù)減少日志的寫入，保持一致性與持久性。
2.4單系統(tǒng)雙拷貝之SQL Server
SQL Server是一個(gè)雙拷貝系統(tǒng)，把數(shù)據(jù)按行切分成group，定期轉(zhuǎn)變成列存儲(chǔ)。具體來說是，每一百萬條數(shù)據(jù)做一個(gè)Group，進(jìn)行切分，然后針對(duì)每列轉(zhuǎn)換成列存儲(chǔ)，叫做segment。每個(gè)列采用單獨(dú)的壓縮算法，比如有些適合用字典壓縮，有些適合用數(shù)值壓縮，因此不同的列采用不同的壓縮算法。轉(zhuǎn)換后的列存儲(chǔ)附加額外字典表（如有），存儲(chǔ)到Blob類型中。外面的directory追蹤這些segment的存放位置。SQL Server也針對(duì)列存儲(chǔ)提供了批量執(zhí)行的算法，加速分析操作。
2.5單系統(tǒng)雙拷貝之Oracle
Oracle是另外一個(gè)采用雙拷貝方式實(shí)現(xiàn)HTAP的系統(tǒng)，每個(gè)系統(tǒng)里針對(duì)有需要的表，會(huì)同時(shí)存在一份行存儲(chǔ)和列存儲(chǔ)，在列存儲(chǔ)上做分析操作；在行存儲(chǔ)上進(jìn)行更新，定期同步到列存儲(chǔ)里。系統(tǒng)可以靈活指定需要采用行存與列存的表，也可以系統(tǒng)運(yùn)行時(shí)更改表特性。Oracle利用RAC集群進(jìn)行橫向拓展。
這里舉兩個(gè)例子，來介紹Oracle是如何利用列存儲(chǔ)加速分期操作的。假如我們查找Outlet這個(gè)商店類型所有的銷售額，首先掃描維表，根據(jù)“type把Outlet類型的商店ID拿到，生成一個(gè)map”，接著在事實(shí)表的對(duì)于外鍵列里把商品ID拿出來在這個(gè)map查找，如果找到就可以把Amount累加起來。它通過只掃描某些特定的列，生成相關(guān)的map，就可以把要訪問的數(shù)據(jù)找出來，即把關(guān)聯(lián)操作簡化成表掃描操作，提升性能。
另外一個(gè)比較復(fù)雜的是要掃描兩個(gè)維表，生成兩個(gè)vectors，在里面再去事實(shí)表找相關(guān)的外鍵列，就可以直接定位到相關(guān)的vector，如果符合條件，就分類寫到相應(yīng)的臨時(shí)表里。優(yōu)點(diǎn)在于可以把表關(guān)聯(lián)操作轉(zhuǎn)換成表掃描操作，只需要訪問查詢中涉及到的列。
2.6松耦合共享存儲(chǔ)之Wildfire
目前還沒有商業(yè)化的HTAP產(chǎn)品采用松耦合共享存儲(chǔ)架構(gòu)，但是IBM開發(fā)了一個(gè)原型，叫Wildfire。從技術(shù)細(xì)節(jié)來看，它的系統(tǒng)分成兩類節(jié)點(diǎn)：一類是有狀態(tài)的節(jié)點(diǎn)，一類是無狀態(tài)的節(jié)點(diǎn)。有狀態(tài)的節(jié)點(diǎn)處理事務(wù)型的請(qǐng)求，無狀態(tài)的節(jié)點(diǎn)處理OLAP型的請(qǐng)求。OLAP型的請(qǐng)求可以容忍一定的延遲。
OLTP型的數(shù)據(jù)不會(huì)直接寫入到共享文件系統(tǒng)里，會(huì)寫入私有組成的一個(gè)集群，按照表分片的模式在這里進(jìn)行數(shù)據(jù)的快速寫入，再定期導(dǎo)入到共享文件系統(tǒng)里，然后供分析型查詢?nèi)?zhí)行。分析型查詢會(huì)自己去定制一個(gè)引擎，去對(duì)接spark executor。這個(gè)引擎是無狀態(tài)的，可以去定制修改，在數(shù)據(jù)分析領(lǐng)域也是比較強(qiáng)悍的引擎，叫BLU，是IBM自家的分析執(zhí)行引擎?？傮w上看，這個(gè)系統(tǒng)分成兩個(gè)集群：一個(gè)是OLTP，一個(gè)是OLAP。
國內(nèi)有部分產(chǎn)品的技術(shù)和該架構(gòu)比較類似，利用spark的能力和生態(tài)去做分析型查詢，比如利用spark的查詢優(yōu)化器和機(jī)器學(xué)習(xí)能力去構(gòu)建OLAP能力，OLTP能力則自己構(gòu)建，這樣就把數(shù)據(jù)和這兩套系統(tǒng)在某種程度上做了一定的融合，變成HTAP。
2.7松耦合獨(dú)立存儲(chǔ)之F1 Lightning
松耦合獨(dú)立系統(tǒng)近幾年比較流行，有兩個(gè)典型代表，一個(gè)是谷歌的F1 Lightning，另外一個(gè)是IBM的IDAA。我們先來介紹F1 Lightning。
F1 Lightning把系統(tǒng)分成三個(gè)模塊：OLTP數(shù)據(jù)庫、Lightning、查詢執(zhí)行引擎。Lightning通過Changepump捕獲OLTP數(shù)據(jù)庫的更新，以訂閱的方式把數(shù)據(jù)分發(fā)到訂閱者。Lightning內(nèi)部還開發(fā)了一個(gè)適配器，將CDC的模式轉(zhuǎn)換成內(nèi)部統(tǒng)一的格式。內(nèi)部有兩級(jí)存儲(chǔ)：內(nèi)存存儲(chǔ)和磁盤存儲(chǔ)。內(nèi)存存儲(chǔ)是以行存儲(chǔ)的模式存在，采用B-tree索引，在這里沒有轉(zhuǎn)換成列存儲(chǔ)，只有在數(shù)據(jù)寫入磁盤時(shí)才把行存儲(chǔ)轉(zhuǎn)換成列存儲(chǔ)。上層查詢通過快照的機(jī)制讀取可見范圍的相關(guān)數(shù)據(jù)。F1 Lightning將捕獲的日志分成兩層存儲(chǔ),為日志維護(hù)系統(tǒng)范圍的檢查點(diǎn)時(shí)間戳以及為適配不同數(shù)據(jù)庫而設(shè)計(jì)的客戶端接口很大程度上借鑒了Databus。這種實(shí)現(xiàn)方式帶來的問題是查詢延遲。從谷歌的測(cè)試來看，查詢延遲在8-10分鐘之間。因?yàn)椴捎肅DC方式，要把OLTP數(shù)據(jù)轉(zhuǎn)換成CDC內(nèi)部統(tǒng)一的格式，再批量提交，因此延遲會(huì)比較大。
2.8松耦合獨(dú)立存儲(chǔ)之IDAA
接下來介紹IBM的IDAA。最初IBM也開發(fā)了類似松耦合的HTAP架構(gòu)。下圖中左邊是Db2，右邊是他們的Warehouse，掛載到事務(wù)型引擎，事務(wù)型引擎將更新定期同步。但I(xiàn)BM系統(tǒng)設(shè)計(jì)者認(rèn)為，CDC方案需要花費(fèi)大量的時(shí)間和背景知識(shí)來維護(hù)額外的進(jìn)程，且延遲比較大?；谶@個(gè)原因，他們對(duì)此進(jìn)行了改進(jìn)，通過輕量級(jí)的集成同步方案規(guī)避上述問題，將延遲減少180倍。
CDC的方案需要在源端經(jīng)歷6個(gè)步驟：讀取數(shù)據(jù)，解密；過濾無關(guān)的日志，按照LSN排序；之后還要對(duì)數(shù)據(jù)進(jìn)行行列轉(zhuǎn)換；把數(shù)據(jù)暫存起來，把數(shù)據(jù)轉(zhuǎn)換成CDC統(tǒng)一內(nèi)部的格式；再批量等待commit或Rollback，發(fā)送之前還要把Rollback數(shù)據(jù)去除。這種情況對(duì)源端的壓力是比較大的，延遲也會(huì)比較大。
IDAA則建議把這幾個(gè)步驟都挪到目的端執(zhí)行。目的端能夠原生地識(shí)別從Db2里傳輸過來的數(shù)據(jù)，當(dāng)然這個(gè)是比較定制化的方案，通用性沒那么好，但延遲可大幅降低，只有原來的1/180?，F(xiàn)在延遲只有1-2秒左右就能讀到最新的數(shù)據(jù)。
2.9 HTAP技術(shù)發(fā)展一覽
這部分我們來對(duì)HTAP近10年來的發(fā)展脈絡(luò)做梳理。圖中的直線方向表示后者的技術(shù)借鑒前驅(qū)或者是從該產(chǎn)品演變過來的。
從圖上可以看到，HTAP技術(shù)在2015、2016年之前主要是以O(shè)ne size fits all策略為主，2015、2016年以后則以松偶合架構(gòu)為主。這幾年如F1 Lightning、IDAA等都是采用松偶合方式來實(shí)現(xiàn)HTAP，甚至SAP也是有采用松偶合的技術(shù)方案實(shí)現(xiàn)HTAP。從One size fits all的演變趨勢(shì)來看，大多是從雙拷貝轉(zhuǎn)換成單拷貝，從行存儲(chǔ)轉(zhuǎn)換成單一的列存儲(chǔ)來應(yīng)對(duì)OLTP/OLAP的請(qǐng)求。從原先在磁盤上用列存儲(chǔ)，到內(nèi)存里用行存儲(chǔ)，再到現(xiàn)在統(tǒng)一改成列存儲(chǔ)。這就是最近10年來HTAP技術(shù)的演變趨勢(shì)。
3、云原生對(duì)于
HTAP系統(tǒng)啟示
這一部分我們來看看云原生架構(gòu)對(duì)HTAP系統(tǒng)實(shí)現(xiàn)是否能帶來幫助。
下面是三個(gè)值得思考的問題：
1.首先是云原生架構(gòu)即存算分離架構(gòu)能否為HTAP的設(shè)計(jì)帶來便利？其次是存算分離架構(gòu)和彈性算力能否緩解資源競爭；
2.因?yàn)檫@兩條技術(shù)下的系統(tǒng)，在資源競爭和數(shù)據(jù)可見度上的表現(xiàn)各有優(yōu)缺點(diǎn)，并不能說哪種產(chǎn)品的表現(xiàn)最優(yōu)，都是在數(shù)據(jù)延遲和資源爭用上做取舍；
3.此外，云環(huán)境下豐富的計(jì)算資源池和存儲(chǔ)資源池能否針對(duì)不同的計(jì)算、不同的業(yè)務(wù)特征進(jìn)行劃分從而降低用戶的成本，這也是值得大家去思考的問題。
下圖是構(gòu)想中的愿景圖?？傮w來看，理想的情況是，在一個(gè)云原生架構(gòu)里，Share storage和Query processing分層，在查詢?nèi)肟谔幉捎枚嘧鈶粼O(shè)計(jì)，這里執(zhí)行查詢解析和查詢的優(yōu)化，然后把查詢的執(zhí)行推到查詢執(zhí)行層。
查詢執(zhí)行層分為有狀態(tài)和無狀態(tài)兩種，分別處理與OLTP和OLAP相關(guān)的請(qǐng)求。共享存儲(chǔ)層Share storage針對(duì)工作模式和工作負(fù)載采取不同的存儲(chǔ)設(shè)計(jì)策略。在OLAP方面可以主打性價(jià)比，用對(duì)象存儲(chǔ)和糾錯(cuò)編碼模式降低成本。AWS Redshift團(tuán)隊(duì)的調(diào)研也表明，OLAP型的用戶會(huì)更加關(guān)注成本，所以在Share storage里OLAP方面可以偏向性價(jià)比的權(quán)衡。而OLTP數(shù)據(jù)存儲(chǔ)則采用高性能的存儲(chǔ)，優(yōu)化事務(wù)提交的關(guān)鍵路徑，達(dá)到用戶最優(yōu)體驗(yàn)，比如說高性能Nvme，加速事務(wù)的提交速度，然后定期把數(shù)據(jù)從OLTP型存儲(chǔ)導(dǎo)入到OLAP型的存儲(chǔ)。
希望在不久的未來，可以看到相關(guān)廠商或數(shù)據(jù)庫開發(fā)者實(shí)現(xiàn)這樣的方案或技術(shù)特征。
4、總結(jié)
總體來看，HTAP已有的問題是OLTP和OLAP這兩種互斥的屬性，如何在一個(gè)系統(tǒng)里共存而干擾盡可能小，數(shù)據(jù)可見度延遲盡可能短。
目前存在兩種架構(gòu)實(shí)踐：
1.一種是One size fits all，用一個(gè)數(shù)據(jù)庫系統(tǒng)來滿足OLTP和OLAP多樣化工作負(fù)載的需求；對(duì)系統(tǒng)相關(guān)的架構(gòu)革新，針對(duì)兩種工作負(fù)載的特性做更好的適配優(yōu)化。
2.另外一種是采用松偶合的方式，通過CDC把兩類系統(tǒng)黏合起來，在上面架構(gòu)一個(gè)類似于proxy的東西，為用戶呈現(xiàn)出一個(gè)系統(tǒng)的表象，用戶感知不到OLAP型系統(tǒng)的存在。
第二種方案能更好地降低兩類工作負(fù)載對(duì)資源的競爭，但是由于需要跨系統(tǒng)進(jìn)行數(shù)據(jù)同步因此延遲較大。而第一種方案雖然資源競爭比較大，但不需要對(duì)數(shù)據(jù)進(jìn)行跨系統(tǒng)同步，因此延遲比較小，數(shù)據(jù)能見度、新鮮度高，可以滿足緊急型任務(wù)的需求。
展望未來，我們認(rèn)為云原生的彈性算力可能更適合HTAP系統(tǒng)，在云原生上會(huì)誕生更優(yōu)秀的HTAP系統(tǒng)。
騰訊云
專欄
閩公網(wǎng)安備 35010202001226號(hào)
