共用方式為

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

  • 發行項

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

注意事項

這些最佳做法涵蓋 Microsoft Purview 統一資料控管解決方案的部署。 如需 Microsoft Purview 風險和合規性解決方案的詳細資訊， 請前往這裡。 如需一般 Microsoft Purview 的詳細資訊， 請前往這裡。

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

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

妥善規劃的資料控管平臺部署可提供下列優點：

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

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

階段 說明
識別目標和目標 請考慮整個組織需要的資料控管和需求。
收集問題 當您開始使用時，您和您的小組可能會有哪些問題，以及您可在何處開始解決這些問題？
建立移至生產環境的程式 建立專為您的組織量身打造的階段式部署策略。
平臺強化 繼續將您的部署擴大至成熟度。

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

識別目標和目標

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

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

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

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

類別 目標
探索 管理員使用者應該能夠掃描 Azure 和非 Azure 資料來源 (包括內部部署來源，) 自動收集資料資產的相關資訊。
分類 平臺應該根據資料取樣自動分類資料，並允許使用自訂分類手動覆寫。
消費 商務使用者應該能夠找到商務和技術中繼資料之每個資產的相關資訊。
血統 每個資產都必須顯示基礎資料集的圖形檢視，讓使用者瞭解原始來源和已進行的變更。
共同作業 平臺必須提供每個資料資產的其他相關資訊，以允許使用者共同作業。
報告 使用者必須能夠檢視資料資產的報告，包括需要額外擴充的敏感性資料和資料。
資料管理 平臺必須允許系統管理員定義存取控制的原則，並根據每個使用者自動強制執行資料存取。
工作流程 平臺必須能夠建立和修改工作流程，才能輕鬆地相應放大及自動化平臺內的各種工作。
整合 票證或協調流程等其他協力廠商技術必須能夠透過腳本或 REST API 整合到平臺中。

識別重要案例

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

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

  1. Persona – 使用者是誰？
  2. 來源系統 – 什麼是資料來源，例如Azure Data Lake Storage Gen2或Azure SQL資料庫？
  3. 影響區域 – 此案例的類別為何？
  4. 詳細案例 – 使用者如何使用 Microsoft Purview 來解決問題？
  5. 預期的結果 – 什麼是成功準則？

案例必須是具有可測量結果的特定、可採取動作和可執行檔。 您可以使用的一些範例案例：

案例 詳細資料 角色
類別目錄業務關鍵資產 我需要每個資料集的相關資訊，才能充分瞭解它是什麼。 此案例包含與目錄中資料集相關的商業和技術中繼資料資料。 資料來源包括 Azure Data Lake Storage Gen2、Azure Synapse DW 和/或 Power BI。 此案例也包含內部部署資源，例如SQL Server。 商務分析師、資料科學家、資料工程師
探索業務關鍵資產 我需要有可搜尋目錄中所有中繼資料的搜尋引擎。 我應該能夠使用技術字詞、商務字詞，以及使用萬用字元的簡單或複雜搜尋來搜尋。 商務分析師、資料科學家、資料工程師、資料管理員
追蹤資料以瞭解其來源，並針對資料問題進行疑難排解 我需要有資料譜系，才能追蹤報表、預測或模型中的資料回到其原始來源。 我也需要瞭解對資料所做的變更，以及資料在整個資料生命週期中的所在位置。 此案例需要支援Azure Data Factory和 Databricks 的優先順序資料管線。 資料工程師、資料科學家
擴充重要資料資產的中繼資料 我需要使用自動產生的技術中繼資料來擴充目錄中的資料集。 分類和標記是一些範例。 資料工程師、網域/企業擁有者
使用易記的使用者體驗來管理資料資產 我需要有商務特定中繼資料的商務詞彙。 商務使用者可以使用 Microsoft Purview 進行自助式案例，為其資料加上批註，並透過搜尋輕鬆探索資料。 網域/企業擁有者、商務分析師、資料科學家、資料工程師

