導(dǎo)讀 本文將介紹騰訊自研的大數(shù)據(jù)計(jì)算平臺(tái)——天穹SuperSQL，以及在應(yīng)對(duì)數(shù)據(jù)湖場(chǎng)景中的復(fù)雜多維分析方面的實(shí)踐。

【資料圖】

全文目錄：

1.SuperSQL架構(gòu)

2.自適應(yīng)計(jì)算引擎

3.實(shí)時(shí)湖倉融合

4.未來展望

分享嘉賓｜程廣旭 騰訊 高級(jí)工程師

編輯整理｜楊文鑄 哈爾濱理工大學(xué)

出品社區(qū)｜DataFun

01

SuperSQL架構(gòu)

首先介紹一下騰訊自研的下一代大數(shù)據(jù)計(jì)算平臺(tái)SuperSQL的技術(shù)架構(gòu)。

1.SuperSQL的整體架構(gòu)

SuperSQL是騰訊自研的下一代大數(shù)據(jù)自適應(yīng)計(jì)算平臺(tái)，通過開放融合的架構(gòu)實(shí)現(xiàn)了一套代碼，高效解決公有云、私有云、內(nèi)網(wǎng)的任何大數(shù)據(jù)計(jì)算場(chǎng)景的問題，將異構(gòu)計(jì)算引擎、異構(gòu)存儲(chǔ)服務(wù)、計(jì)算引擎的智能化和自動(dòng)化、SQL的流批一體、算力感知等智能調(diào)度納入到內(nèi)部的系統(tǒng)閉環(huán)當(dāng)中，為用戶提供極簡(jiǎn)的、統(tǒng)一的大數(shù)據(jù)計(jì)算體驗(yàn)，用戶能夠從復(fù)雜的底層技術(shù)細(xì)節(jié)當(dāng)中脫離出來，專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)，像使用數(shù)據(jù)庫一樣來使用大數(shù)據(jù)，實(shí)現(xiàn)業(yè)務(wù)邏輯和底層大數(shù)據(jù)技術(shù)的解耦。

SuperSQL提供了完整的端到端的大數(shù)據(jù)解決方案，適配公有云、私有云和內(nèi)網(wǎng)等不同的云場(chǎng)景。通過下圖我們可以看到SuperSQL的整個(gè)架構(gòu)主要分為四部分，這四部分互相之間不存在耦合關(guān)系，都是獨(dú)立存在的：

（1）核心引擎層

核心引擎層是SuperSQL的核心所在，是統(tǒng)一計(jì)算的入口和智能決策的中心，對(duì)外提供了通用的SQL語法并自動(dòng)適配計(jì)算引擎的不同SQL標(biāo)準(zhǔn)，同時(shí)匯總來自元數(shù)據(jù)、歷史流水、底層集群狀態(tài)等不同的信息，通過組合算法實(shí)現(xiàn)SQL自身語法的優(yōu)化、物化視圖的自主構(gòu)建、引擎的智能選擇等，從而影響到整個(gè)計(jì)算的生命周期。

（2）計(jì)算層

主要根據(jù)每個(gè)SQL的特點(diǎn)以及使用場(chǎng)景選擇最佳的計(jì)算引擎，從而保證了在不同架構(gòu)下的計(jì)算穩(wěn)定性，其中Remote Shuffle Service則提供了統(tǒng)一的數(shù)據(jù)Shuffle服務(wù)，實(shí)現(xiàn)了計(jì)算、執(zhí)行、拓?fù)涞淖赃m應(yīng)。

Spark負(fù)責(zé)ETL、報(bào)表類的場(chǎng)景 presto負(fù)責(zé)交互式查詢的分析場(chǎng)景 Hermes是騰訊自研的用于日志檢索、用戶畫像場(chǎng)景的組件 StarRocks負(fù)責(zé)數(shù)據(jù)查詢的場(chǎng)景 PowerFL負(fù)責(zé)數(shù)據(jù)安全場(chǎng)景

（3）資源層

主要整合了云上和云下的資源，能夠?qū)λ械馁Y源進(jìn)行統(tǒng)一管理，從而為計(jì)算提供統(tǒng)一的資源池，通過資源的自適應(yīng)調(diào)整、租戶間資源彈性調(diào)度、集群中資源借調(diào)等手段統(tǒng)籌資源的管理，提升整個(gè)資源的使用效率。

（4）數(shù)據(jù)編排層

