azure-data-lake - USQL 嵌套 TVF 和查询给出了可怕的结果

Question

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

我有 2 个单独的查询 (TVF) 进行聚合，然后是最终的 Query 将这 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% 的进度。
但是，所有的 hell 都崩溃了!
最后一个节点是一个包含 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]
    ;

Answer 1

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

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

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