Microsoft Fabric 完全指南 — 從 OneLake 到金層 | SQLYARD

1. 簡介 — 什麼是 Microsoft Fabric？為何重要？

二十年來，建立現代資料平台意味著需要整合一系列各自獨立授權、各自設定、各自監控的服務。您需要 Azure Data Factory 負責資料擷取、Azure Data Lake Storage Gen2 負責原始儲存、Azure Synapse Analytics 負責資料倉儲、Azure Databricks 負責 Spark 工程、Power BI Premium 負責報表，以及 Azure Purview 負責治理。每一個工具在各自領域都表現出色，但整合在一起卻形成了一個需要專業知識才能連接、維護和管理的複雜拼圖。^[1]

Microsoft Fabric 改變了這個局面。於 2023 年 11 月正式發布的 Fabric，是一個作為單一 SaaS 產品交付的端到端分析平台。它將資料工程、資料倉儲、即時分析、資料科學和商業智慧統一在同一個屋頂下，所有工作負載共享一個稱為 OneLake 的單一邏輯資料湖。^[2]

可以這樣理解：如果 Azure 是一組從不同商店購買的最佳工具，那麼 Fabric 就是將這些工具重新設計，使其從同一個工廠協同運作。資料不需要移動。安全模型是共享的。計費是整合的。每位工程師、分析師和資料科學家都在操作同一份真相副本。

2. 為何選擇 Fabric？商業與技術理由

統一儲存 — 單一真相副本

每個 Fabric 工作負載——Spark Notebook、T-SQL 查詢、Power BI 報表、即時串流——都從同一個 OneLake 讀取和寫入。不需要在資料湖、暫存區和資料倉儲之間複製資料。當資料工程師在 Notebook 中轉換一個 Delta 表時，同一個表立即對 Warehouse 中的 SQL 開發人員和透過 Direct Lake 的 Power BI 報表可見。^[3]

預設開放格式

OneLake 以 Delta Parquet 格式儲存所有資料——與 Apache Spark、Databricks 和更廣泛的資料工程生態系統使用的相同開放格式。您永遠不會被鎖定在需要遷移工具才能脫離的專有格式中。^[3]

SaaS 簡便性

Fabric 以軟體即服務形式交付。您購買容量（F-SKU），將工作區分配給該容量，然後開始建置。沒有需要佈建的基礎架構，沒有需要調整大小的 Spark 叢集。平台自動管理計算層。^[1]

較低的總體擁有成本

將五或六個分別授權的 Azure 服務替換為單一 Fabric 容量的組織，通常會在成本和營運開銷方面看到顯著降低。詳細內容請參閱 SQLYARD 的 Fabric 成本分析文章。

Microsoft 365 整合

Fabric 建立在 Microsoft 365 信任邊界之內。每個工作區都由 Entra ID 支持。來自 Microsoft Purview 資訊保護的敏感度標籤自動流經整個平台。^[4]

3. 為何不選 Fabric？誠實的取捨分析

沒有任何平台適合所有情況。以下是對 Fabric 可能不是最佳選擇的情境的誠實分析。

關於 Databricks 與 Fabric 的決策，SQLYARD 比較文章有詳細說明。

4. Fabric 所有主要元件說明

Fabric 以工作負載為組織單位——相關功能的邏輯分組。以下是每個主要工作負載及其關鍵項目類型。^[1]

5. OneLake — 一切的基礎

OneLake 是 Microsoft Fabric 中最重要的概念。如果您理解 OneLake，其他一切都說得通。^[5]

「資料的 OneDrive」比喻

Microsoft 將 OneLake 描述為「資料的 OneDrive」。^[5] 就像 OneDrive 為您提供一個每個 Microsoft 365 應用程式都可以存取的文件位置，OneLake 為您的組織提供一個每個 Fabric 工作負載都可以存取的資料位置。您建立一個工作區、一個 Lakehouse，每個工具——Spark、T-SQL、Power BI、資料科學——都讀取相同的檔案。

技術架構

