IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Stackware

[Actualité] Architecture générale SAS®

Noter ce billet
par , 09/03/2015 à 16h17 (3785 Affichages)
Bonjour à tous,

Un petit billet pour commencer, d'autres suivront, sur le même thème. Une architecture SAS, ça ressemble à quoi?

Je ne parlerai pas des installations locales de SAS (tout sur mon PC et je n'ai besoin de rien d'autre), parce que ça n'a aucun intérêt et que l'on en voit de moins en moins.

Ci-dessous, un petit schéma d'une architecture "historique" valable jusqu'à la version 9.3. Nous somme aujourd'hui en 9.4 depuis plus de 2 ans, et cette dernière offre énormément de choses en plus que ce qui suit :
Nom : archi1.gif
Affichages : 6427
Taille : 22,8 Ko

En installation "basique", c'est à dire hors solutions métier particulières ou bien "Enterprise BI" (qui ajoute un serveur Web avec des applications de type BI), nous avons la plateforme de base : un Metadata server et un Compute server.
Ces deux composantes logiques peuvent être installées sur le même serveur physique bien entendu, mais il est important de faire le distingo entre les deux.
La partie métadonnées gère tous les paramètres des composants installés, ainsi que tout ce qui touche aux habilitations, authentifications et autres.

Le Compute server est appelé aussi serveur de calcul ou d'applications SAS. C'est le moteur. Il est le seul à savoir interpréter du code SAS et à l'exécuter.
Dans ce type de configuration, on peut lancer un programme sas de deux façons :
  • Ouvrir une session sur le serveur et lancer "sas" ou "sas.exe" là où il se trouve, avec des paramètres derrière, dont le nom du programme à lancer
  • Ouvrir une session de type workspace server, à partir d'un outil en client/serveur

Pour le premier cas, facile : je me connecte sur le serveur en ouvrant une session (MSTSC ou session SSH/X), et j'invoque ma commande sas.
Pour le second, je dispose de SAS Enterprise Guide, ou bien de Data Integration Studio (ETL SAS) à partir de mon poste, et ça ouvre une session distante sur le serveur.

Dans les deux cas, il faut que mon couple user/passe soit reconnu sur le serveur. Dans les deux cas, c'est bien le serveur qui travaille, et pas mon poste. Dans les deux cas les fichiers ou tables en entrée doivent être visibles ou accessibles par le serveur pour être traités, et c'est pareil pour le résultat s'il doit y en avoir un.

To be continued...

Envoyer le billet « Architecture générale SAS® » dans le blog Viadeo Envoyer le billet « Architecture générale SAS® » dans le blog Twitter Envoyer le billet « Architecture générale SAS® » dans le blog Google Envoyer le billet « Architecture générale SAS® » dans le blog Facebook Envoyer le billet « Architecture générale SAS® » dans le blog Digg Envoyer le billet « Architecture générale SAS® » dans le blog Delicious Envoyer le billet « Architecture générale SAS® » dans le blog MySpace Envoyer le billet « Architecture générale SAS® » dans le blog Yahoo

Mis à jour 29/03/2015 à 21h09 par Stackware (catégorie)

Catégories
Architecture SAS®

Commentaires

  1. Avatar de kolodz
    • |
    • permalink
    Bonjour,

    J'avoue que jusqu'à la moitié de ce billet, je me posais la question suivante :
    L'utilisation de l’acronyme SAS. Parle-t-on de Statistical Analysis System ? Ou est-ce un SaaS Software as a service ?

    Pour la suite, tu explique deux solutions sans en expliquer les avantages ou les inconvénients. Comment choisit tu l'un par rapport à l'autre ?

    Source :
    http://fr.wikipedia.org/wiki/SAS_%28langage%29
    http://en.wikipedia.org/wiki/Software_as_a_service
  2. Avatar de Stackware
    • |
    • permalink
    Bonjour,
    Je ne peux pas écrire et consacrer énormément de temps à chaque fois, il va falloir être patient (c'est pour cela que j'ai écrit "to be continued"). Entre SAS et SaaS, l'écart est minime, mais il existe. J'ai ajouté ® dans le titre, pour que ce soit plus parlant et qu'il n'y ait plus confusion (SaaS n'est pas une marque déposée).
    En tous cas merci de m'avoir lu et à très bientôt pour la suite d'un billet qui risque d'être assez longue, étant donné la richesse du sujet...