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").
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.
