Die zunehmende Digitalisierung und Geräte-Vernetzung verursacht immer größere Datenmengen, die wir als Ingenieure ungern verstauben lassen. Auch unsere eigenen, simulationsbasierten Datenquellen fördern zunehmend detailliertere Informationen zutage. MathWorks® hat eine recht lesenswerte Übersicht zum Arbeiten mit MATLAB und Big Data zusammengestellt. Ergänzend möchte ich unsere Erfahrungen mit der Verwaltung und Analyse großer Datenmengen teilen.

Die Basics

Jedenfalls 64-bit Versionen vom Betriebssystem und MATLAB installieren. Ein 32-bit Matlab hat nur noch aus Legacy- und Nostalgiegründen Berechtigung. 2GB Arbeitsspeichergrenze pro MATLAB? Undenkbar. MATLAB R2015b war übrigens ohnehin das letzte 32-bit Release. Zusätzlich verbesserte sich ab MATLAB 2015b die Execution Engine.

Frustfreies Arbeiten ohne Wartepausen wegen langsamer HDD-Zugriffe garantiert die Verwendung einer SSD. Ob Workstation oder Notebook, selbst 512 GB sind günstig zu erstehen und beschleunigen Programmstarts sowie Lese- und Schreibzugriffe v.a. bei vielen kleinen, vertstreuten Dateien. Zusätzlich wird der Swap-Speicher ("Auslagerungsdatei") flotter, sollte der Arbeitsspeicher einmal überlaufen. 

Auf die Geschwindigkeit beim Speichern und Laden von *.mat-Files scheint eine SSD jedoch kaum Einfluss zu haben (N=100), der limitierende Faktor scheint hier die Kompression bzw. Dekompression der Daten zu sein (CPU):

Was die Rechenleistung angeht, achten wir auf 4 physikalische Kerne (Intel durch die Bank). Im Gespann mit der Parallel Computing Toolbox sowie mindestens 16 GB Arbeitsspeicher werken dann bis zu 4 MATLABs parallel an einem Problem. Rechenintensive, homogene Tasks in unseren Kerntools sind allesamt für diese parallele Verarbeitung angepasst.

Daten vs. Information

Häufig lässt sich bei der Fülle an Informationen nicht a priori in Relevant und Irrelevant trennen. Alles könnte wichtig sein. Aber vielleicht kann man es wenigstens platzsparend aufbewahren:

Numerische Daten werden in MATLAB standardmäßig als doubles (8 Byte) angelegt. Damit ist man zwar auf der sicheren Seite, was die Genauigkeit angeht, praktisch ist in den allermeisten Fällen auch single-precision ausreichend. Aus pi==3.141592653589793 wird pi==3.1415927. Der Speicherbedarf von Messreihen (real oder simuliert) kann so billig halbiert werden. Darüber hinaus erheben wir nicht den Anspruch, unsere Modelle wären derart genau, dass wir 15 Nachkommastellen bräuchten ;)

Stichwort Zeitreihen: Messreihen aus Versuchsfahrzeugen mit über 900 Kanälen lassen sich durch geschickte Umkodierung auf 30% der ursprünglichen Größe reduzieren. Die meisten Kanäle haben einen geringen Informationsgehält bei gleichzeitig hohem Sampling. Durch die Transformation in nicht-äquidistante Zeitreihen (zB in timeseries-Objekte) gehen keine Informationen verloren.

ANDATA Toolboxes

Zum Schluss noch ein paar Hinweise zu unsereren Tools:

• Bei der Verwaltung vieler tausend Cases im Stipulator empfehlen wir den (maximalen) Java-Heapspace hochzudrehen (512MB)
• Installiere die Toolboxen lokal (nicht auf einem Netzlaufwerk!)
• Signalverarbeitung und Export im Stipulator arbeiten wenn möglich parallel, ebenso Brainer-trainings und Modellauswertung

PS: Für weitere methodische Aspekte im Umgang mit großen Datenmengen v.a. mit Brainer folgt ein separater Blogeintrag.