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

本文是成功將 Microsoft Purview (先前稱為 Azure Purview) 部署到數據資產生產環境的指南。 其目的是協助您從研究到強化生產環境的部署階層化和階段，並且最適合與我們的 部署檢查清單搭配使用。

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

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

妥善規劃的治理平臺部署可提供下列優點：

• 更好的數據探索
• 改善分析共同作業
• 最大化投資報酬率

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

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

識別目標和目標

許多組織已藉由開發符合整個組織中隔離群組和數據網域特定需求的個別解決方案，開始其數據控管旅程。 雖然體驗可能會因產業、產品和文化而有所不同，但大部分的組織發現很難針對這些類型的解決方案維持一致的控制和原則。

您可能想要在早期階段中識別的一些常見數據控管目標，以建立完整的數據控管體驗，包括：

• 最大化數據的商業價值
• 啟用數據文化特性，讓數據取用者可以輕鬆地尋找、解譯和信任數據
• 增加各業務單位之間的共同作業，以提供一致的數據體驗
• 藉由加速數據分析以獲得雲端的優點來促進創新
• 透過各種技能群組的自助選項來減少探索數據的時間
• 縮短傳遞分析解決方案的上市時間，以改善客戶的服務
• 降低因使用領域特定工具和不支持技術而造成的作業風險

一般方法是將這些整體目標細分為各種類別和目標。 部分範例如下：

識別重要案例

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

這些案例可以透過各種方式撰寫，但您應該至少包含下列五個維度：

