Optimisation SAS Viya : Maîtriser le Pass-Through Implicite avec FedSQL
Simon 15 views
Niveau de difficulté
Débutant
Published on :
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").
Important Disclaimer
The codes and examples provided on WeAreCAS.eu are for educational purposes. It is imperative not to blindly copy-paste them into your production environments. The best approach is to understand the logic before applying it. We strongly recommend testing these scripts in a test environment (Sandbox/Dev). WeAreCAS accepts no responsibility for any impact or data loss on your systems.
SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. WeAreCAS is an independent community site and is not affiliated with SAS Institute Inc.
This site uses technical and analytical cookies to improve your experience.
Read more.
