Microsoft Fabric 中的現代資料倉儲獎章式架構

Microsoft Fabric
Power BI

此範例工作負載描述一種以 SQL 為核心的現代化資料倉儲（MDW）獎章式架構。 現代資料倉儲利用基於SQL的資料儲存庫來組織結構化資料，進行分析與報告。 此架構實作Fabric Data Warehouse的銅、銀、金三層，並利用 Fabric Data Factory 協調資料擷取與轉換。

Fabric Data Warehouse 以 Delta 格式儲存 OneLake 中的關聯型資料，並支援透過資料表、檢視、交易及儲存程序進行 T-SQL 開發。 Power BI、SQL 用戶端及其他應用程式會從黃金層取用經整理的資料。

Important

推薦的 Fabric 獎章圖案每層用湖邊小屋，或青銅和銀色層用湖邊小屋，金色層用倉庫。 此架構在三層皆使用倉庫，因為資料保持結構化，並透過整個流程使用 SQL 進行轉換。 資料湖倉更適合用於以 Spark 為基礎的處理作業、資料科學工作負載，以及大量非結構化或半結構化資料。 如需了解支援 Spark 和非結構化資料的 Lakehouse 優先實作，請參閱 Greenfield lakehouse on Microsoft Fabric。

Architecture

Microsoft Fabric 中現代資料倉儲獎章架構的示意圖。

下載此架構的 PowerPoint 檔案。

在圖中，鏡像處理運作式資料庫複製，而 Fabric Data Factory 管線則將非鏡像來源導入青銅路徑。

數據流

下列資料流程對應至上一個圖表：

  1. 營運資料庫、SaaS 應用程式、檔案及其他來源系統會產生資料。

  2. 資料擷取會透過兩條路徑將來源資料匯入 Fabric。 對於支援的作業資料庫，Fabric 中的鏡像處理會持續將資料複寫到 OneLake 中的鏡像資料庫項目。 倉儲 CTAS 或 INSERT ... SELECT 步驟接著會將該資料持久化到青銅資料倉儲中。 對於檔案、SaaS 應用程式及其他非鏡像來源，請使用 Fabric Data Factory 管線或倉庫 T-SQL，例如 COPY INTO，來載入青銅表。

  3. 青銅層將原始且處理最小化的資料存放在倉庫資料表中。 擷取後設資料（例如載入時間戳記和來源識別碼）有助於稽核與重新處理。

  4. 第一個轉換階段（Bronze to silver）驗證並將青銅資料轉換為銀層。

  5. 銀層包含經過清理、去除重複及整合的資料。 在需要歷史分析時，銀表會保留來源變更，並標示生效日期及當前列指示。

  6. 儲存程序或 dbt 工作通常會使用 SQL 模式（例如 INSERT ... SELECT（CTAS）、MERGE 和 Bronze to silver）來實作CREATE TABLE AS SELECT階段。

  7. 金層提供即時可用的星型結構、資料集市及預先彙總的資料表。

  8. 第二個轉換階段（Silver to gold）會將銀層資料轉換為黃金層中的商業實體、維度、事實資料和彙總資料。

  9. Power BI 透過語意模型消耗黃金資料。 其他使用者，如 SQL 用戶端、筆記本和應用程式，則可查詢倉庫 SQL 端點。

Components

  • Fabric Data Warehouse 提供銅層、銀層和金層的 T-SQL 計算表與關聯表。
  • OneLake 以 Delta 格式儲存倉儲資料，並儲存透過 Fabric 鏡像複製的資料。
  • Fabric 中的鏡像會持續將支援的作業資料庫複寫到 OneLake。
  • Fabric Data Factory 負責資料匯入並協調儲存程序、管線及其他轉換活動。
  • Power BI 提供語意模型、報告與儀表板，搭配精心策劃的黃金資料。

設計指引

以下指引說明如何實作青銅、銀色和金色層，並組織支援工作區。 根據你工作負載的數據來源、治理需求以及團隊技能，調整這些建議。

青銅層：原始資料擷取

青銅層會擷取並匯入原始資料，並以原始形式保留所有來源資料，而不套用任何業務邏輯。 它作為記錄系統，實現完整的追蹤與再處理。 此層中的資料表與來源結構描述緊密對應，並刻意避免進行過濾、去重或資料增補。 可選的元資料欄位，如擷取時間戳或原始碼檔名，通常支援審核。

對於支援的操作資料庫，請使用 Fabric 中的鏡像功能，持續將來源資料表複製到 OneLake。 對於檔案、SaaS 或不支援的來源，請使用 Fabric Data Factory 管線、使用 COPY INTO 進行大量擷取，或使用 OPENROWSET 搭配 CTAS 或 INSERT ... SELECT，將外部檔案資料保存到銅層倉儲中。

