SuperSQL：跨數據源、跨DC、跨執行引擎的高性能大數據SQL中間件

2019 年 10 月 6 日
筆記

導語：SuperSQL是騰訊數據平台部自研的跨數據源、跨數據中心、跨執行引擎的統一大數據SQL分析平台/中間件，支援對接適配多類外部開源SQL執行引擎，如Spark、Hive等。

背景

SuperSQL是一款自研的跨數據源、跨數據中心、跨執行引擎的高性能大數據SQL中間件，滿足對位於不同數據中心的不同類型數據源的數據聯合分析/即時查詢的需求。SuperSQL的目標是成為公司內部統一的SQL分析中間件，實現以下三點的價值：

解決業務數據孤島，最大化數據的使用價值
執行引擎最優選擇，提升業務使用數據效率
優化集群資源使用，解決業務資源使用瓶頸

SuperSQL基於Apache社區Calcite[1]動態數據管理框架構建，並圍繞上述目標對Calcite Parser/Planner/MetaStore等組件做了大量的訂製、擴展和優化。SuperSql的主要特性包括：

跨數據源查詢：支援通過JDBC對接MySQL、PostgreSQL、TBase、Hive （ThritServer）、SparkSQL、H2、Oracle、Phoenix (HBase)、ElasticSearch等數據源，且支援對接同一類數據源的不同版本（如Hive 2.3.3與Hive 3.1.1）；
SQL運算元下推：支援常用SQL操作下推數據源執行，具體包括Project、Filter、Aggregate、Join、Sort、Union、Intersect、Except、Limit、Offset、UDF和Nested Query；
SQL引擎CBO（基於代價優化）：基於Volcano模型，選擇最優的查詢執行物理計劃；
跨數據中心CBO：將集群負載、網路頻寬等因子納入代價估算，選擇最優的跨數據中心執行計劃，拆分子查詢到不同DC的多個計算引擎執行；
最優計算引擎選擇：支援對接多種不同類型的分散式計算引擎 (如Spark, Hive, Flink, Presto)，支援為每個SQL智慧挑選最優的執行引擎；
標準SQL語法：支援SQL 2003、Oracle12和MySQL5語法。

SuperSQL的主要應用場景包括：

OLAP數據分析 – 通過SuperSQL對數據分析/挖掘、生成報表等
數據即時查詢 – 通過SuperSQL對數據取樣、小數據互動式查詢等
數據聯邦查詢 – 通過SuperSQL聯合分析不同數據源（例如Hive、HBase）中的數據
割裂的數據版本 – 通過SuperSQL查詢不同集群中部署的不同數據源版本中的數據
跨數據中心查詢 – 通過SuperSQL查詢多個數據中心中的數據

性能優勢：TPC-DS基準評測

目前我們評估了在1GB和100GB的TPC-DS性能測試基準數據集之上，SuperSQL V0.1版本與社區SparkSQL JDBC基準線相比，在Hive和PG數據源上執行99條TPC-DS SQL查詢的響應時間。

測試環境

軟硬體參數

SuperSQL V0.1版本當前作為組件之一隨TBDS套件對外發布。本測試使用的系統版本是TLinux 2.2 64bit Version 2.2 20190320；使用的Hive和PG數據源、Spark計算引擎等SuperSQL系統模組均為套件中自帶的其它組件，參數具體如下所示。

測試結果分析

總體情況

上表給出了性能測試的詳細結果，其中欄位的含義說明如下：

重複次數：代表了TPC-DS 99條SQL每條被執行的次數；如果大於1，結果取多次測量的平均值；
對比組數：針對SuperSQL和Spark JDBC進行對比，只要有一方能成功執行SQL得到結果，即產生對比；
有效對比組數：和對比組數的區別在於，只有SuperSQL和Spark JDBC雙方均能拿到測試結果，才產生對比；
更快方式：對比SuperSQL和Spark JDBC的99條SQL的平均時間，耗時短的更快；
性能提升：Spark JDBC的平均執行時間除以SuperSQL的平均執行時間，表示SuperSQL相比Spark基準線查詢響應時間降低的倍數；
成功組數：能夠拿到測試結果的query數目；
總時間：有效對比組數的總時間，只有雙方都拿到測試結果，才會將這個時間計入；
平均時間：有效對比組數的平均時間。

1GB查詢時間分析

耗時分布對比

上圖展示了在1GB數據規模下，SuperSQL和Spark JDBC針對所有99條TPC-DS SQL（部分SQL帶分號拆分為兩條串列執行，實際為103條）執行時間的對比情況。通過參數優化等方式解決測試中發現的少量SuperSQL查詢執行緩慢問題，目前100%TPC-DS測試用例SQL在SuperSql的執行時間可實現遠低於或持平Spark JDBC。測試中，我們認為相差10%以內的響應時間結果數據為等價。

圖中橫軸代表了SuperSQL某條SQL的查詢時間除以對應Spark JDBC該SQL的查詢時間，然後按照<50%和50%~100%條目分組，分別代表SuperSQL時間是Spark時間的0.5倍以內和1倍以內。縱軸代表了兩個條目每個各自包含的SQL數目。例如，從圖中我們可以看到Hive作為數據源時，有45條（佔比43.69%）SQL 的SuperSQL查詢時間在Spark JDBC的50%以下，PG數據源時這個數目為84條（佔比81.55%），Hive+PG時為40條（佔比38.83%）。

由於1GB的數據規模實在太小，每條query的執行時間都很短，將時間比值作為性能評價依據存在一定的局限性，因此在100GB的結果分析中中，這種現象將會被更加詳細的分析。

平均耗時對比