OneLake 建立在 Azure Data Lake Storage Gen2 之上。^[5] 它繼承了 ADLS Gen2 的階層命名空間、安全模型和 API 相容性。使用 ADLS Gen2 的現有工具可以直接連接到 OneLake，無需修改。儲存階層為：租用戶 → 工作區 → 項目 → 表或檔案。

Delta Parquet — 通用格式

OneLake 中的所有表格資料都以 Delta Parquet 格式儲存。Delta Lake 在 Parquet 檔案之上添加交易日誌（_delta_log），支援 ACID 交易、版本控制、時間旅行和結構描述強制執行。^[5]

OneLake 捷徑（Shortcuts）

捷徑是對儲存在其他地方的資料的引用——另一個 Lakehouse、外部 Azure Data Lake、Amazon S3 儲存桶、Google Cloud Storage 或 Dataverse。^[5] 捷徑行為類似 Linux 符號連結。它們在 Lakehouse 中顯示為資料夾，但不包含實際資料副本。

V-Order 最佳化

Fabric 寫入 Delta 表時可以應用 V-Order——針對 Power BI 使用的 VertiPaq 引擎進行排序、壓縮和編碼的寫入時最佳化。V-Order 寫入略慢，但讀取速度顯著更快。

6. Lakehouse — 資料存放與轉換的場所

Microsoft Fabric 中的 Lakehouse 結合了資料湖的靈活性與資料庫的查詢便利性。^[6]

兩個儲存區域

• Files（檔案）區域：原始物件儲存。存放 CSV、Parquet、JSON、圖像——任何格式。這是銅層登陸區。檔案在轉換為 Delta 表之前無法通過 SQL 查詢。
• Tables（表）區域：在元存儲中註冊的 Delta 表。任何寫入此處的 Delta 表都自動對 Spark Notebook、SQL 查詢和 Power BI 可見。這是銀層和金層資料存放的地方。

SQL 分析端點

每個 Lakehouse 自動生成一個 SQL 分析端點——公開 Tables 區域中所有 Delta 表的唯讀 T-SQL 連接點。^[6] 您可以將 SSMS、Azure Data Studio 或任何 TDS 相容工具直接連接到此端點，無需編寫任何 Spark 程式碼。

7. Data Warehouse — 湖規模的 T-SQL

Fabric Data Warehouse 是完整交易式 T-SQL 引擎，將計算與儲存分離，以 Delta Parquet 格式在 OneLake 上儲存資料。^[7] Warehouse 中的每個表也可被 Spark Notebook 和其他 OneLake 連接工具讀取。

關鍵功能

• 完整 DML 支援：INSERT、UPDATE、DELETE、MERGE
• DDL：CREATE TABLE、CREATE VIEW、CREATE PROCEDURE、CREATE SCHEMA
• 跨資料庫查詢其他 Warehouse 和 Lakehouse
• 重複查詢的結果集快取
• 資料叢集（請參閱 SQLYARD 資料叢集文章）
• 從 OneLake、ADLS 和外部儲存的 COPY INTO
• 即席檔案查詢的 OPENROWSET

何時選擇 Warehouse 而非 Lakehouse

8. Pipeline 與 Data Factory — 編排資料流程

Fabric Pipeline 是所有需要按順序、按排程或有條件執行內容的編排引擎。如果您有 SSIS 或 ADF 背景，Pipeline 會立即感到熟悉。^[8]

核心 Pipeline 活動

• 複製資料（Copy Data）：從 200 多個連接器（SQL Server、Oracle、Salesforce、REST API、SFTP、SAP、SharePoint 等）擷取資料到 Lakehouse 或 Warehouse。
• Notebook 活動：將 Fabric Notebook 作為 Pipeline 步驟執行。傳遞參數以驅動動態行為。
• Dataflow Gen2 活動：將 Dataflow Gen2 作為編排步驟運行。
• 預存程序活動：呼叫 Warehouse 中的預存程序進行載入後轉換或資料品質檢查。
• If 條件 / ForEach / Until：用於條件分支和迴圈的控制流程活動。
• 失敗活動：當驗證檢查失敗時以自訂錯誤訊息顯式使 Pipeline 失敗。

