為什麼執行太快?

[虛擬現實]

我有一個表,全掃描的需要~ 20分鍾在我的集群。該表有“時間”和“天”日期時間戳列列。後者計算(手動)“時間”截斷和用於分區。

我查詢的表使用謂詞基於“時間”(包括“天”不是),但它太快(~ 10 s)工作。我希望不使用分區跳過。解釋還顯示“PartitionFilters:[]”,所以我假設分區不能占性能增益。事實上,添加或刪除“天”謂詞似乎並沒有任何性能的影響。

如何解釋查詢返回的結果這麼快(~ 10 s) ?還有什麼其他的機製可以提供這樣的性能提升?

表:

myschema創建表。mytable(時間的時間戳、TagName字符串值翻倍,質量INT,天日期,isLate布爾)用δ分區(天,isLate)

查詢:

選擇date_trunc(“一分鍾”,時間),從myschema TagName, avg(值)的價值。mytable current_timestamp之間在時間()——間隔3天,current_timestamp group by date_trunc()(“一分鍾”,時間),TagName

更新1:

輸入顯示的數量是可疑的小階段:

[Vidula_Khanna]

嗨@Vladimir Ryabtsev

很高興認識你,謝謝你的問題!

看看你的同行在社區中有一個回答你的問題。否則bricksters能早日回到你身邊。

謝謝

[UmaMahesh1]

嗨@Vladimir Ryabtsev,

因為你創建一個增量表,我認為你所看到的性能改進,因為動態分區修剪,

根據文檔,“分區修剪可以發生在查詢編譯時查詢包括一個顯式的文字謂詞的分區鍵列也可以在運行時通過舉行動態分區修剪”。如果它幫助也閱讀這些文件。//m.eheci.com/blog/2020/04/30/faster-sql-queries-on-delta-lake-with-dynamic-file-prunin..。

如果你想測試一下,關閉使用spark.databricks.optimizer DFP。dynamicFilePruning通過設置為false,檢查性能仍然是相同的。

如果不是,那就太好了如果你發布DAG,這樣我們可以看看正在發生什麼。

希望這有助於…幹杯。

[虛擬現實]

@Uma Maheswara Rao Desula您的文檔使用DFP州以下標準:

• 內部表(探針)加入了三角洲湖格式
• 內或LEFT-SEMI連接類型
• 連接策略是廣播散列連接
• 文件內部表的數量大於spark.databricks.optimizer.deltaTableFilesThreshold的值

在我的例子中,查詢甚至沒有任何連接。

無論如何我試著關掉你給它的參數沒有產生任何影響。

[UmaMahesh1]

嗨@Vladimir Ryabtsev

需要一些更多的信息

1. 你能得到δ的總大小和數量的記錄表格嗎?
2. “全掃描的~ 20分鍾在我的集群”——你使用相同的集群進行查詢,如果是的,全掃描的截圖。
3. DAG,你點擊後火花UI工作細節,你會發現強調了id相關的SQL查詢。點擊這個id,擴大在可視化的查詢計劃的所有細節,請粘貼在這裏。

找到δ表的大小,您可以使用Apache火花SQL命令。

進口com.databricks.sql.transaction.tahoe._

val deltaLog = deltaLog。forTable(火花,“dbfs: / < path-to-delta-table >”)

= deltaLog val快照。/ /當前快照δ表快照

println (s”總文件大小(字節):$ {deltaLog.snapshot.sizeInBytes} ")