U-SQL工作绩效

Question

你能帮助我完成工作表现吗？我用10个AU运行它。并且在最初的部分时间它们几乎全部被使用。但是从执行时间的后半段开始，它仅使用1个AU。我在计划中看到一个超级变换仅由一个顶点组成，它看起来像是低估了执行计划（它只是假设）。

我试图分析执行时间，但如果没有像HashCombine，HashCross等操作的技术说明那么很难......

所以我的问题可以用它做一些事情（修改代码，添加提示等）？

my job ID link

Mychael Rys的解决方案解决了这个问题。

我应用了Michael Rys的解决方案，它完美无缺。一如既往地谢谢你！见下图。几乎所有10AU的10AU现在都在使用。我也使用了建模工具，看起来脚本被线性缩放。太棒了:)。

另一个解决方案

此外，我可以通过左连接替换内部连接（在我的情况下，替换将是等效的，因为在维度表中，对于事实表dim-1中的任何记录，ALWAYS只存在一行：M-fact）。 CBO估计加入的结果基数为“至少不低于事实表”。在这种情况下，CBO生成没有提示的好计划。

Answer 1

我会将您的工作链接转发给我们的一位开发人员，他们可以在我获得更多信息后查看并更新此答案。

但是，对于stackoverflow帮助，查看脚本和/或作业图也会很有帮助。例如，您运行了多少数据？您使用的是暗示订购或分组等的操作吗？

基于顶点执行视图，您似乎从许多小文件中提取，每个小文件只包含少量数据。很可能优化器假设只有少量数据来自这些文件。

您可以在OPTION(ROWCOUNT= xxx)语句中添加EXTRACT提示，以提示更多行（xxx将是强制系统并行化的数字），假设我的初始假设是正确的。

查看工作后的一些其他信息

该计划是一个13向连接，包含12个维度表和1个事实表。 12个连接中的9个完成后，错误（低估导致串行计划）开始。最后3个连接 - 使用dim_application，dim_operation和dim_data_type，是连续完成的。计划的主干仍然有29GB。由于我们没有外键信息，因此我们很难通过9个连接进行估计。

你可以做的最有效的事情是

1. 将join语句拆分为2，其中第二个连接为dim_application，dim_operation和dim_data_type。
2. 使用大数字在第一个连接语句的输出上添加ROWCOUNT提示。

如果有帮助，请告诉我。