SSIS 移轉的三條路徑

1. 重建為 Pipeline + Dataflow Gen2——推薦的長期路徑。
2. 遷移到 Azure Data Factory SSIS 整合執行階段——在 Azure 中運行現有套件同時逐步重建。
3. 混合方式：SSIS 將檔案存放到 OneLake 連接的儲存，Fabric Pipeline 接收和處理。

排程與觸發器

Pipeline 可由排程、儲存事件（新檔案進入 OneLake）或從另一個 Pipeline 呼叫來觸發。常見的生產模式是每日排程 Pipeline 運行完整的銅 → 銀 → 金鏈，失敗時發送電子郵件通知。

9. Dataflow Gen2 — 低程式碼轉換

Dataflow Gen2 是 Fabric 內建的基於 Power Query 的低程式碼 ETL 工具。分析師和業務使用者可以使用熟悉的類 Excel 介面連接來源、應用轉換，並將結果存入 Lakehouse 或 Warehouse——無需編寫程式碼。^[9]

何時使用 Dataflow Gen2

• 連接有清理和重塑需求的 Excel、SharePoint 清單或 CSV 檔案
• 無需 Spark 即可展平巢狀 JSON 或 XML 結構
• 業務分析師擁有的不需要 PySpark 的轉換
• 在 Notebook 中正式化之前快速原型化擷取邏輯
• 具有 Power BI Dataflow 經驗並移轉到 Fabric 的團隊

10. Notebook 與 Spark — 程式碼優先工程

Fabric Notebook 是附加到 Lakehouse 的瀏覽器型互動式程式碼環境，在受管理的 Apache Spark 上運行。^[10] 支援 Python（PySpark）、Scala、SQL 魔法命令（%%sql）和 R。

每天都會用到的 PySpark 模式

from pyspark.sql.functions import col, trim, to_date, when, lit, upper
from pyspark.sql.types import DecimalType

bronze_path = "Files/sales/raw/"
df_raw = spark.read.option("header", True).option("inferSchema", True).csv(bronze_path)
print(f"銅層行數：{df_raw.count()}")

df_silver = (
    df_raw
    .withColumn("order_date", to_date(col("order_date"), "yyyy-MM-dd"))
    .withColumn("customer_name", trim(col("customer_name")))
    .withColumn("product", trim(col("product")))
    .withColumn("country", upper(trim(col("country"))))
    .withColumn("quantity", when(col("quantity").isNull(), lit(0)).otherwise(col("quantity").cast("int")))
    .withColumn("amount", col("amount").cast(DecimalType(18,2)))
    .dropDuplicates(["order_id"])
    .filter(col("order_id").isNotNull())
)

silver_table_path = "abfss://fabric_workshop@onelake.dfs.fabric.microsoft.com/lakehouse_silver.Lakehouse/Tables/silver_sales_orders"
df_silver.write.mode("overwrite").option("overwriteSchema", "true").format("delta").save(silver_table_path)
spark.sql(f"OPTIMIZE delta.`{silver_table_path}` ZORDER BY (order_date, customer_id)")
print("銀層寫入完成。")

Notebook 參數

當 Notebook 從 Pipeline 運行時，您可以傳遞參數控制其行為——要處理的日期分區、來源表名稱或處理模式標誌。在第一個程式碼單元格上切換參數標記並在那裡宣告變數。

11. Direct Lake — 無需匯入重新整理的 BI

Direct Lake 是整個 Fabric 平台中技術上最重要的創新之一。^[11]

問題：匯入模式與 DirectQuery

• 匯入模式將資料複製到 Power BI 的 VertiPaq 記憶體引擎。報表速度快，但資料在排程重新整理之間會過時。大型資料集會達到記憶體限制。
• DirectQuery 模式在每次報表互動時對來源資料庫進行即時查詢。始終最新，但對複雜分析模型來說速度很慢。

Direct Lake：兩者的最佳結合

Direct Lake 是 Fabric 獨有的第三種模式。VertiPaq 引擎直接讀取 OneLake 中的 Delta Parquet 檔案——不通過資料庫查詢，也不通過預載入的匯入。結果是對始終最新的湖資料具有匯入速度的查詢效能，且無需排程重新整理。^[11]

