這篇文章主要介紹“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í)吧！
成都創(chuàng)新互聯(lián)是一家專注網(wǎng)站建設(shè)、網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃、重慶小程序開(kāi)發(fā)、電子商務(wù)建設(shè)、網(wǎng)絡(luò)推廣、移動(dòng)互聯(lián)開(kāi)發(fā)、研究、服務(wù)為一體的技術(shù)型公司。公司成立十多年以來(lái)，已經(jīng)為1000多家成都葡萄架各業(yè)的企業(yè)公司提供互聯(lián)網(wǎng)服務(wù)?，F(xiàn)在，服務(wù)的1000多家客戶與我們一路同行，見(jiàn)證我們的成長(zhǎng)；未來(lái)，我們一起分享成功的喜悅。
本文主要講講，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ì)算類(lèi)似的內(nèi)容。
1.靜態(tài)數(shù)據(jù)集分區(qū)謂詞下推執(zhí)行
SELECT * FROM Sales WHERE day_of_week = ‘Mon’
假如表按照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)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！
分享名稱：spark3.0sql的動(dòng)態(tài)分區(qū)裁剪機(jī)制的具體使用過(guò)程
分享路徑：
http://weahome.cn/article/jccjdd.html
重慶分公司
重慶分公司
