統一的資料平台依賴一致的擷取、轉換與發布標準，讓領導者能信任數據以進行分析與人工智慧。 推薦： 建立全組織性的標準，控制哪些資料進入 OneLake、團隊如何精煉資料，以及受控資料產品如何觸及消費者（見圖 1）。 要應用此建議，請參考本文作為檢查清單：
圖
圖1。設定資料營運標準的三個步驟。
1. 設定資料擷取標準
OneLake 是 Microsoft Fabric 中分析與 AI 的中央資料湖，因此領導者必須掌控進入的內容。 推薦： 設定明確的界線，讓團隊只接收支持明確業務成果的資料。 要應用此建議，請使用以下清單。
你統一哪些資料？ OneLake 中的資料統一意指選擇支持與可衡量業務成果連結的資料產品。 最佳實務： 只有當資料支援某個資料產品並帶來商業價值時，才會將資料帶入 OneLake。 將資料擷取視為產品決策，而非技術上的預設。 決策指引： 當資料用於解釋或衡量領導者所追蹤的業務流程或結果時，決定納入資料。若無活躍的使用案例，則選擇將資料留在操作系統或部門儲存中。 此選擇降低儲存成本與治理負擔。
將協作與知識內容保留在 Microsoft 365 中。 Microsoft 365 資料支援 Microsoft 365 Copilot 代理程式。 這些代理在尊重現有權限的同時，擷取文件、電子郵件及協作資料。 請參見 Microsoft 365 Copilot 架構。 最佳實務： 使用 Microsoft 365 作為主要目的為協作、參考或知識檢索的內容的記錄系統。 請使用 Microsoft 365採用指南 來準備這些資料。
透過支援的模式整合作業資料庫。 營運資料庫通常提供分析與人工智慧情境，但直接存取會帶來風險與不穩定性。 最佳實務： 使用Microsoft Fabric支援的模式，例如虛擬存取捷 徑 與複製存取的 鏡像 。 Azure 資料庫通常需要鏡像以穩定整合。 決策指引： 當虛擬存取符合效能需求時，選擇捷徑。 當要在 OneLake 中取得實體副本以滿足分析效能、隔離或下游重用需求時，請選擇鏡像。
整合現有的資料湖。 許多組織已經在運營資料湖，例如 Azure Data Lake Storage（ADLS）、Google Cloud Storage 或 Amazon S3。 最佳實務： 將現有湖泊視為統一資料資產的一部分，而非強制立即遷移。 使用捷徑或鏡像。 決策指引： 根據準備度和風險來決定。 為了避免重複，請選擇捷徑。 當一致性、效能或合規性高於複製成本時，選擇鏡像。
Surface Azure Databricks 輸出於 OneLake. Azure Databricks 通常已經產生經過精選的分析資料。 最佳實務： 保持 Databricks 的管線完整，最終的 Gold 輸出則在 OneLake 中呈現。 決策指引： 選擇捷 徑 以避免複製，且當遠端存取符合需求時。 當治理或消費模式需要在地資料時，選擇 鏡像 。
內部與外部資料接收分開。 內部分析資料與對外資料需要不同的控制。 最佳實務： 為外部資料產品建立獨立的工作區或湖區。 只在這些地點儲存核准的外部資料集。 決策指引： 及早決定數據是支持內部決策還是外部共享。 選擇實體隔離以減少意外暴露並簡化安全政策執行。
2. 設定資料轉換標準
將資料導入 OneLake 只是第一步。 真正的價值來自於將原始資料轉化為高品質、即用型的資料產品。 領導者不設計流程，但他們定義防止碎片化的平台與架構標準。 推薦： 標準化轉型平台並強制執行一致的精煉架構。 要執行此建議，請使用以下檢查清單：
2.1. 使用正確的數據平台
您選擇的平台決定了您在 Microsoft 和 Azure 環境中資料產品的營運需求。 推薦： 對於每個資料產品，都要在簡單與整合性與專業工程能力需求之間取得平衡。 要執行此建議，請使用以下檢查清單：
Fabric（預設）。 Fabric 提供整合性的資料工程、分析與商業智慧引擎，直接運作於 OneLake，作為公司的統一治理資料資源。 最佳實務： 使用 Fabric 進行標準分析、報告和資料準備。 偏好原生 Fabric 引擎，如 Dataflows Gen2、Spark 和 SQL，以簡化存取控制、血統管理與成本管理。 使用 OneLake 作為單一儲存層。 決策指引： 當需求符合內建功能，且領導層重視統一治理與計費時，選擇 Fabric。 接受有限的客製化，以換取較低的營運開銷。
Azure Databricks。 很多人偏好 Azure Databricks。 它支援大規模處理與先進的機器學習場景。 最佳實務： 在已有專業知識或規模的地方，繼續使用 Databricks。 要求輸出必須進入 OneLake，或透過 OneLake 捷徑連接，以確保治理、安全與發現都集中管理。 決策指引： 當 Fabric 不符合目前需求時，選擇 Databricks。 接受更高的整合複雜性和技能負擔作為代價。
確保平台所有權界限的嚴格執行。 明確的平台邊界可防止重複成本及系統間邏輯不一致。 最佳實務： 將每個工作類別的責任分配給一個平台。 在批准跨平台處理前，要求進行架構審查。 決策指引： 決定哪個平台擁有擷取、轉換與分析結果。 避免重複的轉換和重疊的管線，因為它們會產生相同的業務結果。
2.2. 應用獎章架構
Medallion 架構透過明確的進程，從原始資料到適用於商業的輸出，為所有資料產品建立信任、一致性與治理。 推薦： 要求 OneLake 中的所有資料產品遵循青銅、銀、金三色結構，並禁止繞過這些層級的捷徑。 要執行此建議，請使用以下檢查清單：
強制採用青銅層作為記錄系統（原始擷取）：青銅層能精確捕捉 OneLake 資料，並保持原始原始資料的忠實度。 最佳實務： 資料儲存為僅附加且不可變。 此階段禁止更正或豐富化。 要求所有入站資料集都必須先進入青銅狀態。 決策指引： 決定青銅的存在只是為了保存源頭系統的真相。 接受較慢的可用性，以換取可稽核性與可追溯性。
將銀層視為可信視角。 銀層則存放經過驗證、標準化且淨化過的數據，團隊依賴這些數據來進行一致的分析。 最佳實務： 套用資料品質規則、格式對齊及基本業務驗證。 清楚記錄銀色資料集，並透過治理流程管理變更。 決策指引： 選擇銀作為權威的淨化層。 禁止團隊獨立重新清理原始資料，造成相互矛盾的解讀。
黃金（商業情境、資料產品）： 將黃金資料集認證為商業數據產品。 黃金層提供受控的數據產品，領導者用於決策、績效追蹤及報告。 最佳實務： 將黃金數據與核准的商業定義與指標對齊。 優化結構以適應消費。 將每個黃金資料集註冊為 Microsoft Purview 的資料產品，並附上擁有權、用途及更新細節。 決策指引： 決定任何跨團隊或決策的資料集都必須以黃金形式存在。 拒絕未管理或未經認證、繞過治理的資料集。
製作消毒後的外部使用產品。 外部共享需要刻意與內部營運資料分離。 最佳實務： 製作經過策劃的資料集，移除或遮蔽敏感欄位，並在必要時減少細節。 分配所有權並套用明確標籤，例如公共或外部使用。 將這些資料集儲存在核准的地點。 決策指引： 選擇將外部資料集視為獨立產品。 接受額外的治理措施以降低法律與安全風險。
Fabric 透過 實體化湖泊檢視 支援此模型，可以自動管理轉換過程。 詳見《 Medallion Lakehouse 建築架構在 Fabric 中》。 關於分析架構，請參見 Microsoft Fabric 的端對端分析。
資料表。 獎章建築範例。 金層結合了兩個資料集的資料。
| Dataset | 層 | 示例資料 | 發生了什麼事 |
|---|---|---|---|
| 銷售交易 | 青銅 | OrderID=984321 ·StoreID=17 ·金額=「1,200」·TxnDate=“2026-01-05T14：32：09Z” | 此記錄是從銷售系統送達的，與發送時完全一致。 金額是字串。 時間戳記遵循系統格式。 不賦予任何意義。 |
| 銀 | OrderID=984321 ·StoreID=17 ·金額=1200.00 ·TxnDate=2026-01-05 | 交易經過標準化與驗證。 金額是數字。 日期依企業規則規定。 數據現在變得值得信賴。 | |
| 商店參考編號 | 青銅 | StoreID=“17” ·RegionName = 「EAST」 | 這份紀錄來自一個定位系統。 格式反映來源。 |
| 銀 | StoreID=17 ·區域=東部 | 店鋪識別碼會與銷售數據相符。 區域值乾淨且一致。 | |
| 各地區每日收入 | 金 | 區域=東部 ·日期=2026-01-05 ·總收入=425000 | 此數值結合了銀銷售交易與銀店參考資料。 個別紀錄會被總結以回答商業問題。 |
2.3. 考慮自適應金層
這裡包含了自適應黃金作為前瞻性考量。 這個想法是利用 AI 代理人來創造黃金層。 代理人能觀察到你可能無法察覺的模式。 如果用戶經常詢問「每月按地區劃分的客戶重要議題」，AI 客服人員可以將該資料集具體化。 這項功能目前並未內建於 Microsoft Fabric。 這需要建立一個能在 Fabric 和 Power BI 遙測上運作的客製化 AI 代理。
3. 制定資料產品出版標準
發布標準定義了您的組織如何透過 Microsoft、Fabric、OneLake 和 Microsoft Purview 公開可信的資料產品。 目標是擴大重用、強化治理，並降低分析與 AI 工作負載中的風險。 推薦： 建立統一的發布標準，使每個核准的資料產品都能被發現、受規範，並明確針對特定受眾，才能廣泛使用。 要執行此建議，請使用以下檢查清單：
透過 OneLake 目錄來標準化發行。 OneLake 目錄為跨 Fabric 及外部處理平台（如 Databricks）的資料產品提供統一的存取介面。 最佳實務： 使用 OneLake 作為所有核准資料產品的預設執行與消費層。 將 Microsoft Purview 視為治理與業務定義的記錄系統。 這種對齊讓 Power BI、Fabric 資料代理和 Azure AI 搜尋能持續使用資料，同時實現集中式治理的可視化。
確保可被發現性。 可發現性確保決策者與消費者能在不依賴非正式知識的情況下，找到值得信賴的資料產品。 最佳實務： 設定 Fabric 工作區的可見性，讓相關受眾能發現項目。 他們不需要存取權限，只需要有能力請求存取權限。 啟用 Purview 存取請求工作流程 ，讓使用者能直接向目錄申請權限。 決策指引： 當目標是跨網域重複使用時，選擇廣泛的可發現性。 當有法規或保密限制時，請選擇有限的可查性。 平衡可見性與存取控制，而非隱藏資產。
發布時必須強化元資料。 元資料提供脈絡，讓領導者能評估資料產品的適配度、信任度及重用性。 最佳實務： 在發表時要求提供描述性元資料。 在 Fabric 中使用標籤 來依業務領域或倡議分類產品。 確保描述說明目的與資料範圍。 此做法支持目錄搜尋並提升重用的信心。 決策指引： 決定中繼資料需求是否保持最低，或強制執行標準結構。 當組織同時操作多個領域且需要一致性時，請選擇標準架構。 對於早期成熟階段，選擇較輕盈的做法。
適當時給予背書與認證。 定義背書與認證標準。 背書向組織顯示信任程度與治理成熟度。 最佳實務： 使用「Promoted」表示網域推薦的產品。 使用認證表示通過正式治理審查的產品。 將認證應用於支援高階主管報告或關鍵分析的 Gold 資料集。 參考 Endorsement 的 Fabric 背書指南。 決策指引： 決定哪些產品需要認證。 對於執行或法規工作，請選擇強制認證。 當速度與創新是優先考量時，選擇可選的認證。 接受較慢的入職作為較高信任的代價。
在 Purview 中以資料產品形式發佈。 Purview 資料產品提供更高層次的視圖，將資產分組為受管理的產品生命週期。 最佳實務： 為每個已發表的資料產品建立 Purview 資料產品條目。 包含產品名稱、描述、擁有者、品質狀態及相關資產，如表格、型號與報告。 統一目錄中的參考數據產品。 決策指引： 決定 Purview 資料產品是所有已發表資產皆需，還是僅策略性產品。 當投資組合的能見度至關重要時，請選擇全面覆蓋。 當治理能力有限時，選擇選擇性保障。
明確目標受眾與用途。 明確的意圖可防止濫用，並支持各分析與 AI 情境下的合規性。 最佳實務： 要求每個資料產品說明其目標受眾及支援的工作負載類型。 請指定內部、合作夥伴或公共使用。 識別 AI、分析、BI 或公開網路情境。 同時使用 Purview 的元資料、 詞彙表術語和 敏感性標籤 ，以一致地表達此意圖。 決策指引： 判斷外部使用或代理使用是否需要額外核准。 當資料超出組織邊界時，選擇更嚴格的核准。 接受較慢的發表作為風險降低的代價。