與 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 檔案，而且有三個數據行，而第三個數據行是字串。 但我們在範例上執行的分類器會告訴我們字串是名稱、位址或電話號碼。 光源化此整合點表示我們已定義 Microsoft Purview 如何開啟筆記本、管線、Parquet 檔案、資料表和容器等物件。
  • 內嵌體驗 – 具有如 ADF、Synapse、SQL Studio、PBI 和 Dynamics) 等體驗 (等「Studio」的產品，通常會想要讓使用者探索他們想要互動的資料，以及尋找輸出資料的位置。 Microsoft Purview 的目錄可藉由提供內嵌體驗來協助加速這些體驗。 此體驗可能會在合作夥伴選項的 API 或 UX 層級發生。 藉由內嵌對 Microsoft Purview 的呼叫，組織可以利用 Microsoft Purview 的資料資產對應來尋找資料資產、查看譜系、檢查架構、查看評分、連絡人等。

收集問題

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

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

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

包含適當的專案關係人

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

您可能想要包含的一些重要專案關係人：

角色 角色
資料長 CDO 會監督一系列的功能，包括資料管理、資料品質、主要資料管理、資料科學、商業智慧，以及建立資料策略。 他們可以是 Microsoft Purview 實作專案的贊助者。
網域/企業擁有者 影響工具使用方式並具有預算控制的商務人員
資料分析師 能夠解決商務問題並分析資料，以協助領導者做出商務決策
資料架構設計人員 設計任務關鍵性企業營運應用程式的資料庫，以及設計和實作資料安全性
資料工程師 操作和維護資料堆疊、從不同來源提取資料、整合和準備資料、設定資料管線
資料科學家 建置分析模型並設定要由 API 存取的資料產品
資料庫管理員 擁有、追蹤及解決服務等級協定內的資料庫相關事件和要求， (SLA) ;可設定資料管線
DevOps 企業營運應用程式開發和實作;可能包括撰寫腳本和協調流程功能
資料安全性專家 評估整體網路和資料安全性，其中包含進出 Microsoft Purview 的資料

建立移至生產環境的程式

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

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

階段 1：試驗

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

要完成的工作

工作 詳細資料 持續時間
收集 & 對需求的同意 與所有專案關係人討論，以收集一組完整的需求。 不同角色必須參與，才能就專案每個階段完成的需求子集達成一致。 一周
流覽 Microsoft Purview 治理入口網站 瞭解如何從首頁使用 Microsoft Purview。 一天
設定歷程的 ADF 識別重要管線和資料資產。 收集連線到內部 ADF 帳戶所需的所有資訊。 一天
掃描資料來源，例如Azure Data Lake Storage Gen2或SQL Server。 新增資料來源並設定掃描。 確定掃描成功偵測到所有資產。 兩天
搜尋 和 流覽 允許使用者存取 Microsoft Purview，並執行端對端搜尋和流覽案例。 一天

接受準則

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

階段 2：最小可行產品

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

要完成的工作

工作 詳細資料 持續時間
掃描Azure Synapse分析 開始將您的資料庫來源上線，並掃描它們以填入重要資產 兩天
建立自訂分類和規則 掃描您的資產之後，您的使用者可能會發現除了 Microsoft Purview 的預設分類之外，還有其他使用案例可以進行更多分類。 2-4 周
掃描 Power BI 如果您的組織使用 Power BI，您可以掃描 Power BI，以收集資料科學家或資料分析師所使用的所有資料資產，這些資產都需要包含儲存層中的譜系。 1-2 周
匯入詞彙 在大部分情況下，您的組織可能已經開發資產的詞彙和字詞指派集合。 這需要透過 .csv 檔案將程式匯入 Microsoft Purview。 一周
將連絡人新增至資產 針對最上層資產，您可能想要建立一個程式來允許其他角色指派連絡人，或透過 REST API 匯入。 一周
新增敏感性標籤和掃描 視 Microsoft 365 的標籤使用方式而定，這對某些組織而言可能是選擇性的。 1-2 周
取得分類和敏感性深入解析 針對 Microsoft Purview 中的報告和深入解析，您可以存取這項功能來取得各種報表，並提供簡報給管理。 一天
使用 Microsoft Purview 受控使用者讓更多使用者上線 此步驟會要求 Microsoft Purview 管理員與 Azure Active Directory 管理員合作，以建立新的安全性群組來授與 Microsoft Purview 的存取權。 一周

接受準則

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

階段 3：生產階段前

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

要完成的工作

工作 詳細資料 持續時間
使用掃描規則集來精簡掃描 您的組織將有許多資料來源可供生產階段前使用。 請務必預先定義掃描的關鍵準則，以便能夠一致地全面套用分類和副檔名。 1-2 天
藉由檢查來源頁面來評估每個來源的區域可用性掃描 視資料來源的區域和合規性與安全性的組織需求而定，您可能想要考慮哪些區域必須可供掃描。 一天
瞭解掃描時的防火牆概念 此步驟需要探索組織如何設定其防火牆，以及 Microsoft Purview 如何驗證自己以存取資料來源進行掃描。 一天
瞭解掃描時Private Link概念 如果您的組織使用Private Link，您必須配置網路安全性的基礎，以將Private Link納入需求中。 一天
掃描內部部署SQL Server 如果您有內部部署SQL Server，這是選擇性的。 掃描需要設定自我裝載Integration Runtime，並將SQL Server新增為數據源。 1-2 周
使用 Microsoft Purview REST API 進行整合案例 如果您需要整合 Microsoft Purview 與其他協力廠商技術，例如協調流程或票證系統，您可能會想要探索 REST API 領域。 1-4 周
瞭解 Microsoft Purview 定價 此步驟將提供組織重要的財務資訊以進行決策。 1-5 天

接受準則

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

階段 4：生產

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

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

要完成的工作

工作 詳細資料 持續時間
掃描已啟用防火牆的生產資料來源 如果在防火牆就緒時這是選擇性的，但請務必探索強化基礎結構的選項。 1-5 天
啟用Private Link 如果在使用 Private Link 時，這是選擇性的。 否則，您可以略過此選項，因為啟用 Private 時，這是必須具備的準則。 1-5 天
建立自動化工作流程 工作流程對於自動化程式非常重要，例如核准、呈報、檢閱和問題管理。 2-3 周
建立作業檔 資料控管不是一次性專案。 這是一個持續進行的計畫，可促進資料驅動決策的制定，並為企業創造商機。 記錄重要程式和商務標準非常重要。 一周

接受準則

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

平臺強化

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

  • 啟用防火牆資源掃描或使用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 目前不支援移動租使用者。

後續步驟