In der SAS© Viya™-Umgebung ist die FedSQL-Sprache der Standard für die Interaktion mit Daten. Während sie sich hervorragend dazu eignet, Standardabfragen (ANSI SQL) in Datenbanken zu übersetzen (implizites Pass-Through), stößt sie an ihre Grenzen, sobald man proprietäre Funktionen der Datenbank-Engine nutzen möchte, wie z.B. Geospatial-Funktionen oder das Parsen von JSON.
Dieser Artikel befasst sich mit einer leistungsstarken Technik: dem expliziten Pass-Through, hier illustriert durch die Extraktion von JSON-Daten, die in PostgreSQL gespeichert sind.
Die Herausforderung: Die Grenzen der automatischen Übersetzung
Wenn Sie eine klassische FedSQL-Abfrage schreiben, versucht SAS©, diese in natives SQL zu übersetzen, um sie an die Datenbank zu senden. Enthält Ihre Abfrage jedoch Operatoren, die SAS© nicht kennt, schlägt die Übersetzung fehl, oder SAS© versucht, alle Daten lokal zu verarbeiten.
Betrachten wir den Fall von PostgreSQL, das hervorragende JSON-Verarbeitungsfunktionen über spezifische Operatoren wie -> oder ->> besitzt. Wenn Sie diese Symbole direkt in einer Standard-FedSQL-Abfrage verwenden, erhalten Sie einen Syntaxfehler, da der SAS©-Interpreter sie nicht erkennt.
Die Lösung: Das explizite Pass-Through
Die Lösung besteht darin, die Klausel CONNECTION TO zu verwenden. Diese Syntax erzeugt einen direkten "Tunnel" zur Datenbank.
Das Prinzip ist einfach: Alles, was innerhalb der Verbindungsklausel geschrieben wird, ist für den SAS©/FedSQL-Interpreter unsichtbar. SAS© nimmt die Zeichenfolge einfach und leitet sie unverändert an die PostgreSQL-Engine weiter.
Allgemeine Syntax
Konkreter Fall: Analyse von JSON-Daten
Stellen wir uns eine PostgreSQL-Tabelle vor, die eine Spalte data_json mit Rohdaten enthält. Wir möchten ein spezifisches Feld aus diesem JSON extrahieren und eine Aggregation berechnen, ohne das rohe JSON jemals in CAS zu laden (was aufwendig und unnötig wäre).
Der Code
Technische Analyse
Deshalb ist dieser Ansatz optimal:
Unsichtbarkeit für den Interpreter (Black Box):
Der FedSQL-Interpreter "sieht" die Operatoren -> und ->> nicht. Er versucht daher nicht, sie zu validieren. Würde er sie sehen, würde er einen Syntaxfehler zurückgeben, da diese Symbole im von SAS© unterstützten ANSI SQL-Standard nicht existieren. Es ist PostgreSQL, das die Rohzeichenkette empfängt und interpretiert.
Verwendung nativer Operatoren:
->: Ruft ein JSON-Objektfeld als JSON-Objekt ab.
->>: Ruft ein JSON-Objektfeld als Text (String) ab.
Diese Operatoren ermöglichen die Navigation in der hierarchischen Datenstruktur direkt auf Ebene der Speicher-Engine.
Performance und "Data Movement":
Dies ist der entscheidende Punkt.
Ohne explizites Pass-Through: Man müsste die gesamte Tabelle (mit dem komplexen JSON) in CAS laden und dann versuchen, den Text mit komplexen SAS©-Funktionen zu parsen. Dies verbraucht enorm viel Speicher und Netzwerkressourcen.
Mit explizitem Pass-Through: PostgreSQL führt die JSON-Extraktion und die Aggregation ("schwere Arbeit") durch. Der CAS-Server empfängt nur das Endergebnis: eine kleine Zusammenfassungstabelle ("kleine, gebrauchsfertige Tabelle").
Das explizite Pass-Through über CONNECTION TO ist für fortgeschrittene SAS© Viya™-Benutzer unerlässlich. Es ermöglicht, die Grenzen der Standard-FedSQL-Sprache zu überwinden, um 100% der Fähigkeiten Ihrer Datenbanken (JSON-, XML-Parsing, spezifische Indizierung) zu nutzen und gleichzeitig die Datenbewegungen zum CAS-Server drastisch zu minimieren.
