Fedsql

Optimización SAS Viya: Dominar el Pass-Through Implícito con FedSQL

Simon 10 vues
Niveau de difficulté
Débutant
Publié le :
Dans : Fedsql
Tutorial Avanzado: Manipular JSON nativo en SAS Viya con FedSQL
22/12/2024 • 13
Tutorial de SAS Viya: Preprocesar datos en la base antes de cargar CAS
22/09/2024 • 12
SAS y SQL: Cómo replicar OVER PARTITION BY en SAS
23/07/2022 • 11
Resolver el error de conexión "BASE driver" con PROC FEDSQL
26/04/2022 • 6
Tutorial SAS: Aplicar formatos de fecha SAS con PROC FEDSQL
23/09/2021 • 10
Voir toute la catégorie

En el ecosistema SAS© clásico (v9), el concepto de SQL Pass-Through (implícito o explícito) es bien conocido para delegar los cálculos a la base de datos. Con la llegada de SAS© Viya™ y el motor en memoria CAS (Cloud Analytic Services), esta mecánica evoluciona.

Ahora existen dos formas de hacer SQL en Viya™:

  1. El enfoque tradicional: A través de los motores SAS©/ACCESS en el entorno SPRE (el lado "clásico" de Viya™).

  2. 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.

La Evolución del Comportamiento FedSQL

Para entender la optimización actual, es necesario observar la evolución del motor:

  • En SAS© Viya™ 3.2 (El pasado): El comportamiento predeterminado era la carga sistemática. Si consultaba una tabla de Oracle o PostgreSQL no cargada en memoria, CAS primero cargaba toda la tabla en memoria ("on-the-fly loading"), luego ejecutaba la consulta. Era funcional pero a veces costoso en recursos para filtros simples.

  • Desde SAS© Viya™ 3.3 (El presente): Se introdujo el Pass-Through Implícito. Si las tablas no están cargadas, CAS intenta traducir la consulta FedSQL a SQL nativo de la base de datos, la envía para su ejecución y carga solo el resultado en memoria.

Las condiciones del éxito

Para que el Pass-Through Implícito se active, deben cumplirse varias condiciones:

  1. Las tablas de origen no están ya cargadas en memoria en CAS.

  2. Todas las tablas consultadas pertenecen a la misma CASLIB (es decir, la misma conexión a la base de datos).

  3. La sintaxis de la consulta es compatible con la base de datos de destino (sin funciones SAS© propietarias intraducibles).

Análisis con Ejemplos

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

1caslib pg_db1 datasource=(srctype="postgres", ...);
2 
3PROC FEDSQL sessref=mySession _method;
4 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;
10QUIT;
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).

1PROC 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 ... */
7QUIT;

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.film SeqScan 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.

Caso 3: Funciones SAS© no soportadas

El uso de funciones específicas de SAS© (como PUT con un formato SAS©) a menudo impide la traducción a SQL estándar ANSI.

1/* Utilisation de l'option requireFullPassThrough pour forcer le test */
2PROC FEDSQL sessref=mySession _method cntl=(requireFullPassThrough);
3 create TABLE pg_db1.myresults as
4 select * from pg_db1."customer"
5 where put(create_date,ddmmyy10.)='14/02/2006'; /* Fonction SAS */
6QUIT;

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:

  1. 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.

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

Limitaciones a conocer

  • Solo Consulta Completa: Actualmente, el mecanismo solo soporta el "Full-Query Pass-Through". Esto significa que toda la consulta debe ser traducible. Si solo una parte (como un filtro WHERE) es traducible pero el resto no, la optimización parcial aún no se aplica (a diferencia del SAS©/ACCESS clásico).

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

Retour à la liste des articles
Copyright © WeAreCAS 2014-2026
SAS et tous les autres noms de produits ou de services de SAS Institute Inc. sont des marques déposées ou des marques de commerce de SAS Institute Inc. aux États-Unis et dans d'autres pays. ® indique un enregistrement aux États-Unis. WeAreCAS est un site communautaire indépendant et n'est pas affilié à SAS Institute Inc.