Dans l'environnement distribué de SAS© Viya™ et du moteur CAS (Cloud Analytic Services), comprendre comment vos requêtes sont traitées est crucial pour la performance. Le langage FedSQL, grâce à sa capacité à distribuer les calculs, est puissant, mais peut parfois sembler être une "boîte noire".
Pour optimiser vos traitements et débugger vos requêtes, vous devez analyser le Plan d'Exécution (Query Plan). Cet article technique vous détaille les méthodes pour visualiser ces plans, que vous utilisiez PROC FEDSQL ou l'action fedSql.execDirect.
Avant de plonger dans le code, comprenons l'enjeu. Le plan d'exécution vous révèle comment l'optimiseur FedSQL transforme votre requête SQL en instructions CAS. Il vous permet de répondre à ces questions vitales :
Ma requête est-elle exécutée en parallèle (multi-thread) ?
Y a-t-il des goulots d'étranglement lors du brassage des données (shuffling) ?
Les tables sont-elles dupliquées sur tous les nœuds ou partitionnées ?
SAS© Viya™ offre deux niveaux de détails pour inspecter ces plans.
1. L'option Method (Vision Structurelle)
Cette option fournit une description textuelle brève des nœuds et des étapes du plan.
Comportement : Elle écrit dans la log client.
Mode "Dry Run" : Si couplée avec une option de validation (NOEXEC ou validateOnly), elle affiche le plan sans exécuter la requête.
Note importante (SAS© Viya™ 3.5+) : Depuis la version 3.5, l'option Method est plus concise. Elle n'affiche plus la requête de l'étape ni le nombre de threads SQL utilisés. Pour ces détails, il faut passer à l'option suivante.
2. L'option showStages (Vision Performance)
Introduite avec SAS© Viya™ 3.5, c'est l'option recommandée pour l'optimisation fine. Elle inclut tout ce que fait Method, plus :
La requête exacte générée pour chaque étape (stage query).
Le nombre de threads SQL par étape.
Métriques d'exécution : Temps écoulé, nombre de lignes en sortie, et détails sur le partitionnement (repliqué vs auto-partitionné).
Attention : showStages ne fonctionne pas avec l'option de validation seule (validateOnly), car elle nécessite l'exécution réelle pour collecter les temps de calcul.
Si vous codez en SAS© classique, vous utiliserez la procédure PROC FEDSQL. Voici comment activer ces options.
Cas 1 : Voir le plan sans exécuter la requête (Debugging)
C'est idéal pour vérifier la syntaxe et la logique de l'optimiseur sans consommer de ressources serveur. Utilisez l'option _METHOD (notez l'underscore) combinée à NOEXEC.
Cas 2 : Voir le plan durant l'exécution
Pour voir les étapes pendant que le traitement tourne :
Cas 3 : L'analyse complète avec showStages
Pour obtenir les métriques de temps et de threads, showStages se déclare dans l'instruction CNTL.
Pour les développeurs utilisant CASL, Python (SWAT) ou R, vous passerez par l'action execDirect.
Cas 1 : Plan structurel sans exécution (Dry run
Ici, on utilise les paramètres booléens method et validateOnly.
Cas 2 : Plan structurel avec exécution
Cas 3 : Analyse complète (showStages)
Pour récupérer les temps d'exécution par étape (staging) dans vos logs :
Si vous travaillez sur de très volumétries dans SAS© Viya™, ne lancez jamais une requête complexe sans avoir d'abord testé un _METHOD NOEXEC. Cela vous évitera de lancer un produit cartésien accidentel ou une requête qui ne tire pas profit de l'architecture MPP (Massively Parallel Processing) de CAS. Une fois la logique validée, utilisez showStages pour tuner vos performances.
