[Python-de] Wie Key-Value Sets speichern?

[Dr. Volker Jaenisch]

Servus Florian!

Am 28.09.2016 um 00:09 schrieb Florian Lindner:
> Dabei will ich folgendes:
>
> - Die Datei soll menschen-lesbar sein
>
> - Eingelesen werden soll es mit Python um dann z.B. mit numpy weiterverarbeitet werden.
>
> Wie würde nun ein geeignetes Datenformat ausschauen, was ich dann auch problemlos mit Python einlesen kann?
Ich frage mich, was Du mit dem Ganzen eigentlich bezweckst.

Du willst aus C++ in ein menschenlesbares Datenformat schreiben um es
dann zu Parsen um es dann mit Numpy zu verarbeiten?
Das erscheinen mir gleich zwei Widersprüche zu sein:
Wenn Du numpy brauchst sind es viele Daten. Wenn Du viele Daten hast,
will die sich ein Mensch nicht mehr anschauen. Und Du willst keinen
Parser dafür bauen, weil der a) langsam sein wird und b) Du dir wirklich
sicher sein musst, dass er richtig funktioniert. Was bei vielen Daten
nicht ganz einfach zu überprüfen ist.

Dein Daten sind irregulär, also keine rechteckige Matrix. Daher ist
Numpy sowieso nicht gut geeignet diese Daten direkt zu verarbeiten.
Warum willst Du also Dinge, die sich unterscheiden in einer Datei
aneinander hängen, um sie später für die Verarbeitung in Numpy wieder
auseinander zu pfriemeln.

Wenn Du an Deiner "Alles in einen File"-Strategie festhält, wirst  Du
beim Einlesen sowieso eine Art von Dispatching machen müssen um die
(sofern ich verstanden habe homogenen) Daten der einzelnen Runs wieder
aus Deinem File zu extrahieren.

Wir verarbeiten für einen großen KFZ-Hersteller CAN-Bus-Daten. Das sind
Signale die je nach Datenquelle anders kodiert sind. Also z.B. "Blinker
Hinten Rechts" hat nur ein paar Zustands-Bits. Dagegen ist die Drehzahl,
das Drehmoment und der Öldruck, des Motors ein Fließkomma-Wert. Alle
diese Daten kommen als ein großer Datenstrom an. Das Problem ist also
dem Deinigen evtl. ähnlich gelagert. Jede da draußen mit CAN-Daten
beschäftigte Firma baut sich, wie Du es auch vor hast, ein eigenes
Datenformat, um mit den Daten umzugehen.

Wir wollten nicht den gleichen Fehler machen und haben ein
standardisiertes Datenformat genommen. Wir dispatchen die CAN-Daten nach
der Datenquelle jeweils in eine Tabelle eines HDF5-Files. Es gibt also
eine Tabelle für den "Blinker hinten rechts" und eine andere Tabelle für
die Motordaten. Jede dieser HDF5-Tabellen hat dabei eine andere
Struktur. HDF5 ist ein sehr flexibles selbst dokumentierendes,
standardisiertes, komprimiertes, binäres, plattformunabhägiges
Datenformat welches mit zwei Python-Befehlen eine Tabelle in einen numpy
Array lesen/schreiben kann [1]. Ein HDF5-File ist aufgebaut wie ein
Dateisystem mit Ordnern in denen Tabellen (und beliebige andere Dinge
wie z.B. Grafiken) liegen können. Noch dazu kann mit mehr als
C-Geschwindigkeit in gigantisch großen Datenbeständen (größer als der
verfügbare RAM) aus Python heraus gesucht und gefiltert werden.

HDF5 ist erstmal nicht menschenlesbar - was meiner Meinung nach auch in
den seltensten Fällen nötig oder wünschenswert ist. Aber es gibt mit
hdf5dump und hdfview [2] plattformunabhängige Werkzeuge um HDF5-Files
konfortablel zu betrachten oder in menschenlesbare Form zu bringen. Die
Python Charting-Software VEUSZ [3] kann HDF5-Files direkt einlesen und
verarbeiten, wie auch alle anderen größeren Charting-Programme
Import-Filter für HDF5 anbieten. Ich habe mit Aesir [4] einen
QT-Python-HDF5-Viewer programmiert der deutlich schneller als HDFView
ist. Auch haben wir Datenklassen für Plone programmiert, um direkt im
Browser durch HDF5-Files zu navigieren und deren Tabellen als
Web-Tabellen und Charts darzustellen zu können [5]. Das ist der große
Vorteil eines gut dokumentierten und standardisierten Datenformats, es
ist eine gute Basis um selber darum ein Ökosystem zu entwickeln.

Ich hoffe Du erzählst uns ein bisschen mehr über Dein Projekt, dann
können wir Dir sicher bessere Ratschläge geben als JSON, YAML, welche
beide mit Numpy nicht so recht zusammengehen.

Beste Grüße

Volker

[1] http://www.pytables.org/
[2] https://support.hdfgroup.org/products/java/hdfview/
[3] http://home.gna.org/veusz/
[4] Noch nicht released. Kann bei Interesse aber gerne das Teil "as is"
mal auf github schieben.
[5] Erste Prototypen.

-- 
=========================================================
   inqbus Scientific Computing    Dr.  Volker Jaenisch
   Richard-Strauss-Straße 1       +49(08861) 690 474 0
   86956 Schongau-West            http://www.inqbus.de
=========================================================