PySpark保存二进制数据至Blob存储时追加F4FFFF类乱码问题

固定间隔插入异常字符、首尾附带多余内容的问题，本质是二进制数据误用文本类API写入，触发Spark内置文本写入逻辑+Blob存储客户端默认块写入规则冲突：

• 你观察到的65500字节左右的插入间隔，刚好对应Spark文本写入的默认64KB行缓冲刷盘边界。把二进制数据按UTF-8文本规则写入时，Spark会在每次缓冲块刷盘时自动插入默认行分隔符，遇到非可打印二进制字节时会直接转成乱码填充，就是你看到的间隔异常字符。
• 首尾的异常字符是Spark输出非分区文本文件时，自动给每个输出分片添加的分片识别头/尾标记，这类标记仅服务于文本场景的分片读取，写入二进制内容时不会做转义处理，直接成为脏数据。
• 所有面向文本的写入API（包括write.text()、saveAsTextFile）默认带文本编码、行分隔符插入逻辑，不管怎么调写入配置，都无法完全避免二进制内容被污染。

方案1：使用Spark原生二进制文件写入API（推荐，适配分布式场景） #

将二进制列以专用二进制格式写入，不要走文本写入链路，参考代码：

# 假设存储二进制内容的列名为content，类型为BinaryType
# coalesce(1)保证仅输出1个文件，匹配你单行数据的场景
df.coalesce(1) \
  .write \
  .format("binaryFile") \
  .mode("overwrite") \
  .save("abfss://<容器名>@<存储账户名>.dfs.core.windows.net/<目标路径>")

如果需要自定义输出文件名，写入完成后通过Hadoop FileSystem API重命名生成的part文件即可，不要修改写入格式参数。

方案2：直接用Blob Storage SDK上传（最稳妥，适配单条数据场景） #

你仅需上传1行二进制数据，完全不需要走Spark分布式写入链路，直接将数据拉取到Driver端后用官方SDK上传，从根源避免Spark写入逻辑的污染：

from azure.storage.blob import BlobClient
# 拉取单行二进制内容到Driver
binary_data = df.select("content").first()[0]
# 初始化客户端直传
blob_client = BlobClient.from_connection_string(
    conn_str="<存储账户连接字符串>",
    container_name="<容器名>",
    blob_name="<目标Blob文件名>"
)
blob_client.upload_blob(binary_data, overwrite=True)

以下操作无法解决该问题，无需重复尝试：

• 修改spark.hadoop.mapreduce.textoutputformat.separator参数为空
• 切换压缩格式（包括关闭压缩、用gzip/snappy/zstd压缩）
• 调整spark.sql.files.maxPartitionBytes修改分片大小
• 更换WASB/ABFSS存储客户端版本

上传完成后通过Blob SDK下载对应文件，对比本地原始数据的字节长度、MD5校验值，二者完全一致即说明写入正常。

内容的提问来源于stack exchange，提问作者user19405409