丨h(huán)tap是不是贏者通吃的游戲

OLAP和OLTP通過ETL進(jìn)行銜接。為了提升OLAP的性能，需要在ETL過程中進(jìn)行大量的預(yù)計(jì)算，包括數(shù)據(jù)結(jié)構(gòu)的調(diào)整和業(yè)務(wù)邏輯處理。這樣的好處是可以控制OLAP的延遲，提升用戶體驗(yàn)。但是，因?yàn)橐苊獬槿?shù)據(jù)對(duì)OLTP系統(tǒng)造成影響，所以必須在日終的低谷期才能啟動(dòng)ETL過程。這樣一來，OLAP與OLTP的數(shù)據(jù)延遲通常就在一天左右，習(xí)慣上大家把這種時(shí)效性表述為T+1。其中，T日就是指OLTP系統(tǒng)產(chǎn)生數(shù)據(jù)的日期，T+1日是OLAP1你可能已經(jīng)發(fā)現(xiàn)了，這系的主要問題就是OLAP系統(tǒng)的據(jù)時(shí)效性，1的，進(jìn)入大數(shù)據(jù)時(shí)代后，商業(yè)決策更加注重?cái)?shù)據(jù)的支撐，而且數(shù)據(jù)分析也不斷向一線操作滲透，這都要求OLAP系統(tǒng)更快速地反映業(yè)務(wù)的變化。說到這，你應(yīng)該猜到了，HTAPOLAP用準(zhǔn)實(shí)時(shí)數(shù)據(jù)計(jì)算替代原有批量ETL過程，重建OLAP弱化甚至是干脆拿掉OLAP，直接在OLTP系統(tǒng)內(nèi)擴(kuò)展，也就是HTAP重建OLAP我們先來看第一種思路。重建OLAP體系，重視數(shù)據(jù)加工的時(shí)效性，正是近年來大數(shù)據(jù)技術(shù)的主要發(fā)展方向。Kappa架構(gòu)就是新體系的代表，它最早由LinkedIn的JayKreps在2014年的一篇文章中提出。在Kappa架構(gòu)中，原來的批量文件傳輸方式完全被Kafka替代，通過流計(jì)算系統(tǒng)完成數(shù)據(jù)的快速加工，數(shù)據(jù)最終落地到ServingDB中提供查詢服務(wù)。這里的ServingDB泛指各種類型的，可以是HBase、Redis或者M(jìn)ySQL。要注意的是，Kappa架構(gòu)還沒有完全實(shí)現(xiàn)，因?yàn)樵趯?shí)踐中流計(jì)算仍然無法替代批量計(jì)算，ServingDB也各種類型的分析查詢需求。未來，Kappa架構(gòu)需要在兩方面繼續(xù)完Kafka和FlinkOLAPETL，降低數(shù)據(jù)延遲。這個(gè)新體系是流計(jì)算的機(jī)遇，也是OLAP數(shù)據(jù)庫的自我救贖。新建HTAP第二種思路是HTAP。HTAP（HybridTransaction/yticalProcessing）就是混合事務(wù)分析處理，它最早出現(xiàn)在2014年Gartner的一份報(bào)告中，很巧和Kappa架構(gòu)是同一年。Gartner用HTAP來描述一種新型數(shù)據(jù)庫，它打破了OLTP和OLAP之間的隔閡，HTAP可以省去繁瑣的ETL操作，避免批量處理造成的滯后，更快地對(duì)數(shù)據(jù)進(jìn)行分這個(gè)構(gòu)想很快表現(xiàn)出它性的一面，由于數(shù)據(jù)產(chǎn)生的在OLTP系統(tǒng)，所以HTAP概念很快成為OLTP數(shù)據(jù)庫，尤其是NewSQL風(fēng)格的分布式數(shù)據(jù)庫，向OLAP領(lǐng)域進(jìn)軍的那么，NewSQL在初步解決OLTP場(chǎng)景的高并發(fā)、強(qiáng)一致性等問題后，能不能兼顧其實(shí)還很難講，因?yàn)閺募夹g(shù)實(shí)踐看，重建OLAP路線的相關(guān)技術(shù)似乎發(fā)展得更快，參與廠相比之下，P的進(jìn)展比較緩慢，鮮有生產(chǎn)級(jí)的工業(yè)實(shí)踐，但仍有不少廠商將其作為產(chǎn)品的演進(jìn)方向。目前，廠商官宣的P至少包括B和,而OceBase在近期版本中推出OLAP場(chǎng)景的性?；谏虡I(yè)策略的考慮，我相信未來還會(huì)有分布式數(shù)據(jù)庫豎起P的大旗那么接下來，我們分析下P的，讓你更好地識(shí)P。HTAP的兩種設(shè)這就要先說回OLTP和OLAP，在架構(gòu)上，它們的差異在于計(jì)算和兩方面計(jì)算是指計(jì)算引擎的差異，目標(biāo)都是調(diào)度多節(jié)點(diǎn)的計(jì)算資源，做到最大程度地并行處理。OLAP是海量數(shù)據(jù)要追求高吞吐量，而OLP是指數(shù)據(jù)在磁盤上的組織方式不同，而組織方式直接決定了數(shù)據(jù)的效率。OLTP分布式數(shù)據(jù)庫的主流設(shè)計(jì)理念是計(jì)算與分離，那么計(jì)算就比較容易實(shí)現(xiàn)無狀態(tài)化，所個(gè)P系統(tǒng)內(nèi)構(gòu)建多個(gè)計(jì)算引擎顯然不是太的事情，而真的要將P落地為可運(yùn)行系統(tǒng)，根本性的就是。面對(duì)這個(gè)，業(yè)界有兩個(gè)不同的解決思Spanner使用的融合性PAX（PartitionAttributesAcross），試圖同時(shí)兼容兩類TiDB4.0版本中的設(shè)計(jì)，在原有行式的基礎(chǔ)上，新增列式，并通過創(chuàng)新性的設(shè)首先，我們一起看看Spanner的方案。Spanner2017 ingaSQLSystem”中介紹了它的新一代Ressi，其中使用了類似PAX的方式。這個(gè)PAX并不是Spanner的創(chuàng)新，早在VLDB2002的 “DataPageLayoutsforRelationalDatabasesonDeepMemoryHierarchies”中就被提出了。 從CPU緩存友的角度，對(duì)不同的方式進(jìn)行了探討，涉及NSM、DSM、PAX三種格式。NSM（行式NSM（N-aryStorageModel）就是行式，也是OLTP數(shù)據(jù)庫默認(rèn)的方式，始終伴隨著關(guān)系型數(shù)據(jù)庫的發(fā)展。我們常用的OLTP數(shù)據(jù)庫，比如MySQL（InnoDB）、PostgreSQL、Oracle和SQLServer等等都使用了行式。顧名思義，行式的特點(diǎn)是將一條數(shù)據(jù)記錄集中存在一起，這種方式更加貼近于系模型。寫入的效率較高，在時(shí)也可以快速獲得一個(gè)完整數(shù)據(jù)記錄，這種特點(diǎn)稱為錄內(nèi)的局部性（Intr-Recordatlity但是，行式對(duì)于OLAP分析查詢并不友好。OLAP系統(tǒng)的數(shù)據(jù)往往是從多個(gè)OLTP統(tǒng)中匯合而來，單表可能就有上百個(gè)字段。而用戶一次查詢通常只其中的少量字段，如果以行為單位數(shù)據(jù)，查詢出的多數(shù)字段其實(shí)是無用的，也就是說大量I/O無效的。同時(shí)，大量無效數(shù)據(jù)的，又會(huì)造成CPU緩存的失效，進(jìn)一步降低了系統(tǒng)的性CPUDSM（列式 positionStorageModel）就是列式，它的出現(xiàn)要晚于行式。典型代表系統(tǒng)是C-Store，它是邁克爾·斯通布雷克（MichealStonebraker）主導(dǎo)的開源項(xiàng)目，后來的商業(yè)化產(chǎn)品就是Vertica。列式就是將所有列集中，不僅更加適應(yīng)OLAP的特點(diǎn)，對(duì)CACHE也更友好。這種特點(diǎn)稱為記錄間的局部性（Inter-RecordSpatialLocality）。列式能夠大幅提升查詢性能，以速度快著稱的ClickHouse就采用了列式。列式的問題是寫入開銷更大，這是因?yàn)楦鶕?jù)關(guān)系模型，在邏輯上數(shù)據(jù)的組織單元仍然是行，改為列式后，同樣的數(shù)據(jù)量會(huì)被寫入到的數(shù)據(jù)頁（page）直接對(duì)應(yīng)著物理扇區(qū)，那么磁盤I/OPAX增加了minipage這個(gè)概念，是原有的數(shù)據(jù)頁下的二級(jí)單位，這樣一行數(shù)據(jù)記錄在數(shù)據(jù)頁上的基本分布不會(huì)被破壞，而相同列的數(shù)據(jù)又被集中地在一起。PAX本質(zhì)上還是更接近于行式，但它也在努力平衡記錄內(nèi)局部性和記錄間局部性，提升了OLAP的性理論上，PAX提供了一種兼容性更好的方式，可讓人有些信心不足的是其早在與這個(gè)思路類似的設(shè)計(jì)還有HyPerDataBlock(SIGMOD2016)，DataBlock構(gòu)造了一種獨(dú)有的數(shù)據(jù)結(jié)構(gòu)，同時(shí)面向OLTP和OLAP場(chǎng)景。如果底層是一份數(shù)據(jù)，那么天然就可以保證OLTP和OLAP的數(shù)據(jù)一致性，這是的最大優(yōu)勢(shì)，但是由于模式不同，性能的相互影響似乎也是無法避免，只能盡力選擇一個(gè)平衡點(diǎn)。iB展現(xiàn)了一種不同的思路，介于PAXOLAP和OLAP采用不的方式，物理上是分離的，然后通過創(chuàng)新性的策略，保證兩者的數(shù)據(jù)一致性。TiDB是在較早的版本中就提出了HTAP這個(gè)目標(biāo)，并增加了TiSpark作為OLAP的計(jì)算引擎，但仍然共享OLTP的數(shù)據(jù)TiKV，所以兩種任務(wù)之間的資源競(jìng)爭(zhēng)依舊不可避免。直到近期的4.0版本中，TiDB正式推出了TiFlash作為OLAP的。我們的關(guān)注點(diǎn)集中在TiFlash與TiKV之間的同步機(jī)制上。其實(shí)，這個(gè)同步機(jī)制仍然是基于Raft協(xié)議的。TiDB在Raft協(xié)議原有的Leader和Follower上增加了一個(gè)角色Learner。這個(gè)Learner和Paxos協(xié)議中的同名角色，有類似的職責(zé)，就是負(fù)責(zé)學(xué)習(xí)已經(jīng)達(dá)成一致的狀態(tài)，但不參與投票。這就是說，RaftGroup在寫入過程中統(tǒng)計(jì)多數(shù)節(jié)點(diǎn)時(shí)，并沒有包含Learner，這樣的好處是Learner不會(huì)拖慢寫操作，但帶來的問題是Learner的數(shù)據(jù)更新必然會(huì)于Leader。保證不了AP與TP之間的數(shù)據(jù)一致性吧？r每次接到請(qǐng)求后，首先要確認(rèn)本地的數(shù)據(jù)是否足夠新，而后才會(huì)執(zhí)行查詢操作。怎么確認(rèn)足夠新呢？r會(huì)拿著讀事務(wù)的時(shí)間戳向eader發(fā)起一次請(qǐng)求，獲得r的CommitInde，就是已提交日志的順序編號(hào)。然后，就等待本地日志繼續(xù)Appl，直到本地的日志編號(hào)等于CommitIndex后，數(shù)據(jù)就足夠新了。而在本地副本完成同步前，請(qǐng)求會(huì)一直等待直到超時(shí)。這里，你可能又會(huì)產(chǎn)生疑問。這種同步機(jī)制有效運(yùn)轉(zhuǎn)的前提是TiFlash不能太多，否TiFlash是一個(gè)列式，列式的寫入性能通常不好，TiFlash怎么能夠保持與TiKV這就要說到TiFlash的引擎DeltaTree，它參考了B+Tree和LSM-Tree的設(shè)計(jì)，分為DeltaLayer和StableLayer兩層，其中DeltaLayer保證了寫入具有較高的性能。因?yàn)槟壳斑€沒有向你介紹過引擎的背景知識(shí)，所以這里不再展開DeltaTree的內(nèi)容了，我會(huì)在第22講再繼續(xù)討論這個(gè)話題。lashOLAPOLTP通過ETL與OLAP銜接，所以O(shè)LAP的數(shù)據(jù)時(shí)效性通常是T+1，不反映業(yè)務(wù)的變化。這個(gè)問題有兩種解決思路，一種是重建OLAP體系，通過流計(jì)算方式替代批量數(shù)據(jù)處理，縮短OLAP的數(shù)據(jù)延遲，典型代表是Kappa架構(gòu)。第二種思路是GartnerHTAP。P的設(shè)計(jì)要點(diǎn)在計(jì)算引擎和引擎，其中引擎是基礎(chǔ)。對(duì)于引擎也兩種不同的方案，一種是以PAX為代表，用一份物理融合行式和列式的特點(diǎn)采用了這種方式。另一種是B的h為OLTP和OLAP分別設(shè)行式和列式，通過創(chuàng)新性的同步機(jī)制保證數(shù)據(jù)一致。TiDB的同步機(jī)制仍然是基于Raft協(xié)議的，通過增加Learner角色實(shí)現(xiàn)異步。異步必然帶來數(shù)據(jù)的延遲，Learner在響應(yīng)請(qǐng)求前，通過與Leader同步增量日志的方式，TiFlash作為列存，首先要保證性能，但因?yàn)橐ＷC數(shù)據(jù)一致性，所以也要求具備較高的寫入性能，TiFlash通過DeltaTree開，將在22講繼續(xù)討論。總的來說，HTAP是解決傳統(tǒng)OLAP的一種思路，但是推動(dòng)者只是少數(shù)OLTP數(shù)據(jù)庫廠商。再看另一邊，以流計(jì)算為基礎(chǔ)的新OLAP體系，這些技術(shù)本身就是大數(shù)據(jù)技術(shù)生態(tài)的一部分，有的參與者，不斷有新的成果落地。至于HTAP具有絕對(duì)優(yōu)勢(shì)的數(shù)據(jù)一致性，后者，也就是新OLAPHTAP技術(shù)復(fù)雜度有所降低。最后，TiDB給出的解決方案很有新意，但是能否覆蓋足夠大的OLAP場(chǎng)景，仍有待觀察。TiDBOLAPTiFlash，它保持?jǐn)?shù)據(jù)一致性的方法是，每次TiFlash接到請(qǐng)求后，都會(huì)向TiKVLeader請(qǐng)求的日志增量，本地rey日志后再繼續(xù)處理請(qǐng)求。這種模式雖然能夠保證數(shù)據(jù)足夠新，但比起TiFlash模式還能優(yōu)化嗎？在什么情況下不需要與Leader通訊？AnastassiaAilamakietal.: DataPageLayoutsforRelationalDatabasesonDeepMemoryHierarchiesHaraldLangetal: DataBlocks:HybridOLTPa