Microsoft網狀架構決策指南:選擇數據存放區
使用此參考指南和範例案例,協助您為Microsoft網狀架構工作負載選擇數據存放區。
數據存放區屬性
此數據表會根據數據量、類型、開發人員角色、技能集、作業,比較倉儲、Lakehouse、Power BI datamart 和 eventhouse 等數據存放區。 和其他功能。
倉庫 | Lakehouse | Power BI Datamart | Eventhouse | |
---|---|---|---|---|
數據量 | 無限制 | 無限制 | 最多 100 GB | 不限定 |
資料類型 | 結構化 | 非結構化、半結構化、結構化 | 結構化 | 非結構化、半結構化、結構化 |
主要開發人員角色 | 數據倉儲開發人員,SQL 工程師 | 數據工程師,數據科學家 | 公民開發者 | 公民數據科學家、數據工程師、數據科學家、SQL 工程師 |
主要開發人員技能集 | SQL | Spark(Scala、PySpark、Spark SQL、R) | 沒有程序代碼,SQL | 無程序代碼、KQL、SQL |
依組織的數據 | 資料庫、架構和數據表 | 資料夾和檔案、資料庫和數據表 | 資料庫、數據表、查詢 | 資料庫、架構和數據表 |
讀取作業 | T-SQL、Spark (支援使用快捷方式從數據表讀取,尚不支援存取檢視、預存程式、函式等) | Spark、T-SQL | Spark、T-SQL、Power BI | KQL、T-SQL、Spark、Power BI |
寫入作業 | T-SQL | Spark(Scala、PySpark、Spark SQL、R) | 數據流、T-SQL | KQL、Spark、連接器生態系統 |
多數據表交易 | 是 | 無 | No | 是,用於多數據表擷取。 請參閱 更新原則。 |
主要開發介面 | SQL 指令碼 | Spark 筆記本,Spark 作業定義 | Power BI | KQL 查詢集、KQL 資料庫 |
安全性 | 物件層級(數據表、檢視、函式、預存程式等),數據行層級、數據列層級、DDL/DML、動態數據遮罩 | 數據列層級、數據行層級(適用於透過 SQL 分析端點存取的 Lakehouse)、數據表層級(使用 T-SQL 時),無適用於 Spark | 內建 RLS 編輯器 | 資料列層級安全性 |
透過快捷方式存取數據 | 是的,透過使用三部分名稱的湖屋 | 是 | 無 | Yes |
可以是快捷方式的來源 | 是(表格) | 是 (檔案和資料表) | No | Yes |
跨項目查詢 | 是,跨 Lakehouse 和倉儲數據表查詢 | 是,跨 Lakehouse 和倉儲數據表進行查詢;跨 Lakehouses 查詢 (包括使用 Spark 的快捷方式) | No | 是,使用快捷方式跨 KQL 資料庫、Lakehouses 和倉儲進行查詢 |
案例
請檢閱這些案例,以協助選擇 Fabric 中的數據存放區。
案例 1
專業開發人員 Susan 是Microsoft Fabric 的新手。 他們已準備好開始清理、模型化和分析數據,但需要決定建置數據倉儲或 Lakehouse。 檢閱上表的詳細數據之後,主要決策點是可用的技能集,以及多數據表交易的需求。
Susan 已花費數年時間在關係資料庫引擎上建置數據倉儲,並熟悉 SQL 語法和功能。 思考較大的小組時,此數據的主要取用者也會使用 SQL 和 SQL 分析工具。 Susan 決定使用 數據倉儲,這可讓小組主要與 T-SQL 互動,同時允許組織中的任何 Spark 使用者存取數據。
Susan 會建立新的 Lakehouse,並使用 Lakehouse SQL 分析端點存取數據倉儲功能。 使用 Fabric 入口網站,建立外部數據表的快捷方式,並將其 /Tables
放在資料夾中。 Susan 現在可以撰寫 T-SQL 查詢,以參考在 Lakehouse 中查詢 Delta Lake 數據的快捷方式。 快捷方式會自動顯示為 SQL 分析端點中的數據表,而且可以使用三部分名稱向 T-SQL 查詢。
案例 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 來執行查詢,以比較目前和先前的期間、快速找出新興的問題,或提供陸地和海上路線的地理空間分析。