什么時候UDF會更快
如果您詢問PythonUDF,答案可能是永遠不會*。由于SQL函數(shù)相對簡單,而且不是為復雜的任務設計的,因此它幾乎不可能補償Python解釋器和JVM之間重復序列化、反序列化和數(shù)據移動的成本。
有誰知道這是為什么
上面已經列舉了主要的原因,可以歸結為一個簡單的事實,即星火。DataFrame
它本身就是一個JVM結構,標準的訪問方法是通過對JavaAPI的簡單調用來實現(xiàn)的。另一方面,UDF是用Python實現(xiàn)的,需要來回移動數(shù)據。
雖然PySPark通常需要JVM和Python之間的數(shù)據移動,但是對于低級別的RDDAPI,它通常不需要昂貴的serde活動。SPARK SQL增加了序列化和序列化的額外成本,以及將數(shù)據從JVM上轉移到不安全表示的成本。后者是針對所有UDF(Python、Scala和Java)的,但前者是針對非本地語言的。
與UDF不同,SparkSQL函數(shù)直接在JVM上運行,通常與催化劑和鎢都集成得很好。這意味著可以在執(zhí)行計劃中對其進行優(yōu)化,并且大多數(shù)情況下可以從cocogen和其他鎢優(yōu)化中獲益。此外,它們還可以對其“本機”表示中的數(shù)據進行操作。
因此,在某種意義上,這里的問題是PythonUDF必須將數(shù)據帶到代碼中,而SQL表達式則相反。
*根據粗略估計PySPark窗口UDF可以擊敗Scala窗口函數(shù)。