Tutoriel SAS Viya : Prétraiter les données en base avant le chargement CAS

Dans l'architecture SAS^© Viya^™, le cycle de vie standard des données consiste souvent à copier les tables depuis une source (Oracle, Postgres, Hadoop) vers la mémoire du serveur CAS pour ensuite les analyser. C'est l'approche "Load First, Analyze Later".

Cependant, lorsque les sources de données sont volumineuses (plusieurs téraoctets), charger l'intégralité de la table pour n'en utiliser qu'un résumé ou un sous-ensemble est inefficace. Cela consomme inutilement de la bande passante réseau et de la RAM.

Bien que PROC CASUTIL offre des options simples (WHERE=, VAR=), il existe une méthode beaucoup plus puissante pour effectuer des agrégations complexes ou des jointures directement dans la base de données avant même que les données n'arrivent dans CAS : le FedSQL Pass-Through.

Ce tutoriel explore deux méthodes pour déléguer le travail à la base de données : le mode Implicite et le mode Explicite.

Méthode 1 : Le Pass-Through Implicite (La méthode "Standard")

Le Pass-Through implicite permet d'écrire du code FedSQL standard (proche du SQL ANSI). Le connecteur de données CAS (Data Connector) se charge de traduire votre requête en langage natif de la base de données (SQL Postgres, T-SQL, PL/SQL, etc.).

L'Exemple : Agrégation simple

Imaginons une table Postgres de 2 millions de lignes (orders_large). Nous voulons charger dans CAS uniquement la somme des ventes par type de commande, filtrée sur une date.

Code 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;

Ce qui se passe en coulisses : Si la table orders_large n'est pas déjà chargée dans CAS, le moteur détecte qu'il s'agit d'une table externe. Il traduit la requête en SQL Postgres, l'envoie au serveur, et ne charge dans CAS que le résultat agrégé (quelques lignes).

Gain de performance :

Méthode classique (Chargement total + Agrégation CAS) : ~38 secondes.
Méthode Pass-Through (Agrégation en base + Chargement résultat) : ~0.32 secondes.

La différence est massive car on évite de transférer 2 millions de lignes sur le réseau. Le log SAS^© confirmera l'optimisation avec la note :

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

Attention aux fonctions non supportées (Partial Pass-Through)

Le Pass-Through implicite a ses limites. Si vous utilisez une fonction SAS^© qui n'a pas d'équivalent direct dans la base de données (par exemple KURTOSIS pour calculer l'aplatissement), le moteur ne pourra pas déléguer cette partie du calcul.

Dans ce cas, SAS^© enverra le WHERE à la base (filtrage), mais rapatriera toutes les lignes filtrées pour calculer le KURTOSIS dans CAS. La performance sera dégradée par rapport au "Full Pass-Through".

Méthode 2 : Le Pass-Through Explicite (La méthode "Power User")

Parfois, vous devez utiliser des fonctionnalités très spécifiques à votre base de données (fonctions JSON, fonctions géospatiales, index particuliers) que le FedSQL standard ne connaît pas.

Le Pass-Through explicite vous permet d'envoyer une requête en langage natif (SQL pur de la base) directement au moteur, sans traduction par SAS^©.

Syntaxe

La syntaxe repose sur la clause CONNECTION TO :

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

L'Exemple Avancé : Parsing JSON dans Postgres

Supposons que votre table Postgres jsonorders contienne une colonne de type JSON. Vous voulez extraire des informations structurées (état du client, quantité) stockées dans ce JSON et les agréger avant le chargement dans CAS.

FedSQL ne sait pas parser du JSON nativement, mais Postgres si.

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 (...) : Tout ce qui est entre parenthèses est invisible pour l'interpréteur SAS^©/FedSQL. C'est envoyé tel quel à Postgres.

Opérateurs -> et ->> : Ce sont des opérateurs spécifiques à Postgres pour naviguer dans des objets JSON. SAS^© ne les comprendrait pas en mode implicite.

Résultat : Postgres effectue l'extraction JSON et l'agrégation lourde. CAS ne reçoit qu'une petite table de synthèse prête à l'emploi.

Avertissement important

Les codes et exemples fournis sur WeAreCAS.eu sont à but pédagogique. Il est impératif de ne pas les copier-coller aveuglément sur vos environnements de production. La meilleure approche consiste à comprendre la logique avant de l'appliquer. Nous vous recommandons vivement de tester ces scripts dans un environnement de test (Sandbox/Dev). WeAreCAS décline toute responsabilité quant aux éventuels impacts ou pertes de données sur vos systèmes.

Retour à la liste des articles