适用于迁移的 Microsoft Purview 备份和恢复最佳做法

本文提供有关组织在生产部署中具有 Microsoft Purview 统一数据治理解决方案 时的备份和恢复策略的指南。 还可以使用此一般准则来实现帐户迁移。 本文的范围是介绍 手动 BCDR 方法, 可在其中使用 API 自动执行。 预先考虑一些关键信息:

  • 不建议备份“已扫描”资产的详细信息。 应仅备份特选数据,例如资产上的分类和术语表的映射。 需要备份资产详细信息的唯一情况是通过自定义 拥有自定义 typeDef资产。

  • 备份的资产计数应小于 100,000 个资产。 main驱动因素是,必须使用搜索查询 API 来获取资产,其返回的资产限制为 100,000 个。 但是,如果能够对搜索查询进行分段,以便每个 API 调用获得较少的资产,则可以备份超过 100,000 个资产。

  • 目标是执行一次迁移。 如果要在两个帐户之间持续“同步”资产,本文不会详细介绍其他步骤。 必须使用 Microsoft Purview 的事件中心来订阅和创建另一个帐户的实体。 但是,事件中心仅包含 Atlas 信息。 Microsoft Purview 添加了其他功能,例如 术语表联系人 ,它们无法通过事件中心使用。

确定关键要求

大多数企业组织对 Microsoft Purview 具有备份、业务连续性和灾难恢复等功能的关键要求, (BCDR) 。 若要深入了解此要求,需要区分备份、高可用性 (HA) 和灾难恢复 (DR) 。

虽然它们类似,但 HA 会在出现硬件故障(例如)时保持服务正常运行,但如果有人意外或故意删除了数据库中的所有记录,HA 将无法保护你。 为此,可能需要从备份还原服务。

备份

可能需要从 Microsoft Purview 帐户创建定期备份,并在用户意外或故意从 Microsoft Purview 帐户中删除数据或配置片段时使用备份。

备份应允许从 Microsoft Purview 帐户保存以下配置的时间点副本:

  • 帐户信息 (,例如友好名称)
  • 集合结构和角色分配
  • 自定义扫描规则集、分类和分类规则
  • 已注册的数据源
  • 扫描信息
  • 创建和维护密钥保管库连接
  • Key Vault 连接和凭据以及与当前扫描的关系
  • 已注册的 SHIR
  • 术语表术语模板
  • 术语表术语
  • 手动资产更新 (包括分类和术语表分配)
  • ADF 和 Synapse 连接和世系

备份策略由还原策略决定,或者更具体地说,在发生灾难时还原内容需要多长时间。 若要回答这一问题,可能需要与受影响的利益干系人联系 (业务所有者) ,并了解所需的恢复目标是什么。

需要考虑三个main要求:

  • 恢复时间目标 (RTO) – 定义灾难后允许的最大停机时间,理想情况下系统应恢复运行。
  • 恢复点目标 (RPO) – 定义灾难后可接受的数据丢失量。 通常,RPO 以小时或分钟为单位的时间范围表示。
  • 恢复级别对象 (RLO) – 定义要还原的数据的粒度。 它可以是 SQL Server、一组数据库、表、记录等。

高可用性

在计算中,术语可用性用于描述服务可用的时间段,以及系统响应用户发出的请求所需的时间。 对于 Microsoft Purview,高可用性意味着确保 Microsoft Purview 实例在云区域中的数据中心或单个区域存在本地问题时可用。

测量可用性

可用性通常以百分比表示,指示特定系统或组件在给定时间段内预期的运行时间,其中值 100% 表示系统永远不会发生故障。

这些值根据多个因素计算,包括计划维护期和计划外维护期,以及从可能的系统故障中恢复的时间。

注意

Azure 数据中心中断很少,但可能会持续几分钟到几小时。 有关 Microsoft Purview 可用性的信息,请参阅 Microsoft Purview 的 SLA。 Microsoft Purview 可确保不会丢失数据,但从中断中恢复可能需要重启工作流(例如扫描)。

弹性

系统从故障中恢复并继续运行的能力。 它不是关于避免故障,而是以避免停机或数据丢失的方式响应故障。

业务连续性

业务连续性意味着在发生灾难时继续业务、规划恢复并确保数据映射高度可用。

灾难恢复

组织需要为其 Microsoft Purview 实例提供故障转移机制,因此,当主要区域遇到地震或洪水等灾难性事件时,企业必须做好让系统在其他位置联机的准备。

注意

并非所有 Azure 镜像区域都支持部署 Microsoft Purview 帐户。 例如,对于 DR 方案,如果主要区域是加拿大中部,则不能选择在加拿大东部部署新的 Microsoft Purview 帐户。 即使使用客户管理的 DR,并非所有客户都能够触发 DR。

Implementation steps

本部分提供有关使用 Microsoft Purview 治理门户或 REST API 跨区域或订阅复制资产、术语表、分类 & 关系所需的任务的高级指导。 方法是尽可能以编程方式大规模执行任务。

