Thread by @pavel23

Ich muss hier mal eine Lanze brechen für Python datatables von h2oai. Wenn man große Tabellen verarbeiten und viel und schnell darauf rechnen will, kenne ich nichts schnelleres und vielseitigeres. github.com/h2oai/datatable

Verarbeite damit gerade eine 35 GB große Tabelle mit 150 Mio. Zeilen und 24 Spalten auf dem MacBook Pro, und es ist so schnell, dass ich mir bisher nicht die Mühe gegeben habe, die Performance zu messen, und das will bei mir was heissen. Die Entwickler haben das aber gemacht:

h2o.ai/blog/speed-up-… Auch der Hauptspeicherverbrauch ist vergleichsweise gut; mit der 35GB-Tabelle habe ich nicht über 3GB gesehen, und die meisten vergleichbaren Technologien machen deutlich früher schlapp:

Ja, die Benchmarks sind von den Entwicklern, aber sie bestätigen meinen Eindruck, und es gibt mehr: medium.com/@marekgowacki/…

Nach mehreren Jahren mit 0.x Versionsnummern kommt demnächst die Release 1.0, und ich nutze es seit einem Jahr und hatte wenig Probleme. Die Dokumentation ist auch ok. Und es ist natürlich Open Source, MPL2.0.

Es ist allerdings weder die bekannteste noch meistverwendete Library für den Zweck, weil sie vergleichsweise neu ist, die erste Release war im März 2018, wobei zu dem Zeitpunkt schon einiges an Arbeit reingeflossen war, aber nicht Jahre.

Für mich füllt (py)datatables eine Lücke zwischen SQL-Datenbanken und auch den größeren NO-SQL-Datenbanken, wo man immer spürt, dass da eine Maschinerie dahinter arbeitet.

Datatables hat auch eine Maschinerie dahinter, aber man merkt sie nicht. Es fühlt sich an wie ein 2D-Array mit coolen Features, wo man komplexe Ausdrücke für die Indizes nehmen kann, die auch auf den Inhalt der Tabelle und Variablen im Python-Kontext zugreifen können.

Diese Ausdrücke werden dann an den in C++ geschrieben Kern übergeben und dort supereffizient und zum Teil "lazy" ausgeführt, also erst, wenn das Ergebnis benötigt wird, und es rechnet mit mehreren Threads. Bei alledem gibt es nichts zu konfigurieren. Dafür läuft es echt gut.

Das Ganze ist jetzt kein Ersatz für eine richtige Datenbank, wo man überwiegend mit einzelnen Datensätze hantiert und von verschiedenen Stellen zugreifen möchte und einzelne Datensätze gezielt persistent aktualisieren will, sondern es ist etwas, um schnell mit größeren ...

... Mengen an Zahlen und Strings zu hantieren, ohne sich allzuviel Gedanken über ein Schema oder Datentypen einerseits oder Speichermanagement und Performance andererseits zu machen. Beim Einlesen einer Datei wird für jede Spalte automatisch ein einheitlicher Datentyp gewählt,..

..je nachdem, was in der Spalte steht. Stehen da nur ganze Zahlen drin, wird es eine Ganzzahlen-Spalte, sind da Buchstaben drin, ist es eine String-Spalte. Man kann es aber auch selbst setzen oder konvertieren, aber das habe ich praktisch nie gebraucht.

Der .csv import funktioniert auch besser als in jedem Tabellenkalkulationsprogramm. Mit Word, Numbers, OpenOffice muss dabei man so oft Einstellungen ändern, obwohl es fast trivial ist, zu erkennen, was Trennzeichen und Dezimalpunkte sind und welchen Datentyp eine Spalte hat,..

...aber irgendwie hat sich bisher niemand die Mühe gemacht, dass mal ordentlich zu lösen. Oder kennt ihr was? Datatables ist da auch nicht perfekt, aber gefühlt recht ok, und vor allem konfiguriert man nicht bei jedem .csv-import neu - wenn überhaupt.

Will sagen, es verhält sich sehr wie eine Sprache mit dynamischen Typen, wie Python oder Javascript, mit denselben Nachteilen, nämlich dass Fehler allgemein später im Entwicklungs- und Verarbeitungsprozess erkannt werden, aber mit dem Vorteil, dass man einfach loslegen kann,...

...nah an den Daten dran, ohne wie sonst oft Dinge mehrfach hinschreiben zu müssen, die eigentlich überhaupt nicht hingeschrieben werden müssten, und sich dann durch Schichten durchzuarbeiten, statt Funktionalität zu implementieren.

So eine dynamische Umgebung ist ideal, wenn man Daten jagt, wie ich zum Beispiel neulich die Zensusdaten für alle Landkreise und die Berliner Bezirke und alles in verschiedenen Tabellen mit verschiedenen Spaltennamen daherkommt, oder allgemein in "Laborsituationen".

Meist aber bezahlt man in dynamischen Umgebungen mit hohen Performancenachteilen, und auch hier ist es nicht ganz umsonst, aber die Performance ist im Vergleich zum Programmieraufwand hier so gut, dass es die Grenzen dessen, was man auf dem Laptop machen kann, weit hinausschiebt.

Ja, es gibt große Datenbanksysteme mit viel Hardware und viel Speicher, die mit viel größeren Datenmengen klarkommen, aber eher nicht auf einem Laptop oder PC. Mit datatables dauert "select" mit mehren Variablen und Ergebnis by(Landkreis) auf 150 Mio Zeilen so 0,1-0,3 sec.

Das sind alle Daten, die das RKI seit einem Jahr veröffentlicht hat. Die sind leider alle nötig, um die täglich vom RKI veröffentlichten Zahlen richtig zu berechnen; aus dem letzten Dump allein kann man das nämlich nicht, obwohl er eigentlich fast alle früheren Daten enthält.

Bin jetzt zu 90% durch, um meine aktuell kaputte Risikotabelle mit der neuen Pipeline zu speisen, die präzise die täglichen RKI-Zahlen aus den Dumps herausrechnet, auch für die Altersgruppen und Geschlechter, wobei das die Rechenzeit verzehnfacht und ich da noch was machen muss.

Das coolste Feature aber, dass durch die neue Pipeline ohne viel Aufwand mit abfällt ist, dass man sich zeitlich in der Tabelle wird zurückbewegen können, weil ich jetzt Zeitreihen für alle Tabellenwerte habe, die man natürlich auch visualisieren kann, aber als erstes will ich...

...die Risikotabelle in möglichst ähnlicher Form wieder nutzbar machen. Es haben jetzt auch verschiedene Leute Hilfe angeboten, und sobald ich die Tabelle am Start habe, freue ich mich, gemeinsam nette neue Dinge zu bauen, die helfen, den Blick auf die Pandemie zu schärfen.