Apache Sedona 中 GeoTIFF 栅格数据写入 HDFS 的问题分析与解决方案

问题背景

在使用 Apache Sedona 1.5.0/1.5.1 版本时，开发者尝试将 GeoTIFF 格式的栅格数据写入 HDFS 文件系统时遇到了一个异常现象。具体表现为：当使用 Spark SQL 的 binaryFile 格式读取 TIFF 文件后，尝试通过 Sedona 的 raster 格式写入 HDFS 时，目标目录中仅生成了一个 _SUCCESS 文件，而预期的 TIFF 文件并未出现。

问题现象详细描述

开发者通过以下代码尝试写入栅格数据：

var df = spark.read.format("binaryFile").load("/user/spark/raster/input.tif")
df.write.format("raster").mode(org.apache.spark.sql.SaveMode.Overwrite).save("output")

执行后，HDFS 目标目录中仅出现 _SUCCESS 文件，没有生成预期的 TIFF 文件。通过检查日志发现以下关键信息：

1. HDFS 审计日志中显示文件创建操作，但没有后续的重命名操作
2. 执行器日志中出现警告："Expected 1 files, but only saw 0"，表明输出格式可能没有正确写入文件

根本原因分析

经过深入排查，发现问题出在 RasterFileFormat.scala 文件的实现中。具体来说，在创建输出文件路径时，代码错误地使用了 Paths.get() 方法来拼接 HDFS 路径：

val out = hfs.create(new Path(Paths.get(savePath, new Path(rasterFilePath).getName).toString))

这种实现方式存在两个问题：

1. Paths.get() 是 Java NIO 的 API，主要用于本地文件系统路径操作，不适合用于 HDFS 路径处理
2. 这种路径拼接方式可能导致路径格式不符合 HDFS 的预期

解决方案

正确的实现应该直接使用 Hadoop 的 Path 类进行路径拼接：

val out = hfs.create(new Path(savePath, new Path(rasterFilePath).getName))

这种修改确保了：

1. 完全使用 Hadoop 生态的路径处理方式
2. 路径格式符合 HDFS 的规范
3. 避免了不同文件系统 API 混用可能带来的问题

技术深度解析

文件系统 API 的差异

Java 提供了多种文件系统操作 API：

1. java.nio.file.Paths：标准的 NIO API，主要用于本地文件系统
2. org.apache.hadoop.fs.Path：Hadoop 提供的 API，专为分布式文件系统设计

在 Hadoop/Spark 生态中，处理 HDFS 路径时应始终使用后者，因为：

• 它正确处理了 HDFS 的 URI 格式
• 它考虑了分布式环境下的路径语义
• 它与 Hadoop 文件系统抽象完美集成

文件写入流程分析

Sedona 的栅格数据写入流程大致如下：

1. 通过 Spark 的 DataFrame 接口接收二进制数据
2. 使用 RasterFileFormat 进行格式转换
3. 通过 Hadoop 文件系统 API 写入 HDFS

问题出现在第三步，当使用错误的路径拼接方式时，虽然文件创建操作被记录（出现在审计日志中），但由于路径格式问题，文件无法被正确提交和重命名，导致最终不可见。

最佳实践建议

1. 路径处理一致性：在 Hadoop/Spark 生态中，始终使用 org.apache.hadoop.fs.Path 进行路径操作
2. 跨文件系统兼容性：如果需要支持多种文件系统，应通过 Hadoop 的文件系统抽象层进行处理
3. 错误处理：在文件操作代码中加入适当的错误处理和日志记录
4. 测试覆盖：增加对 HDFS 等分布式文件系统的测试用例

总结

这个案例展示了在分布式计算环境中正确处理文件路径的重要性。Apache Sedona 作为地理空间大数据处理框架，需要特别注意不同文件系统 API 的适用场景。通过修正路径处理逻辑，可以确保栅格数据能够正确写入 HDFS，满足地理空间大数据处理的需求。