使用此參考指南和範例案例來協助您選擇 Microsoft Fabric 工作負載的資料存放區，所有這些都可在 OneLake 的統一儲存體中使用。
| 理想使用案例 | Microsoft Fabric 工作負載 | 依預設， OneLake 中會以開放資料表格式提供資料 |
|---|---|---|
| 串流事件資料、高精細度 （時間、空間、詳細資料 – JSON/文字） 活動資料，用於互動式分析 | Eventhouse | 是的 |
| AI、NoSQL 和向量搜尋 | Fabric 中的 Cosmos DB （預覽版） | 是的 |
| 作業交易式資料庫、OLTP 資料庫 | Fabric 中的 SQL 資料庫 （預覽版） | 是的 |
| 企業數據倉庫、基於 SQL 的 BI、OLAP、 完整的 SQL 事務支持 | 資料倉儲 | 是的 |
| 大數據與機器學習、非/半/結構化數據、 數據工程 | Lakehouse | 是的 |
角色和技能組合
| Microsoft Fabric 工作負載 | 主要開發人員角色 | 主要技能集、工具 | 主要語言 |
|---|---|---|---|
| Eventhouse | 應用程式開發人員、資料科學家、資料工程師 | 無程序代碼、KQL、SQL | KQL （Kusto 查詢語言）、T-SQL |
| Fabric 中的 Cosmos DB （預覽版） | AI開發者、App開發者 | NoSQL 概念、REST API，類似於 Azure Cosmos DB | 透過 JavaScript/TypeScript、Python、C#、Java 等整合 REST API |
| Fabric 中的 SQL 資料庫 （預覽版） | AI 開發人員、應用程式開發人員、資料庫開發人員、資料庫管理員 | 資料庫管理和開發，類似於 Azure SQL 資料庫、SSMS、VS Code 和 SQL Server 相容的查詢工具 | T-SQL |
| 網狀架構數據倉儲 | 資料倉儲開發人員、資料架構師、資料工程師、資料庫開發人員 | 資料倉儲概念、 星狀結構描述資料庫設計、SSMS、VS Code 和 SQL Server 相容查詢工具 | T-SQL，無程式碼 |
| Lakehouse | 資料工程師、資料科學家 | PySpark、Delta Lake、筆記本 | Spark （Scala、PySpark、Spark SQL、R） |
場景
請檢閱這些案例，以協助選擇 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 入口網站中使用 SQL 編輯器，Susan 和其他小組成員撰寫分析查詢，只要使用三部分名稱來執行跨資料庫查詢，即可參考 Lakehouses 中的其他數據倉儲和 Delta 數據表。
案例 2
數據工程師 Rob 需要在 Fabric 中儲存並建立數 TB 數據的模型。 小組混合了 PySpark 和 T-SQL 技能。 執行 T-SQL 查詢的大部分小組都是取用者，因此不需要撰寫 INSERT、UPDATE 或 DELETE 語句。 其餘開發人員在筆記本中工作很自在，而且因為數據儲存在 Delta 中，所以能夠與類似的 SQL 語法互動。
Rob 決定使用 lakehouse，這可讓數據工程小組運用其多樣化技能處理數據，同時讓在 T-SQL 中技術高超的小組成員能夠存取和使用數據。
案例 3
Daisy 是商務分析師，曾使用Power BI分析大型全球零售連鎖店的供應鏈瓶頸。 他們需要建置可調整的數據解決方案，以處理數十億個數據列，並可用來建置可用來做出商務決策的儀錶板和報表。 這些數據來自各種結構化、半結構化和非結構化格式的工廠、供應商、貨運公司和其他來源。
Daisy 決定使用 Eventhouse，因為它的延展性、快速響應時間、進階分析功能，包括時間序列分析、地理空間函式，以及 Power BI 中的快速直接查詢模式。 您可以使用Power BI和 KQL 來執行查詢，以比較目前和先前的期間、快速找出新興的問題，或提供陸地和海上路線的地理空間分析。
案例 4
Kirby 是一位應用程式架構師，擅長開發用於作業資料的 .NET 應用程式。 他們需要一個具備完整 ACID 交易合規性和能強制執行外鍵以維護關聯完整性的高併發資料庫。 Kirby 希望自動調整效能的優點，以簡化日常資料庫管理。
Kirby 決定在 Fabric中使用的 SQL Database，其 SQL Database 引擎與 Azure SQL Database 相同。 Fabric 中的 SQL 資料庫會自動調整以符合整個工作日的需求。 它們具有交易數據表的完整功能，以及交易隔離等級從可串行化到讀取認可快照集的彈性。 Fabric 中的 SQL 資料庫會根據長時間觀察到的執行計劃中強烈信號，自動建立和移除非叢集索引。
在 Kirby 的案例中，操作應用程式的數據必須與其他 Fabric 中的數據進行聯結：在 Spark 中、在倉儲中，以及來自 Eventhouse 的實時事件。 每個網狀架構資料庫都包含 SQL 分析端點，因此使用 DirectLake 模式從 Spark 或 Power BI 查詢即時存取數據。 這些報告解決方案會讓主要作業資料庫免於分析工作負載的額外負荷，並避免反正規化。 Kirby 在其他 SQL 資料庫中也有現有的作業數據，而且需要匯入該數據而不需轉換。 若要匯入現有的作業資料而不進行任何資料類型轉換，Kirby 會使用 Fabric Data Factory 設計管線，以將資料匯入 Fabric SQL 資料庫。