SAS9

SAS-Optimierung: LIBNAME vs. SQL Pass-Through für große Datenmengen

Simon 11 vues
Niveau de difficulté
Débutant
Publié le :
Dans : SAS9
SAS-Tutorial: Daten sortieren mit PROC SORT meistern
26/01/2024 • 11
Optimierung der Leistung von PROC SUMMARY im SAS Enterprise Guide
26/04/2023 • 9
TRIM und Verkettung beherrschen
20/01/2023 • 14
TRIM und Verkettung beherrschen
20/01/2023 • 17
TRIM und Verkettung beherrschen
20/01/2023 • 15
Voir toute la catégorie

Wenn Sie SAS©-Codes erben, die komplexe Abfragen ausführen (viele Joins, Tabellen mit 40 bis 100 Millionen Zeilen), wird die Performance schnell zum entscheidenden Faktor. Eine wiederkehrende Frage stellt sich dann: Soll die einfache Methode des LIBNAME-Moduls verwendet werden oder die Hardcodierung über SQL Pass-Through?

Dieser Artikel untersucht, wie Engpässe diagnostiziert und die beste Strategie für Ihre massiven Joins ausgewählt werden können.

Das Dilemma: Implizit vs. Explizit

In SAS© gibt es zwei Hauptmethoden, eine externe Datenbank (Oracle, Teradata, SQL Server usw.) abzufragen:

  1. LIBNAME (Implizites Pass-Through): Sie weisen eine Bibliothek zu (libname mydb oracle ...) und verwenden die Tabellen, als wären sie lokal. SAS© versucht, Ihren SAS©-Code in natives SQL zu übersetzen, um ihn an die Datenbank zu senden.

  2. SQL Pass-Through (Explizites Pass-Through): Sie verwenden CONNECT TO in einer PROC SQL. Sie schreiben das SQL in der Sprache der Datenbank. SAS© leitet die Anfrage lediglich weiter und ruft das Endergebnis ab.

Das Performance-Problem tritt oft beim LIBNAME auf, wenn SAS© die Komplexität Ihrer Abfrage (insbesondere die 8 Joins) nicht vollständig übersetzen kann. In diesem Fall lädt SAS© die gesamten Tabellen (die 40 Millionen Zeilen) auf den lokalen SAS©-Server herunter, um die Joins selbst auszuführen, was die Verarbeitungszeiten explodieren lässt und das Netzwerk überlastet.

Schritt 1: Diagnose mit SASTRACE

Bevor Sie alles umschreiben, müssen Sie sehen, was "unter der Haube" passiert. Delegiert SAS© die Arbeit an die Datenbank oder ruft es die Daten ab?

Aktivieren Sie die Trace-Optionen, um das vom LIBNAME-Modul generierte SQL zu sehen:

1options sastrace=',,,d' sastraceloc=SASLOG;
Wenn Sie eine komplexe SQL-Abfrage mit Ihren JOIN und WHERE im Protokoll sehen: Das LIBNAME-Modul funktioniert gut (Implizites Pass-Through erfolgreich). Das Problem könnte an fehlenden Datenbankindizes liegen.

Wenn Sie einfache SELECT * FROM table sehen: SAS© ruft Rohdaten ab, um den Join lokal zu verarbeiten. Hier muss gehandelt werden.

Schritt 2: Optimierungsstrategien

Es gibt keine einzelne Antwort, aber hier sind die zu testenden Ansätze, vom einfachsten bis zum komplexesten.

Strategie A: Implizites Pass-Through erzwingen (LIBNAME)

Dies ist die bevorzugte Methode, da sie Ihren Code "sauber" und portabel (unabhängig vom Datenbanktyp) hält. Wenn der SASTRACE zeigt, dass die Arbeit nicht delegiert wird, versuchen Sie, die SAS©-Syntax zu vereinfachen oder SGBD-kompatible Funktionen zu verwenden, um SAS© bei der Übersetzung der Abfrage zu helfen.

Strategie B: Wechsel zum expliziten Pass-Through

Wenn das LIBNAME-Modul keine Optimierung durchführt, schreiben Sie die Abfrage direkt in nativem SQL über CONNECT TO.

  • Vorteil: Sie stellen sicher, dass die rechenintensive Arbeit (Joins, Sortierungen) vom Datenbankserver erledigt wird, der oft leistungsfähiger ist als der SAS©-Server.

  • Nachteil: Sie verlieren die Portabilität (der Code wird spezifisch für Oracle/SQL Server/usw.).

1PROC SQL;
2 connect to oracle (user=... password=... path=...);
3 create TABLE want as
4 select * from connection to oracle
5 (
6 SELECT A.id, B.value
7 FROM tableA A
8 INNER JOIN tableB B ON A.id = B.id
9 /* Ce code est exécuté par Oracle, pas SAS */
10 );
11 disconnect from oracle;
12QUIT;

Strategie C: Der hybride Ansatz (natives SAS©)

Entgegen der Intuition kann es vorkommen, dass Datenbanken für bestimmte Operationen weniger leistungsfähig sind als SAS©, oder dass das Netzwerk zu langsam ist, um das Ergebnis eines komplexen Joins zu übertragen.

Eine solide Alternative besteht darin:

  1. Nur die erforderlichen Spalten jeder Tabelle in temporäre SAS©-Tabellen zu extrahieren (Subsetting).

  2. Lokal PROC SORT und DATA STEP MERGE zu verwenden.

Die SAS©-Sortier-Engine ist extrem leistungsstark. Bei massiven Datenmengen kann ein gut vorbereiteter MERGE manchmal eine schlecht indizierte SQL-Abfrage auf Serverseite übertreffen.

Schritt 3: Die Performance messen

Verlassen Sie sich nicht auf Ihre Uhr. Verwenden Sie die integrierten Benchmarking-Tools, um Ihre Tests (LIBNAME vs. Pass-Through vs. Data Step) zu vergleichen:

  1. options FULLSTIMER;: Zeigt im Protokoll die CPU-Zeit, die reale Zeit und den verwendeten Speicher für jeden Schritt an.

  2. PROC SQL _method;: Wenn Sie bei reinem SAS© bleiben, zeigt Ihnen diese Option den von SAS© verwendeten Algorithmus (Hash Join, Sort Merge Join usw.) zur Ausführung der Abfrage an.

Es gibt keine Magie, nur vergleichende Tests (FULLSTIMER) in Ihrer spezifischen Umgebung.

Zur Optimierung Ihrer massiven Joins:

  1. Prüfen Sie zuerst mit SASTRACE, ob LIBNAME seine Aufgabe erfüllt.

  2. Testen Sie das explizite Pass-Through, wenn das implizite fehlschlägt.

  3. Schließen Sie die Option nicht aus, Datensubsets abzurufen, um einen lokalen MERGE durchzuführen, falls der Datenbankserver überlastet ist.

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.