Apache Arrow DataFusion 中 UNION 操作导致的字段名不匹配问题分析

问题背景

在 Apache Arrow DataFusion 项目中，当处理包含 UNION 操作的 Substrait 计划时，物理规划阶段会出现一个字段名不匹配的错误。具体错误信息为："Input field name $f3 does not match with the projection expression Utf8("people")"。这个问题主要出现在从 Substrait 计划生成逻辑计划后，在构建物理计划的过程中。

问题现象

在物理规划阶段，系统会尝试构建一个 ProjectionExec 物理算子，其表达式为 "Utf8("people") AS product_category, Utf8("people")__temp__0 AS product_type, product_key"。然而，在构建过程中发现，虽然逻辑计划中的 Union 节点在模式(schema)中定义了字段名为 "Utf8("people")"，但实际生成的 UnionExec 物理节点却使用了 "$f3" 作为字段名。

技术分析

1. 逻辑计划与物理计划的差异

从提供的示例逻辑计划可以看出，UNION 操作涉及多个子查询的合并。在逻辑计划中，字段名保持了原始语义（如 "people"），但在转换为物理计划时，某些字段被重命名为 "$fN" 的形式（如 "$f3"）。

2. 字段名处理的机制

DataFusion 在处理 UNION 操作时，会通过 find_or_first 方法来确定最终使用的字段名。这个方法会选择第一个可为空的字段作为结果字段名。在示例中：

• "Utf8("people")" 是不可为空的字段
• "$f3" 是可空的字段

因此，系统选择了 "$f3" 作为结果字段名，导致了与原始逻辑计划中 "Utf8("people")" 的不匹配。

3. 根本原因

问题的根本原因在于物理规划阶段对 UNION 操作字段名处理的逻辑存在不足。当处理来自 Substrait 的计划时，特别是那些包含 UNION 操作的计划，系统没有正确处理字段名的映射关系，特别是在字段可空性影响字段名选择的场景下。

解决方案

1. 字段名一致性处理

需要在物理规划阶段增强对字段名一致性的处理逻辑。具体来说，在构建 UnionExec 物理算子时，应该考虑：

• 保留逻辑计划中的原始字段名语义
• 处理字段可空性时不影响字段名的选择
• 确保投影表达式中的字段名与实际字段名一致

2. 模式合并策略优化

对于 UNION 操作的模式合并，可以改进策略：

• 优先使用非自动生成的字段名（如 "people" 而非 "$f3"）
• 在字段类型和可空性兼容的情况下，保持原始字段名
• 仅在字段名冲突时进行重命名

技术影响

这个问题会影响以下场景：

1. 从 Substrait 计划转换而来的查询执行
2. 包含 UNION 操作的复杂查询
3. 涉及字段重命名或别名的查询

最佳实践建议

对于使用 DataFusion 的开发人员，在处理类似问题时可以：

1. 检查 UNION 操作涉及的字段名是否一致
2. 确保投影表达式中的字段名与实际字段名匹配
3. 在构建复杂查询时，显式指定字段别名以避免自动命名

总结

这个问题揭示了 DataFusion 在处理复杂查询计划转换时的一个边界情况。通过优化 UNION 操作的字段名处理逻辑，可以确保从逻辑计划到物理计划的转换更加准确和可靠。对于项目维护者来说，这是一个值得关注的核心路径问题，因为它影响了查询计划的正确性和可靠性。