Optimisation du code et des temps d'exécution avec SAS
Objectifs pédagogiques
- Acquérir des bonnes pratiques pour optimiser l’exécution de programmes SAS
- Maîtriser les temps d’exécution lors de la manipulation de grosses bases de données
Programme détaillé
Le fonctionnement de SAS 2h
- Les ressources
- Les bases
- Le vecteur de travail
- Les macro-langages SAS
- Les autres langages SAS
Comment optimiser un programme SAS ? 2h
- Les Options
- Optimiser le code
- Optimiser la gestion des données
Manipulation des grosses bases 4h
- Indexation
- Hashage de tables
Le langage SQL 4h
- Notions essentielles de SAS SQL
- Manipulation de grosses bases, indexation en SQL
Synthèse : ce qu’il faut retenir, exercices d’application récapitulatifs
Public visé
Statisticiens et data analysts ayant recours régulièrement au langage SAS et souhaitant en optimiser l’utilisation.
Prérequis
Les stagiaires doivent maitriser le programme des formations SAS initiation et SAS intermédiaire.
Approche pédagogique
Calculés à partir de 6 avis recueillis depuis 09/09/2016, lors de 2 sessions de cette formation.
Code SAS trop lent : mesurer, lire moins, puis indexer ou hacher
Un traitement SAS qui tournait en quelques minutes en prend désormais une heure, parce que les tables ont grossi. Avant de réécrire le programme, il faut savoir où le temps se perd. Sur de grosses tables, le coût principal est souvent la lecture et l’écriture sur disque, bien plus que le calcul.
Mesurer d’abord
L’option FULLSTIMER détaille dans le journal, pour chaque étape, le temps écoulé (real time), le temps processeur (CPU time) et la mémoire utilisée.
options fullstimer;
Un temps écoulé très supérieur au temps processeur signale une étape qui attend le disque ou le réseau : c’est le volume lu ou écrit qu’il faut réduire. À l’inverse, un temps processeur élevé désigne un calcul coûteux, un tri ou une jointure.
Lire moins
Les gains les plus simples consistent à ne charger que ce qui sert. Les options KEEP= et WHERE= placées sur la table d’entrée limitent les colonnes et les lignes lues dès la source. Un IF dans l’étape DATA filtre plus tard, une fois chaque ligne chargée dans le vecteur de travail. Éviter les tris inutiles, et les tables intermédiaires recopiées d’une étape à l’autre, réduit aussi les écritures.
data ventes_idf;
set ventes(keep=id_client region montant where=(region = "IDF"));
run;
Index ou table de hachage ?
Un index permet d’accéder directement aux lignes cherchées sans parcourir toute la table. Il n’est utile que si la sélection est faible : une règle empirique souvent citée par SAS situe le seuil autour de 15 % des observations. Au-delà, une lecture séquentielle reste plus rapide.
Pour enrichir une grosse table à partir d’une table de référence plus petite, la table de hachage, disponible dans l’étape DATA depuis SAS 9 au début des années 2000, charge la table de référence en mémoire. Chaque recherche est alors quasi instantanée, et aucune des deux tables n’a besoin d’être triée, contrairement à un MERGE.
data ventes_enrichies;
if _n_ = 1 then do;
if 0 then set clients(keep=id_client segment);
declare hash h(dataset: "clients(keep=id_client segment)");
h.defineKey("id_client");
h.defineData("segment");
h.defineDone();
end;
set ventes;
if h.find() ne 0 then call missing(segment);
run;
La limite est la mémoire disponible : la table de référence doit y tenir. Côté SQL, l’optimiseur de PROC SQL sait utiliser les index et choisir sa méthode de jointure, mais l’option _METHOD permet de vérifier ce qu’il a réellement fait.
Le macro-langage, abordé dans la formation SAS expert, complète ces techniques pour automatiser des traitements répétitifs.
