火花函数对UDF性能的影响？

Question

火花函数对UDF性能的影响？SPARK现在提供了预定义的函数，可以在数据仓库中使用，而且看起来它们是高度优化的。我最初的问题是哪个更快，但我自己做了一些测试，发现火花函数至少在一个例子中快了10倍。有谁知道为什么会这样，以及什么时候UDF会更快(仅在存在相同火花函数的情况下)？下面是我的测试代码(运行在Databricks社区ed上)：# UDF vs Spark functionfrom faker import Factoryfrom pyspark.sql.functions import lit, concat fake = Factory.create()fake.seed(4321)# Each entry consists of last_name, first_name, ssn, job, and age (at least 1)from pyspark.sql import Rowdef fake_entry():   name = fake.name().split()   return (name[1], name[0], fake.ssn(), fake.job(), abs(2016 - fake.date_time().year) + 1)# Create a helper function to call a function repeatedlydef repeat(times, func, *args, **kwargs):     for _ in xrange(times):         yield func(*args, **kwargs)data = list(repeat(500000, fake_entry))print len(data)data[0]dataDF = sqlContext.createDataFrame(data, ('last_name', 'first_name', 'ssn', 'occupation', 'age'))dataDF.cache()UDF功能：concat_s = udf(lambda s: s+ 's')udfData = dataDF.select(concat_s(dataDF.first_name).alias('name'))udfData.count()火花功能：spfData = dataDF.select(concat(dataDF.first_name, lit('s')).alias('name'))spfData.count()运行两次，UDF通常需要1.1-1.4秒，而火花concat函数总是在0.15秒以下。

Answer 1

什么时候UDF会更快

如果您询问PythonUDF，答案可能是永远不会*。由于SQL函数相对简单，而且不是为复杂的任务设计的，因此它几乎不可能补偿Python解释器和JVM之间重复序列化、反序列化和数据移动的成本。

有谁知道这是为什么

上面已经列举了主要的原因，可以归结为一个简单的事实，即星火。DataFrame它本身就是一个JVM结构，标准的访问方法是通过对JavaAPI的简单调用来实现的。另一方面，UDF是用Python实现的，需要来回移动数据。

虽然PySPark通常需要JVM和Python之间的数据移动，但是对于低级别的RDDAPI，它通常不需要昂贵的serde活动。SPARK SQL增加了序列化和序列化的额外成本，以及将数据从JVM上转移到不安全表示的成本。后者是针对所有UDF(Python、Scala和Java)的，但前者是针对非本地语言的。

与UDF不同，SparkSQL函数直接在JVM上运行，通常与催化剂和钨都集成得很好。这意味着可以在执行计划中对其进行优化，并且大多数情况下可以从cocogen和其他钨优化中获益。此外，它们还可以对其“本机”表示中的数据进行操作。

因此，在某种意义上，这里的问题是PythonUDF必须将数据带到代码中，而SQL表达式则相反。

---

*根据粗略估计PySPark窗口UDF可以击败Scala窗口函数。