共用方式為

使用 Microsoft Fabric 設計企業 BI 解決方案

Microsoft Fabric
Azure Blob 儲存體
Microsoft Entra ID
Power BI

本文說明如何將數據從內部部署數據倉儲傳輸到雲端環境，然後使用商業智慧 （BI） 模型來提供數據。 你可以將此方法視為最終目標，或是邁向雲端元件全面現代化的第一步。

此指引建立在 Microsoft Fabric 端對端情境之上。 從內部 SQL 伺服器擷取資料時，有多種選擇，例如使用 Fabric Data Factory 管道、鏡像、複製作業，以及使用 SQL 的 Fabric 即時事件流變更資料擷取 (CDC)。 擷取後，資料會被轉換以供分析。

Architecture

展示企業商業智慧架構與 Fabric 的示意圖。

下載此架構的 Visio 檔案。

Workflow

下列工作流程對應至上一個圖表。

數據源

  • Azure 中的 SQL Server 資料庫包含源數據。 若要模擬內部部署環境，此案例的部署腳本會設定 Azure SQL 資料庫。 AdventureWorks 範例資料庫用作來源資料結構描述和範例資料。 如需詳細資訊，請參閱 從 SQL Server複製和轉換數據。

擷取和資料儲存體

  • Fabric OneLake 是您整個組織的單一、統一且邏輯性的資料湖。 此 SaaS 提供多種資料儲存選項，如用於資料工程湖屋工作負載的 Fabric Lakehouse 、資料倉儲工作負載的 Fabric Warehouse ，以及高容量時間序列與日誌資料集的 Fabric Eventhouse 。

  • Fabric Data Factory 管線 允許你建立複雜的擷取、轉換、載入（ETL）及資料工廠工作流程，能大規模執行多種任務。 控制流程功能內建於資料管線中，允許你建立工作流程邏輯，提供迴圈和條件句。 在此架構中，元資料驅動的框架允許大規模增量擷取多個資料表。

  • Fabric Data Factory 的鏡像 功能讓你能避免複雜的 ETL 流程，並將現有的 SQL Server 資產與 Fabric 中的其他資料整合。 你可以持續將現有的 SQL Server 資料庫直接複製到 Fabric OneLake。 Fabric Data Factory 複製工作讓你能輕鬆地將資料從來源轉移到目的地，無需使用管線。 資料傳輸可透過內建模式配置批次與增量複製，並支援可擴展的效能。

  • Fabric 事件串流 透過使用 CDC 擷取，從虛擬機（VM）上託管的 SQL Server 資料庫提供高吞吐量、即時的資料匯入。 此模式適合需要即時儀表板與警示的使用情境。

分析和報告

Components

  • Azure SQL Database 是 Azure 裝載的 PaaS SQL 伺服器。 在此架構中，SQL 資料庫提供原始資料並展示遷移情境中的資料流。

  • OneLake 是一個統一的雲端資料湖，用於儲存組織內結構化與非結構化的資料。 在此架構中，OneLake 作為中央儲存層。 它利用 Fabric Lakehouse、Fabric Warehouse、Fabric Eventhouse 及鏡像資料庫等產物，來持久化與組織各種資料，以進行分析與報告。

  • Fabric Data Warehouse 是一項 SaaS 產品，負責承載大型資料集的資料倉儲工作負載。 在此架構中，Fabric Data Warehouse 作為維度資料集的最終儲存庫，並支援分析與報告。

  • Power BI 是一款託管在 Fabric 運算上的商業智慧工具。 它在此情境中呈現並視覺化資料，使業務使用者能根據 Fabric Data Warehouse 及其他來源的資料，與儀表板與報告互動。

  • Microsoft Entra ID 是支援驗證和授權流程的多雲端身分識別和網路解決方案套件。 在此架構中，Microsoft Entra ID 為連接 Power BI 與 Fabric 資源的使用者提供安全存取。

案例詳細資料

在此案例中，組織具有包含大型內部部署數據倉儲的 SQL 資料庫。 該組織希望使用 Fabric 來匯入與分析資料，並透過 Power BI 向使用者提供分析洞察。

使用此架構的時機

