通过自动管理数据生命周期优化成本

Azure Blob 存储生命周期管理可提供基于规则的策略，用于将 blob 数据转移到适合的访问层，或将数据设置为在数据生命周期结束时过期。

利用生命周期管理策略，可以实现以下操作：

• 将一段时间内未访问或修改的 Blob 当前版本、Blob 旧版本和 Blob 快照转移到较冷的存储层，以便优化成本。
• 访问 blob 时，立即将 blob 从冷转换回热。
• 在生命周期结束时，删除 blob 的当前版本、旧版本或快照。
• 将规则应用于整个存储帐户、所选容器或 Blob 子集（使用名称前缀或 Blob 索引标记作为筛选器）。

生命周期管理策略支持块 Blob，并可在常规用途 v2、高级块 Blob 和 Blob 存储帐户中追加 Blob。 生命周期管理不会影响诸如 $logs 和 $web 之类的系统容器。

数据集具有独特的生命周期。 在生命周期的早期，人们经常访问某些数据。 但随着数据的老化，访问需求经常会急剧下降。 有些数据在云中持续处于空闲状态，并且在存储后很少被访问。 有些数据集在创建后的数日或者数月即会过期，还有一些数据集在其整个生存期会频繁受到读取和修改。

假设某个数据集在生命周期的早期阶段频繁被访问，而两周后只是偶尔被访问。 一个月以后，该数据集很少被访问。 在这种场景下，早期阶段最适合使用热存储。 在偶尔访问阶段最适合使用冷存储。 在一个月后数据陈旧时，存档存储便是最佳的层选项。 借助生命周期管理策略规则，根据数据存在时间将其移动到适当的存储层，即可根据需要设计成本最低的解决方案。

生命周期管理策略是 JSON 文档中的规则集合。 下方的 JSON 示例显示了完整的规则定义：

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

策略是规则的集合，如下表所述：

策略中的每个规则都拥有多个参数，如下表所述：

添加或编辑生命周期策略的规则时，更改最多可能需要在 24 小时后才会生效并开始首次执行。

活动策略会定期处理对象，但如果对策略进行了更改，则处理过程会被中断。 如果禁用策略，则不会计划任何新策略运行，但如果一个运行已正在进行，该运行将继续进行，直到运行完成，并且你需要为完成该运行所需的任何操作付费。 如果禁用或删除某个策略中的所有规则，则该策略将变为非活动状态，且不会计划任何新运行。

运行完成所需的时间取决于评估并操作的 blob 数。 如果存储帐户的请求速率接近存储帐户限制，则评估和操作 Blob 的延迟可能更长。 向存储帐户发出的所有请求（包括策略运行发出的请求）都会累积到相同的每秒请求数限制，并且随着该限制的临近，优先级将授予工作负载发出的请求。 若要请求增加帐户限制，请与 Azure 支持联系。

若要查看默认比例尺限制，请参阅以下文章：

• Blob 存储的可伸缩性和性能目标
• 标准存储帐户的可伸缩性和性能目标
• 高级块 blob 存储帐户的可伸缩性目标

策略中的每个规则定义都包括筛选器集和操作集。 筛选器集将规则操作限制为容器或对象名称中的某组对象。 操作集对筛选的对象集应用分层或删除操作。

以下示例规则将筛选帐户，以针对 sample-container 中存在的、以 blob1 开头的对象运行操作。

• 在上次修改后的 30 天后，将 Blob 分层到冷层
• 在上次修改后的 90 天后，将 Blob 分层到存档层
• 在上次修改后的 2,555 天（7 年）后，删除 Blob
• 在创建 90 天后删除以前的版本

{
  "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"
          ]
        }
      }
    }
  ]
}

筛选器将规则行为限制为存储帐户中的 Blob 子集。 如果定义了多个筛选器，将对所有筛选器运行逻辑 AND。 可以使用筛选器指定要包含的 Blob 对象。 筛选器不提供指定要排除的 Blob 的方法。

筛选器包括：

若要详细了解 Blob 索引功能以及已知问题和限制，请参阅通过 Blob 索引管理和查找 Azure Blob 存储上的数据。

满足运行条件时，操作会应用于筛选后的数据块。

