Synapse Pipeline遇DF-Executor-OutOfMemoryError问题求助

针对你遇到的89MB GZIP嵌套JSON文件在Dataflow中出现DF-Executor-OutOfMemoryError，且升级IR、Copy Data解压均无效的问题，可尝试以下针对性优化方案：

1. 优化源读取策略 #

• 启用分区读取：在Dataflow源的「优化」选项卡开启分区，选择「文件分区」或基于JSON内的字段做列分区，让大文件数据分散到多个节点并行读取，避免单节点内存过载。
• 切换流式读取模式：在源的「源选项」中把读取模式改为「流式读取」，替代默认的批量读取，减少一次性加载到内存的数据量，适配大文件处理场景。

2. 拆分大文件后处理 #

• 通过Get Metadata活动获取目标文件信息，结合For Each活动调用Azure Function或Python/PowerShell脚本，直接完成GZIP解压+大JSON拆分（比如拆分为每个10MB以内的小文件），再将拆分后的文件送入Dataflow处理。避免单独用Copy Data解压大文件导致的内存溢出。

3. 精简Dataflow转换逻辑 #

• 尽早过滤数据：在源节点后立即添加「过滤转换」，删除不需要的字段和不符合条件的行，从源头减少数据量。
• 分步扁平化嵌套结构：不要一次性扁平化所有嵌套层级，分多次完成扁平化操作，每一步仅处理一层嵌套，中间可加入分区或缓存转换，降低单步转换的内存压力。

4. 调整集成运行时（IR）配置 #

• 增加节点数而非单节点核心数：选择内存优化型IR时，优先增加节点数量（比如用4个32核节点，总核心数128），而非单节点128核，分布式架构更适合大文件的并行处理。
• 设置作业并行度：在Dataflow的「设置」选项卡调整「默认并行度」，根据IR规模设置合适数值（比如节点数×8），让作业充分利用分布式资源。

5. 自定义Spark配置优化 #

在Dataflow的「Spark配置」中添加以下参数，针对性调优内存和并行处理：

spark.driver.memory=32g
spark.executor.memory=16g
spark.executor.cores=4
spark.sql.shuffle.partitions=200

根据实际IR规模调整数值，核心目标是平衡内存分配与数据并行处理能力。

内容的提问来源于stack exchange，提问作者Ritesh S