Apache Arrow DataFusion 中逻辑计划反解析导致的 SQL 语法兼容性问题分析

在 Apache Arrow DataFusion 项目中，开发者发现了一个关于逻辑计划反解析（unparse）过程中产生的 SQL 语法兼容性问题。这个问题主要出现在处理包含特定类型连接操作的逻辑计划时，特别是当使用 PostgreSQL 等数据库方言进行反解析时。

问题背景

DataFusion 是一个可扩展的查询执行框架，支持将逻辑计划转换为特定数据库方言的 SQL 语句。在这个过程中，系统需要将内部优化的逻辑计划结构（如 LeftAnti Join 和 LeftSemi Join）正确地转换为目标数据库支持的 SQL 语法。

问题现象

当 DataFusion 处理包含以下操作的查询时会出现问题：

1. NOT IN 子查询（会被优化为 LeftAnti Join）
2. EXISTS 子查询（可能被优化为 LeftSemi Join）

优化后的逻辑计划在反解析为 PostgreSQL SQL 时，会生成类似 LEFT ANTI JOIN 或 LEFT SEMI JOIN 这样的语法结构。然而，这些语法并不是标准 SQL 语法，也不被 PostgreSQL 等主流数据库支持。

技术分析

问题的核心在于 DataFusion 的反解析器（Unparser）在处理特定连接类型时，没有考虑到目标数据库方言的语法限制。具体表现为：

1. 优化器将 NOT IN 子查询转换为更高效的 LeftAnti Join 执行计划
2. 反解析器直接将逻辑运算符名称转换为 SQL 关键字
3. 生成的 SQL 语法与目标数据库不兼容

解决方案探讨

要解决这个问题，可以考虑以下几种技术方案：

1. 方言感知的反解析：反解析器应当根据目标数据库方言，将特殊连接类型转换为该方言支持的等效语法结构。例如：

   • 将 LeftAnti Join 转换为 NOT IN 子查询
   • 将 LeftSemi Join 转换为 EXISTS 子查询

2. 保留原始查询结构：在优化过程中保留原始查询的语法结构信息，以便在需要时能够回退到原始语法。

3. 多阶段转换：在逻辑优化和物理优化之间增加一个方言感知的重写阶段，确保生成的执行计划可以被目标数据库支持。

影响范围

这个问题不仅影响 PostgreSQL，还会影响 MySQL、SQLite 等其他不支持这些特殊连接语法的数据库系统。对于实现联邦查询（跨数据源查询）的场景影响尤为明显。

最佳实践建议

对于使用 DataFusion 进行跨数据库查询开发的用户，建议：

1. 明确了解目标数据库支持的语法特性
2. 在涉及子查询优化时，测试生成的实际 SQL 语句
3. 考虑使用查询提示（hint）来指导优化器选择兼容的执行计划

这个问题反映了查询优化器与SQL生成器之间需要更紧密的协作，特别是在多数据源环境下，语法兼容性应该成为优化决策的重要因素之一。