在這個階段，資料擷取會將重塑維持在最低限度，使青銅層仍作為可重放的記錄系統。 針對非鏡像來源，如有需要，可使用 bronze 載入預存程序（或對應的 dbt 模型）來標準化傳入記錄，並加入載入中繼資料。

青銅層的最佳實務強調保存所有原始資料（包括無效紀錄）、使用批次擷取以避免小檔案問題、將結構與來源系統緊密對齊，以及透過使用 Fabric 管線自動化擷取工作流程，以確保大規模的一致性與可靠性。

銀層：資料清理與符合性

銀層則著重於資料清理與一致性，透過應用資料品質規則、標準化、重複去重及跨多來源整合來精煉銅資料。 最終會形成經過清理且可靠資料的單一可信來源。

通常你會在這個階段使用 T-SQL 實作轉換，並採用如 INSERT … SELECT（CTAS）、CREATE TABLE AS SELECT 和 MERGE 等陳述式模式，以支援批次和增量處理。 雖然 Fabric Data Warehouse 不支援實體化視圖，但你可以使用 Spark 實作的實體化湖景來產生 Delta 表格。 SQL 分析端點會將這些 Delta 資料表暴露為倉庫可讀取的資料表。

銀層的最佳實務包括將轉換作業設計為冪等、一致地強制執行資料品質規則，以及使用 MERGE 進行增量更新。 當工作負載需要歷史化時，保留具有有效開始與結束日期及當前列指示的列版本。 Gold 維度可利用這些歷史資料來實現第 1 類或第 2 類緩慢變更維度（SCD）行為。

黃金層：分析用的精選數據

gold 層提供經過整理、可直接用於業務的資料，並已針對分析、報表，以及 Power BI 等 BI 工具的使用進行最佳化。 此層設計圍繞分析建模模式，通常使用帶有事實與維度表的星型結構、領域專屬資料集市及預先彙整的摘要表，以支援高效能查詢與直覺分析。

你通常會從白銀數據中完全推導出黃金表格，並公開給最終用戶和報告工具使用。

請為維度使用穩定的代理鍵，避免讓事實依賴可變動的來源系統鍵。 Fabric Data Warehouse 支援用於產生代理索引鍵的 BIGINT IDENTITY資料行。 身份值是唯一的，但不保證是連續或有序的，且可能出現空白。 如果這些限制不適合工作負載，請在轉換邏輯中產生並持久化代理鍵，並維持對每個自然鍵的持久映射。 完全刷新時不要重新生成代理金鑰。

黃金層的最佳實務包括：依據分析與商業使用案例進行資料建模、盡可能預先彙總資料以提升效能、套用列級安全 (RLS)、欄級安全 (CLS) 及資料遮蔽等安全控管，並完整記錄資料血緣與轉換。

工作空間策略

工作空間策略定義青銅、銀與金層如何邏輯與物理上分開，以平衡治理、安全性與營運簡便性。 你可以透過為每一層使用獨立的工作區來實作各層；在需要強固的安全邊界、明確的所有權或嚴格的職責分離時，我們建議採用這種方式。 例如，你應該將原始資料的擷取與經過精選的商業資料隔離。

或者，您也可以在單一工作區中，透過為銅層、銀層和金層資料分別使用獨立的倉儲，來實作分層架構。 此方法可降低管理負擔，簡化跨層開發與測試，同時保留獎章層間倉庫層級的分離。

這些方法的選擇通常取決於組織規模、安全需求、團隊結構及治理成熟度等因素。 隨著 Fabric 實施的演進，許多企業採用混合模式。 我們建議在需要隔離、治理及所有權邊界時，使用分開的工作空間。

實作指南

Fabric Data Warehouse在青銅、銀、金層提供交易一致性與可靠的資料處理。 使用批次導向寫入以減少小檔案問題，並提升儲存與查詢效率。 在增量處理情境中，使用 MERGE 語句處理延遲到達或變更的資料。

讓交易維持短暫，以減少爭用並最佳化並行性，尤其是在高資料擷取量的環境中。 透過使用 Fabric 查詢洞察與動態管理視圖（DMV）積極監控效能與營運健康狀況。 Fabric 中讀寫工作負載的架構分離，進一步使擷取與轉換工作能同時執行而不阻塞分析查詢，確保下游分析與報告的可預測效能。

