Apache Sedona中GeoTIFF写入HDFS的问题分析与解决

问题背景

在使用Apache Sedona 1.5.0/1.5.1版本处理地理空间数据时，开发人员发现当尝试将GeoTIFF格式的栅格数据写入HDFS时，输出目录中仅生成了一个_SUCCESS文件，而预期的TIFF文件并未出现。该问题发生在Spark 3.2.2环境下，使用Scala 2.12和Java 1.8运行时。

问题现象

当执行以下代码时：

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")

预期应在输出目录中生成TIFF文件，但实际上只观察到了_SUCCESS文件。通过检查HDFS审计日志，可以发现TIFF文件创建记录，但没有后续的重命名操作。

根本原因分析

经过深入排查，发现问题出在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. 这种混合使用不同路径API的方式可能导致路径解析不一致

解决方案

正确的做法是直接使用Hadoop的Path类来构造路径，修改后的代码如下：

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

这一修改确保了路径处理的一致性，完全使用Hadoop的文件系统API来处理HDFS路径。

技术深度解析

在分布式文件系统如HDFS中，路径处理需要特别注意：

1. API选择：Hadoop提供了专门的Path类来处理HDFS路径，它能够正确处理HDFS的特殊路径格式和协议
2. 跨平台兼容性：直接使用Path可以避免不同操作系统路径分隔符带来的问题
3. 文件系统抽象：Hadoop的FileSystemAPI提供了统一的接口，可以透明地处理不同文件系统

最佳实践建议

在处理地理空间数据写入HDFS时，建议：

1. 始终使用Hadoop原生API处理HDFS路径
2. 避免混合使用Java NIO和Hadoop API
3. 在写入完成后，验证文件是否确实存在于文件系统中
4. 考虑使用HDFS客户端工具检查文件状态

总结

这个问题的解决凸显了在分布式环境中处理文件路径时API选择的重要性。通过使用正确的Hadoop API，我们确保了地理空间数据能够正确写入HDFS，为后续的地理空间分析提供了可靠的数据基础。