Microsoft Fabric 決策指南：複製活動、數據流或Spark
使用此參考指南和範例案例，協助您判斷是否需要 Microsoft Fabric 工作負載的複製活動、數據流或 Spark。
複製活動、數據流和Spark屬性
| 管線複製活動 | 數據流 Gen 2 | Spark | |
|---|---|---|---|
| 使用案例 | Data Lake 和數據倉儲移轉， 數據擷取， 輕量型轉換 |
數據擷取， 數據轉換， 數據整頓， 數據分析 |
數據擷取， 數據轉換， 數據處理 數據分析 |
| 主要開發人員角色 | 數據工程師， 數據整合者 |
數據工程師， 數據整合者， 商務分析師 |
數據工程師， 數據科學家， 數據開發人員 |
| 主要開發人員技能集 | 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 中使用您的數據。
案例 1
數據工程師 Leo 需要從內部部署和雲端內嵌外部系統的大量數據。 這些外部系統包括資料庫、檔案系統和 API。 Leo 不想為每個連接器或數據行動作業撰寫和維護程式碼。 他希望遵循獎牌層最佳作法，銅牌、銀牌和金牌。 Leo 沒有任何 Spark 體驗，因此他偏好盡可能使用拖放 UI，以最少的程式代碼撰寫。 他還想要依排程處理數據。
第一個步驟是從 Azure 數據資源和各種第三方來源取得原始數據進入銅層 Lakehouse（例如 Snowflake Web、REST、AWS S3、GCS 等）。 他想要合併的 Lakehouse，讓來自各種 LOB、內部部署和雲端來源的所有數據都位於單一位置。 Leo 會檢閱選項，並選取 管線複製活動 作為原始二進位副本的適當選擇。 此模式同時適用於歷程記錄和累加式數據重新整理。 透過複製活動，Leo 可以視需要將 Gold 數據載入數據倉儲，而且管線會提供可移動 PB 規模的數據的高規模資料擷取。 複製活動 是最佳的低程式代碼和無程式代碼選擇，可從各種來源或透過排程將數 PB 的數據移至 Lakehouse 和倉儲。
案例 2
Mary 是數據工程師，深入瞭解多個 LOB 分析報告需求。 上游小組已成功實作解決方案，將多個LOB的歷史和累加式數據遷移至通用Lakehouse。 Mary 負責清理數據、套用商業規則，並將其載入多個目的地（例如 Azure SQL DB、ADX 和 Lakehouse），以準備各自的報告小組。
Mary 是經驗豐富的 Power Query 使用者，且數據量處於低到中範圍，以達到所需的效能。 數據流提供無程式代碼或低程式碼介面，以擷取來自數百個數據源的數據。 透過資料流，您可以使用 300 個以上的資料轉換選項來轉換資料，並使用易於使用、高度可視化的使用者介面，將結果寫入多個目的地。 Mary 會檢閱這些選項，並決定使用數據流 Gen 2 作為她慣用的轉換選項是合理的。
Scenario3
Adam 是一家使用 Lakehouse 來儲存和分析其客戶數據的大型零售公司的資料工程師。 作為他工作的一部分，Adam 負責建置和維護數據管線，以擷取、轉換和將數據載入 Lakehouse。 公司的商務需求之一是執行客戶檢閱分析，以深入瞭解其客戶體驗並改善其服務。
Adam 決定最佳選項是使用 Spark 來建置擷取和轉換邏輯。 Spark 提供分散式運算平臺，可平行處理大量數據。 他使用 Python 或 Scala 撰寫 Spark 應用程式，以讀取 OneLake 的結構化、半結構化和非結構化數據，以取得客戶評論和意見反應。 應用程式會清理、轉換及將數據寫入 Lakehouse 中的 Delta 資料表。 然後，數據即可用於下游分析。