使用 T-SQL 儲存程序與 Fabric Data Factory 管線進行原生 SQL 轉換與編排。 偏好模組化 SQL 模型與測試的團隊可以使用由 Microsoft 維護的 適用於 Fabric Data Warehouse 的 dbt 介面卡。 在將資料發佈到下游層級之前，先執行唯一性、參照完整性及接受值測試作為部署閘門或管線閘門。

Alternatives

此架構包含多個元件，您可以根據工作負載的功能與非功能需求，以其他 Azure 服務或方法取代。 請考慮以下替代方案及其取捨。

對於著重大規模資料工程、進階分析、機器學習或非結構化資料的情境，在 Microsoft Fabric 上採用以 lakehouse 為優先的架構可能會是更合適的選擇。 在此方法中，Fabric 湖屋作為 OneLake 的主要資料儲存庫，轉換主要透過基於 Spark 的工具，如筆記本或 Dataflow Gen2 來實現。 此模式提供了分散式運算、筆記本與機器學習工具，這些並非此 SQL 優先倉庫架構的重點。

對於專注於資料科學、人工智慧或複雜分散式處理的組織，Azure Databricks 是另一個選擇。 當工作負載需要深度整合開源機器學習框架、細緻控制 Spark 執行，或多雲可攜性時，Azure Databricks 通常被選用。

對於近即時或事件驅動分析，Fabric Real-Time Intelligence、Azure 事件中樞 或 Azure 串流分析 可能比以Fabric Data Warehouse為中心的批次導向獎章設計更為合適。

案例詳細資料

當主要目標是透過熟悉的 SQL 模式，大規模提供經過治理且可直接用於分析的資料時，Fabric Data Warehouse 非常適合這種獎章式架構。

情境一：針對精選、分析準備資料集的關聯語意與 SQL 效能

Fabric Data Warehouse 非常適合，因為它提供關聯式資料表與檢視、ACID 交易，以及在 Delta 資料之上進行 T-SQL 操作。 此功能支援已清理與合規且必須透過 SQL 持續查詢的資料負載。

範例： 一家航空公司建立精選的黃金資料集，用於航班營運與營收分析。 分析師依賴穩定的 SQL 查詢效能來評估準時表現趨勢、路由獲利能力及團隊利用率。 使用倉庫資料表與檢視可確保交易一致性與可靠的查詢行為，而臨時檔案存取則較難保證。

情境二：以 SQL 為核心的集中式治理體驗

Fabric Data Warehouse透過工作區權限、物件層級安全性及內建血統系統實現集中治理，同時透過分析工程團隊熟悉的 SQL 介面揭露資料。 此方法減少營運摩擦、簡化存取控制，並加速團隊間的採用，且不引入新的存取範式。

範例： 全球企業嚴格分工：平台團隊管理資料擷取與轉換，分析團隊僅使用精選資料。 透過倉庫僅公開金層資料表，並集中管理存取，組織避免對原始或中間資料的無控制存取，同時維持熟悉的 SQL 工作流程。

情境 3：供報表與儀表板使用的 BI 最佳化資料取用

該倉庫針對高並發、讀取量大的負載進行優化，當大量商業用戶使用基於一致語意模型的儀表板與報告時，是個強而有力的選擇。 當需要效能、穩定性及可預測查詢行為時，這種優化尤其重要。

範例：財務與營運團隊在營業時間內存取 Power BI 儀表板，監控營收、營運效率及服務協議合規等關鍵績效指標（KPI）。 Fabric Data Warehouse 將 SELECT 和非 SELECT 工作負載隔離至不同的運算集區，減少儀表板查詢與資料倉儲擷取之間的直接資源爭用。

情境四：可重複使用金層的維度建模支援

Fabric Data Warehouse 很自然地契合維度模型設計模式，包括事實資料表和維度資料表；而這些資料表通常會用於金層，以提供對業務友善且可重複使用的資料集。 這些模型簡化分析、減少邏輯重複，並促進團隊間一致的指標定義。

範例： 零售組織會為顧客、產品和門市建立共享維度表，並針對銷售和庫存建立事實表。 這些黃金資料集會在多個 Power BI 報告與事業單位中重複使用，確保淨銷售或庫存周轉等 KPI 能一次定義且一致套用。

Considerations

這些考量體現了 Azure Well-Architected Framework 的支柱；這是一套可用來提升工作負載品質的指導原則。

可靠性

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 欲了解更多資訊，請參閱 可靠性設計審查檢查清單。

檢視 Microsoft Fabric 中的可靠性，了解文件中的韌性模型，包括區域下降行為及區域考量。 根據您所在地區及工作量需求，驗證復原預期是否符合此指引。

