在处理大规模 Excel 文件时，如何实现更高效的并行加载？让我们通过实际测试来看看 Fabric Dataflows Gen2 的 Partitioned Compute 功能是如何帮助我们提升性能的。
背景：Excel 文件作为常见的数据来源，其加载效率往往较低。同时，存储于 SharePoint 中的数据也可能面临请求限制的问题。在之前的文章中（参见 Part 1 和 Part 2），作者已经介绍了并发评估的相关内容，并通过实际测试验证了不同设置对数据加载时间的影响。
背景环境
- 文件来源：上传至 SharePoint 文档库的 244 个 Excel 文件，每份文件包含约 54.2 万行数据。
- 基线配置：创建了一个不使用 Partitioned Compute 的 Fabric Dataflow Gen2，用于合并所有 Excel 文件中的数据并加载到 Fabric Warehouse 中。根据最近运行记录，整个过程耗时约为 28 分钟 8 秒。
实验设计
为了测试更多的并发性是否总是更好的，作者创建了两个版本的数据流：
- 未启用 Partitioned Compute：在不使用分区计算的情况下，数据加载时间保持不变。
- 启用 Partitioned Compute：设置 Excel 文件名作为分区键，理论上可以实现并行处理。通过调整最大并发度来测试不同情况下的表现。
实验结果
| 最大并发度 | 平均刷新时长 (分钟:秒) | |------------|----------------------| | 4 | 18:37 | | 8 | 9:42 | | 16 | 5:24 | | 25 | 05:21 | | 无限制 | 5:16 |
实验结论
从实验结果来看，并非所有情况下更大的并发度都能带来更好的性能。具体原因可能是数据加载过程中的一些瓶颈导致了效率的下降，例如请求频率的限制。
对于实际应用中的经验总结：
- 在处理大规模数据集时，合理设置 Partitioned Compute 可以显著提升加载速度。
- 不要盲目追求更高的并行度，而是根据实际情况进行优化调整。
通过本次实验，我们终于找到了在 Fabric Dataflows Gen2 中实现高效数据加载的最佳实践。告别了以往因并发度过高而导致的加载效率下降问题。
