通过自动管理数据生命周期优化成本
数据集具有独特的生命周期。 在生命周期的早期,人们经常访问某些数据。 但随着数据的老化,访问需求经常会急剧下降。 有些数据在云中持续处于空闲状态,并且在存储后很少被访问。 有些数据集在创建后的数日或者数月即会过期,还有一些数据集在其整个生存期会频繁受到读取和修改。 Azure Blob 存储生命周期管理可提供基于规则的策略,用于将 blob 数据转移到适合的访问层,或将数据设置为在数据生命周期结束时过期。
注意
每次“上次访问时间”更新都会作为“其他事务”被收取费用,24 小时内最多对每个对象收取一次费用,即使它在一天内被访问了 1000 次。 这与读取事务费用是分开的。
利用生命周期管理策略,可以实现以下操作:
- 即时将所访问的 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 层更改时间后的天数 | 此条件仅适用于 tierToArchive 操作,并且只能与 daysAfterModificationGreaterThan 条件一起使用。 |
1 如果没有启用上次访问时间跟踪,则 daysAfterLastAccessTimeGreaterThan 将使用启用生命周期策略的日期,而不是使用 blob 的 LastAccessTime
属性。 当 LastAccessTime
属性为 null 值时,也将使用此日期。 有关使用上次访问时间跟踪的详细信息,请参阅基于上次访问时间移动数据。
生命周期策略运行
平台每天运行一次生命周期策略。 配置或编辑生命周期策略时,更改最多可能需要在 24 小时后才会生效并开始首次执行。 完成策略操作所需的时间取决于评估和操作的 Blob 数量。
如果禁用策略,则不会计划任何新策略运行,但如果一个运行已正在进行,该运行将继续进行,直到运行完成,并且你需要为完成该运行所需的任何操作付费。 请参阅区域可用性和定价。
生命周期策略完成事件
在执行生命周期管理策略定义的操作时,会生成 LifecyclePolicyCompleted
事件。 以下 JSON 演示了一个示例 LifecyclePolicyCompleted
事件。
{
"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": ""
},
"tierToArchiveSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
}
},
"dataVersion": "1",
"metadataVersion": "1"
}
下表描述了 LifecyclePolicyCompleted
事件的架构。
字段 | 类型 | 说明 |
---|---|---|
scheduleTime | 字符串 | 计划生命周期策略的时间 |
deleteSummary | vector<byte> | 计划用于 delete 操作的 blob 的结果摘要 |
tierToCoolSummary | vector<byte> | 计划用于 tier-to-cool 操作的 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 的
LastAccessTime
属性为 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 的“上次访问时间”更新所需的费用。
有关定价的详细信息,请参阅块 Blob 定价。
已知问题和限制
高级块 blob 存储帐户尚不支持分层。 对于所有其他帐户,仅允许在块 blob 上进行分层,而不允许在追加和页 blob 上分层。
必须完整读取或写入生命周期管理策略。 不支持部分更新。
每个规则最多可以有 10 个区分大小写的前缀和 10 个 Blob 索引标记条件。
如果为存储帐户启用了防火墙规则,生命周期管理请求可能会被阻止。 可以通过针对受信任的 Microsoft 服务提供例外来取消阻止这些请求。 有关详细信息,请参阅“配置防火墙和虚拟网络”中的“例外”部分。
生命周期管理策略无法更改使用加密范围的 Blob 层。
生命周期管理策略的删除操作不适用于不可变容器中的任何 Blob。 通过不可变策略,可以创建和读取对象,但不能修改或删除对象。 有关详细信息,请参阅使用不可变的存储来存储业务关键型 Blob 数据。
常见问题 (FAQ)
请参阅生命周期管理常见问题解答。