針對跨區域災難復原情境，設計並記錄符合組織需求及共同責任模式的復原策略。

  • Fabric Data Warehouse 僅支援將 PRIMARY KEY、FOREIGN KEY 和 UNIQUE資料表條件約束 作為 NOT ENFORCED。 倉庫本身並不驗證獨特性或參考完整性。 擷取與轉換邏輯必須偵測重複或孤立的記錄，並防止其到達下游層。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 欲了解更多資訊，請參閱 安全性設計審查檢查清單。

Microsoft Fabric 提供根據組織需求管理、控制及稽核安全設定的能力。 請考慮以下安全措施：

  • 使用 Microsoft Entra ID 單一登入（SSO）來驗證使用者，並提供跨裝置與地點的一致身份管理。

  • 套用基於工作區的權限來控制誰可以建立、修改或使用Fabric產物。

  • 在存取網路內外的資料或服務時，請使用 Fabric 的進出網路安全控制。 這些控制包括 條件存取、 私有連結、 受信任的工作空間存取以及 受管理的私有端點。

  • 使用 Fabric 稽核日誌來追蹤使用者活動、設定變更及跨平台的資料存取。

如需詳細資訊，請參閱 Fabric 中的安全性。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 欲了解更多資訊，請參閱 成本優化的設計審查檢查清單。

Microsoft Fabric 提供指定數量容量單元（CU）的容量預留。 一年預留有助於降低可預測且穩定工作量的成本。

為了最大化 Fabric 產能利用率，請考慮以下做法：

  • 先從試用容量或隨用隨付的 F SKU開始，以了解工作負載行為。 進行一項在明確範圍內的概念驗證，涵蓋具代表性的資料擷取、轉換與報表工作負載。 監控 CU 消耗並推算結果以估算生產需求。 你可以隨著需求增加而擴大 Fabric 的產能。

  • 分析歷史使用情況，以辨識高峰與非尖峰時段。 將非關鍵或背景工作負載安排在需求較低的時段，以降低持續的CU壓力。

  • 透過優化 SQL 查詢、資料分析表達式（DAX）及背景工作，減少不必要的計算消耗。

  • Fabric 支援突發擴充和平滑機制，可吸收短期運算需求高峰，並將背景工作負載的資源耗用分散到較長時間內。 這些功能有助於將容量調整為平均使用量，而非尖峰需求。 如需詳細資訊，請參閱 評估及優化您的網狀架構容量。

  • 協調長期執行的轉換與刷新操作，以避免在相同容量上重疊高計算工作負載。 欲了解更多資訊，請參閱Fabric Data Warehouse工作負載管理。

請留意以下價格考量：

  • OneLake 的儲存容量、保留期間及資料存取模式直接影響總成本。 估算每個獎章層的預期資料成長，並將保留率與業務及合規要求對齊。

  • Microsoft Fabric 定價是以指派的 F 容量為基礎，並以 CU 衡量。 Power BI 的每位使用者授權是獨立的，不會配置 Fabric 容量。

請使用Azure定價計算器中的預設定估算來取得此架構的起始成本。 調整數值以符合你預期的工作量。

卓越營運

卓越營運涵蓋在生產環境中部署、監控及維護工作負載的營運流程。 欲了解更多資訊，請參閱 卓越營運設計審查清單。

Microsoft Fabric 提供涵蓋資料工程、倉儲及分析工作負載的內建營運可視性。 使用 Fabric 容量指標應用程式來監控容量消耗、識別資源密集型產物，並了解互動式與背景工作負載如何影響整體利用率。 這些洞察幫助團隊在擴展、排程與優化等方面做出明智的營運決策。

設置主動警示，讓容量管理員能及早識別高使用率或限速狀況，並在使用者受影響前做出回應。

效能效率

效能效率指的是工作負載能夠有效擴展並滿足使用者需求的能力。 欲了解更多資訊，請參閱 效能設計審查檢查清單。

Microsoft Fabric 包含多種機制以協助管理效能與容量利用率：

  • 突發和平滑化讓短期的運算需求高峰更快完成，同時分散使用。 互動式操作通常會在數分鐘的時間區間內趨於平穩，而背景操作則會在較長的時間區間內趨於平穩。

  • 當某個容量的持續運算使用量超過其指派 SKU 的限制時，就會套用節流。 節流會延遲或拒絕新的操作，以保護平台穩定性。

  • Fabric 容量指標應用程式提供容量消耗的詳細可視化，並區分互動式操作（如報告查詢）與背景操作（如擷取或模型刷新）。 這種區分使得針對不同工作負載類型進行針對性的效能優化。

Contributors

本文由 Microsoft 維護。 以下貢獻者撰寫了這篇文章。

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

後續步驟