原耗时30分钟的同一份USQL作业现需3-4小时，原因何在？

这种作业耗时突然从30分钟飙升到3-4小时的情况确实闹心，结合你提到的顶点数量增加的现象，咱们可以从这几个方向一步步排查：

1. 先看数据本身的变化 #

• 首要检查输入数据量：是不是近期作业处理的数据量突然暴涨了？如果数据规模翻了好几倍，哪怕你还是用1个AU，耗时增加是必然的，而且ADLA会自动分配更多顶点来尝试并行处理大数据量。
• 再看数据的分布/分区情况：如果原本的分区规则不再适配当前数据（比如出现大量相同分区值，或者数据分布变得极度不均匀），就会出现数据倾斜——部分顶点要处理远超其他顶点的数据量，拖慢整体作业，系统也会试图加顶点来缓解，但资源不够的话还是快不起来。

2. 排查集群资源竞争问题 #

• 看作业运行时段的ADLA集群整体负载：如果同一时间有大量其他高资源消耗的作业在跑，你的USQL作业会被抢占资源，导致顶点启动慢、执行卡顿，耗时自然被拉长。可以对比新旧作业运行时段的集群负载差异。
• 虽然你固定用1个AU，但ADLA的资源分配是动态的，如果集群整体资源紧张，实际能给到你作业的资源可能打折扣，系统只能靠增加顶点数来凑，但资源不足的话还是会慢。

3. 检查作业逻辑和依赖的隐性变化 #

• 确认USQL脚本有没有悄悄变过：哪怕是微小的调整（比如新增了聚合逻辑、改了JOIN条件），在数据量小的时候可能没感觉，数据量大了就会变成性能瓶颈，比如不小心写出笛卡尔积、或者大表JOIN没加索引。
• 看看作业依赖的外部资源：比如引用的UDF是不是效率变低了？或者外部数据源（比如Blob存储）有没有性能波动？这些都会拖慢每个顶点的处理速度，进而拉长整体耗时。

4. 查看作业日志和服务状态 #

• 去看作业的顶点执行详情日志：重点看每个顶点的处理数据量、耗时，有没有某个顶点耗时特别长（这是数据倾斜的典型信号）；另外看数据读取/写入的耗时，如果大部分时间花在读写上，可能是存储账户的性能问题。
• 确认ADLA服务本身的状态：可以去Azure门户里查ADLA的服务健康，看看作业运行时段有没有临时的性能波动或者维护操作。

具体动手排查的小步骤 #

• 先对比新旧作业的输入数据统计：比如行数、总文件大小，先确认是不是数据量的锅。
• 找个低峰时段重新跑一遍当前作业：如果耗时能恢复到接近原来的30分钟，那基本就是时段资源竞争的问题。
• 对USQL脚本做性能优化：比如给大表加合适的索引、调整分区策略、优化JOIN和聚合逻辑，必要时可以临时调高AU数，看看能不能提升速度（也能验证是不是资源不够的问题）。

内容的提问来源于stack exchange，提问作者Mahesh Dounde