Comprendre et Gérer les Caslibs dans SAS Viya

Dans l'architecture SAS^©® Viya^™™, la gestion efficace des données repose sur un concept fondamental : la Caslib. Une Caslib est un espace en mémoire sur le serveur CAS (Cloud Analytics Services) destiné à contenir des tables, des contrôles d'accès et des informations sur les sources de données.

Cet article explore les différents types de Caslibs, leur portée (scope) et la manière de les manipuler via du code SAS^©, en mettant l'accent sur les meilleures pratiques pour le chargement et le partage des données.

Qu'est-ce qu'une Caslib ?

Une Caslib agit comme un point d'accès unifié. Elle permet de connecter le serveur CAS à :

Des sources de données externes (fichiers, bases de données comme Oracle ou Hadoop).
Des tables en mémoire qui ont été chargées sur le serveur CAS.

Elle associe également des contrôles d'accès qui définissent quels groupes d'utilisateurs ou individus sont autorisés à interagir avec les données.

Les Types de Caslibs

Il existe trois catégories principales de Caslibs, définies par la manière dont elles sont créées et gérées :

1. Caslib Personnelle

Cette bibliothèque est configurée lors de l'installation du serveur CAS. Lorsqu'une session CAS est initiée, la Caslib personnelle est toujours disponible avec une portée globale pour l'utilisateur courant. Elle permet d'accéder aux tables CAS depuis n'importe quelle session utilisant le même identifiant utilisateur (ex: casuser).

2. Caslib Prédéfinie

Gérées par les administrateurs CAS, ces bibliothèques ont une portée globale. Elles sont généralement utilisées pour des sources de données populaires partagées par un large éventail d'utilisateurs (par exemple, une connexion Hadoop-Hive ou Oracle commune à toute l'équipe). L'administrateur gère les permissions d'accès.

3. Caslib Ajoutée Manuellement

Les utilisateurs autorisés peuvent ajouter des Caslibs via une instruction CASLIB (par exemple dans SAS^©® Studio). C'est la méthode privilégiée pour des accès aux données ad hoc, lorsque l'utilisateur ne souhaite pas nécessairement partager les données avec l'ensemble du serveur.

La Portée des Caslibs : Session vs Global

La notion de portée (scope) est cruciale pour comprendre la visibilité et la persistance des données.

Caslib à Portée de Session (Session-Scope)

Si une Caslib est définie sans l'option GLOBAL, elle est limitée à la session en cours.

Disponibilité : Les tables chargées dans cette Caslib ne sont visibles que par la session CAS spécifique de l'utilisateur.
Persistance : Si l'utilisateur ouvre une nouvelle session, la Caslib et ses tables ne seront plus accessibles.

Exemple de code (Session-Scope) : Le code ci-dessous crée une connexion Hive locale à la session. Notez l'absence de l'option GLOBAL et de l'option PROMOTE.

Comprendre et Gérer les Caslibs dans SAS Viya -

1	CAS mySession host="myServer.com" SESSOPTS=(CASLIB=casuser TIMEOUT=999 LOCALE="en_US");
2
3	/* Assignation d'une Caslib Hive standard (Session scope) */
4	caslib hivelib desc="HIVE Caslib"
5	datasource=(SRCTYPE="HIVE",SERVER="myServerHadoop.com",
6	HADOOPCONFIGDIR="/opt/sas/hadoop/client_conf/",
7	HADOOPJARPATH="/opt/sas/hadoop/client_jar/",
8	schema="default", dfDebug=sqlinfo);
9
10	/* Chargement des tables Hive (En mémoire) */
11	PROC CASUTIL;
12	load casdata="stocks" casout="stocks" outcaslib="hivelib" incaslib="hivelib";
13	QUIT;

Si l'utilisateur tente d'accéder à cette table stocks depuis une nouvelle session (mySession2), il recevra une erreur indiquant que la Caslib n'existe pas :

ERROR: The caslib 'hivelib' does not exist in this session.

Caslib à Portée Globale (Global-Scope)

Une Caslib définie avec l'option GLOBAL est accessible à d'autres utilisateurs ou sessions, sous réserve des contrôles d'accès.

Partage : Pour qu'une table soit partagée, elle doit être chargée avec l'option PROMOTE.
Persistance : La définition de la bibliothèque persiste au-delà de la session unique.

Exemple de code (Global-Scope) : Ici, l'option GLOBAL rend la bibliothèque persistante, et PROMOTE rend la table accessible aux autres.

1	CAS mySession host="myServer.com" SESSOPTS=(CASLIB=casuser TIMEOUT=999 LOCALE="en_US");
2
3	/* Assignation d'une Caslib Hive Globale */
4	caslib hivelib desc="HIVE Caslib"
5	datasource=(SRCTYPE="HIVE",SERVER="myServerHadoop.com",
6	HADOOPCONFIGDIR="/opt/sas/hadoop/client_conf/",
7	HADOOPJARPATH="/opt/sas/hadoop/client_jar/",
8	schema="default", dfDebug=sqlinfo) GLOBAL;
9
10	/* Chargement et promotion de la table */
11	PROC CASUTIL;
12	load casdata="stocks" casout="stocks" outcaslib="hivelib" incaslib="hivelib" PROMOTE;
13	QUIT;

Une fois promue, la table est visible pour tout utilisateur ayant les droits d'accès. Un autre utilisateur peut alors voir et utiliser cette table via l'instruction CASLIB _ALL_ ASSIGN;.

Mécanismes de Chargement des Données

Il est important de distinguer deux mécanismes lors du chargement des données dans une Caslib :

Chargement côté client (Client-side load) : Les données résident sur la machine cliente (par exemple, là où tourne SAS^© Studio). Le transfert se fait du client vers le serveur CAS.
- Syntaxe : Utilise load data=... dans PROC CASUTIL.
Chargement côté serveur (Server-side load) : Les fichiers de données sont physiquement accessibles par le serveur CAS (sur le contrôleur CAS ou un montage NFS). C'est souvent plus performant pour les gros volumes.
- Syntaxe : Utilise load casdata=... via des connecteurs de données (comme PATH ou HIVE).
- Note technique : Pour les Caslibs basées sur un chemin (PATH), le chemin physique doit se trouver sur le serveur contrôleur CAS (ou un lecteur partagé monté sur celui-ci).

Administration et Suppression

Les administrateurs CAS peuvent gérer les privilèges via SAS^© Environment Manager. Cependant, il est parfois nécessaire de gérer les Caslibs par programmation.

Pour supprimer une Caslib (si vous avez les permissions), vous pouvez utiliser la procédure PROC CAS :

1	PROC CAS;
2	TABLE.dropCaslib caslib="NomDeLaCaslib" quiet=TRUE;
3	RUN;
4	QUIT;

Avertissement important

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.

Retour à la liste des articles