背景说明：
近期公司的数据增量迅速增长，存储的成本太高，需要采用生命周期进行管理，热存储中的数据或者被删除，或者备份至冷存储。但是冷备时是否要压缩，需要进行验证。Azure本身没有提供压缩的接口，只能自己处理。以下是测试的结论。
备份压缩步骤
采用压缩流。验证了两种方式，方式一在文件较大时（>3G）会超时报错，方式二可行。
1、方式一：将源stream直接压缩包装输出到目标stream。不经过本地磁盘（测试应用服务器）。
这种方式在测试环境中，当文件>3G时，会报超时错误。
2、方式二：先将源文件下载到本地磁盘（测试应用服务器），然后通过压缩流写入目标stream。
基于这种方式，备份的文件操作步骤如下：
说明：
逐个将blob下载到应用服务器，压缩上传后立即删除，再下载next blob，保证在任一时刻，应用服务器上只有一个blob文件，以减少对应用服务器带来的存储压力和存储成本。
压缩算法测试
测试环境
应用服务器
测试应用服务器：App2（虚拟机）
内存：7G
CPU：Interl Xeon E5-2660 2.20GHz，4个虚拟处理器
操作系统：64位，windows server 2012R2
测试数据：Task_Log目录，包括99个blob，大小从1k至5.5G不等，总大小为20G (20553082991 B)。
热存储
AccountName：hdptest
AccountContainer：backup
冷存储
同热存储。通过热存储进行模拟，重点在于压缩算法的测试。
说明：
热存储、冷存储、应用服务器在同一区域内，不会产生传输费用
测试结果
操作耗时说明：
文件下载时间：539.9651764 s
从存储中删除文件时间：0.2446082 s
删除本地文件时间：1.1063126 s
压缩上传时间：见下表
测试失败的算法：
关于以上压缩算法或格式的说明，后附。
分析报告
1、压缩率与压缩速度成反比。压缩速度的差异 > 压缩率的差异
1）压缩率与压缩速度前三名
压缩率前三：7z-高压缩比，Gzip-优化，Gzip-普通
压缩速度前三：LZ4-普通，Deflate-快速，Gzip-快速
2） 在以上几种算法中，LZ4（普通模式）更新适合目前的备份压缩应用场景。
压缩率=28%，20G压缩时间=256s。相对来说，LZ4（普通模式）的磁盘IO较高。
以1T数据量为例，LZ4（普通模式）压缩后的大小估计284G，压缩时间估计3.5小时。
2、基于压缩传输的时间较长，所以备份的数据量要尽量控制，建议按周或更小的粒度来进行表的分区操作。
3、应用服务器、热存储、冷存储三者必须保证在同一个区域内，否则会产生网络传输费用。
4、关于Block Blob的说明：
1)Azure存储中，单个Block Blob最大4.75TB，追加Blob最大195G，Page Blob最大1T。
2)HBase的单个Block Blob 不超过200G，用的是追加Blob。
是否采用压缩的存储费用对比
对比分析前提说明
1、需要进行冷存储的数据为XX日志，目前总量47T，日增量0.5T，月增量15T。XX日志按月分表，每月备份一次，每次备份的数据量为15T。
XX日志生命周期参考如下：
2、热存储中需要常驻4个月的数据，所以假设备份的日期在2017.12(4个月后)。此时，需要冷备的数据量为47T，热存储中数据量为60T。
3、假设采用算法为LZ4（普通模式），压缩率28.42%，压缩时间3.5h/TB。该算法压缩率较高，但速度最快。
4、存储冗余级别为LRS（本地冗余存储），应用服务器、热存储、冷存储在同一数据中心。
压缩时需要将文件下载到应用服务器，由于是逐个下载，上传完毕即删，然后再下载另一个，所以在应用服务器上产生的存储费用忽略。
Blob存储费用说明：
参考：https://www.azure.cn/pricing/calculator/storage/
https://www.azure.cn/pricing/details/storage/
不冷备时的费用
每个月的固定费用：15943 ，并且每月增长 2235
冷备不压缩时的费用
第一次冷备产生的一次性费用：771
每个月的固定费用：8940+5170+246 = 14356 ，并且每月增长 1650
冷备压缩时的费用
第一次冷备产生的一次性费用：219
每个月的固定费用：8940+1469+70 = 10479 ，并且每月增长 469
三种费用对比
三种存储方式下的费用对比：
三种存储方式下的费用对比示例：
压缩算法简介
