Apache Arrow DataFusion SQL 反解析器中的排序表达式处理问题剖析

在 Apache Arrow DataFusion 项目中，SQL 反解析器（unparser）负责将逻辑执行计划（LogicalPlan）转换回可执行的 SQL 语句。近期发现了一个关于排序表达式处理的缺陷，这个缺陷影响了复杂 ORDER BY 子句的正确反解析。

问题背景

DataFusion 在处理聚合计算时会将底层表达式转换为列引用。例如，一个包含 COUNT 聚合函数的查询，在逻辑计划中会表示为列名类似 count(Int64(1)) 的引用。这种转换在计划优化和执行阶段是合理的，但在反解析回 SQL 时却带来了挑战。

问题本质

问题的核心在于排序表达式的反解析处理不够通用。原有的实现假设 ORDER BY 子句只能是简单的列引用或带别名的列引用，然后通过查找聚合节点来还原原始表达式。然而，SQL 标准允许 ORDER BY 包含任意复杂表达式，包括：

1. 双重别名表达式（如 count(*) AS count(*) AS count(*)）
2. 二元运算表达式（如 grouping(a) + grouping(b)）
3. CASE WHEN 条件表达式

技术细节分析

在 DataFusion 的逻辑计划中，聚合计算后的列会被赋予特定的名称，上层节点通过这个名称引用聚合结果。反解析器需要：

1. 识别出这些特殊命名的列引用
2. 回溯到聚合节点找到原始计算表达式
3. 将原始表达式正确反解析为 SQL 语法

原有的实现仅处理了简单列引用情况，当遇到嵌套在其他表达式中的聚合引用时就会失败。例如，在 TPCDS Q36 查询中的排序条件就包含了二元运算和 CASE 表达式。

影响范围

这个问题在以下场景会显现：

1. 包含复杂排序条件的聚合查询
2. 使用 ROLLUP/GROUPING SETS 等高级分组功能的查询
3. 在排序条件中使用函数组合的查询

解决方案方向

正确的实现应该：

1. 递归遍历整个排序表达式树
2. 对每个列引用节点检查是否是聚合结果引用
3. 对非列引用节点保持原有结构
4. 对聚合引用执行表达式回溯和替换

这种处理方式能够保持原始 SQL 的语义完整性，同时正确处理聚合表达式的反解析。

项目意义

这个问题的修复完善了 DataFusion 的 SQL 往返（round-trip）能力，确保了逻辑计划能够准确还原为原始 SQL。对于以下场景尤为重要：

1. 查询优化器的开发和调试
2. 跨系统查询兼容性
3. 查询历史记录和审计
4. 自动化测试框架

通过解决这个问题，DataFusion 在处理复杂 SQL 语法方面又向前迈进了一步，增强了其作为高性能查询引擎的可靠性。