Apache Sedona中GeoTIFF写入HDFS失败问题分析

问题现象

在使用Apache Sedona 1.5.0/1.5.1版本时，尝试将GeoTIFF格式的栅格数据写入HDFS时遇到了异常情况。具体表现为：当通过Spark的DataFrame API执行写入操作后，目标目录中仅生成了一个_SUCCESS文件，而没有预期的TIFF文件。

环境配置

该问题出现在以下环境中：

• Apache Spark版本：3.2.2
• Scala版本：2.12
• JRE版本：1.8
• 运行模式：Standalone模式

问题根源分析

经过深入排查，发现问题出在Sedona的RasterFileFormat实现中。具体来说，在org.apache.spark.sql.sedona_sql.io.raster.RasterFileFormat.scala文件中，文件路径处理存在缺陷。

原始代码使用了Java的Paths.get方法来构造HDFS路径：

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

这种处理方式在Hadoop文件系统环境下存在问题，因为Paths.get是Java NIO的API，主要用于本地文件系统路径处理，而不适合直接用于HDFS路径构造。

解决方案

正确的做法是直接使用Hadoop的Path类来构造路径：

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

这种修改确保了路径构造方式与Hadoop文件系统API完全兼容，能够正确处理HDFS上的文件操作。

技术背景

理解这个问题需要了解几个关键技术点：

1. Hadoop文件系统API：Hadoop提供了自己的文件系统抽象，通过org.apache.hadoop.fs.Path类来表示文件路径，它能够正确处理HDFS等分布式文件系统的路径语义。

2. Java NIO Path：Java 7引入的NIO.2 API中的Paths类主要用于本地文件系统操作，虽然功能强大，但与Hadoop文件系统API并不完全兼容。

3. Spark文件写入机制：Spark在执行文件写入时，会先创建临时文件，最后通过重命名操作完成最终文件的创建。路径处理不当会导致这一过程失败。

影响范围

该问题主要影响：

• 使用Sedona写入栅格数据到HDFS的场景
• 使用二进制文件格式（如GeoTIFF）的情况
• 在分布式环境（如HDFS）下运行的应用

最佳实践建议

1. 在处理HDFS路径时，始终使用Hadoop的Path类而非Java NIO的Paths类。

2. 对于跨文件系统的代码，应当明确区分本地文件系统操作和分布式文件系统操作。

3. 在编写文件系统相关的单元测试时，应当覆盖HDFS等分布式文件系统的测试场景。

总结

这个案例展示了在分布式计算环境中处理文件路径时需要特别注意API的选择。即使是看似简单的路径构造操作，在不同的文件系统实现下也可能表现出不同的行为。作为开发者，理解底层API的适用场景和限制条件至关重要。