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

Apache DataFusion 是一个用 Rust 编写的查询引擎，它提供了高性能的 SQL 查询执行能力。在使用过程中，我们发现了一个关于分区表逻辑计划序列化/反序列化的有趣问题。

问题现象

当用户尝试对分区表 ListingTable 的逻辑计划进行序列化后再反序列化时，会出现 Schema 验证错误。具体错误信息表明存在重复的字段定义："year"字段在表"hive_style"中被重复定义。

问题复现

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

1. 创建一个基于 Hive 风格分区的 ListingTable
2. 定义分区列（如 year 和 month）
3. 生成查询该表的逻辑计划
4. 对逻辑计划进行序列化
5. 再反序列化后执行

技术分析

问题的核心在于逻辑计划序列化过程中对分区列的处理。当前实现中，在序列化逻辑计划时，会将表的所有列（包括分区列）都包含在 Schema 中。然而，原始表实际上并不包含这些分区列 - 它们是在查询时动态添加的。

当反序列化后的逻辑计划被执行时，Schema 验证会发现重复的列定义：

• 原始表 Schema 中的列
• 动态添加的分区列

这导致了 SchemaError 错误。

解决方案

正确的做法应该是在序列化逻辑计划时，只包含原始表的 Schema，而不包含分区列。这与原始表的行为保持一致。具体来说，应该修改 proto/src/logical_plan/mod.rs 文件中处理 ListingTable 序列化的逻辑。

影响范围

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

• 使用分区 ListingTable
• 需要对逻辑计划进行序列化/反序列化
• 特别是分布式查询场景（如 Ballista）

测试建议

为了确保修复的可靠性，建议在 roundtrip_logical_plan.rs 测试文件中添加针对分区表的序列化测试用例。测试应该验证：

1. 分区表逻辑计划的正确序列化/反序列化
2. 反序列化后查询执行的正确性
3. Schema 的一致性验证

总结

这个问题展示了在分布式查询处理中，逻辑计划的序列化需要特别注意保持与原始对象的一致性。对于分区表这种特殊结构，需要正确处理其动态添加的列与原始 Schema 的关系。这个修复将有助于提升 DataFusion 在分布式场景下的可靠性。