Optimisation SAS Viya : Maîtriser le Pass-Through Implicite avec FedSQL
Simon 15 vues
Niveau de difficulté
Débutant
Publié le :
Le mot de l'Expert
Par Michael
Le Pass-Through Implicite avec FedSQL est le levier de performance ultime dans SAS Viya : il permet de filtrer et joindre vos données à la source pour ne transférer vers CAS que le strict nécessaire. Ma bonne pratique ? Utilisez systématiquement l'option _method dans votre PROC FEDSQL pour vérifier que la note « fully offloaded » apparaît bien dans votre log, garantissant que votre infrastructure ne sature pas inutilement le réseau.
L'approche moderne : Via le langage FedSQL connecté directement à CAS.
Cet article se concentre sur cette seconde méthode : comment FedSQL optimise vos requêtes en décidant intelligemment de les exécuter dans CAS ou directement dans la base de données source.
Utilisons l'option _method dans PROC FEDSQL pour visualiser le plan d'exécution et comprendre ce qui se passe sous le capot.
Cas 1 : Le Pass-Through Réussi (Optimisation maximale)
Imaginons une jointure entre deux tables (film et film_category) situées dans la même CASLIB Postgres (pg_db1).
caslib pg_db1 datasource=(srctype="postgres", ...);
proc fedsql sessref=mySession _method;
create table casuser.myresults{options replace=true} as
select film.title, film_category.category_id
from pg_db1."film" as film,
pg_db1."film_category" as film_category
where film.film_id=film_category.film_id and
film_category.category_id=1;
quit;
create TABLE casuser.myresults{options replace=true} as
5
select film.title, film_category.category_id
6
from pg_db1."film" as film,
7
pg_db1."film_category" as film_category
8
where film.film_id=film_category.film_id and
9
film_category.category_id=1;
10
QUIT;
Analyse du Log : Si le Pass-Through fonctionne, vous verrez une section Offloaded SQL statement montrant la requête SQL native envoyée à Postgres, suivie de la note :
NOTE: The SQL statement was fully offloaded to the underlying data source via full pass-through
Ici, seul le résultat filtré remonte vers CAS.
Cas 2 : Le Pass-Through Impossible (Multi-Sources)
Si nous faisons la même jointure, mais que les tables proviennent de deux bases de données différentes (donc deux CASLIBs distinctes, pg_db1 et pg_db2).
proc fedsql sessref=mySession _method;
create table casuser.myresults as
select film.title, film_category.category_id
from pg_db1."film" as film,
pg_db2."film_category" as film_category
/* ... suite de la requête ... */
quit;
1
PROC FEDSQL sessref=mySession _method;
2
create TABLE casuser.myresults as
3
select film.title, film_category.category_id
4
from pg_db1."film" as film,
5
pg_db2."film_category" as film_category
6
/* ... suite de la requête ... */
7
QUIT;
Analyse du Log :
Le moteur ne peut pas envoyer une seule requête SQL à deux serveurs distincts. Le plan d'exécution montrera :
SeqScan from PG_DB1.filmSeqScan from PG_DB2.film_category
CAS va charger temporairement les tables (ou les scanner séquentiellement) et effectuer la jointure (HashJoin ou MergeJoin) lui-même en mémoire.
/* Utilisation de l'option requireFullPassThrough pour forcer le test */
proc fedsql sessref=mySession _method cntl=(requireFullPassThrough);
create table pg_db1.myresults as
select * from pg_db1."customer"
where put(create_date,ddmmyy10.)='14/02/2006'; /* Fonction SAS */
quit;
1
/* Utilisation de l'option requireFullPassThrough pour forcer le test */
where put(create_date,ddmmyy10.)='14/02/2006'; /* Fonction SAS */
6
QUIT;
Résultat :
Comme nous avons activé l'option de contrôle requireFullPassThrough, la requête va échouer volontairement au lieu de rapatrier les données :
NOTE: Full pass-through to the underlying data source was not possible. Stopping execution.
Sans cette option, CAS aurait rapatrié toute la table customer pour filtrer la date localement, ce qui peut être désastreux en termes de performance sur de gros volumes.
Options de Contrôle Avancées
FedSQL offre deux options puissantes pour le "Query Planner" afin de maîtriser ce comportement :
requireFullPassThrough : Stoppe l'exécution si la requête ne peut pas être entièrement déléguée à la base de données. C'est une sécurité vitale pour éviter les chargements involontaires de données massives.
disablePassThrough : Force le chargement des tables dans CAS pour traitement local (utile si le serveur de base de données est surchargé mais que CAS est puissant).
Sources de données : Cette fonctionnalité est supportée pour Hadoop, Impala, ODBC, Oracle, PostgreSQL, Teradata, Amazon Redshift, DB2 et SAP HANA. (Notez l'absence notable de SQL Server dans certaines versions initiales, à vérifier selon votre version de Viya™).
Casse : FedSQL met les noms en majuscules par défaut. Pour les bases sensibles à la casse (comme Postgres), utilisez des guillemets doubles (ex: pg_db1."table").
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.
SAS et tous les autres noms de produits ou de services de SAS Institute Inc. sont des marques déposées ou des marques de commerce de SAS Institute Inc. aux États-Unis et dans d'autres pays. ® indique un enregistrement aux États-Unis. WeAreCAS est un site communautaire indépendant et n'est pas affilié à SAS Institute Inc.
Ce site utilise des cookies techniques et analytiques pour améliorer votre expérience.
En savoir plus.
