Data Step oder Proc SQL?

[macrobo]

Hallo Forengemeinde,

Data Step oder Proc SQL? Eine immer wieder gerne diskutierte Frage.

In der letzten 'SAS Education Guide' Mail gab es hierzu einen interessanten Link.

Grüße

Robert

[Kurt_Bremser]

Ich gebe der Autorin Recht, dass SQL oft den einfacheren Code ermöglicht. Allerdings habe ich beim Umgang mit großen Datenmengen die leidvolle Erfahrung gemacht, dass ein optisch einfacher SQL Query gegenüber der selben Aktion in einer Folgen von SORT/DATA Steps nicht bloss langsamer (bis zu mehreren Größenordnungen!), sondern in einigen Fällen nicht durchführbar war. Ferner führen die konkurrierenden Random-Zugriffe in die Utility Files zu einer derartigen Auslastung (Latenzen!) auf dem Massenspeicher, dass im Multiuser-Betrieb die Situation schnell unerträglich wird.

Daher verwende ich SQL nur dort, wo ich es unbedingt brauche (Erzeugung eines kartesischen Produkts zB), oder wo die Daten aufgrund der geringen Größe zu keine Performance-Engpässen führen können.

Man sollte, bevor man ein Programm in den dauerhaften Produktionsbetrieb übergibt, immer einen Vergleichstest machen, bzw. prüfen, ob man mit den Echtdaten wegen der Größe in die Bredouille kommen könnte.

[AndreasMenrath]

Also mittlerweile sind wir im Jahr 2016 und es bieten sich für große Datenmengen auch noch weitere Datenverarbeitungslösungen an:

• Abfrage an die Datenbank auslagern
• SAS Code innerhalb der Datenbank ausführen

Darüber hinaus gibt es auch mit SAS Foundation die Möglichkeit mit PROC DS2 die Datenverarbeitung zu parallelisieren.

Wenn die Performance durch die Festplatte ausgebremst wird, bietet es sich auch an auf Produkte wie den SAS SPD Server zu setzen oder die Hardware auf SSD Laufwerke für den SAS WORK Bereich aufzurüsten.

Wie immer sind die Möglichkeiten vielfältig und ohne den konkreten Usecase ist eine Diskussion aus meiner Sicht sinnlos.

Man sollte die Verarbeitungsform (Data Step, SQL, DS2) verwenden, die einem am ehesten liegt und erst bei Performanceproblemen anfangen zu optimieren und Alternativen auszuloten.

Mein Favorit für normale Datenmengen bleibt SQL, da der Quellcode hierdurch wesentlich kompakter wird und man nicht eine ganze Bildschrimseite lesen muss, um einen Join zwischen zwei Tabellen zu sehen und dabei immer wieder die Frage im Raum steht, ob das MERGE Statement evtl. falsche Daten erzeugt, wenn die IDs für den Merge in beiden Tabellen mehrfach vorhanden sind.

[mfab]

Hallo zusammen,

hier möchte ich noch ein paar Aspekte ergänzen.

Wir haben auf unseren Systemen den SAS SPDS im Einsatz. Obwohl bei uns I/O-Zugriffe immer noch oft das Bottleneck sind, konnten wir dank Parallel Join Facility und Verwendung von SQL statt Data Step einige Datenschritte deutlich beschleunigen (Faktor 4 war dabei keine Seltenheit).

Dazu sollte ich ergänzen, dass bei Joins großer Datenmengen nie mehr als zwei Tabellen in einem Schritt verwendet werden sollten.

Komplexeren Code finde ich im Data Step teilweise übersichtlicher und da bieten sich auch mehr Möglichkeiten, wenn man sie denn braucht.

Insbesondere der Merge ist für mich aufgrund der von @AndreasMenrath angesprochenen Thematik nicht sinnvoll zu verwenden, weshalb ein SQL Join alternativlos ist.

Sonnige Grüße

Michael