本文根據(jù)2023云棲大會演講實錄整理而成，演講信息如下：
演講人：姜偉華 | 阿里云計算平臺事業(yè)部資深技術(shù)專家、阿里云實時數(shù)倉Hologres研發(fā)負(fù)責(zé)人
演講主題：Hologres Serverless之路揭秘彈性計算組
實時化成為了大數(shù)據(jù)平臺的核心演進(jìn)趨勢，而其中Serverless技術(shù)可以讓企業(yè)在實時場景取的性能、成本、高可用之間的平衡。2023年云棲大會上，阿里云實時數(shù)倉Hologres研發(fā)負(fù)責(zé)人姜偉華介紹了一站式實時數(shù)倉Hologres在6年研發(fā)期間的Serverless演進(jìn)之路，讓客戶實時數(shù)倉成本降低70%-120%，開發(fā)效率提升100%，性能提升100-200%。
一站式實時數(shù)倉Hologres
首先向大家簡單介紹下Hologres。Hologres 是阿里云自研一站式實時數(shù)倉，以分析服務(wù)一體化架構(gòu)，統(tǒng)一數(shù)據(jù)平臺架構(gòu)，實現(xiàn)一份數(shù)據(jù)，同時支持支持多維分析、在線服務(wù)、湖倉一體、向量計算多個場景，其中包含了：
多維分析（實現(xiàn)同CK、Doris等查詢場景）
數(shù)據(jù)高性能實時寫入、更新與查詢，實現(xiàn)寫入即可查，支持列存、內(nèi)置索引加速
在線服務(wù)（實現(xiàn)同Hbase、Redis等點(diǎn)查場景）
超高QPS下KV與SQL點(diǎn)查、非主鍵點(diǎn)查，支持行存、具備高可用能力
湖倉分析（實現(xiàn)同Presto等交互式分析場景）
無需數(shù)據(jù)搬遷，對MaxCompute、數(shù)據(jù)湖中的表進(jìn)行秒級交互式查詢，元數(shù)據(jù)自動發(fā)現(xiàn)
向量計算（實現(xiàn)同F(xiàn)aiss等向量查詢場景）
內(nèi)置達(dá)摩院Proxima向量引擎，QPS與召回率性能超過開源向量數(shù)據(jù)庫數(shù)倍
Serverless實時數(shù)倉的挑戰(zhàn)與關(guān)鍵技術(shù)
在一個All in one的一站式實時數(shù)倉架構(gòu)下，像我們剛才提到的，希望一份數(shù)據(jù)，同時能支持以上四種場景，那各個業(yè)務(wù)部門、各種業(yè)務(wù)需求便隨之而來，例如：
穩(wěn)定性需求
在進(jìn)行資源的擴(kuò)縮容、啟停時候，如何不影響實時在線的業(yè)務(wù)？
如何保證業(yè)務(wù)/任務(wù)之間的隔離？例如讀寫隔離、寫寫隔離、讀隔離、任務(wù)隔離。并且是比起資源組或者資源隊列來說更加干凈的隔離。
如何有效利用資源？例如水平的擴(kuò)展實現(xiàn)QPS的簡單增加，從500 QPS到擴(kuò)展1000 QPS只需要簡單加一倍資源即可，讓資源管理更加簡單。
成本優(yōu)化需求
如何降低開發(fā)成本？例如上線新業(yè)務(wù)，基于同一份數(shù)據(jù)，但是使用新的計算資源。
如何降低資源資源？例如基于定時和負(fù)載做彈性，應(yīng)對洪峰、日夜變化，用完即銷毀，Endpoint保持不變。
如何降低學(xué)習(xí)成本？例如開發(fā)接口是否通用，是否能對接主流的BI產(chǎn)品。
于是實時數(shù)倉在接收了這么多需求后，自然而然將Severless定義為平臺核心演進(jìn)方向，Hologres在6年的Serverless演進(jìn)過程中，總結(jié)下來了4項Serverless實時數(shù)倉關(guān)鍵技術(shù)挑戰(zhàn)：
存算分離
不管是Hologres, 還是說其他的大數(shù)據(jù)產(chǎn)品，經(jīng)常講一個詞叫存算分離。為什么要做存算分離？因為存算分離是實現(xiàn)Serverless化的一個前置條件，Serverless核心關(guān)注是計算資源的彈性，這就要求存儲和計算必須分離。Hologres從產(chǎn)品第一天開始，就是一個存算分離的架構(gòu)。
如果不做存算分離的話有什么問題呢？傳統(tǒng)上像Greenplum，數(shù)據(jù)是存在本地磁盤的，而本地磁盤有一個容量限制，存滿了就會有搬遷，代價很大。第二個問題是數(shù)據(jù)的訪問，Serverless本質(zhì)上來說，希望計算資源隨時可以拉起，然后就可以去訪問數(shù)據(jù)，任何計算資源都能訪問到這個數(shù)據(jù)。但如果你要存在本地的話，就不能夠讓任何一個計算資源訪問，只有本地盤能訪問。
所以在Serverless的情況下，一般來說數(shù)據(jù)肯定是存在一個分布式的文件系統(tǒng)上的。通過分布式文件系統(tǒng)，首先第一個是解除了容量限制，第二個任何的計算資源都可以去訪問到這份數(shù)據(jù)，計算資源和存儲資源都能池化。如果是一個離線數(shù)倉的話，這個問題就解決了，因為數(shù)據(jù)都在分布式文件系統(tǒng)上，任何計算資源都能訪問到這個數(shù)據(jù)。
對于實時數(shù)倉來說有一個挑戰(zhàn)在于數(shù)據(jù)是不是足夠?qū)崟r。實時數(shù)倉，我們強(qiáng)調(diào)一個實時性，就要求寫進(jìn)去的數(shù)據(jù)馬上就能訪問到，所以在這件事情上，不同的產(chǎn)品可能會有他的各自的取舍。
如果我們能容忍一個五分鐘或者十分鐘的查詢延遲，所有的數(shù)據(jù)客戶端攢5-10分鐘后發(fā)送過來，直接寫到分布式文件系統(tǒng)上，別的計算資源就能訪問到了。但是這個對用戶體驗其實是很差的。因為等于說數(shù)據(jù)寫了，那邊查不出來（延遲5-10分鐘）。Hologres采用的是一個對用戶比較友好的方案：寫入即可查。
寫入即可查是有經(jīng)典方案的，就是Mem Table +LSM Tree。比方說像Hbase或者其他一些產(chǎn)品都是采用這樣一個架構(gòu)，這個架構(gòu)本質(zhì)就是有一部分持久化的數(shù)據(jù)，這些數(shù)據(jù)是存在分布式文件系統(tǒng)上的，別人也能看到。但是最新的數(shù)據(jù)是在mem Table中的，這部分?jǐn)?shù)據(jù)只有本機(jī)能看到。
同時Hologres支持高頻的CRUD, 就是高頻的更新與刪除。因為有很多應(yīng)用，希望基于主鍵，做非常高頻的更新或者刪除，就要求一定要有一個主鍵索引。而這個主鍵索引一定要在內(nèi)存里，否則的話就是性能跟不上。并且這個主鍵索引還在不停的被更新。
Shard Replica
Hologres將實時寫入+高頻CRUD這兩點(diǎn)結(jié)合，讓實時數(shù)倉保持高頻的實時更新或刪除，且寫入即可見，這樣在使用體驗上會非常像一個數(shù)據(jù)庫，對用戶非常友好。但是同時它也帶來了一個新的問題，就是最新的幾分鐘數(shù)據(jù)是在內(nèi)存里。剛才說Serverless的場景下，我們希望任何拉起的計算資源，都能訪問到這些數(shù)據(jù)。但是那些數(shù)據(jù)是在內(nèi)存里的，所以這是一個很特別的挑戰(zhàn)。Hologres解這個問題的方法，我們稱之為叫做Shard Replica（Shard副本）。
簡單來說就是每個Shard Replica在實現(xiàn)機(jī)制上，很像數(shù)據(jù)庫里面的物理復(fù)制。數(shù)據(jù)庫的物理復(fù)制是有一個從實例，通過同步了主實例的write ahead log，然后重放這些log，然后構(gòu)建B+ tree，把數(shù)據(jù)刷下去。在數(shù)據(jù)庫的實現(xiàn)中，主從兩個實例的數(shù)據(jù)也是各自存各的。Hologres在這個地方有一個創(chuàng)新，Shard Replica做了物理復(fù)制，但僅在內(nèi)存中構(gòu)建了自己的MEM Table, 這樣子Shard副本就能看到最新的數(shù)據(jù)。但是Shard副本是不會去flush數(shù)據(jù)到文件系統(tǒng)的。這樣，分布式文件系統(tǒng)上的數(shù)據(jù)就只有一份。這樣Replica通過自己的MEM Table與主Shard的存算分離的落盤數(shù)據(jù)，就可以完整的訪問所有數(shù)據(jù)了，實現(xiàn)了實時的可見性。
副本的維護(hù)代價大概是主的1/4或者1/8的樣子。
Shard Replica能力是Hologres實現(xiàn)存算分離、高可用、容災(zāi)、高QPS等等的基矗
隔離與彈性
有了這個存算分離能力以后，下面怎么樣做？剛才說到有了存算分離，那可以任意地拉起計算資源并訪問，所以這個時候就可以做強(qiáng)的資源隔離，并且自然可以彈性的伸縮，也能夠自適應(yīng)的去響應(yīng)負(fù)載。
高可用
在高可用上，實時數(shù)倉跟一般的離線數(shù)倉做Serverless上有一些差異。因為一般離線數(shù)倉更關(guān)注的是資源能不能用滿，但實時數(shù)倉要求有很高的SLA保證。比方說延遲或抖動，這種都是不允許有的。我們?nèi)绾文鼙ＷC在強(qiáng)隔離的情況下，還能做到各種自由的彈性伸縮與高可用性。
離線數(shù)倉不是基于連接的，每次提交一條SQL，執(zhí)行完給出結(jié)果，然后再來一條。但是實時數(shù)倉是基于連接的，有點(diǎn)像數(shù)據(jù)庫，在資源的變化的過程中（各種變更、擴(kuò)縮容等），如何做到自動的路由負(fù)載均衡。在計算資源彈性時，連接與現(xiàn)有查詢不受影響，在后臺計算資源改變時，原有連接資源可自動路由到新的計算資源上，保證連接不斷。這些能力對于Serverless實時數(shù)倉來說非常有挑戰(zhàn)性。
Hologres的Serverless演進(jìn)之路
剛才說到的這些難題與挑戰(zhàn)，Hologres也不是一下子解決的，接下來我們向大家介紹下Hologres在6年的發(fā)展中，在Serverless是如何逐步演進(jìn)的，希望能和大家有一些交流。
2018年Hologres在阿里內(nèi)部立項。2019年產(chǎn)品化并在阿里集團(tuán)內(nèi)部大規(guī)模使用。到2020年，我們在阿里云上正式商業(yè)化，并且在業(yè)界第一個提出了分析服務(wù)一體化。到了2021年我們主要增強(qiáng)一些企業(yè)級的能力。2022年Hologres重點(diǎn)發(fā)布了主從實例。主從實例是我們Serverless演進(jìn)過程中的一個關(guān)鍵步驟，有非常多的客戶在生產(chǎn)環(huán)境中用上了我們的主從實例，實現(xiàn)了一份數(shù)據(jù)，多種計算。跟傳統(tǒng)數(shù)據(jù)庫的主從不一樣，它的數(shù)據(jù)只有一份，因為大數(shù)據(jù)場景下數(shù)據(jù)量很大，對用戶來說一份數(shù)據(jù)可以極大地節(jié)約存儲成本。同時存算分離下的主從實例，允許大家為不同的業(yè)務(wù)，快速的拉起一個從實例干不同的工作，如果不需要的話，也可以快速地把它給銷毀掉，沒有任何數(shù)據(jù)搬遷的過程。到了2023年我們正式發(fā)布計算組實例。是Hologres面向完全的Serverless化的基本產(chǎn)品形態(tài)。
階段一：獨(dú)享實例
獨(dú)享實例是Hologres常用的形態(tài)，基于之前我們提到的存算分離架構(gòu)，底下是阿里盤古文件系統(tǒng)，上面是計算實例，用戶想要擴(kuò)容、縮容都非常方便，不需要做數(shù)據(jù)搬遷。但是唯一的問題是用戶必須要小心翼翼地控制規(guī)格大小，比方QPS壓力太大了，那你就要擴(kuò)容，不能做到資源按需使用，按需付費(fèi)。
階段二：共享集群
Hologres在2020年就推出了一個完全Serverless化的湖倉共享集群，它是不帶存儲，只會按量收取計算費(fèi)用。首先Hologres與離線數(shù)倉MaxCompute做了一體化的融合，如果想要更快地查詢MaxCompute中的離線數(shù)據(jù)，不需要將數(shù)據(jù)導(dǎo)出，也不需要預(yù)留任何資源，運(yùn)行一條SQL直接查詢就可以，最終只按照SQL查詢量收費(fèi)，用戶在不使用的時候，不會收任何的費(fèi)用，也不需要任何的啟停操作。這是我們做的非常徹底Serverless的產(chǎn)品，不僅僅是MaxCompute中的數(shù)據(jù)，還可以查詢OSS中數(shù)據(jù)湖的數(shù)據(jù)。
共享集群僅適用離線數(shù)倉與數(shù)據(jù)湖加速查詢的場景，沒有很好的SLA的保證。
階段三：主從實例
為了實現(xiàn)資源的強(qiáng)隔離，同時支持一份數(shù)據(jù)、多種計算的愿景，Hologres推出了主從實例，實現(xiàn)一份數(shù)據(jù)多種計算，計算之間完全隔離。
一個典型的場景：首先有一個讀寫的獨(dú)享主實例，負(fù)責(zé)數(shù)據(jù)的寫入，然后按需創(chuàng)建多個只讀的從實例。這個創(chuàng)建過程非�？�，沒有任何數(shù)據(jù)搬遷。比方說現(xiàn)在線上業(yè)務(wù)在跑著，突然發(fā)現(xiàn)線上業(yè)務(wù)數(shù)據(jù)不太對。那怎么辦呢？用戶可以臨時拉起一個從實例，然后在上面做數(shù)據(jù)分析，找出問題在哪里，這對用戶來說是一個非常易用的一種體驗。
這種場景我們做了非常強(qiáng)的隔離，存儲層面依托盤古強(qiáng)大的分布式文件系統(tǒng)的能力，基本可以保證IO之間沒有競爭。計算層面，我們通過K8S實現(xiàn)隔離，做到了計算之間也沒有競爭。存儲與計算都沒有競爭，讓用戶實現(xiàn)了很干凈的強(qiáng)隔離，體驗也非常好。我們見過最多的一個客戶是一主九從，掛了非常多的從實例干各種各樣的事情，比如分配一個從實例給經(jīng)常做分析的同事，或者分配一個從實例給某個特定部門。
但是這種主從實例也有它的問題，由于每一個都是一個獨(dú)立的實例，每個都有一個入口，用戶如果要用新的從實例，必須要去改他的代碼，把代碼指向這個新的實例才能用起來，這樣用戶體驗就不夠好，不夠靈活，所以今年我們正式推出了計算組實例。
階段四：計算組實例
計算組實例內(nèi)部有多個計算組，計算組之間還是強(qiáng)隔離，但是它是一個實例，有一個統(tǒng)一的路由，于是在計算組內(nèi)部，各種強(qiáng)隔離、彈性自動路由等等都可以做了。
計算組上面有一個gateway, 這是一個網(wǎng)關(guān)，用戶所有的請求都會通過這個網(wǎng)關(guān)打過來。下面的計算組跟剛才的從實例很像。每個計算組都是一組獨(dú)立的計算資源。計算組和計算組之間是強(qiáng)隔離的，由網(wǎng)關(guān)來進(jìn)行這個任務(wù)的路由。這樣對用戶來說永遠(yuǎn)看到的是同一個網(wǎng)關(guān)。所有的彈性擴(kuò)縮容等操作，都是管理員做的事情，對用戶來說是無感的，也解決了我們在主從實例中留下的不夠靈活的問題。
舉幾個典型應(yīng)用場景：
計算組實例應(yīng)用：動態(tài)擴(kuò)容
一般我們分2個計算組，包括默認(rèn)計算組和查詢計算組，其中默認(rèn)計算組只承擔(dān)寫入&ETL等流程，查詢計算組負(fù)責(zé)對外查詢，實現(xiàn)讀寫隔離。當(dāng)實時數(shù)倉使用人更多，服務(wù)更多部門時，讀寫隔離不能完全滿足需求，寫入與寫入之間會有資源爭搶，查詢之間也有資源爭搶。我們就可以需要提供擴(kuò)容多種計算組，比如離線寫入計算組、實時寫入計算組、OLAP查詢計算組、在線服務(wù)計算組，實現(xiàn)不同場景/業(yè)務(wù)之間的完全隔離。
計算組實例應(yīng)用：彈性伸縮
在大促或者某些場景下，我們經(jīng)常遇到資源不足的情況，當(dāng)流量洪峰來臨時，根據(jù)業(yè)務(wù)需求對單個計算組擴(kuò)容，低峰期對計算組進(jìn)行縮容，同時系統(tǒng)支持熱擴(kuò)縮容方式，將業(yè)務(wù)影響降到最低，并且防止資源的浪費(fèi)。
計算組實例應(yīng)用：自動路由
某一個計算組出了問題或者壓力太大發(fā)生Failover后，影響業(yè)務(wù)，需要快速止血時，我們希望給它減少流量或者完全停掉。原來是解不了這個問題，用戶只能改應(yīng)用程序�，F(xiàn)在管理員只需要通過SQL命令實現(xiàn)自動路由機(jī)制，無需改動應(yīng)用接口，快速將Failover計算組的負(fù)載路由至默認(rèn)/指定計算組，實現(xiàn)業(yè)務(wù)快速恢復(fù)。
客戶案例：
某客戶Serverless實時數(shù)倉升級之路
剛才我們是從Hologres自身的視角來看待實時數(shù)倉的發(fā)展與演進(jìn)，最后我們來看一個我們長期的資深用戶是如何一步一步基于Hologres來做自己業(yè)務(wù)實時數(shù)倉的升級與Serverless化的。
這是一個物流的客戶，他們業(yè)務(wù)主要做倉儲的管理，有好幾類業(yè)務(wù)，第一類業(yè)務(wù)叫實時播報，需要一個快速開發(fā)的，高保障的一個業(yè)務(wù)。第二個業(yè)務(wù)就是倉庫的各種實時作業(yè)，指導(dǎo)倉庫這種貨放到哪里去等等，需要一個作業(yè)調(diào)度系統(tǒng)，要求高性能并且要持續(xù)服務(wù)高SLA的保證。第三類像傳統(tǒng)的大屏，或者說類似指標(biāo)中心的自助分析，要求更強(qiáng)的靈活性。整體業(yè)務(wù)規(guī)模上，大概有350個左右的實時任務(wù)，消耗1萬CU，量非常大。同時P2級以上的重點(diǎn)任務(wù)占了70%，對SLA的要求也非常高。從性能要求上，日均大概是每秒鐘寫入2000萬條記錄，峰值能達(dá)到每秒6000萬條，然后每秒輸出大概50萬條記錄，整體的實時吞吐性能非常高。
可以看到這是一個業(yè)務(wù)復(fù)雜，對性能、SLA、成本等都有非常多要求的客戶場景。
實時數(shù)倉1.0-Hologres替換傳統(tǒng)數(shù)倉
最早的時候?qū)崟r數(shù)倉1.0，底下實時數(shù)據(jù)從DWD到DWS到ADS, 這個加工層是通過消息隊列Kafka加上Flink來做的。他們會把結(jié)果數(shù)據(jù)同時寫兩個地方，一個是Lindorm，類似于Hbase，因為剛才我們提到的物流庫存作業(yè)是一個高穩(wěn)定性保障業(yè)務(wù)，所以他用這個來對外提供點(diǎn)查的能力。同時將數(shù)據(jù)寫入Hologres，提供交互式分析與OLAP查詢等服務(wù)。
實時數(shù)倉2.0-Hologres升級主從實例，高可用部署
2022年隨著Hologres推出了主從實例，他們做了一次架構(gòu)的變更。首先，從實時數(shù)據(jù)加工鏈路上，本來Flink+Kafka實現(xiàn)的DWD、DWS、ADS層加工，現(xiàn)在改成用Hologres+Flink來做，把DWD層寫到Hologres里面去，同時Flink訂閱Hologres的Binlog。這樣任何一張表的變更，F(xiàn)link都能感知到。Flink加工得到的DWS層再寫到Hologres里面去。然后再通過Flink訂閱Binlog, 加工ADS層寫到Hologres里面去。這時候大家可能覺得這個場景有點(diǎn)奇怪，為什么要這么搞來搞去。其實這個架構(gòu)最大的好處是，每一層數(shù)據(jù)都是可查可對外服務(wù)的。原來架構(gòu)中，數(shù)據(jù)在Kafka中，只能給Flink用。如果數(shù)據(jù)有問題，要去查一下問題都很困難。而在這個架構(gòu)中，每一層的數(shù)據(jù)都是Hologres對外提供服務(wù)的。不需要數(shù)據(jù)冗余，同一份數(shù)據(jù)既可以給Flink應(yīng)用，也可以對外提供服務(wù)。
同時，為了支持隔離與高可用，他們建了好幾個從實例來給不同的業(yè)務(wù)用。需要的時候就再創(chuàng)建一個。實現(xiàn)了讀寫分離和同城容災(zāi)，故障從6次降為0次，存儲下降幾百T，開發(fā)效率提升100%。
實時數(shù)倉3.0（ing）-Hologres計算組實例，彈性和隔離
2023年隨著我們推出了計算組實例后，他們把整個主從實例替換成了計算組實例。通過拉起不同的計算組，統(tǒng)一對外提供服務(wù)。整個實時數(shù)倉的架構(gòu)更加Serverless化，拉起一個新的計算組，不再需要去改應(yīng)用，每個計算組又能提供很好的隔離。
最后講一下我們對未來趨勢的一些看法，，雖然Hologres推出了計算組實例，坦率地說這只是我們Serverless化的開始。作為一個云產(chǎn)品，我們希望讓客戶通過Serverless，使用起來更簡單，成本更低。因此我們在未來主要有兩個目標(biāo)，第一個是Down To Zero，簡單來說，當(dāng)用戶不用任何計算的時候，不問用戶收取任何計算的費(fèi)用。并且在這種情況下，如果有請求進(jìn)來，計算資源能秒級恢復(fù)并響應(yīng)，并不是說停掉了以后請求來了就斷掉了。第二個目標(biāo)，我們希望能夠把獨(dú)享實例和共享實例統(tǒng)一在一起，變成一個統(tǒng)一的對外的形態(tài)，實現(xiàn)自助資源切換。最終用戶在沒有計算的時候可以不花一分錢，請求來了能及時響應(yīng)，業(yè)務(wù)變化又能靈活滿足多種資源需求，這是我們希望給用戶提供的終極形態(tài)。
除了Severless，Hologres在本次云棲大會還將物化視圖升級DynamicTable進(jìn)行升級，與Flink結(jié)合構(gòu)建流批一體的數(shù)倉分層架構(gòu)，用戶只需描述數(shù)據(jù)的應(yīng)用場景、產(chǎn)生邏輯、實時性要求、分層依賴，DynamicTable負(fù)責(zé)高效的一體化工程實現(xiàn)，保持?jǐn)?shù)據(jù)高性能的實時寫入、實時更新、實時查詢，解決離線實時重復(fù)開發(fā)、數(shù)據(jù)不一致，學(xué)習(xí)成本搞，運(yùn)維復(fù)雜等難題。
在淘天集團(tuán)直播數(shù)據(jù)決策分析產(chǎn)品中，Dynamic Table數(shù)倉分層架構(gòu)讓實時數(shù)倉整體性能提升200%，延遲下降85%，在淘天集團(tuán)營銷活動分析場景中，Dynamic Table數(shù)倉分層架構(gòu)讓實時性能提升30%，離線性能提升800%，這個功能在不久之后也會在公共云開放給客戶使用。
可以看到無論是Serverless還是物化視圖的升級，Hologres在演進(jìn)過程中始終緊緊圍繞實時場景，不斷提高實時數(shù)倉的性能、可用性、用戶體驗。Hologres希望替換企業(yè)紛繁蕪雜的數(shù)倉架構(gòu)，通過一站式的理念讓實時數(shù)倉更加干凈、友好、高效，并幫助企業(yè)不斷降低成本，加速數(shù)字化轉(zhuǎn)型升級。