主要適配了系統(tǒng)的異構(gòu)存儲(chǔ)、透明化的存儲(chǔ)差異、解耦計(jì)算和存儲(chǔ)、自主學(xué)習(xí)、數(shù)據(jù)訪問模式、自適應(yīng)緩存（熱點(diǎn)數(shù)據(jù)和元數(shù)據(jù)），從而加速數(shù)據(jù)訪問的性能，提升集群的穩(wěn)定性。

2.SuperSQL的目標(biāo)

（1）SuperSQL整體的目標(biāo)

依托騰訊大數(shù)據(jù)生態(tài)，持續(xù)完善自適應(yīng)能力，從而打造完整的大數(shù)據(jù)極速查詢解決方案 實(shí)現(xiàn)三網(wǎng)合一的云原生化，解決大型復(fù)雜查詢的等待痛點(diǎn) 持續(xù)探索技術(shù)先進(jìn)性，構(gòu)建高性能的融合分布式計(jì)算框架，實(shí)現(xiàn)引擎層的閉環(huán)統(tǒng)一管理

（2）計(jì)算融合

跨源：支持訪問不同類型/版本的數(shù)據(jù)源 跨引擎：支持外接多類分布式計(jì)算引擎 跨DC：支持跨集群/地域的SQL編排

（3）計(jì)算解耦

快速構(gòu)建：不重復(fù)“造輪子“，復(fù)用開源計(jì)算引擎 輕量級(jí)解耦：不強(qiáng)依賴特定引擎，少做侵入性修改 場(chǎng)景自適應(yīng)：根據(jù)SQL特征，智能挑選主流執(zhí)行引擎

3.SuperSQL技術(shù)沙盤

下圖具體展示了SuperSQL 的技術(shù)沙盤。

在整個(gè)技術(shù)沙盤的應(yīng)用層提供了多種多樣的接口來適配業(yè)務(wù)的不同使用方式；中間層是SuperSQL的核心能力，包括元數(shù)據(jù)管理、查詢的解析和優(yōu)化（兼容常用引擎的方言等）、智能計(jì)算等；最下面一層則是SuperSQL對(duì)接的數(shù)據(jù)源，目前SuperSQL已經(jīng)對(duì)接了超過17種的數(shù)據(jù)源，從而滿足不同的業(yè)務(wù)訴求。

02

自適應(yīng)計(jì)算引擎

第二部分介紹SuperSQL自適應(yīng)計(jì)算引擎是如何進(jìn)行選擇的。

1.SQL兼容：插件式解析模塊，支持多引擎

引擎之間或者數(shù)據(jù)源之間所使用的語法存在一定差異，所以選擇引擎的時(shí)候需要對(duì)SQL進(jìn)行轉(zhuǎn)化使其能夠滿足引擎的正確識(shí)別并執(zhí)行。SuperSQL作為計(jì)算平臺(tái)的一個(gè)入口能夠有效兼容不同語法之間的差異，從而做到對(duì)數(shù)據(jù)語法的自適應(yīng)，為整個(gè)大數(shù)據(jù)計(jì)算平臺(tái)奠定了基石。

SQL語法的轉(zhuǎn)化過程主要分為兩部分：SQL的兼容和SQL的轉(zhuǎn)化。

目標(biāo)：SQL語法能夠在常用的計(jì)算引擎之間進(jìn)行無感切換 難點(diǎn)：不同SQL語法差異比較大

2.計(jì)算引擎自適應(yīng)：人工到智能的實(shí)踐

通過長期不斷地迭代，從人工選擇不同的計(jì)算引擎到實(shí)現(xiàn)了智能選擇。智能選擇的主要過程為：SQL通過SuperSQL時(shí)，SuperSQL會(huì)對(duì)SQL進(jìn)行解析并進(jìn)入計(jì)算引擎的選擇過程；目前的引擎選擇框架采用了先進(jìn)的RBO+CBO+HBO的組合進(jìn)行初步的引擎選擇，基于機(jī)器學(xué)習(xí)算法再進(jìn)一步進(jìn)行優(yōu)化（采用這種方式的原因是希望從人工專家經(jīng)驗(yàn)平穩(wěn)過渡到基于算法模型的方案）。

引擎選擇規(guī)則：

RBO：根據(jù)SQL類型以及引擎是否支持等維度判斷當(dāng)前SQL適合哪個(gè)引擎； CBO：基于SQL復(fù)雜度以及用戶底層計(jì)算資源的感知判斷適合提交至哪個(gè)引擎； HBO：基于歷史SQL的執(zhí)行情況進(jìn)一步進(jìn)行判斷； AI預(yù)測(cè)：提取SQL特征，選擇合適引擎。

03

實(shí)時(shí)湖倉融合