如需深入了解，請參閱 SQLYARD 的 第二部分：Microsoft Fabric 中的 Direct Lake。

12. 即時智慧 — 串流與事件資料

對於 IoT 感測器、金融資料串流、應用程式日誌和使用者點擊串流，您需要以秒為單位新鮮的資料。這就是 Fabric 中即時智慧的用武之地。^[12]

關鍵即時元件

• Eventstream：串流資料的擷取 Pipeline。連接到 Azure Event Hubs、IoT Hub、Kafka 或自訂 REST 來源。應用即時轉換並路由到 KQL 資料庫或 Lakehouse 表。
• KQL 資料庫（Kusto）：時間序列最佳化的分析儲存。支援 Kusto 查詢語言，以每秒數百萬個事件的速度擷取，查詢延遲低於一秒。
• 即時中樞（Real-Time Hub）：所有串流資料來源的租用戶範圍目錄。跨工作區發現、連接和共享串流。
• Activator：基於規則的警報引擎。在串流資料上定義條件並自動觸發 Power Automate 流程、Teams 訊息或 Pipeline 運行。

請參閱 SQLYARD 的 第三部分：即時語意模型以獲得更深入的介紹。

13. 獎章架構 — 深入解說

獎章架構是在 Microsoft Fabric 中組織資料的最重要設計模式。Microsoft 將其推薦為 Fabric Lakehouse 的標準方法。^[13]

核心理念

資料品質在來源端降低，並隨著每次轉換而提升。獎章模型通過將資料湖分成三個不同的品質層來正式化這一點，每個層以貴金屬命名。

為何需要三層而非一層？

• 無恢復路徑：如果轉換邏輯有錯誤，原始資料已被覆蓋且丟失。
• 結構描述耦合：每次來源系統更改結構描述時，報表就會中斷。
• 混合關注點：原始擷取邏輯、清理規則和聚合程式碼都在同一個地方，無法隔離和修復問題。
• 無審計追蹤：法規要求通常需要您證明轉換前原始資料的樣子。

三種推薦的實體模式

ACID 合規性與獎章模型

Delta Lake 的 ACID 交易支援意味著每次寫入銀層或金層 Delta 表都是一個交易。如果 Notebook 在寫入中途失敗，表不會損壞——不完整的交易被回滾，之前的版本保持完整。^[13]

獎章層參考摘要

14. 實作工作坊 — 從初學到進階

本工作坊從頭建立完整的獎章 Lakehouse。按順序完成各階段——每個階段都依賴前一個。最終您將擁有連接到 Power BI Direct Lake 報表的完整銅 → 銀 → 金 Pipeline。

階段 1 — 初學者：設定工作區和 Lakehouse

階段 2 — 初學者/中級：第一個 Pipeline 和銅層擷取

階段 3 — 中級：使用 PySpark 進行銀層轉換

from pyspark.sql.functions import col, trim, to_date, when, lit, upper
from pyspark.sql.types import DecimalType

bronze_path = "Files/sales/raw/"
df_raw = spark.read.option("header", True).option("inferSchema", True).csv(bronze_path)
print(f"銅層行數：{df_raw.count()}")

df_silver = (
    df_raw
    .withColumn("order_date", to_date(col("order_date"), "yyyy-MM-dd"))
    .withColumn("customer_name", trim(col("customer_name")))
    .withColumn("product", trim(col("product")))
    .withColumn("country", upper(trim(col("country"))))
    .withColumn("quantity", when(col("quantity").isNull(), lit(0)).otherwise(col("quantity").cast("int")))
    .withColumn("amount", col("amount").cast(DecimalType(18,2)))
    .dropDuplicates(["order_id"])
    .filter(col("order_id").isNotNull())
)

silver_table_path = "abfss://fabric_workshop@onelake.dfs.fabric.microsoft.com/lakehouse_silver.Lakehouse/Tables/silver_sales_orders"
df_silver.write.mode("overwrite").option("overwriteSchema", "true").format("delta").save(silver_table_path)
spark.sql(f"OPTIMIZE delta.`{silver_table_path}` ZORDER BY (order_date, customer_id)")
print("銀層寫入完成。")