高级任务大纲

  1. 创建新帐户
  2. 迁移配置项目
  3. 运行扫描
  4. 迁移自定义 typedefs 和自定义资产
  5. 迁移关系
  6. 迁移术语表术语
  7. 将分类分配给资产
  8. 将联系人分配到资产

创建新帐户

需要按照以下说明创建新的 Microsoft Purview 帐户:

提前规划以后无法更改的配置项目至关重要:

  • 帐户名
  • 地区
  • 订阅
  • 管理资源组名称

迁移配置项目

以下步骤指的是 Microsoft Purview API 文档 ,以便你可以以编程方式快速建立备份帐户:

任务 说明
帐户信息 通过向管理员和/或服务主体授予对根级别帐户的访问权限来维护帐户信息
集合 创建和维护集合以及源与集合的关联。 可以调用列表集合 API,然后通过获取集合 API 获取每个集合的特定详细信息
扫描规则集 创建和维护自定义扫描规则集。 需要调用列出所有自定义扫描规则集 API,并通过调用获取扫描规则集 API 获取详细信息
手动分类 通过调用获取分类 API 获取所有手动分类的列表,并获取每个分类的详细信息
资源集规则 创建和维护资源集规则。 可以调用 获取资源集规则 API 以获取规则详细信息
数据源 调用 获取所有数据源 API 以列出包含详细信息的数据源。 还必须通过调用 获取触发器 API 来获取触发器。 如果需要在新帐户中批量重新创建源,还可以使用 创建数据源 API
凭据 创建和维护扫描时使用的凭据。 没有用于提取凭据的 API,因此必须在新帐户中重新执行此操作。
自承载集成运行时 (SHIR) 获取 SHIR 列表并从新帐户获取更新的密钥,然后更新 SHIR。 必须在 SHIR 的主机中手动完成此操作。 在创建扫描之前,需要运行这些。
ADF 连接 目前,ADF 一次可以连接到一个 Microsoft Purview。 必须断开 ADF 与失败的 Microsoft Purview 帐户的连接,然后将其重新连接到新帐户。

运行扫描

重要

在创建扫描之前,请确保自承载集成运行时已配置且正在运行且可用。

这将使用默认 typedef填充所有资产。 与导出现有资产和导入到新帐户,有几个原因需要再次运行扫描:

  • 从搜索查询返回的资产限制为 100,000 个,用于导出资产。

  • 导出具有关系的资产很麻烦。

  • 重新运行扫描时,你将获得最新的所有关系和资产详细信息。

  • Microsoft Purview 定期推出新功能,因此你可以在运行新扫描时从其他功能中受益。

运行扫描是获取 Microsoft Purview 已支持的所有数据源资产的最有效方法。

迁移自定义 typedefs 和自定义资产

自定义 typedefs

若要标识所有自定义 typedef,可以使用 获取所有类型定义 API。 这将返回每种类型。 你需要以以下格式标识自定义类型: "serviceType": "<custom_typedef>"

自定义资产

若要导出自定义资产,可以搜索这些自定义资产,并通过发现 API 传递适当的自定义typedef

注意

每个搜索结果有 100,000 个返回限制。 可能需要中断搜索查询,使其不会返回超过 100,000 条记录。

可通过多种方式缩小搜索查询的范围以获取资产的子集:

  • 使用 Keyword:传递父 FQN,例如 Keyword: "<Parent String>/*"

  • 使用 Filter:在 assetType 搜索中包含特定自定义项 typedef ,例如 "assetType": "<custom_typedef>"

下面是搜索有效负载的示例,它通过自定义 keywords ,以便仅返回特定存储帐户中的资产 (exampleaccount) :

{
  "keywords": "adl://exampleaccount.azuredatalakestore.net/*",
  "filter": {
    "and": [
      {
        "not": {
          "or": [
            {
              "attributeName": "size",
              "operator": "eq",
              "attributeValue": 0
            },
            {
              "attributeName": "fileSize",
              "operator": "eq",
              "attributeValue": 0
            }
          ]
        }
      },
      {
        "not": {
          "classification": "MICROSOFT.SYSTEM.TEMP_FILE"
        }
      },
      {
        "not": {
          "or": [
            {
              "entityType": "AtlasGlossaryTerm"
            },
            {
              "entityType": "AtlasGlossary"
            }
          ]
        }
      }
    ]
  },
  "limit": 10,
  "offset": 0,
  "facets": [
    {
      "facet": "assetType",
      "count": 0,
      "sort": {
        "count": "desc"
      }
    },
    {
      "facet": "classification",
      "count": 10,
      "sort": {
        "count": "desc"
      }
    },
    {
      "facet": "contactId",
      "count": 10,
      "sort": {
        "count": "desc"
      }
    },
    {
      "facet": "label",
      "count": 10,
      "sort": {
        "count": "desc"
      }
    },
    {
      "facet": "term",
      "count": 10,
      "sort": {
        "count": "desc"
      }
    }
  ]
}

