前言

寫文不易，歡迎大家一起交流，喜歡文章記得關注我點個贊喲，感謝支持！（文末還有福利與彩蛋哦！）

導語： 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版本與

測試環境

軟硬件參數

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）性能優勢明顯 ：

1. TPC-DS 100GB基準測試集， 98% 的Hive和 86% 的Hive + PG查詢，SuperSQL執行時間不到Spark JDBC時間的 20% ；
2. 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的特徵選擇其最適合的引擎來執行。

最後

為感謝各位粉絲的支持，幫助各位喜歡java的朋友，我整理了將近5個G大小的學習資料哦，資料包含了架構學習、面試集錦、硬核知識點解析，視頻教程等。

轉發+關注+私信發送《架構資料》獲得領取方式！

更多筆記分享

賞色

閱讀更多 程序媛拾玖 的文章

關鍵字: Postg Presto 數據源