AWS GLUE Pyspark 作業意外刪除 S3 文件夾

Question

我的膠水工作流程是 DDB -> GLUE 表（通過使用 Crawler）-> S3（通過使用 GLUE 作業）

我在工作流運行之前手動創建 S3 文件夾。

1. 對於大小為 500~MB 的 DDB 表，它總是可以正常工作（運行 7-10 分鍾才能完成），s3 路徑將有正確的結果：例如 s3://glue_example/ddb_500MB/ （我知道通過在 athena 中檢查數據是正確的連接到s3后）

2. 對於大小為 50GB的 DDB 表，該文件夾被 GLUE JOB 刪除（運行 2 小時才能完成，沒有錯誤），例如 s3://glue_example/ddb_50GB 這個文件夾被刪除。 （我為 s3 啟用了日志，並且在日志中，GlueJobRunnerSession 在此文件夾路徑上使用了 DeleteObject ）

3. 這種刪除文件夾的行為並不一致，大多數情況下都會發生，但是如果我發現文件夾被刪除了，並且我手動創建了，那么下次運行該 s3 文件夾中將有正確的數據。

4. 膠水作業（膠水 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 表讀取時增加 dynamodb.splits 應該會有所幫助，因為它會將數據並行讀取到多個分區中。下面是 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-glue-programming-etl-connect-dynamodb