SELECT TOP 10 * FROM silver_sales_orders ORDER BY order_date DESC;

階段 4 — 中級：帶星型結構的金層

df_sales = spark.read.format("delta").load(
    "abfss://fabric_workshop@onelake.dfs.fabric.microsoft.com/lakehouse_silver.Lakehouse/Tables/silver_sales_orders"
)
gold_base = "abfss://fabric_workshop@onelake.dfs.fabric.microsoft.com/lakehouse_gold.Lakehouse/Tables/"

# 客戶維度表
df_dim_customer = df_sales.select("customer_id","customer_name","country").dropDuplicates(["customer_id"]).withColumnRenamed("customer_id","customer_key")
df_dim_customer.write.mode("overwrite").format("delta").save(gold_base + "dim_customer")

# 日期維度表
from pyspark.sql.functions import year, month, date_format, quarter
df_dim_date = (df_sales.select("order_date").dropDuplicates()
    .withColumn("year", year("order_date"))
    .withColumn("month", month("order_date"))
    .withColumn("quarter", quarter("order_date"))
    .withColumn("month_name", date_format("order_date","MMMM"))
    .withColumn("year_month", date_format("order_date","yyyy-MM")))
df_dim_date.write.mode("overwrite").format("delta").save(gold_base + "dim_date")

# 銷售事實表
df_fact_sales = df_sales.select(
    col("order_id").cast("string"),
    col("order_date"),
    col("customer_id").alias("customer_key"),
    col("product"),
    col("quantity").cast("int"),
    col("amount").cast("decimal(18,2)"))
df_fact_sales.write.mode("overwrite").format("delta").save(gold_base + "fact_sales")
spark.sql(f"OPTIMIZE delta.`{gold_base}fact_sales` ZORDER BY (order_date, customer_key)")
print("金層完成。")

階段 5 — 中級/進階：主 Pipeline 編排

階段 6 — 進階：Direct Lake 語意模型和 Power BI

總營收 = SUM(fact_sales[amount])
訂單數 = DISTINCTCOUNT(fact_sales[order_id])
平均訂單金額 = DIVIDE([總營收], [訂單數])
年初至今營收 = TOTALYTD([總營收], dim_date[order_date])

階段 7 — 進階：增量處理和水位線

from pyspark.sql.functions import max as spark_max, lit
from datetime import datetime

watermark_table = "abfss://fabric_workshop@onelake.dfs.fabric.microsoft.com/lakehouse_silver.Lakehouse/Tables/etl_watermark"

try:
    df_watermark = spark.read.format("delta").load(watermark_table)
    last_processed = df_watermark.filter(col("table_name") == "silver_sales_orders").select("last_updated_ts").collect()[0][0]
except:
    last_processed = datetime(2000, 1, 1)

print(f"上次處理時間戳：{last_processed}")

df_new = spark.read.format("delta").load("abfss://.../lakehouse_bronze.Lakehouse/Tables/bronze_sales").filter(col("ingested_ts") > lit(last_processed))
df_new_silver = transform_to_silver(df_new)

from delta.tables import DeltaTable
silver_dt = DeltaTable.forPath(spark, "abfss://.../lakehouse_silver.Lakehouse/Tables/silver_sales_orders")
silver_dt.alias("target").merge(df_new_silver.alias("source"), "target.order_id = source.order_id").whenMatchedUpdateAll().whenNotMatchedInsertAll().execute()

new_max_ts = df_new_silver.select(spark_max("ingested_ts")).collect()[0][0]
spark.createDataFrame([("silver_sales_orders", new_max_ts)], ["table_name","last_updated_ts"]).write.mode("overwrite").format("delta").save(watermark_table)
print(f"水位線更新至：{new_max_ts}")

15. 治理、網域與安全性

沒有治理的分析平台是一種負擔。Fabric 提供對應大多數企業組織方式的分層治理模型。^[4]

租用戶級管理

