Microsoft網狀架構決策指南：選擇數據存放區
使用此參考指南和範例案例，協助您為Microsoft網狀架構工作負載選擇數據存放區。
數據存放區屬性
使用這項資訊，根據數據量、類型、開發人員角色、技能集、作業和其他功能，比較 Fabric 資料存放區，例如倉儲、Lakehouse、Eventhouse、SQL 資料庫和 Power BI Datamart。 這些比較會組織成下列兩個數據表：
| 表格 1 之 2 | 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、連接器生態系統 |
| 多資料表交易 | 不 | 是的 | 是，適用於 多數據表擷取 |
| 主要開發介面 | Spark 筆記本、Spark 作業定義 | SQL 腳本 | KQL 查詢集、KQL 資料庫 |
| 安全性 | RLS、CLS**、表格層級（T-SQL），Spark 不支援 | 物件層級、RLS、CLS、DDL/DML、動態數據遮罩 | RLS |
| 透過快捷方式存取資料 | 是的 | 是，透過 SQL 分析端點 | 是的 |
| 可以是快捷方式的來源 | 是 （檔案和資料表） | 是（表格） | 是的 |
| 跨項目查詢 | 是的 | 是的 | 是的 |
| 進階分析 | 大規模數據處理、內建數據平行處理原則和容錯的介面 | 大規模數據處理、內建數據平行處理原則和容錯的介面 | 時間序列原生元素、完整的地理空間和查詢功能 |
| 進階格式支援 | 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 相容檔格式定義的數據表 | 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 相容檔格式定義的數據表 | 自由文本和像 JSON 這樣的半結構化數據的完整索引 |
| 匯入延遲 | 立即可供查詢 | 立即可供查詢 | 佇列擷取，串流擷取有幾秒鐘的延遲 |
* Spark 支援使用快捷方式從資料表讀取，尚不支援存取檢視、預存程式、函式等。
| 表 2/2 | Fabric SQL 資料庫 | Power BI Datamart |
|---|---|---|
| 數據磁碟區 | 4 TB | 最多 100 GB |
| 數據類型 | 有組織的 半結構化， 非結構化 |
有系統的 |
| 主要開發人員角色 | AI 開發人員、應用程式開發人員、資料庫開發人員、資料庫管理員 | 數據科學家，數據分析師 |
| 主要開發技能 | SQL | 無程式碼，SQL |
| 根據 整理的數據 | 資料庫、架構、數據表 | 資料庫、數據表、查詢 |
| 讀取作業 | T-SQL | Spark、T-SQL |
| 寫入操作 | T-SQL | 數據流、T-SQL |
| 多個表格交易 | 是，完整 ACID 合規性 | 不 |
| 主要開發介面 | SQL 腳本 | Power BI |
| 安全性 | 物件層級、RLS、CLS、DDL/DML、動態數據遮罩 | 內建 RLS 編輯器 |
| 透過快捷方式存取資料 | 是的 | 不 |
| 可以是快捷方式的來源 | 是（表格） | 不 |
| 跨項目查詢 | 是的 | 不 |
| 進階分析 | T-SQL 分析功能，數據復寫至 OneLake 中的 Delta Parquet 用於分析 | 使用自動化效能微調進行數據處理的介面 |
| 進階格式支援 | 對 OLTP、JSON、向量、圖形、XML、空間、鍵值等類型的表格格式提供支援 | 使用 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 入口網站中使用 SQL 編輯器，Susan 和其他小組成員撰寫分析查詢，只要使用三部分名稱來執行跨資料庫查詢，即可參考 Lakehouses 中的其他數據倉儲和 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 datamart，這可讓小組使用無程式代碼體驗快速互動建置功能。 查詢也可以透過Power BI和 T-SQL 執行，同時允許組織中的任何Spark使用者存取數據。
案例 4
Daisy 是商務分析師，曾使用Power BI分析大型全球零售連鎖店的供應鏈瓶頸。 他們需要建置可調整的數據解決方案，以處理數十億個數據列，並可用來建置可用來做出商務決策的儀錶板和報表。 這些數據來自各種結構化、半結構化和非結構化格式的工廠、供應商、貨運公司和其他來源。
Daisy 決定使用 Eventhouse，因為它的延展性、快速響應時間、進階分析功能，包括時間序列分析、地理空間函式，以及 Power BI 中的快速直接查詢模式。 您可以使用Power BI和 KQL 來執行查詢，以比較目前和先前的期間、快速找出新興的問題，或提供陸地和海上路線的地理空間分析。
案例 5
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 資料庫。