AWS Glue单任务多文件夹书签失效问题求助

你遇到的核心问题是Glue书签的上下文管理错误，加上代码里的Job生命周期处理不当，导致未处理的路径被误标记为已处理，同时出现部分记录缺失的情况。我来拆解一下问题原因和具体解决方案：

问题根源分析 #

1. Job初始化/提交的位置错误
   你在循环里每次处理子路径时都调用了job.init()和job.commit()，这会直接打乱Glue书签的跟踪逻辑。Glue的书签是绑定在整个任务运行实例上的，第一次循环处理01路径提交后，书签会记录整个任务的S3源路径（包括未处理的02、03）的状态，后续循环再处理02时，书签会默认认为这个路径属于同一个任务的源范围，已经被扫描过，所以提示“未检测到新文件”。

2. 疑似变量名错误
   代码里读取的动态帧是job_DyF，但写入时用的是df_verify_filtered——如果这不是笔误，会导致写入未定义的变量，直接引发数据缺失（甚至任务失败）。

3. 书签的分区跟踪逻辑偏差
   Glue书签默认跟踪单个文件，但如果你的源是分区结构，且没有配置分区感知的处理逻辑，它会误将整个父路径下的所有分区都标记为已处理。

解决方案 #

1. 修正Job生命周期管理 #

把Job的初始化和提交移到循环外面，一个Glue任务只需要初始化一次、提交一次，循环里仅负责单个子路径的读写操作：

import sys
from awsglue.utils import getResolvedOptions
from awsglue.context import GlueContext
from awsglue.job import Job
from pyspark.context import SparkContext

sc = SparkContext()
glueContext = GlueContext(sc)
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
job = Job(glueContext)

# 首次修复时可以添加重置书签的配置，运行一次后可移除
# job.init(args['JOB_NAME'], args, bookmark_options={"bookmark": "reset"})
job.init(args['JOB_NAME'], args)

s3_paths = ['01', '02', '03'] 
s3_source_path = 's3://bucket_name/'

for sub_path in s3_paths :
    s3_path = f"{s3_source_path}/{sub_path}"
    # 从S3路径获取数据，每个子路径用唯一的transformation_ctx
    job_DyF = glueContext.create_dynamic_frame.from_options(
        's3', 
        {"paths": [s3_path], "recurse": True}, 
        "json", 
        format_options={"jsonPath": "$[*]"}, 
        transformation_ctx = f"job_DyF_{sub_path}"
    )
    # 替换为正确的动态帧变量名，同样使用唯一的transformation_ctx
    data_sink = glueContext.write_dynamic_frame.from_options(
        frame = job_DyF, 
        connection_type = "s3", 
        connection_options = {"path": "s3://target", "partitionKeys": ["partition_0", "partition_1", "partition_2"]}, 
        format = "avro", 
        transformation_ctx = f"data_sink_{sub_path}"
    )

job.commit()

2. 重置现有书签状态 #

因为之前的错误提交已经让书签误标记了02、03路径，需要先重置任务的书签状态：

• 方法1：在Glue控制台找到你的任务，进入「Job details」页面，找到「Bookmark」选项，选择「Reset bookmark」。
• 方法2：在代码里的job.init()中添加bookmark_options={"bookmark": "reset"}，运行一次修复任务后再移除该配置（避免每次都重置所有记录）。

3. 配置分区感知的书签（可选） #

如果你的任务需要长期增量处理分区，可以让Glue按分区跟踪文件状态：
在create_dynamic_frame.from_options的connection_options中添加"groupFiles": "inPartition"，让Glue按分区分组处理文件，书签会单独跟踪每个分区的状态。

4. 验证数据读取逻辑 #

可以在循环里添加日志打印，确认每个子路径的文件是否被正确读取：

print(f"Processing path {s3_path}, total records: {job_DyF.count()}")

通过记录数排查是否是源文件本身存在缺失，而非处理逻辑问题。

关键注意事项 #

• transformation_ctx必须唯一：每个动态帧的transformation_ctx要单独命名，否则Glue书签会混淆不同数据源的跟踪状态。
• 禁止循环内操作Job生命周期：一个Glue任务的init和commit只能执行一次，多次调用会彻底破坏书签的跟踪逻辑。
• 书签的作用范围：Glue书签是针对整个任务的源路径的，不是单个子路径，所以按分区处理时必须明确配置分区感知逻辑。

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