本文属于【Azure Data Platform】系列。
接上文：【Azure Data Platform】ETL工具(22)——Azure Databricks与ADF整合
本文介绍Azure Blob Storage的Lifecycle Management功能
前言
由于最近工作需要，临时加了任务，主要是降低ADLS的存储费用，除了直接删除或手动、编程移动到其他地方，还发现有一个可用的功能“Lifecycle Management”。所以这里整理和总结一下。
Azure 存储是 Microsoft 托管的一项服务，它提供高度可用、安全、持久、可缩放且冗余的云存储。Azure 存储包括 Azure Blob (对象)、Azure Data Lake Storage Gen2、Azure 文件存储、Azure 队列和 Azure 表。
正是由于Azure 存储的广泛普及及其价格相对于传统存储来说更加便宜，安全，所以越来越多云项目会把数据和文件存储在上面。随着时间推移，很容易就会存放超过PB级别的数据。特别是对于生产环境的数据，通常会选择GRS（见下图）冗余存储方式，这种方式单纯存储费用并不是很高，但是传输费用非常惊人，因为一旦上面有数据变动，就会触发同步传输，把主存储上面发生变化的内容同步到配对的数据中心，比如香港数据中心同步到新加坡的数据中心。举个实际例子，一个月的存储费用大概是2000美金，但是传输费用接近20000美金，10倍左右的费用。而且注意新加坡那边的存储也是要钱的，这个费用跟不适用GRS冗余的存储单价相比，接近2倍。
所以存储费用在后期是一个让人头痛的事情。然而检讨数据使用，数据在一定周期之后，基本上就不会再被访问。但是出于合规性的要求，数据又不得不保留数十年之久。
Azure 存储有3种数据访问层：热，冷，归档的（创建时不可用），不同的层性能和费用都不同，对于活动数据我们当然会选择热访问层。但是费用也最贵。
同时，它只支持Blob和Storage V2，如果你的是V1，需要转换到V2。
另外在配置→性能处的高级选项（创建后不能修改）是没有这些层的选择，因为对于这个选择，我们的预期都是希望得到最高的性能。可以创建并用外部程序、脚本进行程序归档迁移到其他的storage account。
基于上面的情况，我们需要制定一个策略，把不常用的数据的访问层转换到冷，甚至归档的访问层，以便减少存储开销。同时又可以满足合规要求。
配置环境
首先创建一个Azure 存储“LifecycleLab”，由于公司使用的是ADLS ，也就是在创建时勾选了“层次结构命名空间”选项。
接下来创建一个容器来测试：
再添加目录：
然后上传一些文件来做测试，这个Lifecycle Management并不需要文件夹不为空。它实际上做的事情就是根据规则把选定的文件夹、文件的访问层进行变更。
初始化阶段，规则是空的，我们可以添加规则来创建自定义的策略。
规则范围的选择，会导致步骤的不同，如果将规则应用于所有blob，则不会出现第三步。
如果选择了使用筛选器限制blob则会出现第三步，配置筛选规则的筛选器集：
通常情况下，我们会选择使用筛选器限定blob，因为把整个blob进行操作并不是很现实。选择了之后，进入下一步也就是第二步，这里只能实现对“上次修改时间”进行操作：
还有一种额外的处理就是基于“上次访问时间”决定是否删除，不过再此之前，需要在lifecycle management的界面中启用访问跟踪，如下图：
启用之后就可以看到策略已经多了一个选择：
现在先不做太多复杂设置，还是保留默认设置。
我们可以看到可选项是移动到冷存储，移动到归档存储和删除，作为第一个规则，可以三选一：
但是一旦出现了多个规则，它的顺序就会定下来，顺序是冷→存档→删除。任何一个都可以向上（冷除外）或者向下（删除除外）移动：
随着规则的逐步指定，可选的内容就越来越少：
但是不管如何选择，都是不能自动回退到热的。
接下来就是对特定的blob进行设置，这里就体现出命名规则的重要性，合理的命名规则及数据归档，可以使得这些数据更容易被标识出来：
实操
接下来我们实际操作一下，把VID开头的文件进行处理：
0天之后，移到冷存储，1天后移到归档存储，2 天后删除：
设定文件的路径和前缀：
接下来就是等待触发，因为没法手动触发，需要等待可能24小时后才能看到：
经过一天后，检查结果，发现可以转换，由于存储费用有限，就步继续等了。
手动更改层：
可以在下图部分选择手动对文件的层进行调整。不过注意存档层到其他层是需要比较久时间并且所需费用很多。