1. Persona – 用戶是誰？
2. 來源系統 – 什麼是數據源，例如 Azure Data Lake Storage Gen2 或 Azure SQL 資料庫？
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位置。 如 Azure Data Factory (ADF) 這可以列舉所有管線，並取得建立、上次執行、目前狀態時的數據。
• 譜系 – 這可讓 Microsoft Purview 從分析/數據變動系統收集數據移動方式的資訊。 對於 Spark 之類的專案，這可能會從筆記本的執行收集資訊，以查看筆記本內嵌的數據、轉換數據的方式，以及輸出數據的位置。 對於類似 SQL 的內容，它可以分析查詢記錄，以反向工程執行哪些變動的作業及其執行的作業。 視需求而定，我們支援推送和提取型譜系。
• 分類 – 這可讓 Microsoft Purview 從數據源取得實體樣本，並透過我們的分類系統加以執行。 分類系統會找出數據片段的語意。 例如，我們可能知道檔案是 Parquet 檔案，而且有三個數據行，而第三個數據行是字串。 但我們在範例上執行的分類器會告訴我們字串是名稱、位址或電話號碼。 光源化此整合點表示我們已定義 purview Microsoft 如何開啟筆記本、管線、parquet 檔案、數據表和容器等物件。
• 內嵌體驗 – 具有如 ADF、Synapse、SQL Studio、PBI 和 Dynamics) 等體驗 (等「Studio」的產品，通常會想要讓使用者探索他們想要互動的數據，以及尋找輸出數據的位置。 Microsoft Purview 的目錄可藉由提供內嵌體驗來協助加速這些體驗。 此體驗可能會在合作夥伴選項的 API 或 UX 層級發生。 藉由內嵌呼叫 Microsoft Purview，組織可以利用 Microsoft Purview 的數據資產對應來尋找數據資產、查看譜系、檢查架構、查看評分、聯繫人等。

收集問題

一旦您的組織同意高階目標和目標，多個群組就會有許多問題。 請務必收集這些問題，以制定計劃來解決所有疑慮。 當您收集這些問題時，請務必 包含相關群組 。 您可以使用我們的檔案來開始回答這些問題。

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

• 組織中的主要數據源和數據系統為何？
• 支援哪些數據源？
• 對於 Microsoft Purview 尚未支持的數據源，我的選項為何？
• 我們應如何為 purview Microsoft預算？
• 誰將使用 Microsoft Purview，以及他們將擁有哪些角色？
• 誰可以掃描新的數據源？
• 誰可以修改 purview Microsoft內的內容？
• 我可以使用哪些程式來改善 Microsoft Purview 中的數據品質？
• 如何使用現有的重要資產、 詞彙和聯繫人來啟動平臺？
• 如何保護 purview Microsoft？
• 如何收集意見反應並建置持續的程式？
• 在災害情況下，我們可以做什麼？
• 我們已經在使用 Azure 資料目錄，是否可以移轉至 Microsoft Purview？

即使您可能無法立即回答大部分的問題，收集問題也可協助您的組織框定此專案，並確保可以符合所有「必須具備」的需求。

包含適當的項目關係人

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

您可能想要包含的一些重要項目關係人：

建立移至生產環境的程式

以下我們提供了可能的四階段部署計劃，其中包含每個階段的工作、實用連結和接受準則：

1. 階段 1：試驗
2. 階段 2：最小可行產品
3. 階段 3：生產階段前
4. 階段 4：生產

階段 1：試驗

在此階段中，必須為一小組使用者建立和設定 Microsoft Purview。 通常只有一組 2-3 人共同合作，才能在端對端案例中執行。 他們被視為組織中Microsoft Purview 的提倡者。 此階段的主要目標是確保能夠符合重要功能，且適當的項目關係人知道專案。

要完成的工作

其他實用的連結

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

接受準則

• Microsoft在組織租使用者下的組織訂用帳戶中成功建立 Purview 帳戶。
• 具有多個角色的一小組用戶可以存取 purview Microsoft。
• Microsoft Purview 設定為至少掃描一個數據源。
• 用戶應該能夠擷取 Purview Microsoft索引鍵值，例如：
  • 搜尋和流覽
  • 譜系
• 用戶應該能夠在資產頁面中指派資產擁有權。
• 簡報和示範，以提高重要項目關係人的認知。
• 從管理購買以核准更多 MVP 階段的資源。

階段 2：最小可行產品

一旦您有同意的需求，並參與業務單位Microsoft Purview 上線，下一個步驟是使用最低可行產品 (MVP) 版本。 在此階段中，您會將 Microsoft Purview 的使用方式擴充為更多需要水準和垂直的使用者。 所有使用者都必須以水準方式符合主要案例，例如詞彙、搜尋和流覽。 每個業務單位或群組也會有垂直的深度需求，以涵蓋特定的端對端案例，例如從 Azure Data Lake Storage 到 Azure Synapse DW 到 Power BI 的譜系。

要完成的工作

其他實用的連結

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

接受準則

• 成功將較大的使用者群組上線Microsoft Purview (50 個以上的)
• 掃描業務關鍵數據源
• 匯入並指派所有重要的詞彙
• 成功測試重要資產上的重要標籤
• 成功符合參與業務單位使用者的最低案例

階段 3：生產階段前

一旦通過 MVP 階段，就可以規劃進入生產階段前里程碑。 您可能想要在內部部署數據源上包含掃描，例如 SQL Server。 如果 Microsoft Purview 不支援任何數據源間距，就可以探索 Atlas API 以瞭解其他選項。

要完成的工作

其他實用的連結

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

接受準則

• 與所有使用者一起成功上線至少一個業務單位
• 掃描內部部署數據源，例如 SQL Server
• 使用 REST API 的 POC 至少整合案例
• 完成移至生產環境的計劃，其中應包含基礎結構和安全性的重要領域

階段 4：生產

應遵循上述階段來建立有效的數據生命週期管理，這是更好的治理計劃的基礎。 數據控管可協助您的組織為不斷成長的趨勢做好準備，例如 AI、Hadoop、IoT 和區塊鏈。 這隻是數據和分析許多專案的起點，還有更多專案可供討論。 此解決方案的結果會提供：

• 以業務為焦點 - 此解決方案符合商務需求與技術需求的案例。
• 未來就緒 - 解決方案會將平台的預設功能最大化，並使用標準化的產業做法進行設定或腳本活動，以支援平台的前進/演進。

要完成的工作

其他實用的連結

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

接受準則

• 成功將所有業務單位及其用戶上線
• 成功符合生產環境的基礎結構和安全性需求
• 成功符合使用者所需的所有使用案例

平台強化

您可以採取更強化的步驟：

• 啟用防火牆資源掃描或使用 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。
• 詞彙 – 可以透過UX匯出和彙入詞彙。 針對自動化案例，您也可以使用 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 帳戶，並將 資訊移 轉至此新帳戶，然後再移除原始資源及其受控資源。

後續步驟

• 集合最佳做法
• 流覽首頁並搜尋資產