這部分主要介紹騰訊新一代的實(shí)時(shí)湖倉融合平臺(tái)。

1.湖倉一體架構(gòu)

（1）傳統(tǒng)實(shí)時(shí)湖倉一體架構(gòu)

從下圖可以看出，一般DataSource里的用戶數(shù)據(jù)會(huì)通過Flink同步到Iceberg中用于實(shí)時(shí)讀取或批量查詢。

該方案優(yōu)點(diǎn)：增量讀取，實(shí)時(shí)性好；相比MQ更穩(wěn)定；

該方案缺點(diǎn)：借用外部查詢引擎，查詢性能一般。

（2）實(shí)時(shí)湖倉融合架構(gòu)

常見的數(shù)據(jù)湖使用場(chǎng)景主要是四種：實(shí)時(shí)寫入離線查詢，實(shí)時(shí)寫入實(shí)時(shí)查詢，離線寫入離線查詢，以及離線寫入實(shí)時(shí)查詢。

SuperSQL實(shí)時(shí)湖倉主要解決了實(shí)時(shí)寫入實(shí)時(shí)查詢的場(chǎng)景。

該方案優(yōu)點(diǎn)：數(shù)據(jù)寫入實(shí)時(shí)性更高，接入簡(jiǎn)單；查詢性能更優(yōu)；

該方案缺點(diǎn)：相比較于Iceberg等湖格式，支持的能力有所欠缺。

整個(gè)架構(gòu)的流程主要是：用戶可以將數(shù)據(jù)導(dǎo)入到MQ中，借助實(shí)時(shí)數(shù)倉能力（目前能力主要依賴于StarRocks開源引擎）進(jìn)行實(shí)時(shí)寫入并構(gòu)建不同層級(jí)的數(shù)據(jù)倉庫，在StarRocks中主要存儲(chǔ)熱數(shù)據(jù)（最近n天的數(shù)據(jù)），n天之前的數(shù)據(jù)自動(dòng)/手動(dòng)降冷至數(shù)據(jù)湖中，入湖之后主要借助SuperSQL跨源跨引擎能力來實(shí)現(xiàn)湖倉數(shù)據(jù)的實(shí)時(shí)查詢。

2.數(shù)據(jù)入倉

（1）實(shí)時(shí)/離線數(shù)據(jù)入倉

具體來看，實(shí)時(shí)/離線數(shù)據(jù)入倉的整體架構(gòu)如下圖。

實(shí)時(shí)數(shù)據(jù)會(huì)通過MQ，或?qū)胫罠link再通過Flink寫入至實(shí)時(shí)數(shù)倉，然后實(shí)時(shí)數(shù)倉中數(shù)據(jù)會(huì)經(jīng)過t+1或t+n模式降冷至數(shù)據(jù)湖。這種方式的問題是數(shù)據(jù)湖中的數(shù)據(jù)會(huì)有一定時(shí)間的延遲，即湖倉數(shù)據(jù)可能不一致（部分業(yè)務(wù)會(huì)有數(shù)據(jù)湖數(shù)據(jù)批量實(shí)時(shí)查詢的訴求，因此我們也有一種實(shí)現(xiàn)雙寫入的方案，即數(shù)據(jù)通過MQ后，同時(shí)寫入數(shù)據(jù)倉庫和數(shù)據(jù)湖中，但雙寫方案對(duì)寫入性能會(huì)有一定的影響）。

離線數(shù)據(jù)通過內(nèi)部離線調(diào)度平臺(tái)的插件，允許用戶通過Hive、Iceberg、Hudi中的數(shù)據(jù)離線同步至數(shù)據(jù)湖中。同時(shí)對(duì)湖、倉數(shù)據(jù)進(jìn)行分區(qū)映射。

（2）離線數(shù)據(jù)入倉

離線數(shù)據(jù)的入倉，對(duì)于Iceberg數(shù)據(jù)源我們借助了StarRocks中Routine Load的能力。通過Iceberg數(shù)據(jù)組織架構(gòu)圖可以看到，數(shù)據(jù)湖中的數(shù)據(jù)每進(jìn)來一批之后會(huì)生成一個(gè)新的metadata file文件，通過最新的S0或S1文件之間的差異比較確認(rèn)增量的數(shù)據(jù)內(nèi)容有哪些，得到增量數(shù)據(jù)后通過StarRocks內(nèi)部FE側(cè)的處理生成不同的task任務(wù)，再把這些task任務(wù)提交到StarRocks BE端，從而實(shí)現(xiàn)離線數(shù)據(jù)的寫入。

