Optimisation SAS Viya : Maîtriser le Pass-Through Implicite avec FedSQL
Simon 15 Aufrufe
Niveau de difficulté
Débutant
Veröffentlicht am :
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").
Wichtiger Haftungsausschluss
Die auf WeAreCAS.eu bereitgestellten Codes und Beispiele dienen Lehrzwecken. Es ist zwingend erforderlich, sie nicht blind in Ihre Produktionsumgebungen zu kopieren. Der beste Ansatz besteht darin, die Logik zu verstehen, bevor sie angewendet wird. Wir empfehlen dringend, diese Skripte in einer Testumgebung (Sandbox/Dev) zu testen. WeAreCAS übernimmt keine Verantwortung für mögliche Auswirkungen oder Datenverluste auf Ihren Systemen.
SAS und alle anderen Produkt- oder Dienstleistungsnamen von SAS Institute Inc. sind eingetragene Marken oder Marken von SAS Institute Inc. in den USA und anderen Ländern. ® zeigt die Registrierung in den USA an. WeAreCAS ist eine unabhängige Community-Site und nicht mit SAS Institute Inc. verbunden.
Diese Website verwendet technische und analytische Cookies, um Ihre Erfahrung zu verbessern.
Mehr erfahren.
