Mit der SAS© Viya™-Architektur entwickelt sich die Ausführung des Data Step von einer sequenziellen zu einer massiv parallelen Verarbeitung innerhalb des CAS-Servers (Cloud Analytic Services). Um diese Leistung voll auszuschöpfen, ist es notwendig, das SPDM-Paradigma (Single Program, Multiple Data) zu verstehen und bestimmte Konfigurationsparameter zu beherrschen.
1. Das Ausführungsparadigma: SPDM
Im Gegensatz zu Base SAS©, das den Code auf einem einzigen Prozessor ausführt, verwendet CAS den SPDM-Ansatz. Der Data Step-Code wird dupliziert und gleichzeitig an jeden "Worker Node" und jeden "Thread" gesendet.
Um eine Ausführung in CAS zu gewährleisten (und nicht eine kostspielige Rückführung zum SAS©-Client), sind zwei Bedingungen zwingend erforderlich:
Die Option DSACCEL=ANY muss aktiv sein (dies ist die Standardeinstellung).
Alle Tabellen (Eingabe und Ausgabe) müssen in einer CAS-Bibliothek (LIBNAME ... CAS) liegen.
Wichtiger Hinweis: Wenn eine einzelne Tabelle der Verarbeitung (z.B. in einer SET- oder MERGE-Anweisung) lokal ist (z.B. SASHELP.CARS oder WORK.DATA), wird die gesamte Verarbeitung auf die Client-Seite (SAS© Workspace Server) verlagert, wodurch die Leistungsvorteile des Clusters zunichte gemacht werden.
2. Der Leistungshebel: Der Parameter COPIES
In einer verteilten Umgebung ist die Verwaltung von Redundanz für die Fehlertoleranz entscheidend, aber sie hat Kosten in Bezug auf den Netzwerkverkehr (Data Movement).
COPIES=1 (Standardverhalten): CAS erstellt eine Sicherungskopie der Datenblöcke auf einem Nachbarknoten. Dies erzeugt erheblichen Inter-Node-Verkehr während des Schreibens.
COPIES=0 : Die Daten werden lokal auf dem verarbeitenden Knoten geschrieben, ohne sofortige Replikation.
Expertenempfehlung:
Für temporäre Tabellen (die keine persistenten Endergebnisse sind), erzwingen Sie systematisch die Option COPIES=0. Bei großen Volumina (z.B. 100 Millionen Zeilen) kann dies die Ausführungszeit um den Faktor 5 verkürzen, indem der Netzwerkengpass eliminiert wird.
3. Speicher- und Festplatten-Cache-Verwaltung (MaxTableMem)
Das Gleichgewicht zwischen RAM (schnell) und Festplatte (langsam) ist der Kern der Leistung in CAS. Obwohl CAS eine "In-Memory"-Technologie ist, basiert sie auf einem Festplatten-Cache-Mechanismus (CAS_DISK_CACHE), wenn der Arbeitsspeicher erschöpft ist oder für die temporäre Persistenz.
Der Parameter MaxTableMem definiert den Speicherschwellenwert, ab dem CAS beginnt, speicherabgebildete Dateien (memory-mapped files) zu verwenden, die von der Festplatte unterstützt werden, anstatt reinen RAM.
Um die interne Mechanik dieser Zuweisungen zu vertiefen, sind zwei Referenzressourcen unerlässlich:
CAS-Speicher verstehen: Für eine detaillierte Ansicht der Blockstruktur und der Interaktion zwischen Speicher und Festplatte lesen Sie den Artikel von Nicolas Housset über die In-Memory-Datenverwaltung in CAS. Er beschreibt detailliert, wie CAS Daten segmentiert, um den parallelen Zugriff zu optimieren.
Die Rolle des CAS_DISK_CACHE: Entgegen einer verbreiteten Meinung ist der Disk-Cache nicht nur ein Überlaufbereich (Swap). Er spielt eine aktive Rolle bei der Verwaltung geladener Tabellen. Der technische Artikel When is CAS_DISK_CACHE used? in der SAS© Community erklärt genau die Szenarien, die seine Verwendung auslösen (initiales Laden, Speicherüberlauf, Failover).
Technischer Tipp: Wenn Ihre Speicherinfrastruktur (die den CAS_DISK_CACHE hostet) langsam ist (HDD vs SSD) oder Ihr Netzwerk begrenzt ist (1GbE), kann eine Erhöhung des Wertes von MaxTableMem die Verwendung von RAM erzwingen und die Disk-I/O reduzieren, wodurch die Leistung erheblich verbessert wird.
4. Funktionale Besonderheiten in CAS
Das Codieren in Data Step für CAS erfordert einige Anpassungen im Vergleich zu traditionellem SAS©:
Anweisung RETAIN: Da Daten partitioniert sind, funktioniert die RETAIN-Anweisung nur innerhalb der Grenzen eines Threads. Es ist unmöglich, eine globale kumulative Summe über die gesamte Tabelle in einem einfachen Data Step zu berechnen.
Datentypen: CAS führt den Typ VARCHAR (variable Länge) ein, der speichereffizienter ist als der traditionelle CHAR (feste Länge) für lange Zeichenketten.
Anweisung BY: Die Gruppenverarbeitung erfordert, dass die Daten zuvor auf den Knoten korrekt partitioniert werden (über partition= oder groupby=), da sonst die implizite Sortierung kostspielig sein kann.
