統一資料平台的操作標準

本文協助決策者建立在統一資料平台上開發與使用資料產品的營運標準。

組織必須決定資料領域如何透過 OneLake 提供資料，並將其轉化為可信賴的資料產品，供組織內部再利用。 中央治理機制應建立全組織的標準。 資料領域應該擁有自己的資料產品，並在這些範圍內做出實施決策。

一致的標準減少不必要的重複，幫助消費者在適當保護下找到並使用可信的資料。 本文涵蓋資料接收、轉換、發布、取用、生命週期管理、安全性與例外狀況。

1. 資料接收

應該以什麼標準來規範資料的接收？ 組織必須制定標準，規範哪些來源資料可透過 OneLake 提供，以及提供資料的首選方法。 只有在原始資料支援核准的資料產品或分析需求時，才可透過 OneLake 提供原始資料。

1.1 資料接收方法

資料領域應該如何透過 OneLake 提供原始資料？ 組織應偏好減少不必要資料流動的模式。

  • 當支援的資料能保留在來源時，捷徑應該是首選模式。
  • 當 Fabric 需要同步存取外部資料庫或目錄時，鏡像處理應是支援來源的首選模式。
  • 當 Fabric 需要資料副本且捷徑或鏡像不符合要求時，應使用資料移動。

當偏好模式不符合要求時，資料網域可選擇其他核准的接收方式。 請參閱 使用 OneLake 捷徑與鏡像統一資料。

1.2 資料來源

我們應該如何整合不同的資料來源？ 資料領域應透過 OneLake 提供可信的輸出，而不是在 Fabric 中重建同等的處理流程，除非這麼做能帶來可衡量的組織效益。

  • Microsoft 365：Microsoft 365 通常應作為協作內容的記錄系統。 資料領域應僅在經核准的資料產品需要時（例如用於結構化分析），才將 Microsoft 365 內容帶入統一資料平台。

  • 營運資料庫：營運資料庫應持續優化以處理交易型工作負載。 資料領域不應允許分析或人工智慧工作負載直接查詢操作資料庫，除非資料庫擁有者已核准預期工作負載並建立必要的控制措施。

  • 現有資料平台：現有的資料湖與轉換平台，如 Azure Databricks，應在持續符合組織需求時保留。 在 Fabric 中進行遷移或重新建立，應該需要可衡量的組織效益。 請參閱捷徑、鏡像 Azure Databricks Unity Catalog，以及整合 OneLake 與 Azure Databricks。

2. 資料轉換

我們該如何將資料轉化為資料產品？ 組織應建立首選的轉型平台，以減少不必要的能力重複。 當 Microsoft Fabric 符合資料產品需求時，可以作為預設選項。 現有平台，如 Azure Databricks，只要具備必要功能或代表組織已建立的投資，就應持續使用。

轉換模式：當資料受益於漸進式優化時，應採用 medallion 架構作為首選模式。 資料領域應只使用產生可信資料產品所需的品質階段。

請參閱 Fabric 的具體化湖泊檢視、Medallion Lakehouse 建築（Fabric）以及 Microsoft Fabric 的端對端分析。

3. 出版

資料產品應該具備什麼條件才能被發佈？ 一個資料產品可以由一個或多個技術資產組成，這些資產共同提供受支援的業務方案。 每個已發表的資料產品都必須有負責人、明確的業務目的、預期用途、存取流程及品質狀態。 當消費者依賴及時取得時，也應明確界定營運承諾。

  • 安全控管：必須在發表前就已具備必要的安全控控措施。 敏感資料產品必須具備所需的分類與處置要求。 請參閱 Purview 敏感度標籤。

  • 元資料：組織必須定義已發表資料產品的最低元資料。 消費者應能判斷資料所屬網域、負責人、支援的使用方式、品質承諾及存取需求。 請參閱 Fabric 中的標籤與 Purview 自訂中繼資料。

  • 資料譜系：可用的資料譜系應提供足夠資訊，以理解重要的上游相依關係並評估下游影響。 參見Fabric 中的譜系。

4. Discovery

消費者應該如何找到資料產品？ 已發表的資料產品應該預設是廣泛可被發現的。 使用 OneLake 目錄進行 Fabric 原生的探索。 當資料產品需要企業業務脈絡或跨越更廣泛資料資產的治理時，請以 Microsoft Purview 整合式目錄 表示資料產品。

請參閱 OneLake 目錄概觀 及 Unified Catalog 中的資料產品。

5. 認可

消費者應該如何判斷資料產品是否值得信賴，可供再利用？ Fabric 認可能幫助消費者評估支持數據產品的項目所提供的保證程度。 組織必須為每個認可等級建立一致的意義與要求。

  • 推廣應表示擁有該資料產品的資料網域推薦該資料產品供重複使用。

  • 認證狀態應表示授權審查員確認資料產品符合組織定義的標準。

出版不應該需要認證。 出版物確立組織中受支援的重用的最低門檻。 認證提供額外的保障。 詳見Fabric 中的背書。

6. 已核准用量

