Вложение TVF и запросов USQL дает ужасные результаты

Я «думаю», что эта проблема связана с оптимизацией запросов, которую выполняет 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 в финальном запросе Граф заданий достигает примерно 97% прогресса примерно за 1,5 минуты. Но тут начинается ад! Последний узел представляет собой Aggregate с 2500 вершинами, что говорит о 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]
    ;

введите здесь описание изображения


person SimonB    schedule 25.09.2017    source источник
comment
Довольно тихий на ответы ... что означает, что я либо задал глупый вопрос, либо объяснил все неправильно. Что я могу сделать, чтобы вызвать интерес?   -  person SimonB    schedule 29.09.2017


Ответы (2)


Мои извинения за поздний ответ. Я путешествовал, и это просто ускользнуло от радаров.

Проблема, скорее всего, в том, что оптимизатор получил неправильную оценку и решил переразбить. Если вы читаете данные из файла, оптимизатор имеет более точную информацию, доступную во время компиляции.

Можете ли вы добавить подсказку OPTION(ROWCOUNT=x) к запросам, которые генерируют входные данные для соединения, чтобы получить лучший план?

person Michael Rys    schedule 10.11.2017

Поэтому я ввел это как билет с 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

person SimonB    schedule 01.12.2017