導讀 本文將介紹騰訊自研的大數據計算平臺——天穹SuperSQL，以及在應對數據湖場景中的復雜多維分析方面的實踐。

【資料圖】

全文目錄：

1.SuperSQL架構

2.自適應計算引擎

3.實時湖倉融合

4.未來展望

分享嘉賓｜程廣旭 騰訊 高級工程師

編輯整理｜楊文鑄 哈爾濱理工大學

出品社區(qū)｜DataFun

01

SuperSQL架構

首先介紹一下騰訊自研的下一代大數據計算平臺SuperSQL的技術架構。

1.SuperSQL的整體架構

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

SuperSQL提供了完整的端到端的大數據解決方案，適配公有云、私有云和內網等不同的云場景。通過下圖我們可以看到SuperSQL的整個架構主要分為四部分，這四部分互相之間不存在耦合關系，都是獨立存在的：

（1）核心引擎層

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

（2）計算層

主要根據每個SQL的特點以及使用場景選擇最佳的計算引擎，從而保證了在不同架構下的計算穩(wěn)定性，其中Remote Shuffle Service則提供了統(tǒng)一的數據Shuffle服務，實現了計算、執(zhí)行、拓撲的自適應。

Spark負責ETL、報表類的場景 presto負責交互式查詢的分析場景 Hermes是騰訊自研的用于日志檢索、用戶畫像場景的組件 StarRocks負責數據查詢的場景 PowerFL負責數據安全場景

（3）資源層

主要整合了云上和云下的資源，能夠對所有的資源進行統(tǒng)一管理，從而為計算提供統(tǒng)一的資源池，通過資源的自適應調整、租戶間資源彈性調度、集群中資源借調等手段統(tǒng)籌資源的管理，提升整個資源的使用效率。

（4）數據編排層

主要適配了系統(tǒng)的異構存儲、透明化的存儲差異、解耦計算和存儲、自主學習、數據訪問模式、自適應緩存（熱點數據和元數據），從而加速數據訪問的性能，提升集群的穩(wěn)定性。

2.SuperSQL的目標

（1）SuperSQL整體的目標

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

（2）計算融合

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

（3）計算解耦

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

3.SuperSQL技術沙盤

下圖具體展示了SuperSQL 的技術沙盤。

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

02

自適應計算引擎

第二部分介紹SuperSQL自適應計算引擎是如何進行選擇的。

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

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

SQL語法的轉化過程主要分為兩部分：SQL的兼容和SQL的轉化。

目標：SQL語法能夠在常用的計算引擎之間進行無感切換 難點：不同SQL語法差異比較大

2.計算引擎自適應：人工到智能的實踐

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

引擎選擇規(guī)則：

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

03

實時湖倉融合

這部分主要介紹騰訊新一代的實時湖倉融合平臺。

1.湖倉一體架構

（1）傳統(tǒng)實時湖倉一體架構

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

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

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

（2）實時湖倉融合架構

常見的數據湖使用場景主要是四種：實時寫入離線查詢，實時寫入實時查詢，離線寫入離線查詢，以及離線寫入實時查詢。

SuperSQL實時湖倉主要解決了實時寫入實時查詢的場景。

該方案優(yōu)點：數據寫入實時性更高，接入簡單；查詢性能更優(yōu)；

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

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

2.數據入倉

（1）實時/離線數據入倉

具體來看，實時/離線數據入倉的整體架構如下圖。

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

離線數據通過內部離線調度平臺的插件，允許用戶通過Hive、Iceberg、Hudi中的數據離線同步至數據湖中。同時對湖、倉數據進行分區(qū)映射。

（2）離線數據入倉

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

（3）實時數據入倉及降冷

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

3.自適應融合查詢

降冷后的數據和數據倉庫的數據是可以實現融合查詢的，這種融合查詢是在SuperSQL側實現的，通過自適應判斷哪些數據來自于數據倉庫、哪些數據來自于數據湖。

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

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

Iceberg源數據是緩存在磁盤上的，當文件比較多或寬表場景下，讀取源數據文件可能會成為性能的瓶頸，所以為了緩解集群訪問HDFS帶來的IO開銷，讀取時會自動將源數據cache到Alluxio中。整個寫的流程沒有太多的變化，讀流程中會自動判斷Alluxio有沒有cache到最新的源數據，假如沒有則會在讀取到源數據后自動cache到Alluxio中，從而達到性能的提升。

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

04

未來展望

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

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

關鍵詞：