Spark UDF 为什么常比内置函数慢？
面试怎么回答
Spark 内置函数属于 Catalyst 可理解的表达式，能参与常量折叠、裁剪、下推和代码生成；UDF 往往是黑盒，会限制这些优化。JVM UDF 主要有表达式优化和调用边界，Python UDF 还可能增加跨进程序列化，Pandas UDF 虽能向量化也需验证。我会优先内置函数和 SQL 表达式，必须使用 UDF 时再看执行计划和基准测试。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
把一段字符串处理封装成 UDF 后，SQL 看起来更干净，任务却慢了一倍。
问题通常不在函数多写了几行，而在优化器看不懂这段黑盒逻辑。
内置表达式更容易被 Catalyst 理解和生成高效代码，UDF 则可能形成优化、代码生成或语言运行时边界。
内置函数为什么更容易优化
Spark SQL 的内置函数属于 Catalyst 表达式体系，优化器知道输入输出类型、确定性和计算语义，因此更容易做常量折叠、表达式简化、列裁剪和 Whole-Stage Code Generation。多个内置表达式还能融合进生成代码，减少对象创建和调用边界。
普通 UDF 往往像一个黑盒
自定义函数只告诉 Spark 输入和输出，优化器通常无法理解内部逻辑，也就难以把条件下推或重写成更优表达式。JVM UDF 仍在 JVM 中执行，但可能失去部分表达式级优化；Python UDF 还会增加 JVM 与 Python 进程之间的数据转换和通信。
不同 UDF 不能一概而论
Pandas UDF 可以利用 Arrow 和向量化批处理，适合某些 Python 数值计算，但并不自动快于内置函数。新版本 Spark 还支持 SQL UDF 等更接近表达式的形式。具体性能取决于函数类型、数据类型、批大小和执行计划，不能只用语言标签判断。
优化顺序应该怎么排
先查是否已有内置函数或高阶函数；其次尝试用 SQL 表达式组合；确实需要复用时考虑 SQL UDF 或 JVM 实现；依赖 Python 库时再评估 Pandas UDF。无论哪种方式，都要检查物理计划、序列化边界和实际吞吐。
一个典型场景
清洗 JSON 数组时，用 Python UDF 逐行解析并抽取字段，既跨语言传输，又让 Spark 无法只读取需要的字段。改用 from_json 和高阶数组函数后，Catalyst 能看到 Schema 和字段引用，列裁剪与代码生成重新生效，逻辑也更容易维护。
参考资料
- Apache Spark Built-in Functions：https://spark.apache.org/docs/latest/sql-ref-functions-builtin.html