Microsoft Purview (前身為 Purview) 部署最佳實務Azure

本文是成功將 Microsoft Purview (過去Azure Purview) 部署到資料資產生產環境中的指南。 它旨在幫助你策略化並分階段部署，從研究到強化生產環境，最佳搭配我們的 部署清單使用。

如果你想要純技術性的部署指南，請使用 部署清單。

如果你正在制定部署 Microsoft Purview 的計畫，並想在制定部署策略時考慮最佳實務，請參考以下文章。 本指南說明任務可分階段完成，持續一個月或更長時間，以發展您的 Microsoft Purview 部署流程。 即使是已經部署 Microsoft Purview 的組織，也能利用本指南確保投資效益最大化。

妥善規劃的治理平台部署，能帶來以下好處：

• 更好的資料發現
• 改善分析合作
• 最大化投資報酬率

本指南透過以下階段，提供完整的部署生命週期洞見，從初步規劃到成熟環境：

許多 Microsoft Purview 的應用程式和功能也有各自的最佳實務頁面。 這些內容在這份部署指南中經常被引用，但你可以在目錄的 「概念 」以及 「最佳實務與指引」中找到所有內容。

明確目標與目標

許多組織的資訊治理之旅，都是從開發針對組織中孤立群組與資料領域特定需求的個別解決方案開始的。 雖然經驗會因產業、產品及文化而異，但大多數組織難以維持這類解決方案的一致控制與政策。

你可能想在早期階段識別一些常見的資料治理目標，以打造完整的資料治理體驗，包括：

• 最大化您資料的商業價值
• 促進資料文化，讓資料使用者能輕鬆找到、解讀並信任資料
• 促進各業務單位間的合作，以提供一致的數據體驗
• 加速數據分析以促進創新，享受雲端帶來的好處
• 透過自助服務選項，減少各種技能群體發掘數據的時間
• 縮短分析解決方案的上市時間，提升對客戶的服務品質
• 降低因使用領域專屬工具及未受支援技術所帶來的營運風險

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

識別關鍵情境

Microsoft Purview 治理服務可用於集中管理組織跨雲端與本地環境的資料治理。 要成功實施，您必須找出對企業至關重要的關鍵情境。 這些情境可能跨越事業單位邊界，或影響多個上游或下游的使用者角色。

這些情境可以用多種方式描述，但你至少應該包含以下五個面向：

1. Persona——使用者是誰？
2. Source system – 有哪些資料來源，例如 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。 Microsoft Purview 中的資訊也可透過 Atlas API 讀取，然後同步回現有產品。

至於其他整合情境，如工單、自訂使用者介面和編排，你可以使用 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. 第二階段：最小可行產品
3. 第三階段：前期製作
4. 第四階段：生產

第一階段：試播

在此階段，必須為少數使用者建立並設定 Microsoft Purview。 通常只有2到3個人一起合作，從頭到尾跑完各種情境。 他們被視為組織內 Microsoft Purview 的倡導者。 此階段的主要目標是確保關鍵功能能被滿足，並讓合適的利害關係人了解該專案。

待完成任務

其他有用的連結

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

接受標準

• Microsoft Purview 帳號在組織租戶下的組織訂閱中成功建立。
• 一小群擁有多角色的使用者可以存取 Microsoft Purview。
• Microsoft Purview 設定至少掃描一個資料來源。
• 使用者應能擷取 Microsoft Purview 的關鍵值，例如：
  • 搜尋與瀏覽
  • 譜系
• 使用者應該能在資產頁面中指定資產所有權。
• 簡報與示範以提升關鍵利害關係人的意識。
• 管理層同意批准更多資源，以進行MVP階段。

第二階段：最小可行產品

一旦你擁有同意的需求和參與的業務單位Microsoft Purview，下一步就是著手製作最小可行產品 (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。
• 資源集模式政策 ——此功能對一般組織來說已進階，容易應用。 在某些情況下，你的Azure Data Lake Storage有資料夾命名規則和特定結構，可能會讓 Purview 產生資源集Microsoft困難。 你的事業單位也可能想透過更多自訂化來調整資源組結構，以符合業務需求。 在這種情況下，最好透過 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 帳號，並將 你的資訊遷移 到這個新帳號，然後再移除原本的資源及其管理資源。

後續步驟

• 典藏最佳實務
• 在首頁瀏覽並搜尋資產