Spark Structured Streaming 读取持续写入中文件的实现方案（不使用Kafka）

你遇到的单文件仅能读到初始内容、无法获取后续新增写入的问题，是Spark Structured Streaming自带文件数据源的固有设计限制，不是代码配置错误。

Spark自带的各类文件流数据源（csv/parquet/json等格式）的核心追踪逻辑为：仅扫描指定目录下已完成写入、后续不会再修改的静态文件，通过文件路径、修改时间在checkpoint中标记已读状态。一旦某文件被标记为已读，无论后续这个文件被追加多少内容，都不会被再次触发读取——这就是你当前代码完全读不到文件增量的核心原因。
你构思的临时方案（间隔生成新文件再复制到读取目录）本质上是适配文件源设计的可行思路，但跨目录复制的步骤属于完全可以去掉的额外开销，不需要承担额外的处理延迟。

1. 低延迟适配：基于文件源的分片写入优化 #

这是改动成本最低的方案，不需要开发自定义逻辑，仅需调整写入端流程：

• 废弃“所有内容往同一个固定文件持续追加”的写入逻辑，改为按和流处理触发周期对齐的时间窗口（比如和你当前配置的10s处理周期对齐）生成独立的分片文件
• 分片文件一旦写入完成，立即关闭文件句柄、不再做任何修改，直接放到流处理的读取目录下，省掉临时目录、跨目录复制的冗余步骤
• 配套调整文件源参数进一步优化稳定性：
  • 配置option("maxFilesPerTrigger", 100)：控制每次触发周期最多读取的分片数量，避免短时间文件过多导致数据积压
  • 配置option("cleanSource", "archive")：已被Spark读取完成的文件自动归档到指定存储路径，避免读取目录下文件数量过多拖慢元数据扫描速度

这种方案的端到端延迟基本和你设置的10s触发周期持平，没有额外的复制延迟，完全兼容你现有的流处理代码，不需要修改下游写入逻辑。

2. 自定义单文件增量监听Source #

如果业务侧确实无法调整写入逻辑（必须往同一个固定文件里持续追加内容），可以绕开自带文件源，基于Structured Streaming的自定义Source接口实现增量监听：

• 核心实现逻辑：不再靠文件路径做已读标记，而是持续记录上次读取到的目标文件的字节偏移量，每次触发时，读取文件从上次偏移量到当前文件末尾的所有新增内容，解析为结构化数据后推送到流处理链路
• 把偏移量的追踪状态持久化存储在checkpoint目录中，Spark任务重启后可以直接从断点位置继续读取，不会出现数据漏读、重复读的问题

这种方案没有任何中间文件的读写开销，处理延迟完全由你设置的触发周期决定，适合写入端逻辑无法改造的场景。

3. 命名管道（FIFO）对接持续写入的文件 #

如果不想开发自定义Source，可以用操作系统层面的命名管道实现无中间文件的流式对接：

• 在持续写入文件的节点上，启动一个守护的tail -f进程，持续追踪目标文件的新增内容，把输出流重定向到一个系统创建的FIFO命名管道中
• 把Spark csv流的读取路径直接指向这个FIFO管道

Spark的csv数据源支持从持续输入的字节流管道读取内容，不会把管道当成“已完成的静态文件”做一次性标记，每次触发时都会读取管道中攒下的新增内容，完全不需要生成新的分片文件。实际落地时需要配套做进程守护，避免tail进程异常退出导致管道断连。

• 绝对不要让文件源读取到“还在被写入的未关闭文件”，否则会出现数据截断、漏读的问题
• 所有读取偏移、分片状态必须持久化到checkpoint目录，不要仅靠内存记录，避免任务重启后出现数据不一致
• 不要尝试通过调整自带文件源的配置去实现单文件tail的能力——从设计层面，这个数据源就不支持持续修改的单文件场景，再怎么调配置都无法生效

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