3. Azure Data Factory性能调优
Azure Data Factory（ADF）的性能问题很少来自单一配置项，而是“并行度、分区、DIU、集成运行时、数据流执行引擎、监控判读”共同作用的结果。调优的基本思路是：先通过监控定位瓶颈发生在读取端、写入端、计算端还是调度端，再针对瓶颈调整对应参数，而不是一次性把所有参数拉满。下面按复制活动、自托管集成运行时、映射数据流和监控指标四条主线展开。
一、复制活动：并行复制与分区策略
复制活动的吞吐由“并行副本数 × 单副本吞吐”决定。在“复制活动 → 设置 → 并行度”中，可以显式指定并行副本数（DIU 与并行度配合使用）；若留空，ADF 会根据源/接收器类型自动决定。并行复制的前提是数据可以被切分，因此分区策略是关键。
以从 Azure SQL Database 复制 2 亿行订单表到 ADLS Gen2 为例，常见分区方式有三种：
- 物理分区：源表已有分区列（如
OrderDate），按日期范围切分，每个副本读取一个区间。 - 动态范围分区：ADF 先执行
SELECT MIN/MAX获取边界，再按 N 等分生成分区查询，适合无物理分区的大表。 - 基于列表分区：按枚举值（如
RegionID IN (1,2,3)）切分，适合维度表或分布不均的数据。
分区列应满足“分布均匀、可下推、有索引”三个条件。若分区列倾斜严重（例如 80% 数据集中在某一天），并行副本会出现长尾，整体耗时由最慢副本决定。此时应改用更细粒度的分区列，或对倾斜区间单独拆分。
二、DIU 设置与自托管集成运行时扩展
DIU（Data Integration Unit）是复制活动的计算资源单位，1 DIU ≈ 1 核 CPU + 4 GB 内存的组合度量。DIU 越高，单副本吞吐越强，但并非线性增长。经验上，从 4 DIU 提升到 16 DIU 通常有明显收益，超过 32 DIU 后边际收益递减，且受源/接收器端吞吐上限约束。
当数据源位于本地或受防火墙保护的网络内时，需使用自托管集成运行时（SHIR）。SHIR 的扩展方式有两种：
- 纵向扩展：提升单节点 CPU/内存，适合单副本大吞吐场景。
- 横向扩展：部署多个 SHIR 节点并加入同一逻辑实例，ADF 会自动在节点间分发并行副本。通常 4 节点、每节点 8 核是较均衡的起点。
SHIR 节点数应不小于并行副本数，否则副本会排队等待节点资源。同时需关注 SHIR 所在机器的网络带宽与磁盘 IO，它们常成为隐性瓶颈。
三、映射数据流优化
映射数据流运行在 Spark 集群上，调优重点是分区与执行模式。数据流中的“优化”选项卡可设置分区方式：
- Round Robin：均匀分布，适合无关联的转换。
- Hash：按连接键分区，减少 shuffle，适合 join/aggregate。
- Fixed：固定分区数，适合已知数据量。
- Key：按唯一键分区，适合去重。
此外，应尽量使用“单阶段”转换替代多阶段链式转换，减少 shuffle 次数；对广播连接（小表 join 大表）启用 Broadcast 优化；在接收器端控制输出文件数量，避免小文件过多导致下游读取变慢。
四、监控指标解读与调优闭环
ADF 监控提供复制活动的“DIU 使用率”“读取耗时”“写入耗时”“吞吐量”等指标。判读逻辑如下：
- 若 DIU 使用率高但吞吐低，说明计算不是瓶颈，应检查源/接收器端限流或网络带宽。
- 若 读取耗时远大于写入耗时，瓶颈在源端，可尝试提高并行度或优化源查询。
- 若 各副本耗时差异大，说明分区倾斜，需重新选择分区列。
- 若 SHIR 节点 CPU 饱和，应增加节点或提升单节点规格。
数据流方面，重点看 Spark 各阶段耗时与 shuffle 数据量。若 shuffle 量异常大，通常意味着 join 或 aggregate 的分区键选择不当，应改用 Hash 分区并确保连接键一致。
五、参数配置参考示例
以下为从 Azure SQL Database 复制大表到 ADLS Gen2 的参考配置（示例参数，需根据实际环境调整）：
复制活动设置：
并行度（并行副本数）：8
DIU：16
分区方式：动态范围分区
分区列：OrderDate
分区数：8
SHIR 配置：
节点数：4
每节点：8 核 / 32 GB
网络带宽：≥ 1 Gbps
映射数据流：
分区方式：Hash
分区键：CustomerID
广播阈值：≤ 100 MB
输出文件数：每分区 1 个按上述配置，若源端可支撑，2 亿行订单表的复制耗时可从单副本的约 40 分钟降至 8～12 分钟量级（示例估算，实际取决于源端吞吐、网络和接收器写入能力）。调优后应再次查看监控，确认各副本耗时接近、DIU 使用率合理、无长尾副本，才算完成闭环。