SAS Viya Tutorial: Daten in der Datenbank vor dem CAS-Laden vorverarbeiten

In der SAS^© Viya^™-Architektur besteht der Standard-Datenlebenszyklus oft darin, Tabellen von einer Quelle (Oracle, Postgres, Hadoop) in den Speicher des CAS-Servers zu kopieren, um sie anschließend zu analysieren. Dies ist der Ansatz „Zuerst laden, später analysieren“.

Wenn jedoch Datenquellen groß sind (mehrere Terabytes), ist es ineffizient, die gesamte Tabelle zu laden, um nur eine Zusammenfassung oder eine Teilmenge davon zu verwenden. Dies verbraucht unnötig Netzwerkbandbreite und RAM.

Obwohl PROC CASUTIL einfache Optionen bietet (WHERE=, VAR=), gibt es eine viel leistungsfähigere Methode, um komplexe Aggregationen oder Joins direkt in der Datenbank durchzuführen, noch bevor die Daten in CAS gelangen: das FedSQL Pass-Through.

Dieses Tutorial untersucht zwei Methoden, um die Arbeit an die Datenbank zu delegieren: den impliziten Modus und den expliziten Modus.

Methode 1: Das implizite Pass-Through (Die „Standard“-Methode)

Das implizite Pass-Through ermöglicht das Schreiben von Standard-FedSQL-Code (ähnlich ANSI-SQL). Der CAS Data Connector ist dafür verantwortlich, Ihre Abfrage in die native Sprache der Datenbank (Postgres-SQL, T-SQL, PL/SQL usw.) zu übersetzen.

Das Beispiel: Einfache Aggregation

Stellen wir uns eine Postgres-Tabelle mit 2 Millionen Zeilen (orders_large) vor. Wir möchten nur die Summe der Verkäufe nach Bestelltyp, gefiltert nach einem Datum, in CAS laden.

SAS^©-Code:

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;

Was hinter den Kulissen geschieht: Wenn die Tabelle orders_large noch nicht in CAS geladen ist, erkennt das Modul, dass es sich um eine externe Tabelle handelt. Es übersetzt die Abfrage in Postgres-SQL, sendet sie an den Server und lädt nur das aggregierte Ergebnis (wenige Zeilen) in CAS.

Performancegewinn:

Klassische Methode (vollständiges Laden + CAS-Aggregation): ~38 Sekunden.
Pass-Through-Methode (Datenbank-Aggregation + Ergebnis laden): ~0,32 Sekunden.

Der Unterschied ist enorm, da die Übertragung von 2 Millionen Zeilen über das Netzwerk vermieden wird. Das SAS^©-Protokoll bestätigt die Optimierung mit dem Hinweis:

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

Vorsicht bei nicht unterstützten Funktionen (Partial Pass-Through)

Das implizite Pass-Through hat seine Grenzen. Wenn Sie eine SAS^©-Funktion verwenden, die keine direkte Entsprechung in der Datenbank hat (z. B. KURTOSIS zur Berechnung der Kurtosis), kann das Modul diesen Teil der Berechnung nicht delegieren.

In diesem Fall sendet SAS^© das WHERE an die Datenbank (Filterung), holt aber alle gefilterten Zeilen zurück, um die KURTOSIS in CAS zu berechnen. Die Leistung wird im Vergleich zum „Full Pass-Through“ beeinträchtigt.

Methode 2: Das explizite Pass-Through (Die „Power User“-Methode)

Manchmal müssen Sie sehr datenbankspezifische Funktionen (JSON-Funktionen, Geodaten-Funktionen, bestimmte Indizes) verwenden, die dem Standard-FedSQL nicht bekannt sind.

Das explizite Pass-Through ermöglicht es Ihnen, eine Abfrage in nativer Sprache (reines Datenbank-SQL) direkt an das Modul zu senden, ohne Übersetzung durch SAS^©.

Syntax

Die Syntax basiert auf der Klausel CONNECTION TO:

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

Das fortgeschrittene Beispiel: JSON-Parsing in Postgres

Angenommen, Ihre Postgres-Tabelle jsonorders enthält eine JSON-Spalte. Sie möchten strukturierte Informationen (Kundenstatus, Menge) aus diesem JSON extrahieren und vor dem Laden in CAS aggregieren.

FedSQL kann JSON nicht nativ parsen, Postgres aber schon.

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 (...) : Alles, was in Klammern steht, ist für den SAS^©/FedSQL-Interpreter unsichtbar. Es wird so, wie es ist, an Postgres gesendet.

Operatoren -> und ->> : Dies sind Postgres-spezifische Operatoren zur Navigation in JSON-Objekten. SAS^© würde sie im impliziten Modus nicht verstehen.

Ergebnis: Postgres führt die JSON-Extraktion und die aufwendige Aggregation durch. CAS erhält nur eine kleine, gebrauchsfertige Übersichts-Tabelle.

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