Élasticité et Équilibrage de Charge CAS

Le paramètre tableRedistUpPolicy () définit la politique de redistribution des données de la table lorsque le nombre de 'worker pods' (nœuds de travail) augmente sur un serveur CAS en cours d'exécution. Les options sont :DEFER : La sélection de la politique de redistribution est différée à une entité de niveau supérieur.NOREDIST : Les données de la table ne sont pas redistribuées lors des changements du nombre de 'worker pods'.REBALANCE : Les données de la table sont rééquilibrées automatiquement pour optimiser la distribution sur les nouveaux 'worker pods'.Cette politique est fondamentale pour maintenir la performance et l'intégrité des données dans un environnement CAS évolutif.

Quelles sont les implications de 'tableRedistUpPolicy' lors de l'évolution de mon cluster CAS ? - alterTable

Le paramètre tableRedistUpPolicyParamètre de SAS Viya contrôlant la redistribution des données CAS lors de l'ajout de nœuds au cluster. Il définit si les tables existantes sont rééquilibrées pour optimiser les performances. (tableRedistUpPolicy="DEFER" | "NOREDIST" | "REBALANCE") définit la politique de redistribution des données de la table lorsque le nombre de 'worker pods' (nœuds de travail) augmente sur un serveur CAS en cours d'exécution. Les options sont :

DEFEROption du moteur de bibliothèque (libname) SAS Viya. Elle retarde la connexion à une base de données distante jusqu'au premier accès effectif, optimisant ainsi les ressources au démarrage. : La sélection de la politique de redistribution est différée à une entité de niveau supérieur.
NOREDISTOption empêchant la redistribution automatique des données entre les nœuds CAS. Elle préserve l'emplacement actuel des partitions pour optimiser les performances lors de jointures spécifiques. : Les données de la table ne sont pas redistribuées lors des changements du nombre de 'worker pods'.
REBALANCEAction CAS redistribuant les partitions d'une table de manière uniforme sur tous les nœuds actifs du cluster. Elle optimise la charge de travail distribuée et les performances de calcul. : Les données de la table sont rééquilibrées automatiquement pour optimiser la distribution sur les nouveaux 'worker pods'.

Cette politique est fondamentale pour maintenir la performance et l'intégrité des données dans un environnement CAS évolutif.

Schéma : Quelles sont les implications de 'tableRedistUpPolicy' lors de l'évolution de mon cluster CAS ?

Exemple de Code Additionnel

1	<pre>/* CASL Script : GESTION DE LA REDISTRIBUTION LORS DU CHARGEMENT EN MÉMOIRE
2	(c) Nicolas Housset 2026 - Code SAS pour VIYA 4 - testé et validé en version 2024.09 */
3	/* 1. Connexion et vérification de la topologie actuelle du cluster */
4	SESSION mySess;
5	BUILTINS.serverStatus RESULT=r;
6	PRINT "Nombre de workers actifs avant scale-up : " r.server.nodes;
7	/* 2. Chargement d'une table avec politique stricte pour optimiser l'élasticité K8s */
8	TABLE.loadTable /
9	caslib="Public"
10	path="massive_transactional_data.sashdat"
11	casout={
12	name="TX_DATA",
13	caslib="casuser",
14	promote=TRUE,
15	copies=1, /* Active la tolérance aux pannes */
16	tableRedistUpPolicy="NOREDIST" /* Empêche le transfert réseau si un pod s'ajoute */
17	};
18	/* 3. Analyse approfondie de la répartition des blocs sur les nodes */
19	TABLE.tableDetails /
20	caslib="casuser"
21	name="TX_DATA"
22	level="NODE"; /* Affiche la volumétrie hébergée par chaque worker pod */</pre>

Exemples pour l'action alterTable

Renommer une table et lui donner un label

Découvrez cet exemple pour l'action CAS alterTable : il illustre la mise à jour atomique des métadonnées (nom et label) au niveau du catalogue CAS, sans réécriture physique des blocs de données.

Modification lourde des colonnes

Découvrez cet exemple pour l'action CAS alterTable : il réalise une restructuration logique par modification de l'ordre des colonnes, suppression de variables et remappage des formats in-memory.

Conseil de l'Expert

En environnement Kubernetes, où l'élasticité (auto-scaling) de vos worker pods CAS est fréquente, privilégiez l'option NOREDIST pour la majorité de vos tables de travail quotidiennes. Le rebalancement (REBALANCE) d'une table massive en mémoire provoque un trafic réseau intra-cluster (I/O via le CNI Kubernetes) extrêmement lourd pour déplacer les blocs de données vers les nouveaux nœuds. Ce "shuffle" peut saturer votre réseau et figer temporairement les sessions concurrentes. Réservez REBALANCE uniquement aux tables analytiques géantes (plusieurs centaines de Go) qui seront sollicitées intensivement par des algorithmes de Machine Learning distribués, où la perfection de la data locality (symétrie de traitement) compense le coût initial du transfert réseau.

Impacts Techniques et Architecturaux du Redimensionnement

Overhead I/O Network (Politique REBALANCE) : Déclenche un transfert mémoire à mémoire des blocs de données entre les pods workers existants et les nouveaux pods. Si l'auto-scaling Kubernetes ajoute plusieurs nœuds simultanément, ce rebalancement massif peut provoquer des pics de latence CPU et réseau, impactant le SLA des autres requêtes en cours d'exécution sur le serveur CAS.
Asymétrie de Calcul (Politique NOREDIST) : Les nouveaux workers démarreront "à vide" concernant cette table. Les threads CAS (Actions Viya) exécutés ultérieurement ne pourront pas traiter de données localement sur ces nouveaux nœuds pour cette table spécifique. Ils agiront au mieux comme des nœuds de calcul génériques, ce qui crée un goulot d'étranglement sur les anciens nœuds possédant physiquement les blocs de la table en RAM.
Résolution de la politique DEFER : L'option DEFER n'est pas une action en soi, elle délègue la décision à la configuration globale du serveur. Dans SAS Viya 4, si aucune politique n'est surchargée, la résolution en cascade de DEFER aboutit généralement à un comportement NOREDIST par défaut pour éviter d'effondrer le cluster par inadvertance lors d'un scale-up.
Interaction avec la Tolérance aux Pannes (Fault Tolerance) : Si votre table possède le paramètre copies=1 (ou plus) pour la redondance, la redistribution affectera aussi les blocs secondaires. Un REBALANCE forcera la réallocation des sauvegardes (backups) sur les nouveaux nœuds pour garantir qu'un nœud ne possède jamais le bloc primaire et sa copie, optimisant ainsi la résilience en cas d'éviction (OOMKilled) d'un pod.
Tables Dupliquées vs Distribuées : La paramètre tableRedistUpPolicy cible l'architecture MPP (Massively Parallel Processing) des tables distribuées par blocs. Pour les petites tables de dimension intégralement chargées sur chaque nœud (tables dupliquées), les nouveaux workers devront obligatoirement charger l'intégralité de la table depuis la source physique (Caslib/HDFS/S3), rendant ce paramètre non pertinent.