我有一個表,全掃描的需要~ 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:
輸入顯示的數量是可疑的小階段:
嗨@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,這樣我們可以看看正在發生什麼。
希望這有助於…幹杯。
嗨@Vladimir Ryabtsev
需要一些更多的信息
找到δ表的大小,您可以使用Apache火花SQL命令。
進口com.databricks.sql.transaction.tahoe._
val deltaLog = deltaLog。forTable(火花,“dbfs: / < path-to-delta-table >”)
= deltaLog val快照。/ /當前快照δ表快照
println (s”總文件大小(字節):$ {deltaLog.snapshot.sizeInBytes} ")