共用方式為


Microsoft Fabric 決策指南:選擇資料存放區

使用此參考指南和範例案例,協助您針對 Microsoft Fabric 工作負載選擇資料存放區。

資料存放區屬性

使用這項資訊,根據數據量、類型、開發人員角色、技能集、作業和其他功能,比較 Fabric 資料存放區,例如倉儲、Lakehouse、Eventhouse、SQL 資料庫和 Power BI Datamart。 這些比較會組織成下列兩個數據表:

Lakehouse 倉儲 Eventhouse
資料量 無限制 無限制 無限制
資料類型
半結構化,
結構化
結構
半結構化 (JSON)

半結構化,
結構化
主要開發人員角色 資料工程師,資料科學家 數據倉儲開發人員,數據架構師,數據工程師,資料庫開發人員 應用程式開發人員、數據科學家、數據工程師
主要開發技能 Spark (Scala、PySpark、Spark SQL、R) SQL 無程式碼、KQL、SQL
資料組織依據 資料夾和檔案、資料庫和資料表 資料庫、結構描述和資料表 資料庫、結構描述和資料表
讀取作業 Spark、T-SQL T-SQL,Spark* KQL、T-SQL、Spark
寫入作業 Spark (Scala、PySpark、Spark SQL、R) T-SQL KQL、Spark、連接器生態系統
多資料表交易 No Yes 是,用於 多重數據表擷取
主要開發介面 Spark 筆記本、Spark 作業定義 SQL 指令碼 KQL 查詢集、KQL 資料庫
安全性 RLS、CLS**、 數據表層級 (T-SQL),無 Spark 物件層級RLS、CLS、DDL/DML、動態數據遮罩 RLS
透過捷徑存取資料 Yes Yes Yes
可以是捷徑的來源 是 (檔案和資料表) 是 (資料表) Yes
跨項目查詢 Yes Yes Yes
進階分析 大規模數據處理、內建數據平行處理原則和容錯的介面 大規模數據處理、內建數據平行處理原則和容錯的介面 時間序列原生元素、完整的地理空間和查詢功能
進階格式支援 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 相容檔格式定義的數據表 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 相容檔格式定義的數據表 免費文字和半結構化資料的完整索引編製,例如 JSON
擷取延遲 立即可供查詢 立即可供查詢 佇列擷取,串流擷取有幾秒鐘的延遲

* Spark 支援使用快捷方式從資料表讀取,尚不支援存取檢視、預存程式、函式等。

網狀架構 SQL 資料庫 Power BI 資料超市
資料量 4 TB 最多 100 GB
資料類型 結構
半結構化,
非結構化
結構化
主要開發人員角色 AI 開發人員、應用程式開發人員、資料庫開發人員、資料庫管理員 數據科學家,數據分析師
主要開發技能 SQL 無程式碼、SQL
資料組織依據 資料庫、架構、數據表 資料庫、資料表、查詢
讀取作業 T-SQL Spark、T-SQL
寫入作業 T-SQL 資料流程、T-SQL
多資料表交易 是,完整 ACID 合規性 No
主要開發介面 SQL 指令碼 Power BI
安全性 物件層級、RLS、CLS、DDL/DML、動態數據遮罩 內建 RLS 編輯器
透過捷徑存取資料 Yes No
可以是捷徑的來源 是 (資料表) No
跨項目查詢 Yes No
進階分析 T-SQL 分析功能,數據復寫至 OneLake 中的差異 Parquet 以進行分析 使用自動化效能微調進行數據處理的介面
進階格式支援 OLTP、JSON、vector、graph、XML、spatial、key-value 的數據表支援 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 相容檔格式定義的數據表
擷取延遲 立即可供查詢 立即可供查詢

** 使用 T-SQL 透過 SQL 分析端點在 Lakehouse 上提供的數據行層級安全性。

案例

請檢閱這些案例,以協助您選擇 Fabric 中的資料存放區。

案例 1

專業開發人員 Susan 是 Microsoft Fabric 的新手。 他們已準備好開始清理、模型化和分析數據,但需要決定建置數據倉儲或 Lakehouse。 檢閱上表的詳細資料之後,主要決策點是可用的技能集,以及多資料表交易的需求。

Susan 已花費數年時間在關聯式資料庫引擎上組建資料倉儲,並熟悉 SQL 語法和功能。 考慮到更大的團隊,此資料的主要使用者也精通 SQL 和 SQL 分析工具。 Susan 決定使用 Fabric 倉儲,這可讓小組主要與 T-SQL 互動,同時允許組織中的任何 Spark 使用者存取數據。

