spark 3.0 sql的動(dòng)態(tài)分區(qū)裁剪機(jī)制的具體使用過(guò)程

發(fā)布時(shí)間：2021-07-28 09:14:28 來(lái)源：億速云閱讀：709 作者：chen 欄目：大數(shù)據(jù)

這篇文章主要介紹“spark 3.0 sql的動(dòng)態(tài)分區(qū)裁剪機(jī)制的具體使用過(guò)程”，在日常操作中，相信很多人在spark 3.0 sql的動(dòng)態(tài)分區(qū)裁剪機(jī)制的具體使用過(guò)程問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”spark 3.0 sql的動(dòng)態(tài)分區(qū)裁剪機(jī)制的具體使用過(guò)程”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

本文主要講講，spark 3.0之后引入的動(dòng)態(tài)分區(qū)裁剪機(jī)制，這個(gè)會(huì)大大提升應(yīng)用的性能，尤其是在bi等場(chǎng)景下，存在大量的where條件操作。

動(dòng)態(tài)分區(qū)裁剪比謂詞下推更復(fù)雜點(diǎn)，因?yàn)樗麜?huì)整合維表的過(guò)濾條件，生成filterset，然后用于事實(shí)表的過(guò)濾，從而減少join。當(dāng)然，假設(shè)數(shù)據(jù)源能直接下推執(zhí)行就更好了，下推到數(shù)據(jù)源處，是需要有索引和預(yù)計(jì)算類似的內(nèi)容。

1.靜態(tài)數(shù)據(jù)集分區(qū)謂詞下推執(zhí)行

下面sql 是為例

   
     
   
   
   SELECT * FROM Sales WHERE day_of_week = ‘Mon’

該語(yǔ)句執(zhí)行有兩種可能：

1) .全表掃描，然后過(guò)濾。

2) .先過(guò)濾再掃描。

spark 3.0 sql的動(dòng)態(tài)分區(qū)裁剪機(jī)制的具體使用過(guò)程

假如表按照day_of_week字段分區(qū)，那sql應(yīng)該是將filter下推，先過(guò)濾，然后在scan。

這就是傳統(tǒng)數(shù)據(jù)庫(kù)存在索引及預(yù)計(jì)算的時(shí)候所說(shuō)的謂詞下推執(zhí)行。

2.動(dòng)態(tài)分區(qū)裁剪場(chǎng)景

Spark 3.0的分區(qū)裁剪的場(chǎng)景主要是基于謂詞下推執(zhí)行filter(動(dòng)態(tài)生成)，然后應(yīng)用于事實(shí)表和維表join的場(chǎng)景。

如果存在分區(qū)表和維表上的filter，則通過(guò)添加dynamic-partition-pruning filter來(lái)實(shí)現(xiàn)對(duì)另一張表的動(dòng)態(tài)分區(qū)修剪。

有下面一個(gè)簡(jiǎn)單的sql，完成的功能是事實(shí)表(sales)和維表(Date)的join:

   
     
   
   
   SELECT * FROM Sales JOIN Date WHERE Date.day_of_week = ‘Mon’；

假如不存在任何下推執(zhí)行的優(yōu)化，執(zhí)行過(guò)程就應(yīng)該如下圖：

上圖就是不存在任何謂詞下推執(zhí)行優(yōu)化的計(jì)算過(guò)程，全量掃描事實(shí)表sales和維表date表，然后完成join，生成的表基礎(chǔ)上進(jìn)行filter操作，然后再scan計(jì)算，顯然這樣做很浪費(fèi)性能。

假如維表支持下推執(zhí)行，那么就可以先進(jìn)行維表的filter操作，減少維表Date的數(shù)據(jù)量加載，然后在進(jìn)行事實(shí)表sales的scan和維表date的scan，最后進(jìn)行join操作。

想一想，由于where條件的filter是維表Date的，spark讀取事實(shí)表的時(shí)候也是需要使用掃描的全表數(shù)據(jù)來(lái)和維表Date實(shí)現(xiàn)join，這就大大增加了計(jì)算量。

假如能進(jìn)一步優(yōu)化，通過(guò)維表date的filter，生成一個(gè)新的事實(shí)表的salesFilterSet，應(yīng)用到事實(shí)表sales，那么就可以大大減少join計(jì)算性能消耗。也即是這個(gè)樣子：

這個(gè)就叫做動(dòng)態(tài)分區(qū)裁剪。下面的例子會(huì)更詳細(xì)點(diǎn)：

表t1和t2進(jìn)行join，為了減少參加join計(jì)算的數(shù)據(jù)量，就為t1表計(jì)算（上圖右側(cè)sql）生成了一個(gè)filter數(shù)據(jù)集，然后再掃描之后過(guò)濾。當(dāng)然，這個(gè)就要權(quán)衡一下，filter數(shù)據(jù)集生成的子查詢及保存的性能消耗，與對(duì)數(shù)據(jù)過(guò)濾對(duì)join的性能優(yōu)化的對(duì)比了，這就要講到spark sql的優(yōu)化模型了。

spark sql 是如何實(shí)現(xiàn)sql優(yōu)化操作的呢？

一張圖可以概括：

現(xiàn)在sql解析的過(guò)程中完成sql語(yǔ)法優(yōu)化，然后再根據(jù)統(tǒng)計(jì)代價(jià)模型來(lái)進(jìn)行動(dòng)態(tài)執(zhí)行優(yōu)化。

邏輯執(zhí)行計(jì)劃的優(yōu)化都是靜態(tài)的，物理計(jì)劃的選擇可以基于統(tǒng)計(jì)代價(jià)模型來(lái)計(jì)算動(dòng)態(tài)選擇。

下圖是一個(gè)基于分區(qū)ID的join實(shí)現(xiàn)。維表的數(shù)據(jù)是沒(méi)有分區(qū)的，事實(shí)表的數(shù)據(jù)是分區(qū)的。假如沒(méi)有動(dòng)態(tài)分區(qū)裁剪，那么完成的執(zhí)行過(guò)程就如圖所示。事實(shí)表和維表都需要全表掃描，然后對(duì)維表執(zhí)行filter操作，最后再進(jìn)行join操作。

假如對(duì)維表的filter操作，進(jìn)行一些計(jì)算然后可以生成事實(shí)表的filter set，那么就可以減少維表和事實(shí)表join的數(shù)據(jù)量了。就如前面的t1和t2的join例子一樣。

當(dāng)然，上面的例子要考慮計(jì)算和保存事實(shí)表的filter set集合的開(kāi)銷(xiāo)是否遠(yuǎn)小于其減少join數(shù)據(jù)量的增益，否則就得不償失了。

還有一種join大家都比較熟悉，那就是Broadcast Hash Join。

這種主要是重用廣播的結(jié)果，來(lái)實(shí)現(xiàn)filter功能。這個(gè)的理解要基于BroadcastExchangeExec。后面出文章詳細(xì)聊吧。

至于效果碼，可以關(guān)注浪尖微信公眾號(hào)：bigdatatip。然后輸入：dpp 獲取完整的ppt。

到此，關(guān)于“spark 3.0 sql的動(dòng)態(tài)分區(qū)裁剪機(jī)制的具體使用過(guò)程”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！

向AI問(wèn)一下細(xì)節(jié)

spark 3.0 sql的動(dòng)態(tài)分區(qū)裁剪機(jī)制的具體使用過(guò)程

猜你喜歡

最新資訊

相關(guān)推薦

相關(guān)標(biāo)簽