Microsoft Fabric 决策指南 - 复制活动、数据流或 Spark
使用此参考指南和示例方案来帮助你确定你的 Microsoft Fabric 工作负载是否需要复制活动、数据流或 Spark。
复制活动、数据流和 Spark 属性
| 管道复制活动 | 数据流 2 | Spark | |
|---|---|---|---|
| 用例 | 数据湖和数据仓库迁移、 数据引入、 轻量化转换 |
数据引入、 数据转换、 数据整理、 数据事件探查 |
数据引入、 数据转换、 数据处理， 数据事件探查 |
| 主要开发人员角色 | 数据工程师、 数据集成商 |
数据工程师、 数据集成商、 业务分析员 (business analyst) |
数据工程师、 数据科学家、 数据开发人员 |
| 主要开发人员技能集 | ETL、 SQL、 JSON |
ETL、 M、 SQL |
Spark（Scala、Python、Spark SQL、R） |
| 编写的代码 | 无代码、 低代码 |
无代码、 低代码 |
代码 |
| 数据量 | 低到高 | 低到高 | 低到高 |
| 开发接口 | 向导、 画布 |
Power Query | Notebook、 Spark 作业定义 |
| Sources | 30 多个连接器 | 150 多个连接器 | 数百个 Spark 库 |
| Destinations | 超过 18 个连接器 | 湖屋、 Azure SQL 数据库、 Azure 数据资源管理器、 Azure Synapse Analytics |
数百个 Spark 库 |
| 转换复杂度 | 低： 轻量化 - 类型转换、列映射、合并/拆分文件、平展层次结构 |
低到高： 300 多个转换函数 |
低到高： 支持本机 Spark 和开源库 |
查看以下三种方案，以获取有关如何选择在 Fabric 中处理数据的方式的帮助。
方案 1
Leo 是一名数据工程师，需要从外部系统引入本地和云中的大量数据。 这些外部系统包括数据库、文件系统和 API。 Leo 不想为每个连接器或数据移动操作编写和维护代码。 他希望遵循奖牌层（铜牌、银牌和金牌）的最佳做法。 Leo 没有任何 Spark 经验，因此他更喜欢尽可能多地拖放 UI，尽量使用最少的编码。 他还希望定期处理数据。
第一步是从 Azure 数据资源和各种第三方源（如 Snowflake Web、REST、AWS S3、GCS 等）获取原始数据进入铜牌层湖屋。 他想要一个经过整合的湖屋，以便让各种 LOB、本地和云源中的所有数据都驻留在一个位置。 Leo 查看选项，并选择“管道复制活动”作为原始二进制副本的适当选择。 此模式适用于历史数据刷新和增量数据刷新。 借助复制活动，Leo 可以根据需要将金牌数据加载到数据仓库（无需使用代码），并且管道提供可以移动 PB 级数据的大规模数据引入。 复制活动是将 PB 级数据从各种源（临时或定期）移动到湖屋和仓库的最佳低代码和无代码选择。
方案 2
Mary 是一名数据工程师，对多个 LOB 分析报包要求有着深入的了解。 上游团队已成功实现一个将多个 LOB 的历史和增量数据迁移到常见湖屋的解决方案。 Mary 的任务是清理数据、应用业务逻辑，并将其加载到多个目标（例如 Azure SQL DB、ADX 和湖屋），为各自的报告团队做准备。
Mary 是经验丰富的 Power Query 用户，数据量在低到中等范围内，以实现所需的性能。 数据流提供无代码或低代码接口，用于从数百个数据源引入数据。 使用数据流，你可以使用 300 多个数据转换选项转换数据，并使用易于使用、高度可视的用户界面将结果写入多个目标。 Mary 查看了这些选项，并确定使用 数据流 Gen 2 作为她的首选转换选项是比较合理的。
方案 3
Adam 是一家大型零售公司的数据工程师，该公司使用湖屋来存储和分析其客户数据。 作为他工作的一部分，Adam 负责构建和维护数据管道，以提取、转换和加载数据到湖屋。 该公司的业务要求之一是执行客户评审分析，以深入了解其客户体验并改进其服务。
Adam 认为最佳选择是使用 Spark 生成提取和转换逻辑。 Spark 提供了一个分布式计算平台，可以并行处理大量数据。 他使用 Python 或 Scala 编写 Spark 应用程序，该应用程序从 OneLake 读取结构化、半结构化和非结构化数据，以供客户评论和反馈。 该应用程序可以清理、转换数据并将其写入湖屋中的 Delta 表。 然后，数据已准备就绪，可用于下游分析。