Apache Arrow DataFusion 中 Join 操作投影列丢失问题分析

在 Apache Arrow DataFusion 项目中，最近发现了一个关于 SQL 查询解析和优化的有趣问题。这个问题涉及到查询计划中的投影列（Projection）在特定情况下会被错误地丢弃，导致生成的 SQL 语句与原始查询意图不符。

问题现象

当执行包含 JOIN 操作的查询时，如果满足以下两个条件：

1. 最终投影列与底层表扫描（TableScan）的列完全匹配
2. 使用特定的优化规则后

生成的 SQL 语句会丢失原本指定的投影列，转而使用通配符(*)选择所有列。例如，对于查询：

SELECT t1.v, t2.v FROM test t1, test t2

优化后的查询计划会错误地生成：

SELECT * FROM "test" AS "t1" CROSS JOIN "test" AS "t2"

技术背景

在 DataFusion 的查询处理流程中，SQL 语句会经历解析、优化和执行几个阶段。其中：

1. 解析阶段：将 SQL 文本转换为逻辑计划
2. 优化阶段：应用各种优化规则改进查询计划
3. 反解析阶段：将优化后的计划转换回 SQL 文本

问题出现在优化和反解析阶段的交互中。DataFusion 有一个优化规则 optimize_projections，它会移除被认为冗余的投影操作。同时，在反解析 JOIN 操作时，try_transform_to_simple_table_scan_with_filters 函数会进一步简化表扫描操作，导致投影信息丢失。

问题根源

深入分析发现，问题的核心在于：

1. 当投影列与表扫描列完全匹配时，优化器认为投影是冗余的并将其移除
2. 在反解析 JOIN 操作时，处理表扫描的逻辑没有保留原始的投影信息
3. 这两个因素共同作用，导致最终生成的 SQL 丢失了指定的列

解决方案思路

解决这个问题有几种可能的途径：

1. 修改 JOIN 反解析逻辑：确保在处理 JOIN 操作时保留投影信息
2. 调整优化规则：防止在特定情况下移除投影操作
3. 增强反解析器：在最终输出前重新应用投影信息

从架构角度看，第一种方案可能更为合理，因为它保持了优化器的独立性，只在反解析阶段做必要的信息恢复。

影响分析

这个问题虽然不会影响查询执行的正确性（因为优化后的计划仍然会返回正确结果），但会影响：

1. 查询的可读性：生成的 SQL 不再反映原始查询的精确意图
2. 工具互操作性：某些工具可能依赖生成的 SQL 格式
3. 调试体验：开发者看到的执行计划与原始查询差异增大

总结

这个案例展示了查询优化器中不同组件间交互的复杂性。在追求性能优化的同时，也需要保持查询表示的一致性。DataFusion 社区正在考虑最合适的修复方案，以平衡优化效果和查询表示的准确性。

对于开发者而言，这个问题提醒我们：在编写涉及查询优化的代码时，需要考虑优化后的表示如何被后续阶段（如反解析）处理，确保整个流程的信息完整性。