El enfoque moderno: A través del lenguaje FedSQL conectado directamente a CAS.
Este artículo se centra en este segundo método: cómo FedSQL optimiza sus consultas decidiendo inteligentemente ejecutarlas en CAS o directamente en la base de datos de origen.
Utilicemos la opción _method en PROC FEDSQL para visualizar el plan de ejecución y entender lo que sucede debajo del capó.
Caso 1: El Pass-Through Exitoso (Optimización máxima)
Imaginemos una unión entre dos tablas (film y film_category) ubicadas en la misma 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;
Análisis del Log: Si el Pass-Through funciona, verá una sección 'Offloaded SQL statement' mostrando la consulta SQL nativa enviada a Postgres, seguida de la nota:
NOTE: The SQL statement was fully offloaded to the underlying data source via full pass-through
Aquí, solo el resultado filtrado vuelve a CAS.
Caso 2: El Pass-Through Imposible (Multi-Fuentes)
Si realizamos la misma unión, pero las tablas provienen de dos bases de datos diferentes (es decir, dos CASLIBs distintas, pg_db1 y 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;
Análisis del Log:
El motor no puede enviar una sola consulta SQL a dos servidores distintos. El plan de ejecución mostrará:
SeqScan from PG_DB1.filmSeqScan from PG_DB2.film_category
CAS cargará temporalmente las tablas (o las escaneará secuencialmente) y realizará la unión (HashJoin o MergeJoin) él mismo en memoria.
/* 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;
Resultado:
Como hemos activado la opción de control requireFullPassThrough, la consulta fallará voluntariamente en lugar de traer los datos:
NOTE: Full pass-through to the underlying data source was not possible. Stopping execution.
Sin esta opción, CAS habría traído toda la tabla customer para filtrar la fecha localmente, lo que puede ser desastroso en términos de rendimiento en grandes volúmenes.
Opciones de Control Avanzadas
FedSQL ofrece dos opciones potentes para el "Query Planner" con el fin de controlar este comportamiento:
requireFullPassThrough: Detiene la ejecución si la consulta no puede ser delegada completamente a la base de datos. Es una seguridad vital para evitar cargas involuntarias de datos masivos.
disablePassThrough: Fuerza la carga de las tablas en CAS para procesamiento local (útil si el servidor de la base de datos está sobrecargado pero CAS es potente).
Fuentes de datos: Esta funcionalidad es compatible con Hadoop, Impala, ODBC, Oracle, PostgreSQL, Teradata, Amazon Redshift, DB2 y SAP HANA. (Tenga en cuenta la notable ausencia de SQL Server en algunas versiones iniciales, verifique según su versión de Viya™).
Mayúsculas/Minúsculas: FedSQL pone los nombres en mayúsculas por defecto. Para bases de datos sensibles a mayúsculas/minúsculas (como Postgres), use comillas dobles (ej: 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.