返回的资产将具有一些可提取详细信息的键/对值:

{
    "referredEntities": {},
    "entity": {
    "typeName": "column",
    "attributes": {
        "owner": null,
        "qualifiedName": "adl://exampleaccount.azuredatalakestore.net/123/1/DP_TFS/CBT/Extensions/DTTP.targets#:xml/Project/Target/XmlPeek/@XmlInputPath",
        "name": "~XmlInputPath",
        "description": null,
        "type": "string"
    },
    "guid": "5cf8a9e5-c9fd-abe0-2e8c-d40024263dcb",
    "status": "ACTIVE",
    "createdBy": "ExampleCreator",
    "updatedBy": "ExampleUpdator",
    "createTime": 1553072455110,
    "updateTime": 1553072455110,
    "version": 0,
    "relationshipAttributes": {
        "schema": [],
        "inputToProcesses": [],
        "composeSchema": {
        "guid": "cc6652ae-dc6d-90c9-1899-252eabc0e929",
        "typeName": "tabular_schema",
        "displayText": "tabular_schema",
        "relationshipGuid": "5a4510d4-57d0-467c-888f-4b61df42702b",
        "relationshipStatus": "ACTIVE",
        "relationshipAttributes": {
            "typeName": "tabular_schema_columns"
        }
        },
        "meanings": [],
        "outputFromProcesses": [],
        "tabular_schema": null
    },
    "classifications": [
        {
        "typeName": "MICROSOFT.PERSONAL.EMAIL",
        "lastModifiedTS": "1",
        "entityGuid": "f6095442-f289-44cf-ae56-47f6f6f6000c",
        "entityStatus": "ACTIVE"
        }
    ],
    "contacts": {
        "Expert": [
        {
            "id": "30435ff9-9b96-44af-a5a9-e05c8b1ae2df",
            "info": "Example Expert Info"
        }
        ],
        "Owner": [
        {
            "id": "30435ff9-9b96-44af-a5a9-e05c8b1ae2df",
            "info": "Example Owner Info"
        }
        ]
    }
    }
}

注意

还需要从 typedef 输出中迁移术语模板。

重新创建自定义实体时,可能需要在发送到 API 之前准备有效负载:

注意

初始目标是迁移没有任何关系或映射的所有实体。 这将避免潜在的错误。

  • 所有 timestamp 值都必须为 null,例如 updateTimeupdateTimelastModifiedTS

  • 无法像以前一样重新生成 , guid 因此必须传入负整数(例如“-5000”)以避免错误。

  • relationshipAttributes的内容不应是有效负载的一部分,以避免错误,因为 可能guids未相同或尚未创建。 在提交有效负载之前,必须转换为 relationshipAttributes 空数组。

    • meanings 包含所有术语表映射,这些映射将在创建实体后批量更新。
  • 同样, classifications 在提交有效负载以创建实体时,也需要是空数组,因为稍后必须使用其他 API 创建到批量实体的分类映射。

迁移关系

若要完成资产迁移,必须重新映射关系。 有三个任务:

  1. 调用 关系 API ,通过它获取实体之间的关系信息 guid

  2. 准备关系有效负载,以便旧 Microsoft Purview 帐户中不会硬引用旧 guids 帐户。 需要将这些 guids 更新到新帐户的 guids

  3. 最后, 在实体之间创建新关系

迁移术语表术语

注意

迁移术语之前,需要迁移术语模板。 自定义 typedef 迁移中应已介绍此步骤。

使用 Microsoft Purview 治理门户

迁移术语表术语的最快方法是将 术语导出到 .csv 文件。 可以使用 Microsoft Purview 治理门户执行此操作。

使用 Microsoft Purview API

若要自动迁移术语表,首先需要通过列表术语表 API 获取术语表 guid (glossaryGuid) 。 glossaryGuid是顶级/根级别的术语表guid

下面的示例响应将提供 guid 用于后续 API 调用的 :

"guid": "c018ddaf-7c21-4b37-a838-dae5f110c3d8"

获得 后, glossaryGuid可以通过两个步骤开始迁移条款:

  1. 将术语表术语导出为 .csv

  2. 通过 .csv导入术语表术语

将分类分配给资产

注意

此步骤的先决条件是让所有分类在 迁移配置项目 步骤中的新帐户中可用。

必须调用 发现 API 才能获取资产的分类分配。 这适用于所有资产。 如果已迁移自定义资产,则有关分类分配的信息已在 属性中 classifications 提供。 获取分类的另一种方法是在旧帐户中列出每个guid分类

若要将分类分配给资产,需要通过 API 批量将分类关联到多个实体

将联系人分配到资产

如果已从前面的步骤中提取资产信息,则 可从发现 API 获取联系人详细信息。

若要将联系人分配到资产,需要列出 guids 并标识所有 objectid 联系人。 可以使用创建或更新实体 API 循环访问所有资产并将联系人重新分配到所有资产,从而自动执行此过程

后续步骤