消費者何時可以在無需額外核准的情況下使用資料產品？ 資料產品可支援多種消費模式，包括分析、應用程式、AI 紮根及代理程式。 無論採用哪種使用技術，皆適用相同的核准使用與安全標準。 所屬資料領域必須定義每個已發表資料產品所支援的用途。 當消費者的擬議使用範圍在這些範圍內時，應該能無需額外核准即可使用資料產品。

組織必須定義哪些用途總是需要額外審查。 這些使用應包括使用實質改變資料風險的情況，例如外部揭露或具有重大後果的人工智慧使用。

對一種用途的批准，不代表對另一種用途的批准。 例如，一個核准用於內部報告的資料產品，不應該自動被批准對外發表。 一個獲准用於 AI grounding 的資料產品，不應該自動被允許用於能採取有重大影響行動的代理人。

7. 資料產品生命週期

數據領域應該如何管理消費者依賴的數據產品？ 已發表的資料產品會產生依賴，而擁有該資料產品的資料領域必須管理這些依賴。 組織必須建立變更與淘汰標準，讓消費者能規劃因應中斷並必要時進行過渡。 發布要求與生命週期承諾共同確立了資料擁有領域與資料產品消費者之間的契約關係。

7.1 可靠性

發表的資料產品應適用哪些可靠性標準？ 組織應根據資料產品無法使用或資料遺失時的業務影響，建立可靠性要求。 資料領域應將這些要求套用於整個資料產品，而非假設 OneLake 或其他平台元件的可靠性能提供所需的保護層級。

  • 可靠性分類：組織應為每個業務關鍵層級定義可靠性需求。 資料網域必須確保完整的資料產品符合適用要求。

  • 復原要求：資料領域的擁有者必須確保完整的資料產品符合其業務關鍵性的可靠性要求。 復原設計應考慮資料產品及使用該資料產品所需的相依性。 業務關鍵資料產品應該有經過測試的復原流程。

  • Fabric 容量需求：資料領域應確保共享的 Fabric 容量不會阻礙任何指定資料產品達到其可靠性要求。 當資料產品需要容量層級的控制，而這些控制不應該適用於其他產品時，則使用獨立容量。

不要把 OneLake 複寫當作完整的資料產品復原。 每個業務關鍵資料產品都應有涵蓋其資料及必要 Fabric 項目的復原設計。 請參閱 OneLake 災難復原與資料保護，以及 Fabric 體驗專屬的災難復原指引。

7.2 變更

資料領域應該如何管理影響取用者的變更？ 資料網域的負責方必須根據資料產品的業務影響來管理重大變更。 他們應在做出破壞性變更前識別受影響的消費者，並提供與影響相稱的過渡期。

隨著依賴度與業務重要性增加，變更承諾也應該增加。 一個被廣泛使用且支援關鍵業務流程的資料產品，其變更要求應比用途有限的資料產品更嚴格。

資料領域應利用現有的資料譜系與影響分析來識別技術依賴性。 他們也應該考慮技術沿襲無法捕捉的已知商業依賴關係。 請參見 Fabric 影響分析。

7.3 退休

資料領域應該如何停用已發表的資料產品？ 組織必須訂定最低退休條件。 在退役前，擁有該資料的領域必須評估活躍的相依關係，並提供與業務影響成比例的過渡期。

資料擁有網域應在有核准的替代方案時識別該替代方案。 當消費者應該停止建立新的依賴時，它應該取消認可。 現有使用者必須在存取權限終止前獲得足夠通知。

8. 資料產品安全

當資料產品被使用時，授權要求應該如何適用？ 新的消費路徑不得削弱來源資料產品所需的保護。 組織必須根據資料產品的授權要求是否仍然有效，對核准的消費模式進行分類。

8.1. 來源授權已保留

消費模式何時會保留來源資料產品的授權？ 消費模式可以依賴來源資料產品的授權，當它保留消費者身份並持續執行必要的存取限制時。

例如，如果銷售資料產品將每位銷售人員限制為只能存取其指派的客戶，消費模式必須為每位消費者保留此限制。 組織應在允許每個核准模式存取受限資料前進行驗證。

請參閱 Fabric 資料代理程式、Power BI 以及 OneLake MCP 伺服器。

8.2. 新的授權邊界

當消費模式必須建立新的授權邊界時，適用哪些標準？ 若消費模式未保留來源資料產品的授權要求，必須建立新的授權邊界，提供等效保護。 當組織無法提供該保護時，不應批准用於受限資料的該模式。

這種情況通常發生在服務建立另一種資料表示方式或透過共享應用程式身份存取來源資料時。

9. 標準的例外

資料領域可以核准哪些例外？ 組織必須定義哪些標準資料領域可以變動，哪些需要中央核定。

  • 資料網域應有權批准僅影響其預算或本地營運模式的例外。 他們不得批准會削弱整個組織的安全要求或法規遵循要求的例外。 對於削弱全組織互通性要求或最低資料產品發佈標準的例外情況，也應要求中央核准。

  • 中央治理應負責全組織標準，並隨著 Fabric 能力與組織實務演進進行審查。 資料領域應提供反覆發生的例外作為這些審查的輸入。 反覆出現例外可能表示組織標準需要改變。

  • 上次更新時間：