Fabric 管理員入口網站控制租用戶範圍的原則：啟用哪些工作負載類型、誰可以建立工作區、外部共享許可權和資料居住設定。對於企業部署，將工作區建立限制為已核准的群組，並在任何新工作區投入生產之前要求容量分配審查。

工作區和角色

每個工作區有四個內建角色：管理員、成員、參與者和檢視者。對於獎章部署的常見模式：資料工程團隊在銅層和銀層上具有參與者權限；BI 團隊在銀層上具有檢視者權限，在金層上具有參與者權限；資料消費者在金層上只有檢視者權限。

網域（Domains）

網域是位於工作區上方的邏輯分組機制。財務網域可能包含財務銅層、銀層、金層和報表工作區。網域啟用了網域級管理員、敏感度原則和 OneLake 目錄中的發現——這是 Fabric 中資料網格架構的基礎。

Microsoft Purview 整合

每個 Fabric 項目都自動編目於 Microsoft Purview。敏感度標籤從 Lakehouse 表自動傳播到任何使用它的 Power BI 報表。沿襲圖顯示資料如何從來源流經銅層、銀層、金層到達報表。

列級安全性

在 Warehouse 中，RLS 通過 SQL 安全性謂詞實施——與 SQL Server 中使用的相同機制。在語意模型中，RLS 使用 DAX 篩選運算式定義。兩者都正確適用於 Direct Lake 模型。

16. 成本與容量規劃

Fabric 按 Fabric 容量單位（CU）計費。每個工作負載——Spark、Warehouse 查詢、Pipeline、Power BI 重新整理——都消耗已分配容量中的 CU。^[14]

關鍵成本原則

• 容量平滑：允許短暫超出容量的峰值，超出部分在接下來的 24 小時內平滑，而不是立即造成節流。
• 暫停和恢復：不使用時可以暫停容量——暫停的容量不收費。使用 Fabric REST API 或 Azure Automation 自動化暫停/恢復。
• OneLake 儲存：按 GB 單獨計費，每 TB 費率低。儲存成本很少是主要費用。
• 預訂折扣：1 年和 3 年承諾與隨用隨付相比可降低 40–60% 的 CU 成本。

如需詳細成本分析，請參閱 SQLYARD 的 Fabric 成本分析文章。

17. 最終想法

Microsoft Fabric 代表了自 Azure 推出以來 Microsoft 資料平台最重大的轉變。它不是對 Synapse 或 ADF 的漸進式改進——它是對分析基礎架構應如何運作的全新思考：統一儲存、共享計算、開放格式，以及跨每個工作負載的單一治理模型。

獎章架構為 Fabric 部署提供了隨著成長保持可維護性所需的結構性紀律。銅層保護您的原始資料安全。銀層使其在技術上值得信賴。金層使其對業務有用。當出現問題——資料領域總是會出現問題——您在每一層都有清晰的恢復路徑。

對於 SQL Server 和 Azure SQL DBA 來說，Fabric 不是替代您現有技能的工具——它是對這些技能的延伸。Warehouse 使用 T-SQL。Lakehouse 中的 SQL 分析端點使用 T-SQL。Direct Lake 消除了使大型 Power BI 部署變得痛苦的匯入/重新整理複雜性。您的 SQL 專業知識可以直接移轉並立即產生價值。

如果您剛開始：建立試用版，建立工作區，將 CSV 放入 Lakehouse，寫三行 PySpark，在 SQL 分析端點查詢結果。整個循環不到 30 分鐘，您學到的一切直接擴展到企業部署。

18. Fabric 資料代理人 — 與您的資料對話的 AI

Fabric 資料代理人（Fabric Data Agent）是整個 Fabric 平台中最實用的 AI 功能之一。於 2025 年 Microsoft Ignite 大會宣布並目前處於預覽階段，它讓任何使用者——無論是否具備技術背景——都能以純中文（或英文）提問關於 OneLake 中儲存的資料，並在不需要編寫任何 SQL、DAX 或 KQL 的情況下獲得準確、受治理的答案。^[21]

它解決了什麼問題？

