胶水作业配置为最大10个节点容量,一个并行作业,失败时没有重试都会出现“未能删除键:目标_文件夹/_临时”的错误,根据堆栈跟踪,问题是S3服务由于请求的数量而开始阻塞Glue请求:"AmazonS3Exception:请降低请求速率。“
注意:问题不在IAM,因为胶水作业使用的IAM角色具有删除S3中的对象的权限。
我在GitHub上找到了一个关于这个问题的建议,并提出了减少工人数量的建议:https://github.com/aws-samples/aws-glue-samples/issues/20
“我已经成功地减少了工人的数量。”
然而,我不认为10是太多的工人,甚至想要实际增加工人人数到20,以加快ETL。
面对这个问题,有人成功了吗?我该怎么解决这个问题?
缩短的堆栈跟踪:
py4j.protocol.Py4JJavaError: An error occurred while calling o151.pyWriteDynamicFrame.
: java.io.IOException: Failed to delete key: target_folder/_temporary
at com.amazon.ws.emr.hadoop.fs.s3n.S3NativeFileSystem.delete(S3NativeFileSystem.java:665)
at com.amazon.ws.emr.hadoop.fs.EmrFileSystem.delete(EmrFileSystem.java:332)
...
Caused by: java.io.IOException: 1 exceptions thrown from 12 batch deletes
at com.amazon.ws.emr.hadoop.fs.s3n.Jets3tNativeFileSystemStore.deleteAll(Jets3tNativeFileSystemStore.java:384)
at com.amazon.ws.emr.hadoop.fs.s3n.S3NativeFileSystem.doSingleThreadedBatchDelete(S3NativeFileSystem.java:1372)
at com.amazon.ws.emr.hadoop.fs.s3n.S3NativeFileSystem.delete(S3NativeFileSystem.java:663)
...
Caused by: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.AmazonS3Exception: Please reduce your request rate. (Service: Amazon S3; Status Code: 503; Error Code: SlowDown; Request ID: ...Glue ETL python脚本的一部分(以防万一):
datasource0 = glueContext.create_dynamic_frame.from_catalog(database="database", table_name="table_name", transformation_ctx="datasource0")
... relationalizing, renaming and etc. Transforming from DynamicDataframe to PySpark dataframe and back.
partition_ready = Map.apply(frame=processed_dataframe, f=map_date_partition, transformation_ctx="map_date_partition")
datasink = glueContext.write_dynamic_frame.from_options(frame=partition_ready, connection_type="s3", connection_options={"path": "s3://bucket/target_folder", "partitionKeys": ["year", "month", "day", "hour"]}, format="parquet", transformation_ctx="datasink")
job.commit()解决了(某种程度上),谢谢用户ayazabbas
接受了帮助我走向正确解决方向的答案。我正在寻找的事情之一是如何将许多小文件压缩成大块,然后重新分区就可以做到这一点。我使用的不是重新分区(X),其中x是一个胶水作业的4*工人计数,这样glue服务就可以将每个数据块分配给每个可用的vCPU资源。如果x确实存在,那么至少使用2*4*worker_count来解释较慢和更快的转换部件可能是有意义的。
我做的另一件事是在将数据写入S3之前将数据分区的列数从5减少到4。
当前的缺点是,我还没有弄清楚如何在胶水服务为作业分配的胶水脚本中找到工人计数,因此数字是根据作业配置硬编码的(Glue服务分配的节点有时多于配置的节点)。
发布于 2020-01-15 13:11:12
我也有过同样的问题。在编写到S3之前,我通过在动态框架上运行重新分区(X)来解决这个问题。这将强制每个分区的x文件和写入过程中的最大并行度为x,从而降低了S3的请求速率。
我将x设置为1,因为我希望每个分区有一个拼花文件,所以我不确定在请求率过高之前,并行性的安全上限是多少。
我想不出更好的方法来解决这个问题,这很烦人,因为您在编写过程中有那么多空闲容量。
希望这能有所帮助。
https://stackoverflow.com/questions/59734196
复制相似问题