從阿里核心場景看實時數(shù)倉的發(fā)展趨勢
作者：果貝，阿里云資深技術(shù)專家 ，實時數(shù)倉Hologers負責人
2022年1月7日，阿里云實時數(shù)倉Hologres舉行了年度發(fā)布會，在發(fā)布會上，來自阿里的資深技術(shù)專家從阿里的核心場景出發(fā)，為大家解讀了實時數(shù)倉的新發(fā)展趨勢“在線化、敏捷化、一站式”。通過本文，我們將會深入解讀實時數(shù)倉發(fā)展所面臨的問題，以及核心發(fā)展趨勢，以幫助大家更好的做產(chǎn)品選型和數(shù)倉規(guī)劃。
實時數(shù)倉是現(xiàn)在大數(shù)據(jù)領(lǐng)域非常熱門的一個概念(和它同熱度的大概就是湖倉一體了)。經(jīng)過十多年的發(fā)展，大數(shù)據(jù)已經(jīng)成為每家公司的標配。傳統(tǒng)上，離線數(shù)倉(開源以Hive/Spark為代表，閉源以阿里MaxCompute、Snowflake、AWS Redshift、Google BigQuery等為代表，以及Vertica、Oracle、HANA等傳統(tǒng)IT廠商)，流式計算(以Flink/Spark Structured Streaming為代表)，數(shù)據(jù)服務(wù)層(HBase、MySQL、ES、Redis等)共同組成了大數(shù)據(jù)處理的標準架構(gòu)：Lambda架構(gòu)。Lambda架構(gòu)提供了實時數(shù)據(jù)的服務(wù)(serving)能力。但Lambda架構(gòu)的典型問題是開發(fā)復雜、數(shù)據(jù)冗余和分析不靈活。
近幾年，以ClickHouse、Apache Doris、阿里Hologres等為代表的實時數(shù)倉興起，通過實時寫入明細數(shù)據(jù)+靈活交互式查詢部分實現(xiàn)了去Lambda架構(gòu)，在實時性、靈活性、成本、管理和運維等多方面都達到了較好的平衡。
隨著2021年雙11的完美落幕，實時數(shù)倉技術(shù)在阿里雙11場景也經(jīng)歷了多年的實踐和發(fā)展。從早期的基于不同作業(yè)的煙囪式開發(fā)，到基于領(lǐng)域分層建模的數(shù)倉引入，再到分析服務(wù)一體化的新型融合式一站式架構(gòu)，開發(fā)效率逐步提升，數(shù)據(jù)質(zhì)量更有保證，也沉淀了更多技術(shù)創(chuàng)新，讓我們看到了一些未來數(shù)倉開發(fā)、應(yīng)用的可能性和趨勢。
下面我們來聊聊從阿里雙11看到的實時數(shù)倉發(fā)展的一些趨勢。
一、實時數(shù)倉已經(jīng)成為業(yè)務(wù)標配
第一個趨勢是實時數(shù)倉已經(jīng)成為標配。
業(yè)務(wù)對時效的要求、對靈活性的要求越來越高，從而使得實時數(shù)據(jù)變?yōu)橐环N剛需。而實時數(shù)倉在成本、靈活性上的巨大優(yōu)勢使得業(yè)務(wù)優(yōu)先選擇實時數(shù)倉作為實時數(shù)據(jù)的生產(chǎn)、存儲和使用平臺。在阿里巴巴，Hologres服務(wù)了約90%的BU，集群規(guī)模超過了60萬core，并保持100%的增長速度。在這些業(yè)務(wù)中，有較常見的實時數(shù)倉場景，比如：
- 數(shù)字化運營：這種場景上游對接Flink進行數(shù)據(jù)流式加工;下游對接BI工具、數(shù)據(jù)大屏等，實現(xiàn)業(yè)務(wù)的自助開發(fā)和上線。極大提升了開發(fā)效率和靈活性，支持所見即所得的開發(fā)體驗。
- 網(wǎng)絡(luò)流量分析、Metrics分析：通過對網(wǎng)絡(luò)流量、及其他Metrics類數(shù)據(jù)的實時存儲和監(jiān)控，可快速預警和定位設(shè)備潛在故障。在萬億級記錄上查詢秒級響應(yīng)，故障秒級發(fā)現(xiàn)。
- 實時物流跟蹤：通過實時數(shù)倉實現(xiàn)物流信息的實時跟蹤，保證物流流轉(zhuǎn)狀態(tài)的實時更新、實時查詢。
在這些相對常見的實時數(shù)倉場景外，因為分析服務(wù)一體化(Hybrid Serving/Analytics Processing，以下簡稱HSAP)能力(以及與之對應(yīng)的Hologres高速純實時寫入能力和點查能力)，Hologres也被用在了很多非典型的實時數(shù)倉場景。例如：
- 對商家的廣告人群圈選：通過Hologres對廣大商家(to B)提供高QPS、低延遲的人群圈選和廣告投放服務(wù)。
- 無人車送貨：Hologres承載無人車上商品的訂單、物流等指標信息，面向B端驛站，實時匯報物流信息，從而幫助驛站老板完成智能化包裹分揀、移動投柜等任務(wù);面向用戶，再通過系統(tǒng)調(diào)度運力，實現(xiàn)”定時上門、送貨到樓”。
- 搜索推薦中的特征存儲和樣本存儲：利用Hologres的強大點查能力，實現(xiàn)實時樣本(feature store)、實時特征(sample store)和實時算法效果分析。
- 客戶全鏈路體驗：客服服務(wù)部門通過在Hologres存儲客戶的相關(guān)多渠道數(shù)據(jù)，實現(xiàn)直接對消費者提供各種明細查詢能力(to C)。
- …
類似的場景還有很多，數(shù)據(jù)的實時“被看見”，“被使用”成為企業(yè)高速發(fā)展的原動力。
二、實時數(shù)倉支撐在線生產(chǎn)系統(tǒng)
第二個趨勢就是實時數(shù)倉越來越成為生產(chǎn)系統(tǒng)的一部分。
傳統(tǒng)上，實時數(shù)倉(數(shù)據(jù)倉庫)是一個非生產(chǎn)系統(tǒng)。因為它主要面對的是內(nèi)部客戶，所以雖然大屏等重要性很高，但實時數(shù)倉本質(zhì)上并不在生產(chǎn)關(guān)鍵鏈路上，也就是說，如果實時數(shù)倉不可用了，對客戶的影響并不大。這也是為什么大部分實時數(shù)倉產(chǎn)品在高可用性、資源隔離、災(zāi)備等能力上和數(shù)據(jù)庫等系統(tǒng)是有很大差距的。
傳統(tǒng)上對外的服務(wù)是通過離線/流式加工+結(jié)果點查來提供的，即和用戶交互的關(guān)鍵鏈路是結(jié)果點查(通過HBase、Redis、MySQL這樣的系統(tǒng)去承載)。這種模式的好處是簡單可靠，但限制也是巨大的，能提供的服務(wù)功能非常有限，且不靈活。業(yè)務(wù)迫切希望能將內(nèi)部的實時數(shù)倉能力以可控的方式開放給外部客戶(to B、to C)，并且保持內(nèi)外兩套系統(tǒng)在數(shù)據(jù)和邏輯上的一致性。上面列舉的阿里廣告、無人車送貨、客戶全鏈路體驗等場景都是這種to B，甚至to C的案例。
隨著實時數(shù)倉作為一個服務(wù)對外提供，用戶對服務(wù)的并發(fā)度、可用性、穩(wěn)定性都提出了更高的需求。這也是Hologres在過去一年中重點發(fā)力的地方。Hologres在過去一年中引入了多副本、熱升級、快速failover、資源隔離、讀寫分離、災(zāi)備等能力，實現(xiàn)了生產(chǎn)級高可用，并在今年的雙11中得到了很好的應(yīng)用。舉幾個例子：
- 阿里巴巴客戶體驗事業(yè)部(Chief Customer Office，以下簡稱CCO)去年是業(yè)務(wù)上做了雙鏈路寫入和存儲冗余來保證高可用。今年雙11使用了Hologres原生高可用方案下掉手工雙鏈路，省去備用數(shù)據(jù)鏈路上實時任務(wù)開發(fā)、數(shù)據(jù)比對的人力投入，減少鏈路切換時的數(shù)據(jù)不一致，整體開發(fā)人力成本減少200人日，環(huán)比去年降低50%以上;減少了100+用于實時重保的備份鏈路作業(yè)，減少計算資源2000CU。
- 阿里巴巴數(shù)據(jù)產(chǎn)品與技術(shù)部(Data Technology，以下簡稱DT)使用Hologres讀寫分離方案，高吞吐寫入和靈活查詢互不干擾;分析查詢QPS增長80%的同時，查詢抖動明顯減少。
我們認為實時數(shù)倉的生產(chǎn)系統(tǒng)化是一個必然的趨勢，相信各個實時數(shù)倉產(chǎn)品都會逐步加碼這方面的開發(fā)投入。
三、分析服務(wù)一體化(HSAP)
第三個趨勢是分析服務(wù)的一體化(HSAP)。
Hologres是這方面的首倡者，源頭是阿里集團內(nèi)的業(yè)務(wù)對分析服務(wù)一體化有強訴求，分析服務(wù)一體化最佳實踐首先在阿里內(nèi)部落地，但我們在業(yè)界也看到越來越多的產(chǎn)品和企業(yè)在倡導和實踐分析服務(wù)一體化。
分析服務(wù)一體化(HSAP)可以從幾個層面上去理解：
最基礎(chǔ)的是用戶可以使用一套技術(shù)棧(Flink+Hologres)去解決Ad-hoc Query分析(對內(nèi))和線上服務(wù)(對內(nèi)、to B、to C)兩個任務(wù)，從而降低開發(fā)運維成本。傳統(tǒng)上，實時數(shù)倉做的是Ad-hoc Query，而lambda架構(gòu)實現(xiàn)的是線上服務(wù)。這兩個在技術(shù)棧、數(shù)據(jù)鏈路、開發(fā)運維等都完全不同，但處理的數(shù)據(jù)來源往往是同一份數(shù)據(jù)，導致了大量的開發(fā)作業(yè)冗余，同時數(shù)據(jù)的一致性也是大難題。而通過使用統(tǒng)一技術(shù)棧同時滿足這兩方面的需求，開發(fā)、運維、治理變的簡單。
以阿里CCO的場景為例，數(shù)據(jù)寫入到Hologres行存表后(行存表寫入吞吐高，主鍵查詢快，更新場景Binlog開銷低)，會通過Hologres表的binlog被Flink二次消費加工后，存入Hologres的列存表提供分析(列存對于統(tǒng)計類查詢速度快)。行存表提供線上服務(wù)/點查，列存表提供分析能力。
更高層次的HSAP是用戶可以在一個平臺上用一份數(shù)據(jù)去實現(xiàn)Ad-hoc Query和線上服務(wù)兩個任務(wù)，同時實現(xiàn)良好的資源隔離和可用性。
例如，今年雙11 DT部門上了Hologres讀寫分離方案(由兩個Hologres實例分別負責實時寫入和實時查詢，但共享一份底層數(shù)據(jù)存儲)，同時有多個讀實例分別負責不同類型的查詢，這樣就可以保證讀寫隔離、分析查詢和服務(wù)查詢隔離，且只有一份數(shù)據(jù)。也就是所謂的One Data，Multi Workload。
分析服務(wù)一體化除了上述的好處外，另外一個顯著的優(yōu)勢是服務(wù)上線速度明顯加快。因為一體化后，分析和服務(wù)的邊界變的模糊，所以服務(wù)的開發(fā)和分析差異不大，可以認為服務(wù)就是一種簡單、固定pattern的分析。這樣，傳統(tǒng)上服務(wù)上線的復雜流程就被大大簡化了。當有緊急需求需要臨時開發(fā)，也能馬上就上線，無需繁瑣的流程了。
我們相信分析服務(wù)一體化的理念隨著像Hologres這樣的產(chǎn)品的發(fā)展，會在更多的場景落地。而這也會反哺像Hologres這樣的HSAP產(chǎn)品，將HSAP的理念、方法論、支持能力在產(chǎn)品中更好的沉淀下來，從而讓更多的用戶更容易的從HSAP中獲益。
四、實時數(shù)據(jù)治理成為剛需
第四個趨勢是實時數(shù)據(jù)治理變的越來越重要。
實時數(shù)據(jù)對于企業(yè)來說，有著致命的吸引力。因此，企業(yè)會自覺不自覺的逐步加大實時數(shù)倉上的投入。而各企業(yè)的實時數(shù)倉因為實時性的要求，往往沒有實施離線數(shù)倉那么嚴密的方法論和管理體系。因為沒有治理，數(shù)據(jù)大量冗余或者不合理，往往會導致成本急劇增大，數(shù)據(jù)可信度下降。在阿里這樣的超大企業(yè)中，這塊的成本就會突顯出來，這已經(jīng)成為實時數(shù)倉的一種剛需。
通過對實時數(shù)倉、離線數(shù)倉、流式計算、消息隊列等全鏈路進行數(shù)據(jù)治理，可以實現(xiàn)數(shù)據(jù)沒有“法外之地”，從而在節(jié)省成本的同時，提高數(shù)據(jù)的質(zhì)量，真正將數(shù)據(jù)變?yōu)槠髽I(yè)的資產(chǎn)。
五、實時數(shù)倉的類數(shù)據(jù)庫化
第五個趨勢是實時數(shù)倉的類數(shù)據(jù)庫化。
大數(shù)據(jù)誕生于對傳統(tǒng)數(shù)據(jù)庫的揚棄，從NoSQL到NewSQL，大數(shù)據(jù)產(chǎn)品走出了一條獨立于數(shù)據(jù)庫的路。但就像從NoSQL到NewSQL一樣，大數(shù)據(jù)產(chǎn)品中的實時數(shù)倉也在像數(shù)據(jù)庫學習，提供了和數(shù)據(jù)庫更好的兼容性，從而讓用戶能以更低的成本使用實時數(shù)倉產(chǎn)品。
這包含幾個方面：
- 操作SQL化以及和傳統(tǒng)數(shù)據(jù)庫在協(xié)議、語法上的兼容性，從而方便開發(fā)同學可以用習慣的工具(BI、開發(fā)工具等)去對接開發(fā)。大數(shù)據(jù)在這方面的積累還是及不上數(shù)據(jù)庫幾十年的積累的，相當多的業(yè)務(wù)同學對于數(shù)據(jù)庫很熟練，但對于大數(shù)據(jù)(特別是實時數(shù)倉)就感覺不容易上手了。
- 數(shù)據(jù)模型和語義向傳統(tǒng)數(shù)據(jù)庫靠攏。例如，主鍵(Primary Key)概念是傳統(tǒng)數(shù)倉類產(chǎn)品所缺乏的，操作的原子性數(shù)倉產(chǎn)品往往也不能保證，這就限制了很多場景的應(yīng)用。比方說，Clickhouse缺乏數(shù)據(jù)庫意義上的主鍵(CK所說的主鍵是另外一個東西，非唯一性約束)，所以就不合適處理數(shù)據(jù)庫CDC同步場景。這兩年，大數(shù)據(jù)業(yè)界可以明顯看到對這塊的增強。最典型的例子是DeltaLake、Iceberge和Hudi等為代表的近實時數(shù)倉增加了ACID能力。當然，受制于架構(gòu)，這種近實時ACID在頻繁更新場景下的性能和延時是有瓶頸的。
在阿里，大量場景需要這種基于主鍵的更新能力，以阿里巴巴內(nèi)部場景為例：
- 數(shù)據(jù)庫的實時同步：通過將上游的分庫分表和多個業(yè)務(wù)庫實時同步(鏡像)到一個大數(shù)據(jù)實時數(shù)倉中，可以提供對業(yè)務(wù)數(shù)據(jù)的強大分析能力，而這就需要很好的處理純實時的高頻UPDATE和DELETE操作。
- Flink 計算產(chǎn)生的UPDATE和DELETE(RETRACTION)操作：例如統(tǒng)計GMV，F(xiàn)link在結(jié)果更新時會生成UPDATE記錄，而在有些場景下會生成RETRACTION記錄(DELETE)，這都要求下游系統(tǒng)能很好的處理這兩類事件。
- 風控等業(yè)務(wù)的計算是由多路作業(yè)共同完成的，這些作業(yè)共同實時更新一張大寬表(每個作業(yè)更新部分字段)，這就要求下游系統(tǒng)能提供基于主鍵的部分更新能力。
傳統(tǒng)上，這樣的業(yè)務(wù)是由HBase、Redis這樣的NoSQL系統(tǒng)或者MySQL、PostgreSQL等數(shù)據(jù)庫RDS來承接的。但NoSQL的問題是分析能力普通偏弱，而數(shù)據(jù)庫問題是寫入性能和規(guī)模有限制。
這些業(yè)務(wù)在大數(shù)據(jù)處理中普遍存在。但在阿里的挑戰(zhàn)是因為規(guī)模的巨大(特別是雙11這樣的場景)，對基于主鍵的更新性能和延遲有苛刻的要求。
Hologres從設(shè)計之初就考慮了這兩點。Hologres完全兼容了PostgreSQL 11的協(xié)議、語法、函數(shù)等，很多PostgreSQL擴展(例如PostGIS)可以直接使用。同時，Hologres提供了完整的主鍵概念和強大的更新能力，并提供了單SQL的ACID。今年雙11，有業(yè)務(wù)測得了每秒350萬+的實時寫入更新性能。這些能力極大的放寬了實時數(shù)倉的應(yīng)用場景，將傳統(tǒng)由NoSQL和RDS承載的場景改由實時數(shù)倉來承載，為用戶提供了更加強大的分析處理工具。
實時數(shù)倉的類數(shù)據(jù)庫化并不就等價于HTAP數(shù)據(jù)庫了。HSAP相比于HTAP，在事務(wù)能力上是削弱的。因為在服務(wù)(serving)場景，并不需要傳統(tǒng)數(shù)據(jù)庫完整的事務(wù)能力。而這種舍棄，帶來的是在實時寫入性能和查詢性能上的極大提升，以及可擴展性上的提升(因為不需要全局事務(wù)管理器了)。因此，HSAP相比HTAP也就更加適合大數(shù)據(jù)場景。
六、實時數(shù)倉開發(fā)敏捷化
最后一個趨勢是開發(fā)方法論上的變化，實時數(shù)倉的開發(fā)越來越敏捷，以適應(yīng)分析場景的靈活多變。
過去數(shù)倉的開發(fā)往往按照經(jīng)典的方法論，采用ODS->DWD->DWS->ADS逐層開發(fā)的方法，層與層之間采用事件驅(qū)動，或者微批次的方式調(diào)度。分層帶來更好的語義層抽象和數(shù)據(jù)復用，但也增加了調(diào)度的依賴、降低數(shù)據(jù)的時效性、減少數(shù)據(jù)靈活分析的敏捷性。
實時數(shù)倉驅(qū)動了業(yè)務(wù)決策的實時化，在決策時通常需要豐富的上下文信息，因此傳統(tǒng)的高度依據(jù)業(yè)務(wù)定制ADS的開發(fā)方法受到了較大挑戰(zhàn)，成千上萬的ADS表維護困難，利用率低，更多的業(yè)務(wù)方希望通過DWS甚至DWD進行多角度數(shù)據(jù)對比分析，這對查詢引擎的計算效率、調(diào)度效率、IO效率都提出了更高的要求。
隨著計算算子向量化重寫、精細化索引、異步化執(zhí)行、多級緩存等多種查詢引擎優(yōu)化技術(shù)，Hologres的計算力在每個版本都有較大改善。因此我們看到越來越多的用戶采用了敏捷化的開發(fā)方式，在計算前置的階段，只做數(shù)據(jù)質(zhì)量清理、基本的大表關(guān)聯(lián)拉寬，建模到DWD、DWS即可，減少建模層次，同時，將靈活查詢在真正分析時在交互式查詢引擎中執(zhí)行，通過秒級的交互式分析體驗，支撐了數(shù)據(jù)分析民主化的重要趨勢。
七、總結(jié)
阿里巴巴在業(yè)界是較早應(yīng)用實時數(shù)倉來處理海量數(shù)據(jù)的公司。實時數(shù)倉在阿里的發(fā)展也逐漸走入深水區(qū)。無論是生產(chǎn)系統(tǒng)化、分析服務(wù)一體化、實時數(shù)據(jù)治理(平臺化)還是類數(shù)據(jù)庫化、敏捷化，實時數(shù)倉正在隨著業(yè)務(wù)需求的快速發(fā)展而快速迭代，并在雙11這樣的年度大戲中煥發(fā)出越來越明亮的光彩，成為業(yè)務(wù)必不可少的伙伴和助手。
業(yè)務(wù)驅(qū)動技術(shù)，數(shù)據(jù)帶來價值，實時數(shù)倉Hologres同阿里巴巴核心業(yè)務(wù)一起成長一起打磨，從多維復雜OLAP分析到高QPS點查，高性能實時寫入與更新到高可用，為大數(shù)據(jù)平臺提供統(tǒng)一分析服務(wù)出口，滿足一站式實時數(shù)倉的存儲、開發(fā)、治理、服務(wù)全流程全場景。
我們相信，這些實時數(shù)倉的趨勢也適用于整個業(yè)界，我們會逐步把在阿里雙11中積累的能力在云上產(chǎn)品中透出，幫助客戶用好實時數(shù)倉，共同成長!
【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
