发布于: May 19, 2021
在 Amazon S3 云存储成本优化过程中我们会遇到许多问题，接下来我们就多常见的问题进行解释说明，并提供解决方案。
常见问题 3.使用 S3 批量处理的时候作业失败，报错 Task Target Couldn’t be URL decoded
使用 S3 批量处理的时候，大家可能会遇到类似这样的报错: Failed to parse task from Manifest XXXXX.csv at bytes offset XXXXXXXX. ErrorMessage: Task target couldn’t be URL decoded.这是由于提供的清单文件 csv 文件中有一些前缀含有非 Unicode 字符，原理是由于 S3 批量处理需要文件夹目录和文件名对于特殊字符已经经过转码处理（比如空格，百分号等）。
解决方式：开启清单模式的时候不要选择 ORC 或者 Parquet，仅选择 csv 格式开启清单，这样生成的清单文件就会已经经过自动转码处理。
常见问题 4.正常情况下删除文件是不收费的，但是优化之后在下月账单或者 CUR 中发现了 DeleteObject 收费
这是由于 IA/ 智能分层 /Glacier/Glacier Deep Archive 这几个存储类别都有最少存储天数的要求，如果优化过程中删除了某些文件，但是这些文件没有达到相应存储类型的最少存储天数的要求，那么就会产生一次性的删除费用，补齐这些文件如果继续存满最小天数之后需要缴纳的费用。对于这几个存储类型，最少存储天数要求分别是 ， IA 和智能分层最少 30 天，Glacier 最少存储 90 天，Glacier Deep Archive 最少存储 180 天。
解决方式：没有解决方式，因为这是正常的使用费用。
常见问题 5.使用 S3 批量处理或者生命周期转换文件的时候有部分文件并没有被转换
这是因为这部分文件大小小于 128 KB，小于 128KB 的文件无法被转换为 IA 或者智能分层存储。
解决方式：使用 S3 清单，查询 Athena 排除小于 128KB 的文件，再使用 S3 批量处理进行转换到 IA 或者智能分层。使用生命周期的话无法排除，会直接不处理这些小文件，也不会收取额外费用。
常见问题 6.小文件转换为 Glacier 和 Glacier Deep Archive 可能会造成成本上升而不是下降
由于 S3 在将文件转换为 Glacier 或者 Deep Archive 的时候会自动增加 40KB 的元数据，其中 8KB 会继续存在标准存储上,32KB 存在对应的 Glacier 或者 Deep Archive。所以 8KB 以下的文件转换到 Glacier 或 Deep Archive 可能会让这部分数据存储费反而增加。
解决方式：使用 S3 清单，查询 Athena 看小于 8KB 的文件有多少（具体命令参考上一篇博客文章），如果数量巨大，那么需要查询 Athena 排除小于 8KB 的文件，然后使用 S3 批量处理来做类型转换。如果数量很少可以接受，还是可以使用生命周期做自动转换（但是无法排除小文件）。
常见问题 7.生命周期建立之后很久没有运行，导致成本优化没有进行
生命周期规则每天只会在通用协调时间 (UTC) 的午夜（00:00）运行一次，并且最多需要 48 小时才能开始运行参考官方文档
常见问题 8.S3 批量处理作业建立好之后，运行时间很长一直显示运行中。
S3 批量处理转换所需的时间不是数据大小决定的，而是根据您对象的数量决定的。经过测试 1 天时间大概能够处理 2 亿文件量。
解决方式：S3 批量处理作业会显示完成百分比，失败百分比等等。所以可以根据已经进行的时间预计完成时间。
总结
至此我们详细讲述了 S3 云存储成本优化过程以及可能遇到的各种问题和解决方法，但是长期来看还会有进一步优化方案，比如改进应用将不需要频繁访问的文件直接上传为 IA 以节省后期转换费成本，应用上传文件的时候就打好业务标签以便于以后优化分析等等，但是由于不属于对已有的成本优化而是未来架构方面的优化，本文就不再一一探讨。最后希望大家在使用 Amazon Web Services 的时候能更有效率的使用 S3 服务。
相关文章