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

Apache Arrow DataFusion 是一个高性能的查询引擎，它使用 Rust 编写，能够处理大规模数据集。最近在使用过程中发现了一个关于 JOIN 操作后投影列(Projection)丢失的问题，这个问题会影响查询结果的正确性。

问题现象

在 DataFusion 中执行包含 JOIN 操作的 SQL 查询时，生成的优化后逻辑计划虽然正确包含了投影列信息，但在将逻辑计划转换回 SQL 语句(unparse)的过程中，投影列信息被意外丢弃了。这导致最终生成的 SQL 语句使用了 SELECT * 而不是预期的特定列选择。

具体表现为：

1. 原始 SQL 查询：select t1.v, t2.v from test t1, test t2
2. 优化后的逻辑计划正确显示了投影列：TableScan: test projection=[v]
3. 但最终生成的 SQL 却是：SELECT * FROM "test" AS "t1" CROSS JOIN "test" AS "t2"

问题根源

经过分析，这个问题主要由两个因素共同导致：

1. 投影优化规则：当最终投影列与表扫描(TableScan)中的列完全匹配时，optimize_projections优化规则会将投影操作优化掉，认为这是冗余操作。

2. JOIN 反解析逻辑：在unparser模块中的try_transform_to_simple_table_scan_with_filters函数处理JOIN操作时，会丢弃表扫描的投影信息，导致最终生成的SQL缺少正确的列选择。

技术影响

这个问题会导致几个潜在的技术影响：

1. 查询结果不一致：虽然执行引擎内部处理是正确的，但生成的SQL与原始意图不符，可能造成混淆。

2. 性能隐患：虽然当前情况下执行计划优化正确，但如果逻辑发生变化，缺少正确的投影可能导致不必要的数据传输。

3. 调试困难：开发者在查看生成的SQL时无法准确了解查询的真实执行情况。

解决方案方向

解决这个问题需要考虑以下几个方面：

1. 保留投影信息：即使在优化过程中投影操作被简化掉，也应该保留投影列信息用于SQL生成。

2. JOIN反解析改进：修改unparser模块中处理JOIN操作的逻辑，确保能够正确处理和保留投影列信息。

3. 投影优化规则调整：可能需要调整optimize_projections规则，使其在优化投影操作时保留必要的元数据。

这个问题展示了查询优化器中优化规则与反解析逻辑之间需要保持一致的挑战，也提醒我们在设计优化规则时需要考虑后续的查询表示需求。