Apache DataFusion 中分区表逻辑计划序列化问题分析

Apache DataFusion 是一个用 Rust 编写的现代化查询引擎，它提供了高性能的 SQL 查询执行能力。在最新版本中，我们发现了一个关于分区表逻辑计划序列化/反序列化的有趣问题，这个问题值得深入探讨。

问题现象

当使用 DataFusion 处理分区表（特别是 Hive 风格的分区表）时，如果对逻辑计划进行序列化后再反序列化，会导致查询失败。具体表现为 Schema 校验错误，提示字段重复（"DuplicateQualifiedField"），特别是分区字段如"year"和"month"被重复识别。

技术背景

DataFusion 的 ListingTable 支持从文件系统读取数据，并可以自动识别 Hive 风格的分区结构。例如，路径如"/data/year=2024/month=1/"会被自动解析，并将"year"和"month"作为分区列添加到表结构中。

在内部实现上，ListingTable 会维护两个部分的数据：

1. 基础表结构（从文件元数据推断）
2. 分区列信息（从路径解析）

问题根源

经过分析，我们发现问题的核心在于逻辑计划的序列化过程中，proto 转换层错误地将分区列包含在了基础表结构中。具体来说：

1. 原始表结构不包含分区列，分区列是单独维护的
2. 序列化时错误地将分区列合并到了基础表结构
3. 反序列化后，分区列既存在于分区信息中，又被错误地包含在表结构中，导致重复

解决方案

修复方案相对直接：在 proto 转换层确保分区列不会被错误地包含在基础表结构中。具体来说：

1. 修改 logical_plan_to_bytes 实现，确保分区列信息正确分离
2. 添加专门的测试用例覆盖分区表序列化场景
3. 保持与原始表结构的一致性，不重复包含分区列

影响范围

这个问题主要影响以下场景：

1. 分布式查询执行（如 Ballista）
2. 需要序列化逻辑计划的缓存机制
3. 跨进程边界的查询计划传递

最佳实践

对于开发者使用 DataFusion 的分区表功能，建议：

1. 明确区分基础列和分区列
2. 在自定义序列化逻辑时注意保持这种区分
3. 测试时特别验证分区表的序列化场景

这个问题虽然技术点具体，但揭示了在复杂查询引擎中维护数据结构一致性的重要性，特别是在涉及序列化和分布式执行的场景下。