生命周期管理支持对当前版本的分层和删除操作，并支持之前版本和 Blob 快照。 为每条规则至少定义一个操作。

¹ 仅当在 enableAutoTierToHotFromCool 运行条件下使用时，daysAfterLastAccessTimeGreaterThan 操作才可用。 下表中描述了该条件。

² 当应用于已启用分层命名空间的帐户时，delete 操作将删除空目录。 如果目录不为空，则 delete 操作会在第一个生命周期策略执行周期内删除满足策略条件的对象。 如果该操作产生的空目录也满足策略条件，则该目录将在下一个执行周期内被删除，依此类推。

³ 除非删除与当前版本 blob 关联的任何先前版本或快照，否则生命周期管理策略不会删除 blob 的当前版本。 如果存储帐户中的 blob 有以前的版本或快照，则在将 delete 操作指定为策略的一部分时，必须包含以前的版本和快照。

⁴ 只有为 LRS、GRS 或 RA-GRS 配置的存储帐户才支持将 Blob 移动到存档层。 ZRS、GZRS 或 RA-GZRS 帐户不支持存档层。 根据为帐户配置的冗余设置，此操作被列入。

运行条件基于期限。 为了跟踪陈旧程度，当前版本使用上次修改时间或上次访问时间，旧版本使用版本创建时间，blob 快照使用快照创建时间。

¹ 如果没有启用上次访问时间跟踪，则 daysAfterLastAccessTimeGreaterThan 将使用启用生命周期策略的日期，而不是使用 blob 的 属性。 当 LastAccessTime 属性为 null 值时，也将使用此日期。 有关使用上次访问时间跟踪的详细信息，请参阅基于上次访问时间移动数据。

在执行生命周期管理策略定义的操作时，会生成 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 事件的架构。

以下示例演示如何使用生命周期策略规则满足常见场景。

此示例演示如何转移前缀为 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 元数据和获取 Blob 标记不是访问操作，因此不会更新上次访问时间。

如果启用了上次访问时间跟踪，生命周期管理将使用 LastAccessTime 来确定是否满足运行条件 daysAfterLastAccessTimeGreaterThan。 在以下情况下，生命周期管理使用启用生命周期策略的日期，而非使用 LastAccessTime：

• Blob 的 LastAccessTime 属性值为 null 值。

  备注

  如果自启用上次访问时间跟踪后未访问某个 blob，则该 blob 的 lastAccessedOn 属性为 null。

• 未启用上次访问时间跟踪。

为了尽量减少对读取访问延迟的影响，只有最近 24 小时的第一次读取会更新最后访问时间。 同一个 24 小时期间内的后续读取不会更新上次访问时间。 如果 Blob 在两次读取之间被修改，则上次访问时间是两个值中的较新值。

在以下示例中，如果 Blob 在 30 天内未被访问，则会将其移到冷存储。 enableAutoTierToHotFromCool 属性是一个布尔值，用于指示当某个 Blob 在被分层到冷层后再次被访问时，是否应自动将其从冷层恢复到热层。

{
  "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
              }
          }
        }
      }
    }
  ]
}

某些数据预期在创建后的数日或数月内过期。 可以将生命周期管理策略配置为：根据数据陈旧程度删除数据，以使数据过期。 以下示例演示了一个策略，用于删除过去 365 天内尚未修改的所有块 Blob。

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

某些数据只有在明确标记为删除时才会过期。 你可以配置生命周期管理策略，使标记有 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 和页 Blob 进行分层。

• 必须完整读取或写入生命周期管理策略。 不支持部分更新。

• 每个规则最多可以有 10 个区分大小写的前缀和 10 个 Blob 索引标记条件。

• 生命周期管理策略不能用于将使用加密范围的 Blob 层更改为存档层。

• 生命周期管理策略的删除操作对不可变容器中的任何 blob 均不起作用。 通过不可变策略，可以创建和读取对象，但不能修改或删除对象。 有关详细信息，请参阅使用不可变的存储来存储业务关键型 Blob 数据。

请参阅生命周期管理常见问题解答。

• 配置生命周期管理策略
• Blob 数据的热访问层、冷访问层和存档访问层
• 通过 Blob 索引管理和查找 Azure Blob 存储上的数据
• 使用 blob 访问层的最佳做法