你可以使用多種方法來滿足企業商業智慧的需求。 各種面向定義了商業需求，例如目前的技術投資、人力技能、現代化的時間表、未來目標，以及你偏好平台即服務（PaaS）還是軟體即服務（SaaS）。

請考慮下列設計方法：

本文的架構假設你使用 Fabric 湖屋或 Fabric 倉庫作為企業語意模型的持久層，並且使用 Power BI 進行商業智慧。 這種 SaaS 方法具備彈性，能因應各種商業需求與偏好。

Authentication

Microsoft Entra ID 會驗證連線到 Power BI 儀錶板和應用程式的使用者。 單一登入（SSO）將使用者連結到 Fabric 倉庫及 Power BI 語意模型中的資料。 授權是在源頭進行的。

累加式載入

當你執行自動化的 ETL 或 ELT 程序時，應該只載入自上次執行以來改變的資料。 這個過程稱為 增量負載。 相較之下，滿載時會載入所有資料。 若要執行累加式載入，請決定如何識別已變更的數據。 您可以使用 高水位標記 值方法，該方法會追蹤日期時間數據行的最新值或源數據表中唯一的整數數據行。

您可以在 SQL Server 中使用 時態表。 時序資料表是系統版本化的資料表，用來儲存資料變更歷史。 資料庫引擎會自動記錄個別記錄資料表中每項變更的歷程記錄。 若要查詢歷程記錄數據，您可以將 FOR SYSTEM_TIME 子句新增至查詢。 資料庫引擎會從內部查詢記錄資料表，但這個查詢過程對應用程式是隱蔽的。

時態表支援維度數據，這可能會隨著時間而變更。 事實表通常代表不可更改的交易，例如銷售，在這些情況下，保留系統版本歷史並不重要。 相反地，交易通常會有一個欄位來表示交易日期。 數據行可作為水位線值。 例如，在 AdventureWorks 數據倉儲中，SalesLT.* 數據表具有 LastModified 字段。

以下步驟描述 ELT 管線的一般流程：

  1. 針對來源資料庫中的每個資料表，追蹤上次執行 ELT 作業的截止時間。 將此資訊儲存在資料倉儲中。 在初始設定時，所有時間都會設定為 1-1-1900。

  2. 在資料匯出步驟期間，截止時間會當做參數傳遞至來源資料庫中的一組預存程序。 這些預存程式會查詢在截止時間之後變更或建立的任何記錄。 對於該範例中的所有資料表，您可以使用 ModifiedDate 資料行。

  3. 當資料移轉完成時，請更新儲存截止時間的資料表。

資料管線

此案例使用的資料來源是 AdventureWorks 範例資料庫。 累加式數據載入模式可確保只會載入最近一次管線執行之後修改或新增的數據。

元資料驅動的擷取框架

Fabric Data Factory 管線中的 元資料驅動擷取框架 會逐步載入關聯式資料庫中的所有資料表。 文章中提到資料倉儲作為來源，但也可以用 Azure SQL 資料庫作為來源取代。

  1. 選擇浮水印欄位。 在來源資料表中選擇一個資料行，以協助追蹤新的或變更的記錄。 此欄位通常包含隨著新增或更新資料列而增加的值（如時間戳記或 ID）。 請使用本欄最高值作為 浮水印 ，以了解你上次停在哪裡。

  2. 設置一個表格來儲存你最後的浮水印值。

  3. 建立包含以下活動的管道：

    • 兩個查詢活動。 第一個活動會得到最後一個浮水印值（我們上次停在那裡）。 第二個活動會獲得新的浮水印值（這次我們會停止）。 這兩個值都會傳給複製活動。

    • 當浮水印欄位的值介於舊浮水印和新浮水印之間時，執行複製作業以尋找該列。 接著它會將這些資料從你的資料倉儲複製到你的湖屋，作為一個新檔案。

    • 一個儲存程序活動，會儲存新的浮水印值，以決定下一次管線執行的起點。

    圖示中展示了取用、使用及更新浮水印值的各項活動流程圖。

以下圖片展示了完成的管線。 更多資訊請參見 增量吞嚥。

截圖顯示了一個媒體擷取流程，裡面有查找活動以取得浮水印值、一個複製活動用於新資料，以及一個儲存程序來更新浮水印。