（3）實(shí)時(shí)數(shù)據(jù)入倉及降冷

對(duì)于實(shí)時(shí)數(shù)據(jù)入倉和降冷也是借助StarRocks中Routine Load的能力把MQ中的數(shù)據(jù)寫入StarRocks；降冷這部分首先會(huì)去支持降冷的操作，用戶創(chuàng)建降冷任務(wù)，并指定具體表的降冷及降冷至什么位置（例如降冷至Iceberg或Hudi等）。降冷任務(wù)創(chuàng)建后就會(huì)儲(chǔ)存到實(shí)時(shí)數(shù)倉集群中，實(shí)時(shí)數(shù)倉則會(huì)定時(shí)輪詢調(diào)度已提交的降冷任務(wù)并進(jìn)行判斷哪些分區(qū)數(shù)據(jù)需要降冷、哪些分區(qū)數(shù)據(jù)不需要降冷，假如所有的分區(qū)數(shù)據(jù)都不需要降冷，則進(jìn)入下一次輪詢；假如有分區(qū)數(shù)據(jù)需要降冷則會(huì)提交對(duì)應(yīng)的降冷任務(wù)至任務(wù)隊(duì)列中，后續(xù)再從隊(duì)列中取出降冷任務(wù)并真正執(zhí)行，從而實(shí)現(xiàn)數(shù)據(jù)降冷。

3.自適應(yīng)融合查詢

降冷后的數(shù)據(jù)和數(shù)據(jù)倉庫的數(shù)據(jù)是可以實(shí)現(xiàn)融合查詢的，這種融合查詢是在SuperSQL側(cè)實(shí)現(xiàn)的，通過自適應(yīng)判斷哪些數(shù)據(jù)來自于數(shù)據(jù)倉庫、哪些數(shù)據(jù)來自于數(shù)據(jù)湖。

假如SQL查詢指令完全命中熱數(shù)據(jù)，則會(huì)把該命令下發(fā)至實(shí)時(shí)數(shù)倉；假如未完全命中熱數(shù)據(jù)或完全命中冷數(shù)據(jù)，則會(huì)進(jìn)入自適應(yīng)選擇流程。其中元數(shù)據(jù)的關(guān)聯(lián)就是冷數(shù)據(jù)和熱數(shù)據(jù)哪些表是有關(guān)聯(lián)的以及可能產(chǎn)生的分區(qū)映射，映射關(guān)系的做法是在數(shù)據(jù)湖的表屬性中映射熱數(shù)據(jù)相關(guān)信息。

除湖倉一體架構(gòu)之外，在StarRocks訪問Iceberg的性能方面也做了很多優(yōu)化。以下是主要的優(yōu)化點(diǎn)：

Iceberg源數(shù)據(jù)是緩存在磁盤上的，當(dāng)文件比較多或?qū)挶韴?chǎng)景下，讀取源數(shù)據(jù)文件可能會(huì)成為性能的瓶頸，所以為了緩解集群訪問HDFS帶來的IO開銷，讀取時(shí)會(huì)自動(dòng)將源數(shù)據(jù)cache到Alluxio中。整個(gè)寫的流程沒有太多的變化，讀流程中會(huì)自動(dòng)判斷Alluxio有沒有cache到最新的源數(shù)據(jù)，假如沒有則會(huì)在讀取到源數(shù)據(jù)后自動(dòng)cache到Alluxio中，從而達(dá)到性能的提升。

下面是我們基于融合查詢新一代湖倉一體平臺(tái)做的性能測(cè)試，通過TPC-H數(shù)據(jù)集對(duì)比了SR內(nèi)表、使用SR和Presto查詢Iceberg的性能對(duì)比，結(jié)果顯示Presto查詢相比于StarRocks較低，SR內(nèi)表查詢性能分別是Presto查詢和SR直接查詢的4-65倍、1-25倍，通過SuperSQL融合查詢預(yù)期可以帶來3倍左右的性能提升。

04

未來展望

首先，后續(xù)會(huì)繼續(xù)完善SuperSQL的自適應(yīng)能力，向更智能的方向邁進(jìn)； 其次，會(huì)完善湖倉融合平臺(tái)能力來支持更多數(shù)據(jù)湖倉能力，盡可能達(dá)到原生Iceberg的性能和能力； 另外，會(huì)優(yōu)化計(jì)算平臺(tái)查詢數(shù)據(jù)湖的性能； 最后，會(huì)繼續(xù)優(yōu)化數(shù)據(jù)湖格式，比如增加更多索引等。

今天的分享就到這里，謝謝大家。

關(guān)鍵詞：