Avec l'architecture SAS© Viya™, l'exécution du Data Step évolue d'un traitement séquentiel vers un traitement massivement parallèle au sein du serveur CAS (Cloud Analytic Services). Pour tirer pleinement parti de cette puissance, il est nécessaire de comprendre le paradigme SPDM (Single Program, Multiple Data) et de maîtriser certains paramètres de configuration.
1. Le Paradigme d'Exécution : SPDM
Contrairement à Base SAS© qui exécute le code sur un seul processeur, CAS utilise l'approche SPDM. Le code Data Step est dupliqué et envoyé simultanément à chaque "Worker Node" et chaque "Thread".
Pour garantir une exécution dans CAS (et non un rapatriement coûteux vers le client SAS©), deux conditions sont impératives :
L'option DSACCEL=ANY doit être active (c'est le défaut).
Toutes les tables (entrée et sortie) doivent résider dans une bibliothèque CAS (LIBNAME ... CAS).
Point de vigilance : Si une seule table du traitement (par exemple dans une instruction SET ou MERGE) est locale (ex: SASHELP.CARS ou WORK.DATA), l'intégralité du traitement basculera côté client (SAS© Workspace Server), annulant les gains de performance du cluster.
2. Le Levier de Performance : Le paramètre COPIES
Dans un environnement distribué, la gestion de la redondance est cruciale pour la tolérance aux pannes, mais elle a un coût en termes de trafic réseau (Data Movement).
COPIES=1 (Comportement par défaut) : CAS crée une copie de sauvegarde des blocs de données sur un nœud voisin. Cela génère un trafic inter-nœuds important lors de l'écriture.
COPIES=0 : Les données sont écrites localement sur le nœud qui les traite, sans réplication immédiate.
Recommandation d'expert :
Pour les tables intermédiaires (qui ne sont pas des résultats finaux persistants), forcez systématiquement l'option COPIES=0. Sur de gros volumes (ex: 100 millions de lignes), cela peut diviser le temps d'exécution par 5 en éliminant le goulot d'étranglement réseau.
3. Gestion de la Mémoire et du Cache Disque (MaxTableMem)
L'équilibre entre la RAM (rapide) et le disque (lent) est le cœur de la performance dans CAS. Bien que CAS soit une technologie "In-Memory", il s'appuie sur un mécanisme de cache disque (CAS_DISK_CACHE) lorsque la mémoire vive est saturée ou pour la persistance temporaire.
Le paramètre MaxTableMem définit le seuil de mémoire au-delà duquel CAS commence à utiliser des fichiers mappés en mémoire (memory-mapped files) soutenus par le disque, plutôt que la RAM pure.
Pour approfondir la mécanique interne de ces allocations, deux ressources de référence sont incontournables :
Comprendre le stockage CAS : Pour une vision détaillée de la structure des blocs et de l'interaction entre mémoire et disque, consultez l'article de Nicolas Housset sur la gestion des données In-Memory dans CAS. Il y détaille comment CAS segmentent les données pour optimiser l'accès parallèle.
Le rôle du CAS_DISK_CACHE : Contrairement à une idée reçue, le cache disque n'est pas uniquement un espace de débordement (swap). Il joue un rôle actif dans la gestion des tables chargées. L'article technique When is CAS_DISK_CACHE used? sur la communauté SAS© explique précisément les scénarios déclenchant son utilisation (chargement initial, dépassement de mémoire, failover).
Conseil technique : Si votre infrastructure de stockage (qui héberge le CAS_DISK_CACHE) est lente (HDD vs SSD) ou si votre réseau est limité (1GbE), augmenter la valeur de MaxTableMem peut forcer l'utilisation de la RAM et réduire les I/O disque, améliorant ainsi significativement les performances.
4. Particularités Fonctionnelles en CAS
Coder en Data Step pour CAS implique quelques adaptations par rapport au SAS© traditionnel :
Instruction RETAIN : Comme les données sont partitionnées, l'instruction RETAIN ne fonctionne qu'au sein des frontières d'un thread. Il est impossible de calculer une somme cumulative globale sur toute la table en une seule passe Data Step simple.
Types de données : CAS introduit le type VARCHAR (longueur variable), plus efficace en mémoire que le CHAR (longueur fixe) traditionnel pour les chaînes longues.
Instruction BY : Le traitement par groupe nécessite que les données soient correctement partitionnées sur les nœuds au préalable (via partition= ou groupby=), sinon le tri implicite peut être coûteux.
