導(dǎo)語：SuperSQL是騰訊數(shù)據(jù)平臺部自研的跨數(shù)據(jù)源、跨數(shù)據(jù)中心、跨執(zhí)行引擎的統(tǒng)一大數(shù)據(jù)SQL分析平臺/中間件，支持對接適配多類外部開源SQL執(zhí)行引擎，如Spark、Hive等。

背景

SuperSQL是一款自研的跨數(shù)據(jù)源、跨數(shù)據(jù)中心、跨執(zhí)行引擎的高性能大數(shù)據(jù)SQL中間件，滿足對位于不同數(shù)據(jù)中心的不同類型數(shù)據(jù)源的數(shù)據(jù)聯(lián)合分析/即時查詢的需求。SuperSQL的目標(biāo)是成為公司內(nèi)部統(tǒng)一的SQL分析中間件，實現(xiàn)以下三點的價值：

• 解決業(yè)務(wù)數(shù)據(jù)孤島，最大化數(shù)據(jù)的使用價值
• 執(zhí)行引擎最優(yōu)選擇，提升業(yè)務(wù)使用數(shù)據(jù)效率
• 優(yōu)化集群資源使用，解決業(yè)務(wù)資源使用瓶頸

SuperSQL基于Apache社區(qū)Calcite[1]動態(tài)數(shù)據(jù)管理框架構(gòu)建，并圍繞上述目標(biāo)對Calcite Parser/Planner/MetaStore等組件做了大量的定制、擴展和優(yōu)化。SuperSql的主要特性包括：

• 跨數(shù)據(jù)源查詢：支持通過JDBC對接MySQL、PostgreSQL、TBase、Hive （ThriftServer）、SparkSQL、H2、Oracle、Phoenix (HBase)、ElasticSearch等數(shù)據(jù)源，且支持對接同一類數(shù)據(jù)源的不同版本（如Hive 2.3.3與Hive 3.1.1）；
• SQL算子下推：支持常用SQL操作下推數(shù)據(jù)源執(zhí)行，具體包括Project、Filter、Aggregate、Join、Sort、Union、Intersect、Except、Limit、Offset、UDF和Nested Query；
• SQL引擎CBO（基于代價優(yōu)化）：基于Volcano模型，選擇最優(yōu)的查詢執(zhí)行物理計劃；
• 跨數(shù)據(jù)中心CBO：將集群負載、網(wǎng)絡(luò)帶寬等因子納入代價估算，選擇最優(yōu)的跨數(shù)據(jù)中心執(zhí)行計劃，拆分子查詢到不同DC的多個計算引擎執(zhí)行；
• 最優(yōu)計算引擎選擇：支持對接多種不同類型的分布式計算引擎 (如Spark, Hive, Flink, Presto)，支持為每個SQL智能挑選最優(yōu)的執(zhí)行引擎；
• 標(biāo)準(zhǔn)SQL語法：支持SQL 2003、Oracle12和MySQL5語法。

SuperSQL的主要應(yīng)用場景包括：

• OLAP數(shù)據(jù)分析?- 通過SuperSQL對數(shù)據(jù)分析/挖掘、生成報表等
• 數(shù)據(jù)即時查詢?- 通過SuperSQL對數(shù)據(jù)采樣、小數(shù)據(jù)交互式查詢等
• 數(shù)據(jù)聯(lián)邦查詢?- 通過SuperSQL聯(lián)合分析不同數(shù)據(jù)源（例如Hive、HBase）中的數(shù)據(jù)
• 割裂的數(shù)據(jù)版本?- 通過SuperSQL查詢不同集群中部署的不同數(shù)據(jù)源版本中的數(shù)據(jù)
• 跨數(shù)據(jù)中心查詢?-?通過SuperSQL查詢多個數(shù)據(jù)中心中的數(shù)據(jù)

性能優(yōu)勢：TPC-DS基準(zhǔn)評測

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

測試環(huán)境

軟硬件參數(shù)

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

測試結(jié)果分析

總體情況

上表給出了性能測試的詳細結(jié)果，其中字段的含義說明如下：

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

1GB查詢時間分析

耗時分布對比

上圖展示了在1GB數(shù)據(jù)規(guī)模下，SuperSQL和Spark JDBC針對所有99條TPC-DS SQL（部分SQL帶分號拆分為兩條串行執(zhí)行，實際為103條）執(zhí)行時間的對比情況。通過參數(shù)優(yōu)化等方式解決測試中發(fā)現(xiàn)的少量SuperSQL查詢執(zhí)行緩慢問題，目前100%TPC-DS測試用例SQL在SuperSql的執(zhí)行時間可實現(xiàn)遠低于或持平Spark JDBC。測試中，我們認為相差10%以內(nèi)的響應(yīng)時間結(jié)果數(shù)據(jù)為等價。

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