在大多數組織中，從資料中獲得答案仍然需要編寫查詢、建立報表，或向 BI 團隊提交工單。需要快速答案的主管、營運經理和業務主管因缺乏技術技能而受阻。Fabric 資料代理人從根本上改變了這一點——使用者可以簡單地問「上季度加州的總銷售額是多少？」，代理人就會自動撰寫查詢、對正確的資料來源執行查詢，並返回可讀的答案，同時顯示底層查詢以確保透明度。

運作原理

Fabric 資料代理人使用大型語言模型（LLM）幫助使用者自然地與資料互動，應用 Azure OpenAI Assistant API 並以代理人方式運作。當提交問題時：

1. 代理人解析自然語言問題
2. 使用使用者自己的憑證和權限識別最相關的資料來源
3. 根據來源生成適當的查詢——T-SQL、DAX 或 KQL
4. 執行查詢並返回純文字答案以及查詢本身

重要的是，代理人絕不繞過安全性。它完全在請求使用者現有的列級安全性、欄級安全性和工作區權限範圍內運作。如果使用者無法直接查看某些資料，代理人也無法呈現這些資料。

支援的資料來源

Fabric 資料代理人支援最多五個資料來源的任意組合，包括 Lakehouse、Warehouse、KQL 資料庫、Power BI 語意模型、本體（Ontology）和 Microsoft Graph。這意味著單一代理人可以同時回答跨越您的金層 Lakehouse、Warehouse 和現有 Power BI 語意模型的問題——使用者無需知道或關心答案來自哪個系統。

設定資料代理人

您是 SQLYARD Corp 的銷售分析助理。
您可以存取銷售訂單、客戶資料和產品表。
- 「營收」始終表示 fact_sales 中 amount 欄的總和
- 「活躍客戶」是指過去 90 天內至少有一筆訂單的客戶
- 除非使用者另有指定，否則始終篩選當前會計年度
- 不要返回個別客戶的個人識別資訊——僅返回聚合資料

與 Copilot、Teams 和 Copilot Studio 的整合

發布後，資料代理人可以在多個地方呈現。業務使用者可以直接從 Power BI 中的 Copilot 查詢它，無需切換應用程式。開發人員可以將其連接到 Microsoft Copilot Studio，以建立將代理人作為更廣泛工作流程一部分的自訂組織 Copilot。它還支援模型上下文協定（MCP），支援與整個 Microsoft 生態系統中其他 AI 代理人的互通性。

19. Fabric IQ — 語意智慧層（預覽）

Fabric IQ 是 Microsoft Fabric 平台最新也是最具雄心的新增功能。於 2025 年 Microsoft Ignite 大會宣布，Fabric IQ 是一個由語意理解和代理式 AI 驅動的統一智慧平台——它代表了 Fabric 設計目標的根本性轉變。如果說 Fabric 的其餘部分是關於儲存、移動和查詢資料，那麼 Fabric IQ 就是賦予這些資料意義。^[22]

Fabric IQ 解決的問題

即使是工程最完善的資料平台也有一個盲點：它儲存資料但不儲存意義。您的金層 Lakehouse 有一個 customer_id 欄，但它不知道在您的業務中「客戶」與「潛在客戶」有何不同，「營收」不包括退款，或「活躍資產」對您的營運團隊有特定含義。這種語意知識存在於人們的腦海中、文件中，以及散落在報表和試算表中的不一致定義裡。沒有這種基礎，AI 就無法推理連鎖影響、約束條件或目標。Fabric IQ 通過提供一個正式定義業務意義的地方來解決這個問題——並使其對您 Fabric 環境中的每個工具、報表和 AI 代理人都可用。

Fabric IQ 的關鍵元件

本體（Ontology）— 預覽

Fabric IQ 的核心是本體項目，它引入了將人員、流程、系統、動作、規則和資料連接到統一本體中的語意基礎。您定義業務實體（客戶、產品、資產、訂單）、它們的屬性以及它們之間的關係。然後，您將這些實體綁定到 Lakehouse、Warehouse 和語意模型中的實際表。一旦綁定，每個接觸這些表的 AI 代理人、報表和查詢都能理解它們在業務術語中代表什麼——而不僅僅是原始欄名稱。

