Microsoft Purview (先前Azure Purview) 部署最佳做法

本文是成功將 Microsoft Purview (先前Azure Purview) 部署到數據資產生產環境的指南。 它旨在協助您制定部署策略並逐步進行，從研究到強化生產環境，最好與我們的 部署檢查清單搭配使用。

如果您正在尋找嚴格的技術部署指南，請使用 部署檢查清單。

如果您要建立部署 Microsoft Purview 的計劃，並想要在開發部署策略時考慮最佳做法，請遵循下列文章。 本指南概述工作可以在一個月或更長時間內分階段完成，以開發 Microsoft Purview 的部署程式。 即使是已部署 Microsoft Purview 的組織，也可以使用本指南來確保他們充分利用其投資。

精心規劃的治理平台部署可以提供下列優點：

• 更好的資料探索
• 改善分析協作
• 最大化投資回報

本指南提供完整部署生命週期的深入解析，從初始規劃到成熟環境，遵循下列階段：

許多 Microsoft Purview 的應用程式和功能也有自己的個別最佳做法頁面。 本部署指南中經常會參考它們，但您可以在目錄中的 [概念 ] 和 [最佳做法和指導方針] 中找到所有這些。

確定目的和目標

許多組織已透過開發個別解決方案來開始其資料治理之旅，以滿足整個組織中隔離群組和資料網域的特定要求。 儘管體驗可能因行業、產品和文化而異，但大多數組織發現很難為這些類型的解決方案保持一致的控制和策略。

您可能想要在早期階段識別的一些常見資料控管目標，以建立全面的資料控管體驗，包括：

• 最大化資料的商業價值
• 啟用資料文化，讓資料取用者可以輕鬆尋找、解譯和信任資料
• 加強各業務部門之間的協作，以提供一致的數據體驗
• 透過加速資料分析來促進創新，以從雲端中獲益
• 透過各種技能組的自助服務選項減少探索資料的時間
• 縮短交付分析解決方案的上市時間，以改善對客戶的服務
• 降低因使用領域特定工具和不受支援的技術而造成的作業風險

一般方法是將這些總體目標分解為不同的類別和目標。 部分範例如下：

識別關鍵案例

Microsoft Purview 治理服務可用來集中管理跨雲端和內部部署環境的組織資料資產的資料控管。 若要成功實作，您必須識別對業務至關重要的關鍵案例。 這些案例可以跨越業務單位界限，或影響上游或下游的多個使用者角色。

這些場景可以用各種方式編寫，但您至少應該包含以下五個維度：

1. 角色 – 誰是使用者？
2. 來源系統 – Azure Data Lake Storage Gen2 或 Azure SQL Database 等資料來源有哪些？
3. 影響區域 — 此案例的類別是什麼？
4. 詳細案例 – 使用者如何使用 Microsoft Purview 來解決問題？
5. 預期成果 – 成功標準是什麼？

這些場景必須是具體的、可操作的、可執行的，並具有可衡量的結果。 您可以使用的一些範例案例：

與 Microsoft Purview 的整合點

成熟的組織很可能已經有現有的資料目錄。 關鍵問題是是否要繼續使用現有的技術，並與 Microsoft Purview 資料對應和資料目錄同步處理。 為了處理與組織中現有產品的同步處理， Microsoft Purview 提供 Atlas REST API。 Atlas API 提供了一種強大而靈活的機制來處理推送和拉取場景。 您可以使用 Atlas API 將資訊發佈至 Microsoft Purview，以進行啟動至啟動，或將最新更新從另一個系統推送至 Microsoft Purview。 您也可以使用 Atlas API 讀取 Microsoft Purview 中可用的資訊，然後同步處理回現有的產品。

對於其他整合案例，例如票證、自訂使用者介面和協調流程，您可以使用 Atlas API 和 Kafka 端點。 一般而言，Microsoft Purview 有四個整合點：

