扫描 Delta 表时为何出现警告和性能差异？
结论
仅凭这条警告，无法判断扫描失败、数据丢失或性能变慢的根因。它说明 delta_kernel::engine::default::json 的 read_json 路径中，接收端 channel 在发送完成信号前已关闭。要确认这是正常取消、错误路径还是版本相关问题，还需要查看实际版本和完整日志。
Spark 和 Polars 写出的表虽然都使用 Delta 格式，底层文件布局和写入元数据仍可能不同。因此，“同一工具写读更快”只是当前测试中的观察结果，不能据此认定两种工具存在固定的性能排序。
为什么读写性能可能不同
读取时间和内存占用会受到多个因素影响，例如 Delta 表的数据文件数量和大小、part 分区分布、写入时是否分块，以及读取引擎实际扫描和处理数据的方式。两种工具生成的文件数量或大小不同时，读取端需要处理的工作量也会不同。
“最快”和“最省内存”衡量的是不同指标。你观察到 Polars 的 streaming engine 惰性读取 Polars 写入的表耗时较短，而读取 Spark 写入的表时内存占用较低，两项结果并不冲突。它们只反映这组数据和运行条件下的表现，不能直接推广到其他数据集或环境。
如何排查警告
先确认扫描结果是否正确，再判断警告是否影响任务：
- 记录 Spark、Polars、Delta 相关依赖的版本，以及每次扫描的完整日志和退出状态。
- 对比有警告和无警告的运行，检查扫描是否完成、结果行数是否一致，以及任务是否异常退出。
- 检查表的
_delta_log和数据文件，比较两种写入方式生成的文件数量、大小和分区分布。 - 如果警告持续出现，并且伴随扫描失败或结果不一致，保留最小复现数据、完整日志和版本信息，再针对相应依赖版本排查。单凭这条日志无法确定具体故障原因。
公平比较 Spark 与 Polars
使用同一份输入数据，并确保两种写入方式采用相同的分区策略和目标数据范围。写入完成后，记录 Delta 数据文件的数量、大小分布和总数据量，再分别用 Spark 和 Polars 读取两张表。
每组测试都要记录读写耗时和峰值内存，并确认读取结果一致。如果实际工作负载使用 Polars 的惰性或 streaming 读取，就按实际查询方式测试，不要只比较完整读取的耗时。重复运行并固定环境，有助于减少缓存和资源波动的干扰。
选择建议
如果 Spark 的 API 和写入时的内存管理更适合管道需求，而 Polars 是主要消费者，可以先用 Spark 写入，再通过真实的 Polars 查询负载验证读取时间和内存占用。如果 Polars 在当前数据规模下写入更快，也要确认是否需要分块，以及生成的文件布局是否适合后续读取。
选择时应结合端到端负载，比较写入成本、读取成本、峰值内存和运行稳定性。现有信息没有提供版本、数据规模或文件布局，因此无法据此判断哪种工具普遍更快，也无法确认这条警告是否只是无害提示。
备注：内容仅供参考。