Microsoft Purview 灾难恢复和迁移最佳做法

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

Azure 数据中心中断很少,但可能会持续几分钟到几小时。 数据中心中断可能会导致数据治理所依赖的环境中断。 按照本文中详述的步骤操作,可以在 Microsoft Purview 帐户的主要区域发生数据中心中断时继续管理数据。

提示

有关 Microsoft Purview 可靠性的详细信息,请参阅 可靠性文档。

实现 Microsoft Purview 的业务连续性

业务连续性和灾难恢复 (BCDR) Microsoft Purview 实例是指使企业能够保护数据丢失并在出现中断时继续运营的机制、策略和过程,尤其是扫描层、目录层和见解层。 本页介绍如何为 Microsoft Purview 配置灾难恢复环境。

目前,Microsoft Purview 不支持自动 BCDR。 在添加支持之前,你负责处理备份和还原活动。 可以手动创建辅助 Microsoft Purview 帐户作为另一个区域中的暖备用实例。

以下步骤总结了如何手动实现灾难恢复:

  1. 创建主要Microsoft Purview 帐户后,请在单独的区域中创建一个或多个辅助Microsoft Purview 帐户。

    重要

    Microsoft Purview 目前支持每个租户单个Microsoft Purview 实例。 若要创建用于备份和灾难恢复的第二个帐户, 请联系支持人员

  2. 在主要 Microsoft Purview 帐户上执行的所有活动也必须在辅助 Microsoft Purview 帐户上执行。 这包括:

    • 维护帐户信息
    • 创建和维护自定义扫描规则集、分类和分类规则
    • 注册和扫描源
    • 创建和维护集合以及源与集合的关联
    • 创建和维护扫描时使用的凭据
    • 策展数据资产
    • 创建和维护术语表术语

本文稍后提供了创建和维护灾难恢复帐户的具体步骤。 在遵循它们之前,请通读限制和注意事项。

限制和注意事项

创建手动 BCDR 计划时,请记住以下几点:

  • 你将为主要和辅助Microsoft Purview 实例付费。

  • 如果适用,无法将主要和辅助 Microsoft Purview 帐户配置为同一Azure 数据工厂 Azure Data Share 和 Synapse Analytics 帐户。 因此,Azure 数据工厂 和 Azure Data Share 的世系无法在辅助 Microsoft Purview 帐户中看到。 当支持自动 BCDR 时,将解决此限制。

  • 集成运行时特定于 Microsoft Purview 帐户。 因此,扫描需要在主要和辅助Microsoft Purview 帐户中并行运行,必须维护多个自承载集成运行时。 当支持自动 BCDR 时,也会解决此限制。

  • 在同一源上并行执行主要和辅助Microsoft Purview 帐户的扫描可能会影响源的性能。 这可能会导致扫描持续时间因 Microsoft Purview 帐户而异。

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

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

  • 如果要在两个帐户之间持续“同步”资产,本文中未详细介绍其他步骤。 必须使用 Microsoft Purview 的事件中心来订阅和创建另一个帐户的实体。 但是,事件中心仅包含 Atlas 信息。 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 定期推出新功能,因此在运行新扫描时可以从其他功能中受益。

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

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

如果组织 已在 Microsoft Purview 中创建自定义类型,则需要手动迁移这些类型。

自定义 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 循环访问所有资产并将联系人重新分配到所有资产,从而自动执行此过程。