通过自动管理数据生命周期优化成本
Azure Blob 存储生命周期管理可提供基于规则的策略，用于将 blob 数据转移到适合的访问层，或将数据设置为在数据生命周期结束时过期。
利用生命周期管理策略，可以实现以下操作：
- 将一段时间内未访问或修改的 Blob 当前版本、Blob 旧版本和 Blob 快照转移到较冷的存储层，以便优化成本。
- 即时将所访问的 Blob 从冷层转移回热层。
- 在其周期结束时，删除 blob 当前版本、blob 旧版本或 blob 快照。
- 将规则应用于整个存储帐户、所选容器或 Blob 子集（使用名称前缀或 Blob 索引标记作为筛选器）。
生命周期管理策略支持块 Blob，并可在常规用途 v2、高级块 Blob 和 Blob 存储帐户中追加 Blob。 生命周期管理不会影响诸如 $logs 和 $web 之类的系统容器。
重要
如需将数据集设置为可读，则请不要设置将 Blob 移动到存档层的策略。 除非 Blob 是首个解除冻结对象，否则无法读取存档层中的 Blob，且这一过程可能既耗时又昂贵。 有关详细信息，请参阅存档层中的 blob 解除冻结概述。 如果需要经常读取数据集，请不要设置将 Blob 移动到冷层的策略，因为这可能会增加事务成本。
通过管理数据生命周期来优化成本
数据集具有独特的生命周期。 在生命周期的早期，人们经常访问某些数据。 但随着数据的老化，访问需求经常会急剧下降。 有些数据在云中持续处于空闲状态，并且在存储后很少被访问。 有些数据集在创建后的数日或者数月即会过期，还有一些数据集在其整个生存期会频繁受到读取和修改。
假设某个数据集在生命周期的早期阶段频繁被访问，而两周后只是偶尔被访问。 一个月以后，该数据集很少被访问。 在这种场景下，早期阶段最适合使用热存储。 在偶尔访问阶段最适合使用冷存储。 在一个月后数据陈旧时，存档存储便是最佳的层选项。 借助生命周期管理策略规则，根据数据存在时间将其移动到适当的存储层，即可根据需要设计成本最低的解决方案。
生命周期管理策略定义
生命周期管理策略是 JSON 文档中的规则集合。 下方的 JSON 示例显示了完整的规则定义：
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
策略是规则的集合，如下表所述：
| 参数名称 | 参数类型 | 注释 |
|---|---|---|
rules |
规则对象的数组 | 一个策略至少需要包含一个规则。 最多可在一个策略中定义 100 个规则。 |
策略中的每个规则都拥有多个参数，如下表所述：
| 参数名称 | 参数类型 | 注释 | 必须 |
|---|---|---|---|
name |
String | 规则名称最多只能包含 256 个字母数字字符。 规则名称区分大小写。 该名称必须在策略中唯一。 | True |
enabled |
布尔 | 一个允许暂时禁用规则的可选布尔值。 如果未设置，则默认值为 true。 | False |
type |
枚举值 | 当前的有效类型为 Lifecycle。 |
True |
definition |
定义生命周期规则的对象 | 每个定义均由筛选器集和操作集组成。 | True |
生命周期管理规则定义
策略中的每个规则定义都包括筛选器集和操作集。 筛选器集将规则操作限制为容器或对象名称中的某组对象。 操作集对筛选的对象集应用分层或删除操作。
示例规则
以下示例规则将筛选帐户，以针对 sample-container 中存在的、以 blob1 开头的对象运行操作。
- 在上次修改后的 30 天后，将 Blob 分层到冷层
- 在上次修改后的 90 天后，将 Blob 分层到存档层
- 在上次修改后的 2,555 天（7 年）后，删除 Blob
- 在创建 90 天后删除以前的 Blob 版本
{
"rules": [
{
"enabled": true,
"name": "sample-rule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"delete": {
"daysAfterCreationGreaterThan": 90
}
},
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
},
"tierToArchive": {
"daysAfterModificationGreaterThan": 90,
"daysAfterLastTierChangeGreaterThan": 7
},
"delete": {
"daysAfterModificationGreaterThan": 2555
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"sample-container/blob1"
]
}
}
}
]
}
注意
生命周期管理策略中的 baseBlob 元素是指 blob 的当前版本。 Version 元素引用以前的版本。
规则筛选器
筛选器将规则操作限制为存储帐户中的 Blob子集。 如果定义了多个筛选器，将对所有筛选器运行逻辑 AND。 可以使用筛选器指定要包含的 Blob。 筛选器不提供指定要排除的 Blob 的方法。
筛选器包括：
| 筛选器名称 | 筛选器类型 | 注释 | 是否必需 |
|---|---|---|---|
| blobTypes | 预定义枚举值的数组。 | 当前版本支持 blockBlob 和 appendBlob。 appendBlob 仅支持“删除”操作，不支持“设置层级”。 |
是 |
| prefixMatch | 要匹配的前缀字符串数组。 每个规则最多可定义 10 个区分大小写的前缀。 前缀字符串必须以容器名称开头。 例如，如果要匹配 https://myaccount.blob.core.chinacloudapi.cn/sample-container/blob1/... 下的所有 Blob，请将 prefixMatch 指定为 sample-container/blob1。 此筛选器将匹配 sample-container 中名称以 blob1 开头的所有 Blob。。 |
如果未定义 prefixMatch，规则将应用到存储帐户中的所有 Blob。 前缀字符串不支持通配符匹配。 * 和 ? 等字符被视为字符串字面量。 |
否 |
| blobIndexMatch | 由要匹配的 Blob 索引标记键和值条件组成的字典值数组。 每个规则最多可以定义 10 个 Blob 索引标记条件。 例如，对于某个规则，如果要匹配 https://myaccount.blob.core.chinacloudapi.cn/ 下 Project = Contoso 的所有 Blob，则 blobIndexMatch 为 {"name": "Project","op": "==","value": "Contoso"}。 |
如果未定义 blobIndexMatch，则规则将应用于存储帐户中的所有 Blob。 | 否 |
若要详细了解 Blob 索引功能以及已知问题和限制，请参阅通过 Blob 索引管理和查找 Azure Blob 存储上的数据。
规则操作
满足运行条件时，操作将应用到筛选的 Blob。
生命周期管理支持对 Blob 当前版本的分层和删除操作，并支持早期 Blob 版本和 Blob 快照。 为每条规则至少定义一个操作。
注意
高级块 blob 存储帐户尚不支持分层。 对于所有其他帐户，仅允许在块 blob 上进行分层，而不允许在追加和页 blob 上分层。
| 操作 | 当前版本 | 快照 | 早期版本 |
|---|---|---|---|
| tierToCool | 对 blockBlob 支持 |
支持 | 支持 |
| tierToCold | 对 blockBlob 支持 |
支持 | 支持 |
| enableAutoTierToHotFromCool1 | 对 blockBlob 支持 |
不支持 | 不支持 |
| tierToArchive4 | 对 blockBlob 支持 |
支持 | 支持 |
| delete2、3 | 支持 blockBlob 和 appendBlob |
支持 | 支持 |
1 仅当在 daysAfterLastAccessTimeGreaterThan 运行条件下使用时，enableAutoTierToHotFromCool 操作才可用。 下表中描述了该条件。
2 当应用于已启用分层命名空间的帐户时，delete 操作将删除空目录。 如果目录不为空，则 delete 操作会在第一个生命周期策略执行周期内删除满足策略条件的对象。 如果该操作产生的空目录也满足策略条件，则该目录将在下一个执行周期内被删除，依此类推。
3 除非删除与当前版本 blob 关联的任何先前版本或快照，否则生命周期管理策略不会删除 blob 的当前版本。 如果存储帐户中的 blob 有以前的版本或快照，则在将 delete 操作指定为策略的一部分时，必须包含以前的版本和快照。
4 只有为 LRS、GRS 或 RA-GRS 配置的存储帐户才支持将 Blob 移动到存档层。 ZRS、GZRS 或 RA-GZRS 帐户不支持存档层。 此操作根据为帐户配置的冗余列出。
注意
如果在同一 Blob 中定义了多个操作，生命周期管理将对该 Blob 应用开销最低的操作。 例如，操作 delete 的开销比 tierToArchive 更低。 操作 tierToArchive 的开销比 tierToCool 更低。
运行条件基于期限。 为了跟踪陈旧程度，当前版本使用上次修改时间或上次访问时间，旧版本使用版本创建时间，blob 快照使用快照创建时间。
| 操作运行条件 | 条件值 | 说明 |
|---|---|---|
| daysAfterModificationGreaterThan | 指示陈旧程度（天）的整数值 | 对 blob 的当前版本执行操作的条件 |
| daysAfterCreationGreaterThan | 指示陈旧程度（天）的整数值 | 对当前版本或先前版本的 blob 或 blob 快照执行操作的条件 |
| daysAfterLastAccessTimeGreaterThan1 | 指示陈旧程度（天）的整数值 | 启用访问跟踪时 Blob 当前版本的条件 |
| daysAfterLastTierChangeGreaterThan | 整数值，指示自上次 blob 层更改时间后的天数 | 解除冻结的 blob 在返回到存档层之前在热、冷或寒层中保留的最短持续时间（以天为单位）。 此条件仅适用于 tierToArchive 操作。 |
1 如果没有启用上次访问时间跟踪，则 daysAfterLastAccessTimeGreaterThan 将使用启用生命周期策略的日期，而不是使用 blob 的 LastAccessTime 属性。 当 LastAccessTime 属性为 null 值时，也将使用此日期。 有关使用上次访问时间跟踪的详细信息，请参阅基于上次访问时间移动数据。
生命周期策略运行
添加或编辑生命周期策略的规则时，更改最多可能需要在 24 小时后才会生效并开始首次执行。
活动策略会持续处理对象，如果对策略进行更改，则处理会中断。 如果编辑、删除或禁用规则，则该策略的执行在 15 分钟内终止，并在 24 小时内再次重启并更新规则。 如果禁用或删除某个策略中的所有规则，则该策略将变为非活动状态，且不会计划任何新运行。
完成运行所需的时间取决于评估和操作的 Blob 数量。 如果存储帐户的请求速率接近存储帐户限制，则评估和操作 Blob 的延迟可能更长。 向存储帐户发出的所有请求（包括策略运行发出的请求）都会累积到相同的每秒请求数限制，并且随着该限制的临近，优先级将授予工作负载发出的请求。 若要请求增加帐户限制，请与 Azure 支持联系。
若要查看默认调整限制，请参阅以下文章：
生命周期策略完成事件
在执行生命周期管理策略定义的操作时，会生成 LifecyclePolicyCompleted 事件。 策略定义中包含的每个操作都会显示摘要部分。 以下 json 显示了策略的示例 LifecyclePolicyCompleted 事件。 由于策略定义包含 delete、tierToCool、tierToCold 和 tierToArchive 操作，因此每个操作都会出现一个摘要部分。
{
"topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
"subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
"eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
"eventTime": "2022-05-26T00:00:40.1880331",
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"data": {
"scheduleTime": "2022/05/24 22:57:29.3260160",
"deleteSummary": {
"totalObjectsCount": 16,
"successCount": 14,
"errorList": ""
},
"tierToCoolSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToColdSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToArchiveSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
}
},
"dataVersion": "1",
"metadataVersion": "1"
}
下表描述了 LifecyclePolicyCompleted 事件的架构。
| 字段 | 类型 | 说明 |
|---|---|---|
| scheduleTime | 字符串 | 计划生命周期策略的时间 |
| deleteSummary | vector<byte> | 计划用于 delete 操作的 blob 的结果摘要 |
| tierToCoolSummary | vector<byte> | 计划用于 tier-to-cool 操作的 blob 的结果摘要 |
| tierToColdSummary | vector<byte> | 计划用于 tier-to-cold 操作的 blob 的结果摘要 |
| tierToArchiveSummary | vector<byte> | 计划用于 tier-to-archive 操作的 blob 的结果摘要 |
生命周期策略示例
以下示例演示如何使用生命周期策略规则满足常见场景。
将陈旧的数据移到冷层
此示例演示如何转移前缀为 sample-container/blob1 或 container2/blob2 的块 Blob。 该策略将 30 天以上未修改的 Blob 转移到冷存储，并将 90 天未修改的 Blob 转移到存档层：
{
"rules": [
{
"name": "agingRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
},
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 90 }
}
}
}
}
]
}
基于上次访问时间移动数据
可以启用“上次访问时间跟踪”，以记录 Blob 上次读取或写入的时间，并将该功能用作筛选器，管理 Blob 数据的分层和保留。 若要了解如何启用“上次访问时间跟踪”，请参阅启用访问时间跟踪（可选）。
启用上次访问时间跟踪后，在读取或写入 Blob 时会更新名为 LastAccessTime 的 Blob 属性。 获取 Blob 操作被视为访问操作。 获取 Blob 属性、获取 Blob 元数据和获取 Blob 标记不是访问操作，因此不会更新上次访问时间。
如果启用了上次访问时间跟踪，则生命周期管理将使用 LastAccessTime 来确定是否满足运行条件 daysAfterLastAccessTimeGreaterThan。 在以下情况下，生命周期管理使用启用生命周期策略的日期，而非使用 LastAccessTime：
Blob 的
LastAccessTime属性值为 null 值。注意
如果自启用上次访问时间跟踪后未访问某个 blob，则该 blob 的
lastAccessedOn属性为 null。未启用上次访问时间跟踪。
为了尽量减少对读取访问延迟的影响，只有最近 24 小时的第一次读取会更新最后访问时间。 同一个 24 小时期间内的后续读取不会更新上次访问时间。 如果 Blob 在两次读取之间被修改，则上次访问时间是两个值中的较新值。
在以下示例中，如果 Blob 在 30 天内未被访问，则会将其移到冷存储。 enableAutoTierToHotFromCool 属性是一个布尔值，用于指示当某个 Blob 在被分层到冷层后再次被访问时，是否应自动将其从冷层恢复到热层。
提示
如果一个 Blob 移动到冷层，然后在 30 天内自动移回，则将收取提前删除费用。 在设置 enablAutoTierToHotFromCool 属性之前，确保分析数据的访问模式，以便降低意外费用。
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
引入数据后对其进行存档
某些数据在云中处于空闲状态，并且很少（如果有）被访问。 以下生命周期策略已配置为在引入数据后立即对其进行存档。 此示例将容器中名为 archivecontainer 的块 Blob 转换为存档层。 通过在上次修改时间后 0 天对 blob 执行操作来完成转换。
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
注意
Azure 建议直接将 Blob 上传到存档层，以提高效率。 可以在 放置 Blob或 放置块列表操作内的“x-ms-access-tier”标头中指定存档层。 REST 版本 2018-11-09 及更高版本，或最新的 Blob 存储客户端库支持“x-ms-access-tier”标头。
基于陈旧程度使数据过期
某些数据预期在创建后的数日或数月内过期。 可以将生命周期管理策略配置为：根据数据陈旧程度删除数据，以使数据过期。 以下示例显示了一个策略，该策略删除过去 365 天内未修改的所有块 Blob。
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
删除带 Blob 索引标记的数据
某些数据只有在明确标记为删除时才会过期。 你可以配置生命周期管理策略，使标记有 Blob 索引键/值属性的数据过期。 以下示例中演示的策略会删除标有 Project = Contoso 的所有块 Blob。 若要详细了解 Blob 索引，请参阅通过 Blob 索引管理和查找 Azure Blob 存储上的数据。
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
管理旧版本
对于在其整个生存期内定期修改和访问的数据，你可以启用 Blob 存储版本控制来自动维护对象的早期版本。 你可以创建策略，对早期版本进行分层或删除。 可通过评估版本创建时间来确定版本的陈旧程度。 此策略规则将容器 activedata 中版本创建时间至少为 90 天的早期版本移动到冷层，并删除版本创建时间至少为 365 天的早期版本。
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
区域可用性和定价
生命周期管理功能在所有 Azure 区域中均可用。
生命周期管理策略不收取费用。 不过客户需要支付设置 Blob 层 API 调用的标准操作成本费用， 而删除操作亦不会收取费用。 但是，其他 Azure 服务和实用工具可能会对通过生命周期策略进行管理的操作收费。
需要在其他操作类别下支付每次 Blob 的“上次访问时间”更新所需的费用。 每次“上次访问时间”更新都会作为“其他事务”被收取费用，24 小时内最多对每个对象收取一次费用，即使它在一天内被访问了 1000 次。 这与读取事务费用是分开的。
有关定价的详细信息，请参阅块 Blob 定价。
已知问题和限制
高级块 blob 存储帐户尚不支持分层。 对于所有其他帐户，仅允许在块 blob 上进行分层，而不允许在追加和页 blob 上分层。
必须完整读取或写入生命周期管理策略。 不支持部分更新。
每个规则最多可以有 10 个区分大小写的前缀和 10 个 Blob 索引标记条件。
生命周期管理策略无法更改使用加密范围的 Blob 层。
生命周期管理策略的删除操作不适用于不可变容器中的任何 Blob。 通过不可变策略，可以创建和读取对象，但不能修改或删除对象。 有关详细信息，请参阅使用不可变的存储来存储业务关键型 Blob 数据。
常见问题 (FAQ)
请参阅生命周期管理常见问题解答。