一、SuperSQL架構

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

1、SuperSQL的整體架構

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

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

（1）核心引擎層

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

（2）計算層

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

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

（3）資源層

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

（4）數據編排層

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

2、SuperSQL的目標

（1）SuperSQL整體的目標

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

（2）計算融合

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

（3）計算解耦

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

3、SuperSQL技術沙盤

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

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

二、自適應計算引擎

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

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

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

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

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

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

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

引擎選擇規則：

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

三、實時湖倉融合

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

1、湖倉一體架構

（1）傳統實時湖倉一體架構

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

該方案優點：增量讀取，實時性好；相比MQ更穩定；

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

（2）實時湖倉融合架構

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

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

該方案優點：數據寫入實時性更高，接入簡單；查詢性能更優。

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

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

2、數據入倉

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

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

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

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

（2）離線數據入倉

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

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

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

3、自適應融合查詢

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

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

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

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倍左右的性能提升。

四、未來展望

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