目录

先入为主的反例

性能调优的本质

性能调优实操案例

性能调优相关文章 

---

先入为主的反例

在典型的 ETL 场景中，我们经常需要对数据进行各式各样的转换，有的时候，因为业务需求太复杂，我们往往还需要自定义 UDF（User Defined Functions）来实现特定的转换逻辑。 但是，无论是 Databricks 的官方博客，还是网上浩如烟海的 Spark 技术文章，都警告我们尽 量不要自定义 UDF 来实现业务逻辑，要尽可能地使用 Spark 内置的 SQL functions。

在日常的工作中，我发现这些警告被反复地用于 Code review 中，Code reviewer 在审查代码的时候，一旦遇到自定义的 UDF，就提示开发的同学用 SQL functions 去重写业务逻辑， 这几乎成了一种条件反射。 甚至，开发的同学也觉得非常有道理。于是，他们花费大量时间用 SQL functions 重构业务代码。但遗憾的是，这么做之后 ETL 作业端到端的执行性能并没有什么显著的提升。这种情况就是所谓的投入时间与产出不成正比的窘境：调优的时间没少花，却没啥效果。 之所以会出现这种情况，我觉得主要原因在于 Code reviewer 对于性能调优的理解还停留在 照本宣科的层次，没有形成系统化的方法论。要建立系统化的方法论，我们就必须去探究性能 调优的本质到底是什么。否则，开发者就像