Ne vous contentez pas d'écrire du code qui fonctionne, écrivez du code qui scale : l'analyse du plan de requête est votre seul moyen de vérifier que vos jointures s'exécutent en parallèle sur tous les workers CAS plutôt que de saturer le contrôleur. Ma règle d'or : utilisez systématiquement METHOD avec VALIDATEONLY en phase de test pour débusquer les nœuds Sort ou Limit qui brisent le multi-threading avant même de lancer vos traitements sur des téraoctets de données
En tant qu'expert SAS©, je rencontre souvent des développeurs confrontés à des requêtes lentes sur de gros volumes de données dans SAS© Cloud Analytic Services (CAS). La clé pour débloquer la performance ne réside pas dans le code lui-même, mais dans la compréhension de son exécution.
Le FedSQL Query Plan est votre meilleur allié pour auditer vos requêtes. Voici comment l'utiliser pour transformer vos traitements de données.
Le planificateur de requêtes FedSQL génère un plan interne qui décrit chaque étape du processus d'exécution. En l'analysant, vous pouvez identifier :
Les goulots d'étranglement (ex: tris inutiles).
L'efficacité des jointures (HashJoin vs MergeJoin).
Si vos tables sont correctement distribuées ou répliquées sur les workers CAS.
Il existe trois options principales pour auditer vos requêtes, utilisables via la procédure PROC FEDSQL ou l'action fedSql.execDirect en CASL.
L'option METHOD (ou _METHOD dans la procédure) affiche une description textuelle brève des nœuds et des étapes (stages).
Usage : Comprendre la structure logique de la requête.
Astuce d'expert : Couplez-la avec validateOnly (ou NOEXEC) pour voir le plan sans consommer de ressources CPU en exécutant la requête.
Idéal pour la phase de développement. En utilisant validateOnly, FedSQL vérifie la syntaxe et génère le plan de nœuds sans lire les données.
Note : Comme la requête n'est pas exécutée, les détails spécifiques aux étapes de données réelles sont omis.
C'est l'outil de prédilection pour le tuning de performance. showStages fournit :
Le nombre de lignes/colonnes en entrée et sortie.
Le temps écoulé par étape.
Le mode de distribution (Auto-partitioning vs Replication).
Le nombre de threads utilisés par worker.
Chaque étape (Stage) représente une requête SQL autonome. Voici les principaux nœuds que vous rencontrerez dans vos logs :
| Étape d'exécution FedSQL | Nœud du Query Plan | Support Multi-threading |
| Simple SELECT | SeqScan | Oui |
| SELECT DISTINCT | Unique | Oui |
| Jointure de deux tables | HashJoin / MergeJoin | Oui |
| GROUP BY | Agg / Group | Oui |
| ORDER BY | Sort | Non |
| LIMIT / OFFSET | Limit | Non |
Imaginons une requête joignant des données géographiques (WorldCityCoords) avec des températures (WorldTemps) incluant une sous-requête groupée.
| 1 | PROC FEDSQL sessref=casauto _method; |
| 2 | select |
| 3 | C.ID_CLIENT, |
| 4 | C.NOM, |
| 5 | C.REGION, |
| 6 | V.TOTAL_ACHATS, |
| 7 | V.NB_TRANSACTIONS |
| 8 | from CLIENTS_DATA C |
| 9 | inner join ( |
| 10 | select ID_CLIENT, sum(MONTANT) as TOTAL_ACHATS, count(*) as NB_TRANSACTIONS |
| 11 | from VENTES_TRANSACTIONS |
| 12 | group BY ID_CLIENT |
| 13 | ) V on C.ID_CLIENT = V.ID_CLIENT |
| 14 | order BY TOTAL_ACHATS desc; |
| 15 | QUIT; |
Le Query Plan va afficher des nœuds spécifiques. Voici ce qu'ils signifient pour vos performances :
| Opération SQL | Nœud FedSQL | Impact Performance |
group by ID_CLIENT | Agg | Multi-threadé. Efficace en CAS. |
inner join | HashJoin | Très rapide si la petite table tient en mémoire. |
order by | Sort | Attention : Souvent effectué sur un seul nœud à la fin. |
select * | SeqScan | Lecture séquentielle des données. |
showStagesSi vous activez cntl=(showStages), vous verrez des sections comme celle-ci :
Stage 2 : Aggregation (VENTES_TRANSACTIONS)
Input: 50 000 000 rows
Output: 1 200 000 rows (Résultats groupés par client)
Action: Partitionnement local et tri par thread.
Stage 3 : Join (CLIENTS_DATA + Stage 2)
Detail: Table CLIENTS_DATA Replicated to all workers.
Note de l'expert : FedSQL a jugé que la table Client était assez petite pour être copiée partout, évitant ainsi un transfert massif de la table de transactions.
Surveillez le nœud "Sort" : Si votre requête finit par un order by sur des millions de lignes, FedSQL devra peut-être rapatrier les données sur un seul worker (ou le client), créant un goulot d'étranglement.
Vérifiez le "Replicated" : Dans le log de showStages, si vous voyez qu'une table géante est répliquée (Replicated to all workers), cela peut saturer la mémoire. Assurez-vous que vos tables sont distribuées sur une clé commune.
Utilisez validateOnly en prod : Avant de planifier un job batch lourd, lancez-le une fois avec NOEXEC pour valider que le planificateur n'a pas choisi une stratégie de jointure sous-optimale.
Les codes et exemples fournis sur WeAreCAS.eu sont à but pédagogique. Il est impératif de ne pas les copier-coller aveuglément sur vos environnements de production. La meilleure approche consiste à comprendre la logique avant de l'appliquer. Nous vous recommandons vivement de tester ces scripts dans un environnement de test (Sandbox/Dev). WeAreCAS décline toute responsabilité quant aux éventuels impacts ou pertes de données sur vos systèmes.