La meilleure façon de comprendre CAS est de comprendre la terminologie et les concepts utilisés.

Le CAS controller

Le système CAS comprend de 1 à plusieurs node. Un node est désigné "contrôleur". Le contrôleur exécute un processus en tant que server controller et un processus pour chaque server worker. Le contrôleur est le référentiel pour l'état global  de CAS. Le client se connecte au contrôleur de serveur. Une fois authentifié, le CAS controller  crée un processus de session sur le contrôleur et sur chaque worker à inclure dans cette session. La connexion du client est ensuite transférée vers le contrôleur de session. À ce stade, le client peut commencer à soumettre des travaux à CAS.

Les CAS workers

L'objectifs  des CAS workers est d’exécuter la même demande que les autres workers et du CAS controller, et de traiter les données  locales. Cela permet à l’utilisateur ou à l’administrateur d’étaler les données sur le cluster pour permettre le traitement parallèle local des données qui seront ensuite rassemblées pour produire un résultat. CAS peut être déployé dans l’un des deux modes suivants:

• SMP: Symmetric Multi-Processing
• MPP: Massive Parallel Processing

En mode SMP, un seul node exécute CAS. Cela permet à un seul nœud de tirer parti de CAS sans avoir à investir dans un grand cluster ou dans un environnement cloud : En mode MPP, CAS permet le traitement parallèle sur les multiples workers : Ces deux modes offrent à un administrateur beaucoup de liberté pour configurer le système CAS de manière avantageuse pour leur utilisateurs. Un utilisateur peut souhaiter travailler avec CAS en mode SMP, sur un serveur simple, pour travailler et développer sur une application avant d'être éventuellement  sur un  cluster MPP.

Les sessions

CAS utilise des sessions pour suivre les utilisateurs et offre une interface de sécurité complète pour protéger les données au niveau fichier, comme au niveau colonne. Cette connexion à CAS a pour objectif de pouvoir exécuter des requêtes du serveur. Aussi, un utilisateur doit créer une session avant de pouvoir soumettre une requête. Une fois l’utilisateur authentifié, le contrôleur de serveur crée un processus session controller pour utilisateur et un processus session worker pour chaque CAS worker.  

Les tables CAS

Les données dans CAS sont représentées sous forme de table. Ces tables doivent être chargées en mémoire pour être accessibles. Une fois que chargée, une table peut être enregistrée en tant que fichier (sashdat) sur le disque. Les tables chargées ne doivent pas nécessairement entrer dans la mémoire disponible. En MPP, les  données de la table sont  réparties sur plusieurs workers pour permettre un traitement parallèle des données.

D'où viennent les tables et où sont-elles stockées ?

L'un des concepts importants dans CAS est l'origine d'une table, son chargement et les métadonnées nécessaires pour la charger. Les tables peuvent être chargées à partir du disque ou  à partir d'une base de données . CAS fournit un mécanisme pour organiser ces sources de données, les  «bibliothèques CAS» ou caslibs.

Les caslib

Les bibliothèques de CAS sont appelées caslibs et constituent un concept important pour accéder aux données dans CAS. Une caslib peut contenir zéro ou plusieurs tables CAS, en mémoire ou sous forme de fichiers sur un disque. Une caslib est associée à une source de données à partir de laquelle le serveur peut accéder aux données (Répertoires,base de données). Une caslib est associée à des contrôles d'accès qui définissent les groupes et les utilisateurs individuels autorisés à accéder à son contenu.

Les CAS actions

Le but de CAS est de permettre aux utilisateurs d'analyser leurs tables en mémoire et d'obtenir des résultats. Une CAS action est une tâche effectuée par CAS à la demande de l'utilisateur renvoyant une réponse contenant les résultats et le statut. Ce sont les éléments de base de l'exploration analytique. L'action est exécutée sur tous les nœuds du cluster. Comme expliqué au début de cet article, chaque nœud traite les données qui existent sur son nœud et synchronise la réponse vers le contrôleur. Source : The Architecture of the SAS® Cloud Analytic Services in SAS® Viya™ de Jerry Pendergrass