由于1GB的數(shù)據(jù)規(guī)模實在太小，每條query的執(zhí)行時間都很短，將時間比值作為性能評價依據(jù)存在一定的局限性，因此在100GB的結(jié)果分析中中，這種現(xiàn)象將會被更加詳細的分析。

平均耗時對比

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

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

100GB查詢時間分析

耗時分布對比

上圖展示了在103條TPC-DS查詢中，SuperSQL和Spark JDBC查詢時間的對比情況。將每條查詢的SuperSQL執(zhí)行時間除以Spark JDBC執(zhí)行時間，按照20%以下、20%~50%和50%~100% 3個區(qū)間段進行區(qū)分。橫軸代表了不同數(shù)據(jù)源時上述各分組，縱軸代表的是各分組的數(shù)目。從圖中我們可以觀察到，在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組查詢過程中拋出異常，沒有返回結(jié)果，但是SuperSQL則不會出現(xiàn)類似的情況。針對這種情況，上圖的表述為：Spark JDBC的異常組別（無結(jié)果）作為時間比值<20%處理，實際上這種處理合乎常理，因為Spark JDBC的異常查詢組別顯得艱難無比，往往需要40min以上才給出報錯，這種反應(yīng)完全可以當(dāng)作Spark JDBC的查詢時間在40min以上，也有可能更長，而SuperSQL往往在400s以內(nèi)就能夠返回結(jié)果，所以上述處理是合理的。這也反映了SuperSQL在相同參數(shù)配置的情況下，比Spark JDBC應(yīng)對復(fù)雜query的處理能力整體更加優(yōu)異，對原SQL的優(yōu)化和處理是卓有成效的。

平均耗時對比

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

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

測試結(jié)果總結(jié)

SuperSQL 性能測試結(jié)果匯總?cè)缦卤硭?#xff0c;SuperSql在海量數(shù)據(jù)下相比社區(qū)基線（Spark JDBC）性能優(yōu)勢明顯：

TPC-DS 100GB基準(zhǔn)測試集，98%的Hive和86%的Hive + PG查詢，SuperSQL執(zhí)行時間不到Spark JDBC時間的20%；

TPC-DS 1GB基準(zhǔn)測試集, 44%的Hive、82%的PG和39%的Hive + PG查詢，SuperSQL執(zhí)行時間不到Spark JDBC時間的50%。

SuperSQL作為公司自研的跨DC多數(shù)據(jù)源的數(shù)據(jù)分析平臺，不管是單源還跨源的情況下都比開源Spark JDBC有著極為突出的性能優(yōu)勢，且在應(yīng)對復(fù)雜查詢時對資源的要求遠比Spark要低，具有更好的魯棒性。SuperSQL性能測試后續(xù)將持續(xù)進行并獲取新的結(jié)果，同時在后續(xù)版本中針對性能測試發(fā)現(xiàn)的問題持續(xù)優(yōu)化，進一步提升SuperSQL的可用性與穩(wěn)定性。

未來規(guī)劃

現(xiàn)在的SuperSQL即將融合現(xiàn)網(wǎng)落地，但仍有很多特性需要完善和改進，之后的主要方向包括：

• 兼容存量業(yè)務(wù)和數(shù)據(jù)：兼容各個BG存量的業(yè)務(wù)和數(shù)據(jù)，這包括不同的數(shù)據(jù)版本、不同的業(yè)務(wù)類型等；
• 高效統(tǒng)計信息采集：統(tǒng)計信息（CBO Stats）是代價估算的基礎(chǔ) ，高效的Stats采集是SQL引擎必不可少的一部分，包括支持基于并發(fā)采樣與增量更新的采集機制、兼容對接第三方Stats接口或倉庫，基于歷史查詢負載的智能自動采集，等等；
• 基于多代價因子的優(yōu)化：擴展優(yōu)化Calcite的VolcanoPlanner CBO模型，支持包括：規(guī)則集切分優(yōu)化、單DC CBO網(wǎng)絡(luò)代價與字節(jié)數(shù)估算擴展、多計算引擎的跨DC分布式查詢執(zhí)行、下推并發(fā)子查詢切分，等等；
• 最優(yōu)執(zhí)行引擎的智能選擇：不同的SQL可能適合于不同類型的計算引擎（Hive，Spark，Flink，Presto等）來執(zhí)行，目前路由基于簡單的規(guī)則和啟發(fā)性代價，未來要開發(fā)一套智能規(guī)則，根據(jù)每個SQL的特征選擇其最適合的引擎來執(zhí)行。

參考

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

總結(jié)

以上是生活随笔為你收集整理的SuperSQL：跨数据源、跨DC、跨执行引擎的高性能大数据SQL中间件的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。