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").
Aviso importante
Los códigos y ejemplos proporcionados en WeAreCAS.eu son con fines educativos. Es imperativo no copiarlos y pegarlos ciegamente en sus entornos de producción. El mejor enfoque es comprender la lógica antes de aplicarla. Recomendamos encarecidamente probar estos scripts en un entorno de prueba (Sandbox/Dev). WeAreCAS no acepta ninguna responsabilidad por cualquier impacto o pérdida de datos en sus sistemas.
SAS y todos los demás nombres de productos o servicios de SAS Institute Inc. son marcas registradas o marcas comerciales de SAS Institute Inc. en los EE. UU. y otros países. ® indica registro en los EE. UU. WeAreCAS es un sitio comunitario independiente y no está afiliado a SAS Institute Inc.
Este sitio utiliza cookies técnicas y analíticas para mejorar su experiencia.
Saber más.