上圖顯示了SuperSQL和Spark JDBC在不同數據源下的平均執行時間對比情況。Hive作為數據源時，SuperSQL執行一條TPC-DS SQL的平均時間為11.66s，而Spark JDBC為21.68s，性能上SuperSQL較Spark JDBC提升了約86%；PG作為數據源時，性能提升約60%；Hive + PG跨源時，SuperSQL性能提升約83%。

整體而言，在測試數據集規模比較小1GB時，SuperSQL整體較Spark JDBC可匹配或快不到一倍，但是由於整體平均查詢時間僅在十幾秒左右，計算耗時的比重較小，SuperSQL的性能提升優勢並不是很明顯，當數據規模增大時這一情況將會完全改觀。

100GB查詢時間分析

耗時分布對比

上圖展示了在103條TPC-DS查詢中，SuperSQL和Spark JDBC查詢時間的對比情況。將每條查詢的SuperSQL執行時間除以Spark JDBC執行時間，按照20%以下、20%~50%和50%~100% 3個區間段進行區分。橫軸代表了不同數據源時上述各分組，縱軸代表的是各分組的數目。從圖中我們可以觀察到，在Hive單源下，有101條（98.1%）SQL的SuperSQL查詢時間只佔到Spark JDBC查詢時間的20%以下；在100GB Hive+PG的混合源下，有88條（85.4%）SQL的SuperSQL的查詢時間只佔到Spark JDBC查詢時間的20%以下。

需要說明的是，在100GB Hive + PG的組別中，Spark JDBC有46組查詢過程中拋出異常，沒有返回結果，但是SuperSQL則不會出現類似的情況。針對這種情況，上圖的表述為：Spark JDBC的異常組別（無結果）作為時間比值<20%處理，實際上這種處理合乎常理，因為Spark JDBC的異常查詢組別顯得艱難無比，往往需要40min以上才給出報錯，這種反應完全可以當作Spark JDBC的查詢時間在40min以上，也有可能更長，而SuperSQL往往在400s以內就能夠返回結果，所以上述處理是合理的。這也反映了SuperSQL在相同參數配置的情況下，比Spark JDBC應對複雜query的處理能力整體更加優異，對原SQL的優化和處理是卓有成效的。

平均耗時對比

上圖給出了SuperSQL以及Spark JDBC所有查詢平均時間的對比。可以看到，在Hive數據源下，SuperSQL執行TPC-DS SQL的平均執行時間僅為1.15min，而Spark JDBC則需要31.27min，SuperSQL較Spark JDBC性能提升了約26倍。在Hive + PG跨源的情況下，SuperSQL執行TPC-DS SQL的平均時間為4.63min，而Spark JDBC需要25.7min，性能提升約4.5倍。相比於1GB數據規模，100GB數據規模時SuperSQL的查詢優勢更加明顯，這也與事實相符：在數據規模更加大時，計算耗時的比重更加大，總體耗時更能反映出查詢過程的性能優劣。

有一點需要注意的是，從結果上看居然發現Spark JDBC跨源時的平均查詢時間反而比單源更快，事實上，正如上一小節所述，Hive + PG作為跨源數據源時，Spark JDBC有將近一半（46條）query 查詢失敗，而在計算平均時間時這些組別是無法進行統計的，所以在能夠執行的query範圍內，Spark JDBC的跨源平均查詢時間才比單源快，因此這個只是偶發現象，對整體而言是不準確的結論。正是因為Spark JDBC存在諸多異常組別（無結果），平均時間的對比並不能完全反應SuperSQL的性能優勢，若是Spark JDBC有更多的組別不會因為資源限制拿不到結果，預計SuperSQL在數值上的性能提升將會更加可觀。

測試結果總結

SuperSQL 性能測試結果匯總如下表所示，SuperSql在海量數據下相比社區基準線（Spark JDBC）性能優勢明顯：

TPC-DS 100GB基準測試集，98%的Hive和86%的Hive + PG查詢，SuperSQL執行時間不到Spark JDBC時間的20%；
TPC-DS 1GB基準測試集, 44%的Hive、82%的PG和39%的Hive + PG查詢，SuperSQL執行時間不到Spark JDBC時間的50%。

SuperSQL作為公司自研的跨DC多數據源的數據分析平台，不管是單源還跨源的情況下都比開源Spark JDBC有著極為突出的性能優勢，且在應對複雜查詢時對資源的要求遠比Spark要低，具有更好的魯棒性。SuperSQL性能測試後續將持續進行並獲取新的結果，同時在後續版本中針對性能測試發現的問題持續優化，進一步提升SuperSQL的可用性與穩定性。

未來規劃

現在的SuperSQL即將融合現網落地，但仍有很多特性需要完善和改進，之後的主要方向包括：

兼容存量業務和數據：兼容各個BG存量的業務和數據，這包括不同的數據版本、不同的業務類型等；
高效統計資訊採集：統計資訊（CBO Stats）是代價估算的基礎，高效的Stats採集是SQL引擎必不可少的一部分，包括支援基於並發取樣與增量更新的採集機制、兼容對接第三方Stats介面或倉庫，基於歷史查詢負載的智慧自動採集，等等；
基於多代價因子的優化：擴展優化Calcite的VolcanoPlanner CBO模型，支援包括：規則集切分優化、單DC CBO網路代價與位元組數估算擴展、多計算引擎的跨DC分散式查詢執行、下推並發子查詢切分，等等；
最優執行引擎的智慧選擇：不同的SQL可能適合於不同類型的計算引擎（Hive，Spark，Flink，Presto等）來執行，目前路由基於簡單的規則和啟發性代價，未來要開發一套智慧規則，根據每個SQL的特徵選擇其最適合的引擎來執行。

參考

[1] Calcite: https://calcite.apache.org/