Tutorial de SAS Viya: Preprocesar datos en la base antes de cargar CAS

En la arquitectura de SAS^© Viya^™, el ciclo de vida estándar de los datos a menudo consiste en copiar tablas de una fuente (Oracle, Postgres, Hadoop) a la memoria del servidor CAS para luego analizarlas. Este es el enfoque "Cargar primero, analizar después".

Sin embargo, cuando las fuentes de datos son voluminosas (varios terabytes), cargar la tabla completa para usar solo un resumen o un subconjunto es ineficaz. Esto consume innecesariamente ancho de banda de red y RAM.

Aunque PROC CASUTIL ofrece opciones simples (WHERE=, VAR=), existe un método mucho más potente para realizar agregaciones complejas o uniones directamente en la base de datos incluso antes de que los datos lleguen a CAS: el FedSQL Pass-Through.

Este tutorial explora dos métodos para delegar el trabajo a la base de datos: el modo Implícito y el modo Explícito.

Método 1: El Pass-Through Implícito (El método "Estándar")

El Pass-Through implícito permite escribir código FedSQL estándar (cercano al SQL ANSI). El conector de datos CAS (Data Connector) se encarga de traducir su consulta al lenguaje nativo de la base de datos (SQL Postgres, T-SQL, PL/SQL, etc.).

El Ejemplo: Agregación simple

Imaginemos una tabla de Postgres de 2 millones de filas (orders_large). Queremos cargar en CAS únicamente la suma de las ventas por tipo de pedido, filtrada por una fecha.

Código SAS^©:

1	cas mysession;
2	/* Définition de la connexion à Postgres */
3	caslib caspgr datasource=(srctype="postgres", database="DCON", server="...", ...) libref=caspgr;
4
5	PROC FEDSQL sessref=mysession;
6	/* Création de la table résultante directement dans la RAM de CAS */
7	create TABLE caspgr.revenuesummary{options replace=true} as
8	select order_type, sum(total_sale) as revenue
9	from caspgr."orders_large" /* Notez les guillemets pour préserver la casse */
10	where order_date < date'2015-01-01'
11	group BY order_type;
12	QUIT;

Lo que sucede entre bastidores: Si la tabla orders_large no está ya cargada en CAS, el motor detecta que es una tabla externa. Traduce la consulta a SQL Postgres, la envía al servidor y solo carga en CAS el resultado agregado (unas pocas líneas).

Ganancia de rendimiento:

Método clásico (Carga total + Agregación CAS) : ~38 segundos.
Método Pass-Through (Agregación en base de datos + Carga de resultado) : ~0.32 segundos.

La diferencia es enorme porque se evita transferir 2 millones de líneas por la red. El registro de SAS^© confirmará la optimización con la nota:

NOTE: The SQL statement was fully offloaded to the underlying data source via full pass-through

Atención a las funciones no soportadas (Partial Pass-Through)

El Pass-Through implícito tiene sus límites. Si utiliza una función de SAS^© que no tiene un equivalente directo en la base de datos (por ejemplo, KURTOSIS para calcular la curtosis), el motor no podrá delegar esta parte del cálculo.

En este caso, SAS^© enviará el WHERE a la base de datos (filtrado), pero recuperará todas las líneas filtradas para calcular la KURTOSIS en CAS. El rendimiento se degradará en comparación con el "Full Pass-Through".

Método 2: El Pass-Through Explícito (El método "Usuario Avanzado")

A veces, necesita utilizar funcionalidades muy específicas de su base de datos (funciones JSON, funciones geoespaciales, índices particulares) que el FedSQL estándar no conoce.

El Pass-Through explícito le permite enviar una consulta en lenguaje nativo (SQL puro de la base de datos) directamente al motor, sin traducción por SAS^©.

Sintaxis

La sintaxis se basa en la cláusula CONNECTION TO :

1	SELECT ... FROM CONNECTION TO nom_caslib ( votre_requête_native_ici )

El Ejemplo Avanzado: Parseo de JSON en Postgres

Supongamos que su tabla de Postgres jsonorders contiene una columna de tipo JSON. Quiere extraer información estructurada (estado del cliente, cantidad) almacenada en este JSON y agregarla antes de cargar en CAS.

FedSQL no sabe parsear JSON de forma nativa, pero Postgres sí.

1	PROC FEDSQL sessref=mysession;
2	create TABLE caspgr.StateSalesSummary as
3	select customerstate, minquantity, maxquantity, sumquantity
4	from connection to caspgr
5	(
6	/* DEBUT DU SQL NATIF POSTGRES */
7	SELECT customerstate,
8	min(quantity) as minquantity,
9	max(quantity) as maxquantity,
10	sum(quantity) as sumquantity
11	FROM
12	(
13	/* Utilisation des opérateurs JSON Postgres -> et ->> */
14	SELECT orderinfo -> 'customer' ->> 'state' as customerstate,
15	cast(orderinfo -> 'items' ->> 'qty' as integer) as quantity
16	FROM jsonorders
17	) t
18	GROUP BY customerstate
19	/* FIN DU SQL NATIF POSTGRES */
20	);
21	QUIT;

FROM CONNECTION TO caspgr (...) : Todo lo que está entre paréntesis es invisible para el intérprete SAS^©/FedSQL. Se envía tal cual a Postgres.

Operadores -> y ->> : Son operadores específicos de Postgres para navegar en objetos JSON. SAS^© no los entendería en modo implícito.

Resultado: Postgres realiza la extracción JSON y la agregación pesada. CAS solo recibe una pequeña tabla de resumen lista para usar.

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.

Volver a la lista de artículos