USQL Nesting TVFs et Queries donne des résultats épouvantables

Question

Je pense que ce problème est lié à l'optimisation des requêtes effectuée par Azure Data Lake Analytics; mais voyons ...

J'ai 2 requêtes séparées (TVF) faisant des agrégations, puis une requête finale pour joindre les 2 ensemble pour les résultats finaux. Alors ...

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

Pour tester toute la logique, je lance les requêtes mineures séparément avec un filtre, stocker les résultats dans un fichier, puis utilisez les fichiers durs comme sources pour la requête finale; ce sont les durées totales (minutes).

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

Donc, je sais qu'au maximum, je peux obtenir mon résultat en environ 3,5 minutes. Cependant, je ne veux pas vraiment créer de nouveaux fichiers intermédiaires. Je veux utiliser les TDF directement pour alimenter la requête finale. Avec les TDF dans la requête finale, le graphique du travail obtient 97% de progression en environ 1,5 minute. Mais alors, tout l'enfer se déchaîne! Le dernier noeud est un agrégat avec 2500 sommets qui indique 16 minutes de temps de calcul. Donc ma question ... POURQUOI ??

Est-ce un cas où je ne comprends pas certains concepts fondamentaux du fonctionnement d'Azure?

Donc, quelqu'un peut-il expliquer ce qui se passe? Toute aide appréciée.

requête finale:

@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

J'ai donc entré celui-ci comme un ticket avec Microsoft. Voici leur réponse, que j'ai implémentée et réussie.

De: #######@microsoft.com Sujet: RE: ########### USQL emploi affiche le plan de travail bizarre et l'exécution Retour

Donc, la question ici est la cardinalité. Lorsque le script est divisé en plusieurs parties, le compilateur U-SQL dispose d'une nouvelle entrée à chaque étape intermédiaire et il connaît la taille réelle des données et la distribution de cette nouvelle entrée, ce qui permet à l'optimiseur d'allouer des ressources avec précision.

Cependant, lorsque le script est mis en un seul, l'estimation de l'optimiseur est très différente, car il ne sait pas quelle sera la taille exacte et la distribution de ces étapes intermédiaires. Nous nous attendons donc à ce qu'il y ait une différence d'estimations entre un script qui a été divisé en plusieurs parties et un script tout en un.Votre meilleure défense contre les différences d'optimisation telles que celles-ci consiste à CRÉER DES STATISTIQUES sur des colonnes de table. Dans ce cas, vous devez CREER STATISTICS sur la colonne CTNNumber et voir si cela améliore les performances du script de travail unique.

Voici une documentation entourant CREATE STATISTIQUES: https://docs.microsoft.com/en-us/sql/t-sql/statements/create-statistics-transact-sql

Answer 2

Mes excuses pour la réponse tardive. Je voyageais et cela a juste échappé au radar.

Le problème est très probablement que l'optimiseur a obtenu une mauvaise estimation et a décidé de sur-partitionner. Si vous lisez les données du fichier, l'optimiseur dispose d'informations plus précises disponibles au moment de la compilation.

Pouvez-vous ajouter un indice OPTION(ROWCOUNT=x) aux requêtes qui génèrent l'entrée pour la jointure afin d'obtenir un meilleur plan?