將資料載入 Fabric 資料倉儲

複製活動會將資料從 SQL 資料庫複製到 Fabric 資料倉儲。 這個範例的 SQL 資料庫是在 Azure 中，所以它使用在 Fabric 入口網站的 「管理連線與閘道」下設置的連線。

使用 Fabric Data Factory 管線

Fabric Data Factory 中的管線定義了一組有序的活動，以完成增量負載模式。 手動或自動觸發程式會啟動管線。

轉換資料

若需要轉換，則可利用 Fabric 資料流 設計低程式碼、AI 輔助的 ETL 轉換，重塑資料。 Fabric 資料流依賴 Power Query 引擎來套用這些轉換並將結果寫入 Fabric Data Warehouse。

在生產環境中，使用 Fabric 筆記本 實作 ETL 轉換，透過由 Apache Spark 驅動的分散式運算框架，對大型資料集表現良好。

備註

使用 原生執行引擎 來執行資料工程或 ETL 工作負載。

使用 Power BI 搭配 Fabric 功能來存取、建模及視覺化資料

Power BI 的 Fabric 容量支援多種儲存模式以連接 Azure 資料來源：

  • 進口： 將資料載入 Power BI 語意模型，用於記憶體內查詢。

  • DirectQuery： 直接對關聯型儲存執行查詢，且不載入記憶體。

  • 綜合模型： 在同一資料集中，將部分資料表的匯入模式與其他資料表的 DirectQuery 結合。

  • 直接湖： 查詢來自 Fabric 工作空間語意模型中 OneLake 的 delta 資料表。 它優化了大型資料表的互動分析，能隨需載入資料到記憶體中。

此案例會使用 DirectQuery 儀錶板，因為它具有少量數據和低模型複雜度。 DirectQuery 會將查詢委派給基礎計算引擎，並在來源上使用安全性功能。 DirectQuery 可確保結果一律與最新的源數據一致。

匯入模式可以提供最低的查詢延遲。 若符合以下條件，請考慮匯入模式：

  • 模型完全符合Power BI的記憶體。
  • 重新整理之間的數據延遲是可接受的。
  • 您需要來源系統與最終模型之間的複雜轉換。

在這種情況下，使用者希望能完整存取最新資料，且 Power BI 刷新時不會有延遲，且他們想要所有歷史資料，這超出了 Power BI 資料集的容量。 Power BI 資料集可處理 25 GB 至 400 GB 的大小，視容量大小而定。 專用 SQL 集區中的數據模型已經在星型架構中，不需要轉換，因此 DirectQuery 是適當的選擇。

截圖顯示一個 Power BI 儀表板，包含銷售指標、趨勢圖表、篩選器和詳細資料表。

使用 Power BI 來管理大型模型、分頁報告和部署管線。 利用內建的 Azure Analysis Services 端點。 你也可以擁有專屬 容量 ，擁有獨特的價值主張。

當 BI 模型成長或儀錶板複雜度增加時，您可以切換至複合模型，並透過 混合式數據表匯入查閱數據表的元件，以及匯入預先匯總的數據。 您可以在 Power BI 中針對匯入的數據集啟用 查詢快取，並針對儲存模式屬性使用 雙數據表。

在複合模型中，數據集可作為虛擬傳遞層。 當使用者與視覺化互動時，Power BI 會產生 SQL 查詢至 Fabric Data Warehouse。 Power BI 會根據效率判斷要使用記憶體內部或 DirectQuery 記憶體。 引擎決定何時從記憶體內切換到 DirectQuery，並將邏輯推送至 Fabric 資料倉儲。 根據查詢資料表的情境，它們可以作為快取（匯入）或非快取的複合模型使用。 您可以選擇要快取到記憶體中的數據表、結合一或多個 DirectQuery 來源的數據，或結合 DirectQuery 源數據和匯入的數據。

當您使用 DirectQuery 搭配 Fabric 資料倉儲或湖倉時，請按照以下步驟操作：

  • 使用 Fabric Z 順序與 V-Order 來優化底層資料表資料以 delta 格式檔案儲存，以提升查詢效能。

  • 使用 Fabric 數據湖倉中的 物質化視圖 來預先計算、儲存並維護資料，就像資料表一樣。 在具體化檢視中使用所有數據或數據子集的查詢可以達到更快的效能，而不需要直接參考定義的具體化檢視來使用它。

