SQL 应该是数据工程管道的默认选择

SQL的优点
更多人将能够理解您的代码
阅读代码的次数多于编写代码的次数。通过使用 SQL，更多人可以阅读您的代码，包括 BI 开发人员、业务分析师、数据工程师和数据科学家。

数据工程管道有多年坚持的习惯，而 SQL 经受住了时间的考验。它是最有可能在 10 年甚至 20 年后仍能被理解的语言。

SQL 也是声明性的——这意味着作者描述了他们想要什么结果，而不是如何计算它们，这意味着它可以说比其他一些命令式数据处理语言更接近于自我记录。

面向未来，具有自动速度改进和“自动缩放”
尽管自 1970 年代以来一直存在，但基于 SQL 的工具在过去十年中一直是数据工具创新最活跃的领域之一。与十年前相比，用 SQL 编写的数据管道能够更快地运行，处理更大的数据，而底层 SQL 代码几乎没有变化。

除了对更传统的 SQL 引擎的不断改进之外，我们还看到了Spark和Presto等分布式工具的出现，它们使 SQL 能够在巨大的数据集上运行。最近，DuckDB在单台机器上实现了极快的并行分析查询——与一些最快的替代方案（如data.table和polars ）竞争，并且能够直接在 csv 和parquet 文件上运行。如果您正在使用特定风格的 SQL 的任何非标准功能，SQLGlot允许自动翻译。

总的来说，SQL 可能是编写数据管道的最有前途的工具——它的存在时间比预期的要长。虽然有很多竞争对手，但 SQL 最有可能在 20 年后仍在使用。

维护更简单，依赖管理更少
依赖管理给数据管道增加了显着的维护负担，意味着维护人员需要额外的技能。虽然使用 SQL 并不能消除问题，但它大大简化了问题，因为 SQL 语法更改的频率要低得多，并且运行时需要很少的依赖项。

例如，五年前用 R 或 Python 编写的管道可能需要几天甚至几周的工作才能更新。设置环境以运行代码可能需要花费大量精力。用 SQL 编写的相同管道需要的更改要少得多才能更新，并且寻求简单理解代码的读者可以轻松地执行 SQL，而无需设置新的开发环境。

SQL 也可以从几乎任何编程语言执行，从而更容易将管道迁移到不同的工具，或将逻辑嵌入到其他应用程序中。

与良好实践软件工程的兼容性
许多数据工程师都熟悉发现难以理解的数千行 SQL 脚本的痛苦，该脚本是十年前编写的，但却是组织数据管道的关键部分。或者对运行在大量数据上的 Spark SQL 管道进行微小更改的挑战。总的来说，从历史上看，编写符合良好工程实践的 SQL 一直是一项挑战 - 例如清晰、简洁且经过测试的代码被拆分成易于理解的组件。

现在，使用三个组件可以更轻松地克服其中一些挑战：

• DuckDB，一种针对分析查询进行优化的零依赖 SQL 引擎，可用于运行单元测试，并且更普遍地使快速迭代 SQL 代码更加符合人体工学
• CTE（公用表表达式）- 一种将大型查询拆分为多个语义上有意义的部分的方法，这些部分可以单独测试。这些测试可以构成您的 CI 管道的一部分
• SQLGlot，一个 SQL 转换引擎，它允许您更轻松地在 DuckDB 中测试您的代码，即使它是针对不同的目标引擎（例如 PySpark）编写的。

甚至还有像dbt这样的工具，它们采用类似的想法并将它们组合成一个框架。

SQL 比以前更具表现力和通用性
现代 SQL 引擎支持一系列功能，这些功能使复杂的操作比以前简单得多，解决了早期的缺点：

• 现在可以存储和操作嵌套数据结构，包括编写任意 lambda 函数来处理这些结构
• 窗口函数已经存在很长时间了，但是非常强大

SQL可能不合适的情况
什么时候可能有强烈的理由支持使用其他工具？我在这篇文章中指出，SQL 通常使您能够编写简单、可读且易于测试的管道。从长远来看，整体代码和基础设施相对简单且可维护。

但在某些情况下，情况恰恰相反。例如，要在 pandas 中插入时间序列，您可以使用resample方法 - 一行代码，意图很明确。在许多 SQL 引擎中，等效的 SQL 更加复杂且难以阅读。同样，SQL 可能不是操作类图数据结构的最佳工具。

最终 SQL 不应该是您考虑的唯一工具 - 但我建议在没有充分理由的情况下对其他工具进行推定。