溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

spark 3.0 sql的動態分區裁剪機制的具體使用過程

發布時間:2021-07-28 09:14:28 來源:億速云 閱讀:742 作者:chen 欄目:大數據

這篇文章主要介紹“spark 3.0 sql的動態分區裁剪機制的具體使用過程”,在日常操作中,相信很多人在spark 3.0 sql的動態分區裁剪機制的具體使用過程問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”spark 3.0 sql的動態分區裁剪機制的具體使用過程”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!

本文主要講講,spark 3.0之后引入的動態分區裁剪機制,這個會大大提升應用的性能,尤其是在bi等場景下,存在大量的where條件操作。

動態分區裁剪比謂詞下推更復雜點,因為他會整合維表的過濾條件,生成filterset,然后用于事實表的過濾,從而減少join。當然,假設數據源能直接下推執行就更好了,下推到數據源處,是需要有索引和預計算類似的內容。

1.靜態數據集分區謂詞下推執行
下面sql 是為例
   
     
   
   
   SELECT * FROM Sales WHERE day_of_week = ‘Mon’
該語句執行有兩種可能:  
1) .全表掃描,然后過濾。
2) .先過濾再掃描。
spark 3.0 sql的動態分區裁剪機制的具體使用過程
假如表按照day_of_week字段分區,那sql應該是將filter下推,先過濾,然后在scan。
spark 3.0 sql的動態分區裁剪機制的具體使用過程
這就是傳統數據庫存在索引及預計算的時候所說的謂詞下推執行。
2.動態分區裁剪場景
Spark 3.0的分區裁剪的場景主要是基于謂詞下推執行filter(動態生成),然后應用于事實表和維表join的場景。
如果存在分區表和維表上的filter,則通過添加dynamic-partition-pruning filter來實現對另一張表的動態分區修剪。
有下面一個簡單的sql,完成的功能是事實表(sales)和維表(Date)的join:
   
     
   
   
   SELECT * FROM Sales JOIN Date WHERE Date.day_of_week = ‘Mon’;
假如不存在任何下推執行的優化,執行過程就應該如下圖:  
spark 3.0 sql的動態分區裁剪機制的具體使用過程
上圖就是不存在任何謂詞下推執行優化的計算過程,全量掃描事實表sales和維表date表,然后完成join,生成的表基礎上進行filter操作,然后再scan計算,顯然這樣做很浪費性能。  
假如維表支持下推執行,那么就可以先進行維表的filter操作,減少維表Date的數據量加載,然后在進行事實表sales的scan和維表date的scan,最后進行join操作。
spark 3.0 sql的動態分區裁剪機制的具體使用過程
想一想,由于where條件的filter是維表Date的,spark讀取事實表的時候也是需要使用掃描的全表數據來和維表Date實現join,這就大大增加了計算量。
假如能進一步優化,通過維表date的filter,生成一個新的事實表的salesFilterSet,應用到事實表sales,那么就可以大大減少join計算性能消耗。也即是這個樣子:
spark 3.0 sql的動態分區裁剪機制的具體使用過程
這個就叫做動態分區裁剪。下面的例子會更詳細點:
spark 3.0 sql的動態分區裁剪機制的具體使用過程
表t1和t2進行join,為了減少參加join計算的數據量,就為t1表計算(上圖右側sql)生成了一個filter數據集,然后再掃描之后過濾。當然,這個就要權衡一下,filter數據集生成的子查詢及保存的性能消耗,與對數據過濾對join的性能優化的對比了,這就要講到spark sql的優化模型了。
spark sql 是如何實現sql優化操作的呢?
一張圖可以概括:
spark 3.0 sql的動態分區裁剪機制的具體使用過程
現在sql解析的過程中完成sql語法優化,然后再根據統計代價模型來進行動態執行優化。
邏輯執行計劃的優化都是靜態的,物理計劃的選擇可以基于統計代價模型來計算動態選擇。
下圖是一個基于分區ID的join實現。維表的數據是沒有分區的,事實表的數據是分區的。假如沒有動態分區裁剪,那么完成的執行過程就如圖所示。事實表和維表都需要全表掃描,然后對維表執行filter操作,最后再進行join操作。
spark 3.0 sql的動態分區裁剪機制的具體使用過程
假如對維表的filter操作,進行一些計算然后可以生成事實表的filter set,那么就可以減少維表和事實表join的數據量了。就如前面的t1和t2的join例子一樣。  
spark 3.0 sql的動態分區裁剪機制的具體使用過程
當然,上面的例子要考慮計算和保存事實表的filter set集合的開銷是否遠小于其減少join數據量的增益,否則就得不償失了。
還有一種join大家都比較熟悉,那就是Broadcast Hash Join。
spark 3.0 sql的動態分區裁剪機制的具體使用過程
這種主要是重用廣播的結果,來實現filter功能。這個的理解要基于BroadcastExchangeExec。后面出文章詳細聊吧。
spark 3.0 sql的動態分區裁剪機制的具體使用過程
至于效果碼,可以關注浪尖微信公眾號:bigdatatip。然后輸入 :dpp  獲取完整的ppt。  

到此,關于“spark 3.0 sql的動態分區裁剪機制的具體使用過程”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

亚洲午夜精品一区二区_中文无码日韩欧免_久久香蕉精品视频_欧美主播一区二区三区美女