考慮事項

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

Reliability

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。

文章 《可靠性 》說明了 Fabric 如何支援可靠性，包括透過可用性區域的區域韌性，以及跨區域復原與業務連續性。 Fabric 會在容量設定頁面上提供災害復原開關。 當 Azure 區域配對與 Fabric 服務配置相符時，它才會被使用。 當災難復原容量設定開啟時，跨區域複製即被啟用，作為 OneLake 資料的 災難復原功能 。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱安全性的設計檢閱檢查清單。

雲端現代化引進了安全性考慮，例如數據外泄、惡意代碼感染和惡意代碼插入。 您需要雲端提供者或服務解決方案來解決您的疑慮，因為安全性措施不足可能會造成重大問題。

此情境透過多層安全控制（包括網路、身份、隱私及授權控制）來解決最具挑戰性的安全問題。 Fabric 資料倉儲儲存了大部分資料。 Power BI 透過 SSO 透過 DirectQuery 存取資料。 使用 Microsoft Entra ID 進行認證。 布建集區內的數據授權也有廣泛的安全性控制。

請考慮以下常見的安全疑慮：

  • 定義誰可以看到哪些數據。

    • 請確定您的數據符合聯邦、當地和公司指導方針，以降低數據外泄風險。 Fabric 提供全面的 資料保護功能 ，以支持安全並促進合規。

    • OneLake 安全 控制所有 OneLake 資料的存取，並以繼承自父項目或工作區權限的不同權限。

      • 工作空間 是一種協作環境，用來創造和管理物品。 工作區的角色可以在此層級上進行管理。

      • 功能項 是一組功能打包在一起的單一元件。 資料項目是一種子類型，允許透過 OneLake 將資料儲存在其中。 物件繼承自工作區角色的權限，但也可以具備額外的權限。 項目內的資料夾用於儲存和管理資料，例如Tables/或Files/。

  • 判斷如何驗證使用者的身分識別。

    • 使用 Fabric 來控制誰能存取哪些資料，透過存取 控制 和 認證。

  • 選擇網路安全性技術來保護網路和數據的完整性、機密性和存取權。

  • 選擇可偵測並通知您威脅的工具。

  • 決定如何保護 Fabric OneLake 上的資料。

    • 透過使用 Microsoft Purview 資訊保護的敏感標籤，協助 保護 Fabric 上的資料 。 像是一般、機密和高度機密等標籤，在 Microsoft Office 應用程式如 Word、PowerPoint 和 Excel 中廣泛使用，以保護敏感資訊。 資料會自動從一個項目流動到另一個項目，貫穿於整個 Fabric 環境，從資料來源一路到企業用戶。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。

本節概述解決方案中各項服務的價格細節，並透過範例資料集說明此情境下的決策。 使用 Azure 價格計算器的 起始設定，並調整以符合你的情境。 欲了解更多 Fabric SKU 資訊，請參閱 Fabric 定價概覽。 欲了解更多如何產生整體布料消耗估算的資訊，請參閱 布料容量估計器。

織體可擴展架構

Fabric 是大多數工作負載的無伺服器架構，你可以獨立擴展運算和儲存層級。 計算資源會根據使用量產生成本。 您可以視需要調整或暫停這些資源。 儲存資源會按 GB 產生成本，因此當你導入資料時，成本會增加。

布料工廠管線

三個主要元件會影響管線的價格：

  • 編排資料管線活動： 為了優化成本，透過實施平行流程來縮短總編排時間。

  • Dataflow Gen2 用於計算： 為了優化成本，透過過濾不必要的資料並處理增量擷取，簡化 ETL 管線。

  • 用於複製工作或複製活動的資料移動： 為了優化成本，請設定複製工作採用增量擷取，並根據複製活動調整吞吐量。

欲了解更多資訊，請參閱 Data Factory 定價表的分頁。