Susan 會建立新的數據倉儲,並使用 T-SQL 與其互動,就像她的其他 SQL 伺服器資料庫一樣。 她為在 SQL Server 上建置倉儲而撰寫的大部分現有 T-SQL 程式代碼,都會在 Fabric 數據倉儲上運作,讓轉換變得容易。 如果她選擇,她甚至可以使用相同的工具來處理其他資料庫,例如SQL Server Management Studio。 在 Fabric 入口網站中,Susan 和其他小組成員使用 SQL 編輯器撰寫分析查詢,參考湖庫中的其他資料庫和 Delta 資料表,並只需使用三段式名稱,即可執行跨資料庫查詢。

案例 2

資料工程師 Rob 需要在 Fabric 中儲存並建立數 TB 資料的模型。 團隊混合了 PySpark 和 T-SQL 技能。 執行 T-SQL 查詢的大部分團隊都是取用者,因此不需要寫入 INSERT、UPDATE 或 DELETE 陳述式。 其餘開發人員在筆記本中工作很自在,而且因為資料儲存在 Delta 中,所以能夠與類似的 SQL 語法互動。

Rob 決定使用 Lakehouse,這可讓資料工程團隊針對資料使用其多樣化技能,同時允許 T-SQL 中高技能的小組成員取用資料。

案例 3

Ash 是公民開發者,是 Power BI 開發人員。 他們熟悉 Excel、Power BI 和 Office。 他們需要為營業單位組建資料產品。 他們知道,他們不太具備組建資料倉儲或 Lakehouse 的技能,而且那些對於他們的需求和資料量而言似乎超出所需了。 他們檢閱了上表的詳細資料,並看到主要決策點在於他們自身的技能、對自助服務和無代碼能力的需求,以及資料量低於 100 GB。

Ash 與熟悉 Power BI 和 Microsoft Office 的商務分析師合作,並知道他們已經有 Premium 容量訂用帳戶。 當他們考慮其較大的小組時,他們意識到此數據的主要取用者是分析師,熟悉無程式代碼和 SQL 分析工具。 Ash 決定使用 Power BI 資料超市,這可讓團隊使用無程式碼體驗快速互動組建功能。 查詢也可以透過 Power BI 和 T-SQL 執行,同時允許組織中的任何 Spark 使用者存取資料。

案例 4

Daisy 是一位商務分析師,曾使用 Power BI 分析大型全球零售連鎖店的供應鏈瓶頸。 他們需要建置可調整的資料解決方案,以處理數十億個資料列,並可用來建置可用於制定商務決策的儀表板和報表。 這些資料來自各種結構化、半結構化和非結構化格式的工廠、供應商、貨運公司和其他來源。

Daisy 決定使用 Eventhouse ,因為它的延展性、快速響應時間、進階分析功能,包括時間序列分析、地理空間函式,以及 Power BI 中的快速直接查詢模式。 您可以使用 Power BI 和 KQL 來執行查詢,以比較目前和先前的期間,快速找出新興的問題,或提供陸地和海上路線的地理空間分析。

案例 5

Kirby 是開發適用於作業數據的 .NET 應用程式時所經歷的應用程式架構師。 他們需要具有完整 ACID 交易合規性的高並行資料庫,並針對關係型完整性強式強制執行外鍵。 Kirby 希望自動調整效能的優點,以簡化日常資料庫管理。

Kirby 決定在 Fabric 中使用與 Azure SQL 資料庫 相同的 SQL 資料庫 引擎來決定 SQL 資料庫。 Fabric 中的 SQL 資料庫會自動調整以符合整個工作日的需求。 它們具有交易數據表的完整功能,以及交易隔離等級從可串行化到讀取認可快照集的彈性。 Fabric 中的 SQL 資料庫會根據一段時間觀察到的執行計劃強式訊號,自動建立和卸除非叢集索引。

在 Kirby 的案例中,作業應用程式的數據必須與其他 Fabric 中的數據聯結:在 Spark 中、倉儲中,以及來自 Eventhouse 中的實時事件。 每個網狀架構資料庫都包含 SQL 分析端點,因此使用 DirectLake 模式從 Spark 或 Power BI 查詢即時存取數據。 這些報告解決方案會讓主要作業資料庫免於分析工作負載的額外負荷,並避免反正規化。 Kirby 在其他 SQL 資料庫中也有現有的作業數據,而且需要匯入該數據而不需轉換。 若要匯入現有的作業數據,而不需要任何數據類型轉換,Kirby 會使用 Fabric Data Factory 設計數據管線,以將數據匯入 Fabric SQL 資料庫。