Microsoft Fabric 決策指南：複製活動、資料流程或 Spark
使用本參考指南和範例案例，協助您決定您是否需要 Microsoft Fabric 工作負載的複製活動、資料流程或 Spark。
複製活動、資料流程和 Spark 屬性
| 管線複製活動 | 資料流程 Gen2 | Spark | |
|---|---|---|---|
| 使用案例 | 資料湖和資料倉儲移轉、 資料擷取、 輕量型轉換 |
資料擷取、 資料轉換、 資料整頓、 資料分析 |
資料擷取、 資料轉換、 資料處理、 資料分析 |
| 主要開發人員角色 | 資料工程師、 資料整合者 |
資料工程師、 資料整合者、 商務分析師 |
資料工程師、 資料科學家、 資料開發人員 |
| 主要開發人員技能集 | ETL、 SQL、 JSON |
ETL、 M, SQL |
Spark (Scala、Python、Spark SQL、R) |
| 撰寫的程式碼 | 無程式碼、 低程式碼 |
無程式碼、 低程式碼 |
代碼 |
| 資料量 | 低至高 | 低至高 | 低至高 |
| 開發介面 | 精靈、 畫布 |
Power Query | 筆記本、 Spark 作業定義 |
| 來源 | 30 個以上連接器 | 150 個以上連接器 | 數百個 Spark 程式庫 |
| 目的地 | 18 個以上連接器 | Lakehouse、 Azure SQL 資料庫、 Azure 資料總管、 Azure Synapse Analytics |
數百個 Spark 程式庫 |
| 轉換複雜度 | 低： 輕量型 - 類型轉換、資料行對應、合併/分割檔案、扁平化階層 |
低至高： 300 個以上轉換函數 |
低至高： 支援原生 Spark 和開放原始碼程式庫 |
請檢閱下列三個案例，以協助您選擇如何在 Fabric 中使用您的資料。
案例 1
資料工程師 Leo 需要從外部系統 (內部部署和雲端) 擷取大量資料。 這些外部系統包括資料庫、檔案系統和 API。 Leo 不想為每個連接器或資料移動作業撰寫和維護程式碼。 他希望遵循獎牌層級的最佳做法，包括銅級、銀級和金級。 Leo 沒有任何 Spark 體驗，因此他更喜歡盡可能使用拖放式 UI，並使用最少的編碼。 他還想依排程處理資料。
第一步是將未經處理資料從 Azure 資料資源和各種協力廠商來源 (如 Snowflake Web、REST、AWS S3、GCS 等) 放入到銅級層 Lakehouse。 他想要一個合併的 Lakehouse，以便來自各個 LOB、內部部署和雲端來源的所有資料都駐留在一個位置。 Leo 檢閱選項並選取管線複製活動作為原始二進位複製的適當選擇。 此模式適用於歷史資料重新整理和增量資料重新整理。 透過複製活動，Leo 無需程式碼即可將金級資料載入至資料倉儲 (如果有需要)，且管線提供可移動 PB 規模的資料的高延展性資料擷取。 複製活動是將數 PB 的資料從各種來源 (臨機操作或透過排程) 移動到 Lakehouse 和倉儲的最佳低程式碼和無程式碼選擇。
案例 2
Mary 是一位資料工程師，對多個 LOB 分析報告需求有著深入的了解。 上游團隊成功實作了一個解決方案，將多個 LOB 的歷史資料和增量資料移轉到公用 Lakehouse。 Mary 的工作是清理資料、套用商務邏輯並將其載入到多個目的地 (例如 Azure SQL DB、ADX 和 Lakehouse)，為各自的報表團隊做好準備。
Mary 是一位經驗豐富的 Power Query 使用者，資料量處於中低範圍，無法達到所需的效能。 資料流程提供無程式碼或低程式碼介面，以擷取來自數百個資料來源的資料。 透過資料流程，您可以使用 300 多個資料轉換選項來轉換資料，並透過便於使用、高度視覺化的使用者介面將結果寫入到多個目的地。 Mary 檢閱這些選項，並認為使用 [資料流程 Gen 2] 作為慣用轉換選項是有意義的。
案例 3
Adam 是一名資料工程師，在一間大型零售公司工作，該公司使用 Lakehouse 來儲存和分析客戶資料。 作為工作的一部分，Adam 負責建置和維護資料管線，這些資料管線用於將資料擷取、轉換和載入到 Lakehouse 中。 該公司的業務需求之一是執行客戶評論分析，以深入了解客戶的體驗並改善服務。
Adam 決定最好的選擇是使用 Spark 來建置擷取和轉換邏輯。 Spark 提供了一個可以平行處理大量資料的分散式運算平台。 他使用 Python 或 Scala 撰寫 Spark 應用程式，此應用程式從 OneLake 讀取結構化、半結構化和非結構化資料以供客戶評論和提供意見反應。 此應用程式清理、轉換資料並將其寫入 Lakehouse 中的差異資料表。 然後，資料即可用於下游分析。