USQL 嵌套 TVF 和查询给出了可怕的结果答案

【问题标题】：USQL Nesting TVFs and Queries is giving horrendous resultsUSQL 嵌套 TVF 和查询给出了可怕的结果
【发布时间】：2017-09-25 13:57:34
【问题描述】：

我“认为”这个问题与 Azure Data Lake Analytics 所做的查询优化有关；但是让我们看看...

我有 2 个单独的查询 (TVF) 进行聚合，然后有一个最终查询将这 2 个查询连接在一起以获得最终结果。所以...

Table >  Header Query
Table >  Detail Query
Result = Header Query + Detail Query

为了测试整个逻辑，我使用过滤器单独运行次要查询，将结果存储到文件中，然后将硬文件用作最终查询的源；这些是总持续时间（分钟）。

Header Query  1.4  (408 rows)
Detail Query  0.9  (3298 rows)
Final Query   0.9  (408 rows)

所以我知道，我最多可以在 3.5 分钟左右得到结果。但是，我真的不想创建新的中间文件。我想直接使用 TDF 来提供最终查询。

在最终查询中使用 TDF，作业图在大约 1.5 分钟内达到大约 97% 的进度。但随后，所有的地狱都崩溃了！最后一个节点是具有 2,500 个顶点的聚合，表示计算时间为 16 分钟。所以我的问题......为什么？？

这是我不了解 Azure 工作原理的一些基本概念的情况吗？

那么，谁能解释发生了什么？任何帮助表示赞赏。

最终查询：

@Header =
SELECT [CTNNumber],
       [CTNCycleNo],
       [SeqStart],
       [SeqEnd],
       [StartUTC],
       [EndUTC],
       [StartLoc],
       [StartType],
       [EndLoc],
       [EndType],
       [Start Step],
       [Start Ctn Status],
       [Start Fill Status],
       [EndStep],
       [End Ctn Status],
       [End Fill Status]
FROM [Play].[getCycles3]
     ("") AS X;


@Detail =
SELECT [CTNNumber],
       [SeqNo] AS [SeqNo],
       [LocationType],
       [LocationID],
       [BizstepDescription],
       [ContainerStatus],
       [FillStatus],
       [UTCTimeStampforEvent]
FROM [Play].[getRaw]
     ("") AS Z;

@result =
    SELECT
        H.[CTNNumber], H.[CTNCycleNo], H.[SeqStart], H.[SeqEnd]
        ,COUNT([D].[SeqNo]) AS [SeqCount]
        //, COUNT(DISTINCT [LocationID]) AS [#Locations]
    FROM 
        @Header AS [H]
        INNER JOIN
        @Detail AS [D]
        ON 
        [H].[CTNNumber] == [D].[CTNNumber] 
    WHERE 
        [D].[SeqNo] >= [H].[SeqStart] AND
        [D].[SeqNo] <= [H].[SeqEnd]  
    GROUP BY 
        H.[CTNNumber], H.[CTNCycleNo], H.[SeqStart], H.[SeqEnd]
    ;

【问题讨论】：

回复很安静……这意味着我要么问了一个愚蠢的问题，要么解释错了。我可以做些什么来获得一些兴趣？

标签： azure-data-lake u-sql

【解决方案1】：

对于迟到的回复，我深表歉意。我正在旅行，这只是从雷达上溜走。

问题很可能是优化器估计错误并决定过度分区。如果从文件中读取数据，优化器会在编译时获得更精确的信息。

您能否向生成连接输入的查询添加OPTION(ROWCOUNT=x) 提示以获得更好的计划？

【讨论】：

【解决方案2】：

所以我输入了这个作为 Microsoft 的票。这是他们的回应，我实施并取得了成功。

发件人：#######@microsoft.com 主题：RE：########### USQL Job 显示奇怪的作业计划和运行时返回

所以这里的问题是基数。当脚本被分成几部分时，U-SQL 编译器在每个中间步骤都有一个新的输入要处理，它知道新输入的实际数据大小和分布，因此优化器能够准确地分配资源。

但是，当脚本全部合二为一时，优化器的估计就大不相同了，因为它不知道这些中间步骤的确切大小和分布。因此，我们预计分解成部分的脚本和一体成型的脚本之间的估计会有一些差异。

针对此类优化差异的最佳防御措施是在表列上创建统计信息。在这种情况下，您应该在 CTNNumber 列上创建统计信息，看看这是否会提高单个作业脚本的性能。

以下是有关 CREATE STATISTICS 的一些文档： https://docs.microsoft.com/en-us/sql/t-sql/statements/create-statistics-transact-sql

【讨论】：