AWS GLUE Pyspark作业意外删除S3文件夹

Question

我的粘合工作流程是DDB->GLUE表(通过使用Crawler(->S3(通过使用胶水作业(

我在工作流运行之前手动创建S3文件夹。

1. 对于大小为500~MB的DDB表，它总是运行良好(运行7-10分钟即可完成(，s3路径将具有正确的结果：例如s3://glue_example/DDB-500MB/(我通过连接到s3后在athena中检查数据来知道数据是正确的(

2. 对于大小为50GB的DDB表，GLUE JOB会删除该文件夹(运行2小时完成，无错误(，例如s3://GLUE_example/DDB_50GB，该文件夹会被删除。(我为s3启用了日志，在日志中，GlueJobRunnerSession在此文件夹路径上使用了DeleteObject(

3. 这种删除文件夹的行为是不一致的，大多数时候都会发生，但如果我发现文件夹被删除了，并且我手动创建了，那么下次运行将在s3文件夹中有正确的数据。

4. GLUE作业(GLUE 3.0-支持spark 3.1、Scala 2、Python 3(的代码非常简单。唯一写入s3的行是:ApplyMapping_node2.toDF().write.mode("overwrite").format("parquet").save('s3://glue_example/ddb_50GB')

5. 工作流/作业的并发性为1，因此它不是由竞争引起的问题

我使用覆盖来保持文件夹只有最新的数据。但我不知道为什么这会不断删除以大尺寸DDB作为数据源的文件夹。知道吗？

Answer 1

问题是由于整个表被读取到单个分区中，因为这是默认行为。在从DDB表中读取数据时增加generandb.split应该会有所帮助，因为它将数据并行读取到多个分区中。下面是pySpark中的一个示例。

dyf = glue_context.create_dynamic_frame.from_options(
connection_type="dynamodb",
connection_options={"dynamodb.input.tableName": "test_source",
"dynamodb.throughput.read.percent": "1.0",
"dynamodb.splits": "100"
}
)

有关更多信息，请参阅以下链接：

https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-connect.html#aws-胶水编程etl连接dynedb