Microsoft網狀架構決策指南:複製活動、數據流或Spark
使用本參考指南和範例案例,協助您判斷您是否需要Microsoft Fabric 工作負載的複製活動、數據流或Spark。
複製活動、資料流和Spark屬性
管線複製活動 | 數據流第二代 | Spark | |
---|---|---|---|
使用案例 | 資料湖和資料倉儲遷移, 資料導入 輕量化轉換 |
數據擷取, 數據轉換, 數據整頓, 數據分析 |
數據擷取, 數據轉換, 數據處理 數據分析 |
主要開發人員角色 | 數據工程師, 數據整合者 |
數據工程師, 數據整合者, 商務分析師 |
數據工程師, 數據科學家, 數據開發人員 |
主要開發人員技能集 | ETL, SQL、 JSON |
ETL, M, SQL |
Spark (Scala、Python、Spark SQL、R) |
撰寫的程式碼 | 沒有程序代碼, 低程序代碼 |
沒有程序代碼, 低程序代碼 |
代碼 |
數據磁碟區 | 低到高 | 低到高 | 低到高 |
開發介面 | 巫師 帆布 |
Power Query | 筆記本 Spark 作業定義 |
來源 | 30 個以上的連接器 | 150 個以上的連接器 | 數百個 Spark 函式庫 |
目的地 | 18 個以上的連接器 | Lakehouse、 Azure SQL Database Azure 數據總管, Azure Synapse 分析 |
數百個Spark函式庫 |
轉換複雜度 | 低: 輕量型 - 類型轉換、欄位映射、合併/分割檔案、階層扁平化 |
低到高: 300 個以上的轉換函式 |
低到高: 支援原生 Spark 和開放原始碼函式庫 |
請檢閱下列三個案例,以協助您選擇如何在 Fabric 中使用您的數據。
Scenario1
數據工程師 Leo 需要從內部部署和雲端的外部系統中擷取大量數據。 這些外部系統包括資料庫、檔案系統和 API。 Leo 不想為每個連接器或數據傳輸操作撰寫和維護程式碼。 他希望遵循獎章等級的最佳實踐,即銅牌、銀牌和金牌。 Leo 沒有任何 Spark 體驗,因此他偏好盡可能使用拖放 UI,以最少的程式代碼撰寫。 他還想要依排程處理數據。
第一個步驟是從 Azure 數據資源和各種第三方來源取得原始數據進入銅層 Lakehouse(例如 Snowflake Web、REST、AWS S3、GCS 等)。 他想要一個整合型湖倉,這樣來自各種業務線、內部部署和雲端來源的所有數據都能集中在單一位置。 Leo 會檢閱選項,並選取 管線複製活動 作為原始二進位副本的適當選擇。 此模式同時適用於歷程記錄和累加式數據重新整理。 透過資料複製活動,Leo 可以在需要時以無代碼的方式將 Gold 數據載入數據倉儲,而管道則提供高效的資料擷取功能,幫助移動拍字节級別的數據。 複製功能是低代碼與無代碼開發的最佳選擇,可以將數 PB 的數據從各種來源,即時或按計劃地移至資料湖與數據倉儲。
Scenario2
Mary 是數據工程師,深入瞭解多個 LOB 分析報告需求。 上游小組已成功實作解決方案,將多個LOB的歷史和累加式數據遷移至通用Lakehouse。 Mary 負責清理數據、套用商業規則,並將其載入多個目的地(例如 Azure SQL DB、ADX 和 Lakehouse),以準備各自的報告小組。
Mary 是經驗豐富的 Power Query 使用者,且數據量處於低到中範圍,以達到所需的效能。 數據流提供無程式代碼或低程式碼介面,以擷取來自數百個數據源的數據。 透過資料流,您可以使用 300 個以上的資料轉換選項來轉換資料,並使用易於使用、高度可視化的使用者介面,將結果寫入多個目的地。 Mary 檢閱這些選項,並覺得使用 Dataflow Gen 2 作為她偏好的轉換選項是合理的。
Scenario3
Adam 是一家使用 Lakehouse 來儲存和分析其客戶數據的大型零售公司的資料工程師。 作為他工作的一部分,Adam 負責建置和維護數據管線,以擷取、轉換和將數據載入 Lakehouse。 公司的商務需求之一是執行客戶檢閱分析,以深入瞭解其客戶體驗並改善其服務。
Adam 決定最佳選項是使用 Spark 來建置擷取和轉換邏輯。 Spark 提供分散式運算平臺,可平行處理大量數據。 他使用 Python 或 Scala 撰寫 Spark 應用程式,以讀取 OneLake 的結構化、半結構化和非結構化數據,以取得客戶評論和意見反應。 應用程式會清理、轉換及將數據寫入 Lakehouse 中的 Delta 資料表。 然後,數據即可用於下游分析。
相關內容
- 如何使用複製功能 複製數據
- 快速入門:建立第一個數據流以取得和轉換數據
- 如何在 Fabric 中建立 Apache Spark 作業定義