價格會依元件或活動、頻率以及與編排相關的整體運算量而有所不同。 任何因資料管道活動或複製任務而產生的資料移動都會產生成本。 然而，透過 Fabric 鏡像 進行資料移動的運算是免費的，而鏡像資料的儲存成本則可免費，直到容量大小為止。 例如，如果你購買 F64 容量，你會獲得 64 TB 的免費儲存空間，專門用於鏡像。 當空閒鏡像儲存限制超過或容量暫停時，OneLake 儲存會被計費。

布料工作負載決策指南

請使用這份 決策指南 ，為您的 Fabric 工作負載選擇資料儲存庫。 所有選項皆可在 OneLake 的統一儲存中提供。

Fabric Lakehouse 或 Fabric Warehouse 的 SQL 端點提供執行臨時查詢以進行分析的能力。 它也允許 Power BI 語意模型匯入或直接查詢資料。 湖舍或倉庫的成本相當於進行 SQL 查詢以對應 SQL 端點而消耗的 CU。 為了優化成本，請在 Fabric Lakehouse 實作 Z-Ordering 和 V -Ordering ，以提升查詢效能。 對於資料倉儲，優化查詢以讀取較小批次。

OneLake 儲存

OneLake 儲存以即用即付的方式按每 GB 資料計費，且不佔用 Fabric 容量單位（CUs）。 Lakehouse 和倉儲等 Fabric 項目會取用 OneLake 儲存體。 更多資訊請參閱 布料定價。

為了優化 OneLake 成本，請專注於管理儲存容量，定期刪除未使用的資料，包括軟 刪除 儲存中的資料，並優化讀寫操作。 OneLake 儲存是與運算分開計費，因此使用 Fabric 容量指標應用程式監控使用情況非常重要。 為了降低儲存成本（根據每月平均每日使用量計算），可以考慮盡量減少儲存的資料量。

Power BI

此情境使用內建效能提升 的 Power BI 工作空間 ，以滿足嚴苛的分析需求。 為了優化成本，請在匯入模式擷取中實作 增量刷新。 在可能的情況下，實作 直接湖 模式以報告較大的資料集，以減輕整體 Fabric 容量負擔。

如需詳細資訊，請參閱 Power BI 定價。

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運的設計檢閱檢查清單。

  • 使用 Azure DevOps 版本流程與 GitHub Actions，自動化 Fabric 工作空間產物在多個環境中的部署。 欲了解更多資訊，請參閱 Fabric 工作空間的持續整合與持續交付。

  • 將每個工作負載放在個別的部署範本中，並將資源儲存在原始檔控制系統中。 您可以一起或個別部署範本，作為持續整合和持續傳遞 （CI/CD） 程式的一部分。 此方法可簡化自動化程式。 此架構有四個主要工作負載：

    • 資料倉儲與相關資源
    • Data Factory 管線
    • Power BI 資產，包括儀錶板、應用程式和數據集
    • 內部部署至雲端模擬案例

  • 考慮在可行的情況下暫存您的工作負載。 將您的工作負載部署到各種階段。 在移至下一個階段之前，請在每個階段執行驗證檢查。 這種方法會以受控的方式將更新推送至您的生產環境，並將未預期的部署問題降到最低。 使用 藍綠部署 和 canary 發行 策略來更新實時生產環境。

  • 使用復原策略來處理失敗的部署。 例如，您可以從部署歷程記錄中自動重新部署先前成功的部署。 在 Azure CLI 中使用 --rollback-on-error 旗標。

  • 請使用 Fabric 容量指標應用程式 ，全面監控 Fabric 容量消耗。 使用 workspace monitoring 來詳細監控 Fabric 工作空間遙測日誌。

  • 使用 布料容量估算器 來估算您的布料容量需求。

效能效率

效能效率是指工作負載能夠有效率地調整以符合使用者需求。 有關詳細資訊，請參閱效能效率的設計審核清單。

本文利用 Fabric F64 容量 來展示 BI 功能。 Fabric 中的專用 Power BI 容量範圍從 F64 到 最大 SKU 大小。 更多資訊請參閱 布料定價。

要判斷你需要多少容量，請採取以下步驟：

貢獻者們

本文由 Microsoft 維護。 下列參與者撰寫本文。

主要作者：

其他貢獻者：

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

後續步驟