• 資料資產 – 這可讓 Microsoft Purview 掃描市集的資產，以列舉這些資產是什麼，並收集任何現成的中繼資料。 因此，對於 SQL，這可能是保存在 .sys.tables 對於 ADF) Azure Data Factory (這可能是列舉所有管線，並取得有關它們建立時間、上次執行、目前狀態的資料。
• 譜系 – 這可讓 Microsoft Purview 從分析/數據變動系統收集資料如何移動的資訊。 對於像 Spark 這樣的東西，這可能是從筆記本的執行中收集信息，以查看筆記本攝取了哪些數據、它如何轉換它以及它輸出它的位置。 對於 SQL 之類的東西，它可以分析查詢日誌來逆向工程執行了哪些突變操作以及它們執行了什麼。 我們根據需要支持基於推拉的血統。
• 分類 – 這可讓 Microsoft Purview 從數據源取得實體範例，並透過我們的分類系統執行它們。 分類系統會找出一段資料的語意。 例如，我們可能知道一個檔案是 Parquet 文件，有三列，第三個是字串。 但是我們在樣本上運行的分類器會告訴我們字串是名稱、地址或電話號碼。 點亮此整合點表示我們已定義 Microsoft Purview 如何開啟筆記本、管線、Parquet 檔案、資料表和容器等物件。
• 內嵌體驗 – 具有類似「工作室」體驗 (（例如 ADF、Synapse、SQL Studio、PBI 和 Dynamics） 的產品) 通常希望使用戶能夠發現他們想要與之互動的數據，並找到輸出數據的位置。 Microsoft Purview 的目錄可以透過提供內嵌體驗來協助加速這些體驗。 此體驗可以在 API 或 UX 層級發生，由合作夥伴選擇。 藉由內嵌對 Microsoft Purview 的呼叫，組織可以利用 Microsoft Purview 的數據資產對應來尋找數據資產、查看譜系、檢查架構、查看評等、連絡人等。

收集問題

一旦您的組織就高層次的目標達成一致，就會有來自多個小組的許多問題。 收集這些問題對於制定解決所有問題的計劃至關重要。 在收集這些問題時，請務必 包括相關群體 。 您可以使用我們的文件開始回答這些問題。

您在初始階段可能會遇到的一些範例問題：

• 我們組織中的主要資料來源和資料系統是什麼？
• 支援哪些資料來源？
• 對於 Microsoft Purview 尚不支援的資料來源，我有哪些選項？
• 我們應該如何為 Microsoft Purview 制定預算？
• 誰將使用 Microsoft Purview，以及他們將擁有哪些角色？
• 誰可以掃描新的資料來源？
• 誰可以修改 Microsoft Purview 內的內容？
• 我可以使用哪些程式來改善 Microsoft Purview 中的資料品質？
• 如何使用現有的關鍵資產、 詞彙表術語和聯繫人引導平台？
• 我們如何保護 Microsoft Purview？
• 我們如何收集回饋並建立永續的流程？
• 在災難情況下我們能做什麼？
• 我們已經在使用 Azure 資料目錄，我們可以移轉至 Microsoft Purview 嗎？

即使您可能無法立即獲得大多數問題的答案，收集問題也可以幫助您的組織構建此項目並確保滿足所有“必備”要求。

納入合適的利害關係人

若要確保成功為整個組織實作 Microsoft Purview，請務必讓正確的專案關係人參與。 只有少數人參與初始階段。 不過，隨著範圍的擴大，您將需要更多角色來為專案做出貢獻並提供意見反應。

您可能想要包括的一些關鍵利害關係人：

建立移至生產環境的流程

下面我們提供了一個潛在的四階段部署計劃，其中包括每個階段的工作、有用的連結和接受標準：

1. 第一階段：試點
2. 第 2 階段：最小可行產品
3. 第三階段：前期製作
4. 第四階段：生產

第一階段：試點

在此階段中，必須為一小部分使用者建立和設定 Microsoft Purview。 通常，它只是一組 2-3 人一起工作，以完成端到端的場景。 他們被視為組織中 Microsoft Purview 的倡導者。 此階段的主要目標是確保能夠滿足關鍵功能，並且正確的利益相關者了解該項目。

要完成的任務

其他有用的鏈接

• 建立 Microsoft Purview 帳戶
• 建立集合
• 概念：權限和存取權
• Microsoft Purview 產品詞彙表

驗收準則

• Microsoft Purview 帳戶會在組織租用戶下的組織訂用帳戶中成功建立。
• 具有多個角色的一小群使用者可以存取 Microsoft Purview。
• Microsoft Purview 會設定為掃描至少一個數據源。
• 使用者應該能夠擷取 Microsoft Purview 的索引鍵值，例如：
  • 搜尋和瀏覽
  • 譜系
• 使用者應該能夠在資產頁面中指派資產擁有權。
• 演示和演示以提高主要利益相關者的認識。
• 管理層的支持以批准 MVP 階段的更多資源。

第 2 階段：最小可行產品

一旦您擁有商定的需求和參與的業務單位以加入 Purview Microsoft，下一步就是處理最小可行產品 (MVP) 版本。 在此階段中，您會將 Microsoft Purview 的使用範圍擴大至更多使用者，這些使用者在水平和垂直方向上會有更多需求。 所有使用者都必須橫向滿足一些關鍵場景，例如詞彙表術語、搜尋和瀏覽。 每個業務單位或群組也會有垂直深入的需求，以涵蓋特定的端對端案例，例如從 Azure Data Lake Storage 到 Azure Synapse DW 再到 Power BI 的譜系。

要完成的任務

其他有用的鏈接

• 集合架構最佳做法
• 分類最佳做法
• 套用標籤最佳做法

驗收準則

• 成功將較大的使用者群組上線，以Microsoft Purview (50+)
• 掃描業務關鍵數據源
• 匯入並指派所有重要的詞彙表術語
• 成功測試關鍵資產的重要標籤
• 成功滿足參與業務單位使用者的最低情境

第三階段：前期製作

一旦 MVP 階段過去，就該規劃前期生產里程碑了。 您可能想要在內部部署資料來源 （例如 SQL Server） 上包含掃描。 如果 Microsoft Purview 不支援的數據源有任何差距，是時候探索 Atlas API 以瞭解其他選項了。

要完成的任務

其他有用的鏈接

• 套用標籤最佳做法
• 網路架構最佳做法

驗收準則

• 成功將至少一個業務單位與所有使用者一起上線
• 掃描內部部署資料來源，例如 SQL Server
• 使用 REST API 進行至少一個整合案例的 POC
• 完成投入生產的計劃，其中應包括基礎設施和安全的關鍵領域

第四階段：生產

應遵循上述階段來創建有效的數據生命週期管理，這是更好治理計劃的基礎。 資料控管將幫助您的組織為人工智慧、Hadoop、物聯網和區塊鏈等成長趨勢做好準備。 這只是許多數據和分析的開始，還有更多可以討論的內容。 該解決方案的結果將提供：

• 以業務為中心 - 與業務需求和場景一致的解決方案，而不是技術需求。
• 未來就緒 — 解決方案將最大化平台的預設功能，並使用標準化的產業做法進行設定或指令碼活動，以支援平台的進步/演進。

要完成的任務

其他有用的鏈接

• 管理工作流程執行
• 工作流程要求和核准
• 管理整合執行階段
• 要求存取資料資產

驗收準則

• 成功將所有業務單位及其使用者上線
• 成功滿足生產的基礎設施和安全要求
• 成功滿足用戶所需的所有用例

平台強化

可以採取更多的硬化步驟：

• 藉由啟用防火牆資源的掃描或使用 Private Link 來增加安全性狀態
• 微調示波器掃描以提高掃描效能
• 使用 REST API 匯 出重要中繼資料和屬性，以進行備份和復原
• 使用工作流程 自動執行票務和活動，以避免人為錯誤
• 使用原則 ，透過 Microsoft Purview 治理入口網站來管理資料資產的存取權。

生命週期考量

生產流程中要包含的另一個重要方面是如何遷移分類和標籤。 Microsoft Purview 有超過 90 個系統分類器。 您可以在檔案、表格或直欄資產上套用系統或自訂分類。 分類就像主旨標籤，用於標記和識別掃描期間在資料資產中找到的特定類型的內容。 敏感度標籤可用來識別組織數據內的分類類型類別，然後將您想要套用至每個類別的原則分組。 它使用與 Microsoft 365 相同的敏感性資訊類型，可讓您將現有的安全性原則和保護延伸至整個內容和資料資產。 它可以掃描並自動對文檔進行分類。 例如，如果您有名為 multiple.docx 的檔案，而且其內容中有國家識別碼，Microsoft Purview 會在 [資產詳細資料] 頁面中新增分類，例如歐盟國家識別號碼。

在 Microsoft Purview 資料對應中，目錄系統管理員需要在數個區域中確保其生命週期的一致性和維護最佳做法：

• 資料資產 — 需要跨環境重新掃描資料來源。 不建議僅在開發中掃描，然後在生產環境中使用API重新產生它們。 主要原因是 Microsoft Purview 掃描器會在數據資產的幕後執行更多「佈線」，將它們移至不同的 Microsoft Purview 實例可能會很複雜。 在生產環境中新增相同的資料來源並再次掃描來源要容易得多。 一般最佳作法是記錄所有正在使用的掃描、連線及鑑別機制。
• 掃描規則集 — 這是指派給特定掃描的規則集合，例如要偵測的檔案類型和分類。 如果您沒有那麼多掃描規則集，可以透過生產再次手動重新建立它們。 這將需要一個內部流程和良好的文件。 不過，如果您的規則集每天或每週變更，則可以透過探索 REST API 路由來解決此問題。
• 自訂分類 — 您的分類可能也不會定期變更。 在部署的初始階段，可能需要一些時間來了解各種需求，以提出自訂分類。 然而，一旦解決，這就不需要什麼改變。 因此，這裡的建議是透過 REST API 手動移轉任何自訂分類，或使用 REST API。
• 詞彙表 – 可以透過使用者體驗匯出和匯入詞彙表術語。 對於自動化案例，您也可以使用 REST API。
• 資源集模式原則 — 此功能是進階的，可供任何一般組織套用。 在某些情況下，您的 Azure Data Lake Storage 具有資料夾命名慣例和特定結構，可能會導致 Microsoft Purview 產生資源集發生問題。 您的業務單位可能也想要使用更多自訂來變更資源集建構，以符合業務需求。 在此案例中，最好透過 REST API 追蹤所有變更，並透過外部版本設定平臺記錄變更。
• 角色指派 – 您可以在這裡控制誰可以存取 Microsoft Purview ，以及他們擁有哪些許可權。 Microsoft Purview 也有 REST API 來支援使用者和角色的匯出和匯入，但這與 Atlas API 不相容。 建議是指派 Azure 安全性群組，並改為管理群組成員資格。

搬遷租戶

Microsoft Purview 目前不支援移動租用戶。

移動訂閱

您可以在訂用帳戶之間移動您的 Microsoft Purview 帳戶。 不過，如果您的帳戶是在 2023 年 12 月 15 日之前建立 (，或使用 2023-05-01-preview) 之前的 API 版本部署，或使用受控事件中樞，則與您的 Microsoft Purview 帳戶相關聯的受控儲存體帳戶和受控事件中樞將不會與您的執行個體一起移轉。 您的 Microsoft Purview 帳戶仍可運作，但您不應該移除這些資源。

如果您需要從其他訂用帳戶移除受控資源，您必須先建立新的 Microsoft Purview 帳戶，並將 您的資訊移轉 至此新帳戶，再移除原始資源及其受控資源。

後續步驟

• 收款最佳實務
• 導覽首頁並搜尋資產