Spark中选择df.select()还是建临时表后执行spark.sql的考量因素

• 团队技术栈适配
  要是团队成员以数据分析、数仓人员为主，普遍熟悉SQL语法，优先选spark.sql()方案，学习成本低，还可以直接复用历史Hive/Spark SQL脚本，减少改写工作量。要是团队以后端/大数据开发工程师为主，熟悉Scala/Python等开发语言，优先选DataFrame API，静态语法校验（Scala场景下尤为明显）可以在编译阶段就发现字段名错误、类型不匹配等问题，避免运行到中途才报错。
• 代码可维护性与调试效率
  对于嵌套层级多、逻辑复杂的ETL任务，DataFrame API更适合：可以拆分多步编写、分步调试打印中间结果，参数传递直接用代码变量即可，不需要处理SQL字符串拼接的特殊字符转义、引号嵌套等问题。对于逻辑相对简单、或者需要对外暴露查询能力的场景，SQL方案更直观，业务逻辑可读性更强，非开发人员也能快速理解查询逻辑。
• 功能扩展需求
  如果查询逻辑需要结合Spark生态其他组件（MLlib机器学习、GraphX图计算等）、调用复杂自定义函数、处理深度嵌套的半结构化数据，DataFrame API的灵活度更高，和代码逻辑的集成度更好。如果有跨引擎兼容需求（比如同一套查询逻辑需要同时支持Hive、Trino等引擎执行），SQL方案的迁移成本更低，不需要针对不同引擎改写API代码。
• 性能表现
  常规写法下两种方案最终生成的物理执行计划完全一致，Catalyst优化器会对两种写法做相同的逻辑优化、物理优化，性能没有明显差异。只有当写法存在明显问题时才会出现性能差距：比如SQL拼接遗漏谓词下推条件、DataFrame API使用了未优化的自定义处理算子。
• 应用场景匹配
  临时交互式分析、即席查询场景优先选SQL方案，创建临时视图后直接写SQL查询即可，开发效率更高。生产级稳定ETL流水线、和业务代码（异常处理、动态参数生成等）深度结合的场景优先选DataFrame API，更便于做版本管理、单元测试、链路追踪。

内容的提问来源于stack exchange，提问作者Guilherme Melo Delmondes