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