S3_upload
S3 Upload for DEEP_ARCHIVE scenery
在 aws-sample 中的S3 resumable upload（https://github.com/aws-samples/amazon-s3-resumable-upload) 代码很好解决了大文件断点续传多线程上传的问题，但并不适用于所有场景。
本示例代码针对的客户场景：由于行业新规，产线实时产品照片需要进行25年以上的归档存储，客户多个工厂原有本地存储系统只能存储三个月的图片数据，已有的历史图片超100T，每月新增的图片20T以上，都需要一个低成本的存储方案。每张图片大小是2M，首先协助用户进行了成本的分析，以 us-east-1 为例，以20T存储12个月简略计算：
| 存储类型 | 数据量及文件大小 | 存储费用/月 | Put费用 | 12个月总费用 |
|---|---|---|---|---|
| S3标准 | 20T/2M | 471.04 | 52.4288 | 5704.9088 |
| S3 单区–不频繁访问 | 20T/2M | 204.8 | 104.8576 | 2562.4576 |
| S3 Glacier Deep Archive | 20T/2M | 20.2752 | 524.288 | 767.5904 |
| S3 Glacier Deep Archive | 20T/80M | 20.2752 | 13.1072 | 256.4096 |
从对比可以看到，S3 Glacier Deep Archive 存储等级在存储成本上拥有极大优势，但是客户以小文件为主，若不对文件进行任何合并，put费用会显得更高，所以本示例代码中，对文件进行聚合后再上传，以40倍聚合比为例，可以将put费用极大降低，整体成本进一步优化，相比本地存储也具有很大的价格优势。
本示例基于 S3 resumable upload 进行重写，实现基本功能如下
- 文件聚合
用户可以通过参数 SrcFileAggreRatio 设置文件聚合比，原始文件在本地聚合后进行上传，降低put次数；
- 多进程上传
用户可以通过参数 MaxThread 设置进程数量，python 由于GIL锁的存在，每个进程中同时运行线程只有一个，对于上传类操作简单提高线程数目并不能很好提高上传速率，为了最大化利用用户本地公网带宽，利用多进程可以明显提高上传的速率。建议该参数和虚拟机CPU核数一致。
- 本地临时文件夹管理
实际测试中发现打包速率远超上传速率（用户各工厂公网带宽150M-200M），本地存储以NAS方式挂载到负责上传的虚拟机上，在虚拟机磁盘上存储压缩后的临时文件，上传结束验证完MD5后删除临时文件，为避免磁盘占满，用户可以设置 LocalFolderSize ，在空间快利用完时主动降低打包速率；
- 异常中断处理
客户测试过程中出现过本地机房掉电等场景，为了避免压缩上传重新开始，用户可以设置 ifRecoverFromLast，LastZipIndexFile 参数，脚本会自动从上一次最后一个文件开始恢复压缩和上传操作。
冷备的文件偶尔也存在检索需求，针对用户的检索需求，可以采用如下的 serverless 架构来实现。