Fabric Graph

定義本體後，Fabric 會自動建立一個可導覽的 Fabric Graph——您業務實體如何相互關聯的視覺化、可查詢表示。這不是一個圖表工具；它是一個即時的、可查詢的知識圖譜。AI 代理人可以遍歷它來理解多跳關係：影響供應商的供應鏈中斷會影響零件，進而影響產品，再影響訂單——圖譜使這種推理鏈明確且自動化。

營運代理人（Operations Agent）— 預覽

Fabric 中的營運代理人持續即時監控您的業務，對即時狀況進行推理，評估取捨，並自動採取行動以推進所需的業務成果。它們以本體定義、規則和動作作為行動手冊。例如：監控物流網路的營運代理人可以檢測交付約束何時被違反，根據業務規則評估替代路線，並觸發適當的工作流程——無需人工介入。

計畫（Plan）— 預覽

計畫消除了對獨立規劃工具或基於試算表的工作流程的需求，讓組織能夠在共享語意模型上整合目標、計畫和實際結果。財務團隊可以直接在受治理的 Fabric 資料之上建立預算、預測、目標和情境模型。預測安全地回寫並立即流經連接的 Power BI 報表——無需匯出到 Excel，無版本控制噩夢，無過時數字。

Fabric IQ 如何與其他一切連接

Fabric IQ 通過將來自 OneLake 的各種來源（如 Lakehouse、Eventhouse 和 Power BI 語意模型）的資料合併到單一一致模型中，實現了分析和操作資料的統一。本體作為共享語意層位於所有這些之上。當資料代理人（第 18 節）以本體為基礎時，其準確性會顯著提高——它不再需要從欄名稱猜測含義，而是讀取您正式宣告的業務定義。

誰應該現在開始探索 Fabric IQ？

Fabric IQ 處於預覽階段，最適合以下組織：

• 已經擁有成熟的獎章 Lakehouse 和乾淨的金層表格
• 正在處理跨團隊和報表的不一致業務定義
• 希望建立能夠推理業務背景而不僅僅是查詢資料的 AI 代理人
• 規劃和預算流程仍在不連接的 Excel 試算表中運行
• 正在評估需要有根基、受治理決策的代理式 AI 使用案例

如需官方文件，請從 Microsoft Learn — 什麼是 Fabric IQ？ 和 Microsoft Learn — Fabric 資料代理人 開始。

參考資料

1. Microsoft Learn — 什麼是 Microsoft Fabric？
2. Microsoft Fabric 部落格 — 正式發布（2023年11月）
3. Microsoft Learn — OneLake，資料的 OneDrive
4. Microsoft Learn — Microsoft Fabric 中的治理與合規
5. Microsoft Learn — OneLake 概述與架構
6. Microsoft Learn — Microsoft Fabric 中的 Lakehouse 是什麼？
7. Microsoft Learn — Microsoft Fabric 中的資料倉儲是什麼？
8. Microsoft Learn — Microsoft Fabric 中的 Data Factory
9. Microsoft Learn — Dataflow Gen2 概述
10. Microsoft Learn — Fabric Notebook
11. Microsoft Learn — Direct Lake 概述
12. Microsoft Learn — Microsoft Fabric 中的即時智慧
13. Microsoft Learn — 在 Fabric 中實施獎章 Lakehouse 架構
14. Microsoft Learn — Microsoft Fabric 授權與容量 SKU
15. SQLYARD — 建立 Microsoft Fabric 獎章 Lakehouse + Warehouse
16. SQLYARD — 從擷取到洞察：Microsoft Fabric 中的實用資料工程
17. SQLYARD — Fabric 成本分析詳解
18. Microsoft Learn — Fabric 中的 Delta 最佳化與 V-Order
19. Microsoft Learn — Lakehouse 與 Warehouse：更好的組合
20. Microsoft Learn — Lakehouse 端到端情境教學
21. Microsoft Learn — Fabric 資料代理人概述
22. Microsoft Learn — 什麼是 Fabric IQ（預覽）？