首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >S3异常“请降低请求速率”导致的AWS“未能删除键:目标_文件夹/临时”

S3异常“请降低请求速率”导致的AWS“未能删除键:目标_文件夹/临时”
EN

Stack Overflow用户
提问于 2020-01-14 12:54:09
回答 1查看 2.1K关注 0票数 2

胶水作业配置为最大10个节点容量,一个并行作业,失败时没有重试都会出现“未能删除键:目标_文件夹/_临时”的错误,根据堆栈跟踪,问题是S3服务由于请求的数量而开始阻塞Glue请求:"AmazonS3Exception:请降低请求速率。“

注意:问题不在IAM,因为胶水作业使用的IAM角色具有删除S3中的对象的权限。

我在GitHub上找到了一个关于这个问题的建议,并提出了减少工人数量的建议:https://github.com/aws-samples/aws-glue-samples/issues/20

“我已经成功地减少了工人的数量。”

然而,我不认为10是太多的工人,甚至想要实际增加工人人数到20,以加快ETL。

面对这个问题,有人成功了吗?我该怎么解决这个问题?

缩短的堆栈跟踪:

代码语言:javascript
复制
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脚本的一部分(以防万一):

代码语言:javascript
复制
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服务分配的节点有时多于配置的节点)。

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2020-01-15 13:11:12

我也有过同样的问题。在编写到S3之前,我通过在动态框架上运行重新分区(X)来解决这个问题。这将强制每个分区的x文件和写入过程中的最大并行度为x,从而降低了S3的请求速率。

我将x设置为1,因为我希望每个分区有一个拼花文件,所以我不确定在请求率过高之前,并行性的安全上限是多少。

我想不出更好的方法来解决这个问题,这很烦人,因为您在编写过程中有那么多空闲容量。

希望这能有所帮助。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/59734196

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档