Der moderne Ansatz: Über die Sprache FedSQL, die direkt mit CAS verbunden ist.
Dieser Artikel konzentriert sich auf die zweite Methode: wie FedSQL Ihre Abfragen optimiert, indem es intelligent entscheidet, ob diese in CAS oder direkt in der Quellendatenbank ausgeführt werden sollen.
Verwenden wir die Option _method in PROC FEDSQL, um den Ausführungsplan zu visualisieren und zu verstehen, was unter der Haube geschieht.
Fall 1: Erfolgreiches Pass-Through (Maximale Optimierung)
Stellen wir uns einen Join zwischen zwei Tabellen (film und film_category) vor, die sich in derselben Postgres CASLIB (pg_db1) befinden.
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;
Log-Analyse: Wenn das Pass-Through funktioniert, sehen Sie einen Abschnitt 'Offloaded SQL statement', der die an Postgres gesendete native SQL-Abfrage zeigt, gefolgt von der Notiz:
NOTE: The SQL statement was fully offloaded to the underlying data source via full pass-through
Hier gelangt nur das gefilterte Ergebnis zurück zu CAS.
Fall 2: Das Pass-Through ist nicht möglich (Multi-Quellen)
Wenn wir denselben Join ausführen, die Tabellen jedoch aus zwei verschiedenen Datenbanken (also zwei unterschiedlichen CASLIBs, pg_db1 und pg_db2) stammen.
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;
Log-Analyse:
Die Engine kann keine einzelne SQL-Abfrage an zwei verschiedene Server senden. Der Ausführungsplan zeigt an:
SeqScan from PG_DB1.filmSeqScan from PG_DB2.film_category
CAS lädt die Tabellen temporär (oder scannt sie sequentiell) und führt den Join (HashJoin oder MergeJoin) selbst im Speicher aus.
/* 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;
Ergebnis:
Da wir die Kontrolloption requireFullPassThrough aktiviert haben, schlägt die Abfrage absichtlich fehl, anstatt die Daten zurückzuholen:
NOTE: Full pass-through to the underlying data source was not possible. Stopping execution.
Ohne diese Option hätte CAS die gesamte customer-Tabelle abgerufen, um das Datum lokal zu filtern, was bei großen Datenmengen katastrophal für die Performance sein kann.
Erweiterte Kontrolloptionen
FedSQL bietet zwei leistungsstarke Optionen für den "Query Planner", um dieses Verhalten zu steuern:
requireFullPassThrough: Stoppt die Ausführung, wenn die Abfrage nicht vollständig an die Datenbank delegiert werden kann. Dies ist eine wichtige Sicherheitsmaßnahme, um unbeabsichtigtes Laden großer Datenmengen zu vermeiden.
disablePassThrough: Erzwingt das Laden der Tabellen in CAS zur lokalen Verarbeitung (nützlich, wenn der Datenbankserver überlastet ist, CAS aber leistungsstark ist).
Datenquellen: Diese Funktionalität wird für Hadoop, Impala, ODBC, Oracle, PostgreSQL, Teradata, Amazon Redshift, DB2 und SAP HANA unterstützt. (Beachten Sie das bemerkenswerte Fehlen von SQL Server in einigen anfänglichen Versionen, abhängig von Ihrer Viya™-Version zu überprüfen).
Groß-/Kleinschreibung: FedSQL setzt Namen standardmäßig in Großbuchstaben. Für datenbanken, die Groß-/Kleinschreibung beachten (wie Postgres), verwenden Sie doppelte Anführungszeichen (z.B. 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.
