Die Zuweisung 'df = read_feather()' überschreibt die alte Referenz zur Dataframe in df, sodass die alte Dataframe gelöscht wird, dh. es würde hier noch zusätzliche Zeit für das freigeben des Speichers der Dataframe eingerechnet werden. Ein 'del df' oder auch 'df = None' könnte hier vor dem starten des Timers eingebaut werden, sodass das Löschen der großen Dataframe nicht erst bei der Zuweisung geschieht. Genau so könnte man hier auch verschiedene Variablennamen nutzen.
Bei riesigen Datensätzen fällt das Editieren von Hand in der Datei sowieso in den Hintergrund, dass lasse ich lieber meinen Rechner erledigen... sehr nice erklärt
Für alle, die R und Python nutzen: Feather ist interoperabel! Es gibt das package "feather" für R, das ihr nutzen könnt. Daher ist feather ne gute bridge für beide systeme! Die Frage, die schon mal genannt wurde bleibt dennoch: Derzeit ist für sehr viele csv noch das Standardformat. CSV in R hat zB das Problem, dass es durch öffnen in anderen apps geändert wird und dann die R Funktionen zum Einlesen gerne spinnen. Insofern ist feather hier besser, da man gezwungen ist, es in der IDE oder eben der Console aufzumachen. Schöne Sache!
Dass feather-Dateien nicht im Klartext lesbar und editierbar sind, hätte ich gleich am Anfang des Videos gesagt. Daher sind sie kein Ersatz für CSV's, können aber ggf. eine effizientere Alternative sein. Interessanter wäre m.E. gewesen, die Vor- und Nachteile der Feathers gegenüber anderen Binärformaten aufzuzeigen.
Editierbarkeit ist bei einem unterspezifierten Format wie CSV eher Fluch als Segen. Da ist nix festgelegt, kein Trennzeichen, keine Quotierung von Steuerzeichen etc. Ergo kann man eine CSV Datei schnell kaputt machen wenn man sie in einem Tabellenkalkulation lädt und dann wieder falsch rausspeichert. Von der Datenstruktur ganz zu schweigen - ob ein Zahlenfeld int sein muss oder auch Floats enthalten kann, lässt sich in CSV nicht definieren. Streng genommen könnte das Format Zeile für Zeile wechseln.
Ich hätte in der Schleife die Reihenfolge von Feather und CSV nach jeder Iteration getauscht bzw. in allen Kombinationen gleichverteilt ausgeführt, da durch Caches womöglich ein Bias entsteht.
Der Knackpunkt bei .feather ist, welche Programmiersprachen/Tools dieses Dateiformat überhaupt übersetzen können. einen .csv - parser kann ich mir theoretisch in jeder Programmiersprache mit verhältnismäßig geringem Aufwand selbst schreiben und auch die meisten Tabellenprogramme, wie excel oder libre calc, können damit etwas anfangen. Vor allem dann, wenn auch Naturwissenschaftler mit den Daten etwas anfangen wollen und dann mit Excel ankommen, stelle ich mir das schwierig vor. Bei Wissenschaft geht es auch darum, Daten einer möglichst breiten Masse zur Verfügung zu stellen.
Hier geht es aber nicht unbedingt um Datensätze, die von Menschen wieder gelesen werden sollen. Z.B. hat eine CSV Datei eines IOT-Netzwerks mit 1 Millionen Geräten, dass 4 verschiedene uint8 Parameter für jede Sekunde eines tages abspeichert eine Größe von 350 MB. Wenn ich das für ein ganzes Jahr speichern möchte, um danach CNNs zu trainieren muss ich 130 GB speichern, die mir das ganze Jahr über den Speicher belegen, bis ich sie dann mal 2 Wochen lang nutze. Den Datensatz händisch auszulesen ist bei solchen Datenmengen eh zwecklos und eine csv Datei lässt sich in dieser Größe auch nicht mehr mit Excel öffnen. Aber eine Millionen Geräte ist ja nicht das Limit. Wenn ich in 20 verschiedenen Ländern je 5 Millionen Geräte habe sind das bereits 13 Terabyte, die auf einen herkömmlichen Arbeitsrechner gar nicht gespeichert werden können und dann verdoppeln wir das ganze noch einmal wegen der Back Ups. Und das ganze nur um ein paar 8-bit Integer als Rohdaten zu sammeln.
Naja, intern kann man das nutzen. Aber wen die Dateien noch irgendwo anders verwendet werden dann ist csv immer noch ein gute Wahl. Fraglich wieviel Programme feather als Datenformat unterstützen.
Super Video und gut erklärt, ich hätte nur die letzten beiden print statements in print(f"{duration_feather / runs = }") und print(f"{duration_csv / runs = }") geändert. Dadurch wird die Ausgabe meiner Meinung nach deutlich übersichtlicher, weil man auch gleich sieht, auf welche Variablen sich das Ergebnis bezieht :)
Ich verwende feather immer um große Datenmengen zu speichern wenn das Programm läuft. Während der Entwicklung nutze ich jedoch manchmal csv files damit ich mir die Prozedur erst mit kleineren Datensets in Tabellenkalulaltionsprogrammen überlegen kann. Einige davon unterstützen den Import von feather leider nicht.
Naja Textformat vs Binary war jetzt nicht so sonderlich überraschend Generell wäre ein Vergleich der Datenformate eventuell interessant und wann und warum man welches davon Verwenden sollte / könnte. Also Feather / Parquet / HDF5 / usw.
Unabhängige Zufallsgrößen sind vielleicht nicht das Beste, um ein komprimierendes Datenformat wie Feathers zu testen. Echte Daten haben für gewöhnlich weniger Entropie, da spielt Kompression seine Stärke besser aus. Ich habe das Video nach ein paar Minuten nicht weiter anschauen wollen. Es hat einfach gefehlt, um was es eigentlich geht - was Feather überhaupt ist. Stattdessen wilde Tests und wenig Theorie. Da habe ich lieber selber nachgelesen.
Feather ist ein bissl schneller beim schreiben, langsamer beim lesen. Bei parquet ist es genau umgekehrt. Schreibst du genau so oft wie du liest, nimm feather. Wenn du einmal schreibst und 5 mal liest, nimm Parquet.
Hi Morpheus, es wäre sehr interessant wie ich eine bestehende csv Datei in feather konvertieren kann. Ich habe das Problem , dass ich alle App Store Apps gescrapt habe und die jetzt gerne analysieren würde in Notebook, aber die csv Datei ist zu groß und wenn ich das in Chunks verwandle kann ich die Daten nicht mehr analysieren. Gibt es dazu eine Lösung? Würde mich über eine schnelle antwort sehr freuen
Irgendeinen Tod muss man bekanntlich sterben und je nach Szenario kann das eine oder andere eben besser sein. Außerdem: Dario Radecic hätte sich bestimmt gefreut, mit seinem Artikel v. Sep. 2021 (auf towardsdatascience) verlinkt zu werden, wenn der Source schon "adaptiert" wird.
Werde mir das aber gleich mal anschauen, rufe gerade Daten aus verschiedene Quellen ab und führe diese zusammen. Klingt nach einer guten Möglichkeit, die Daten aus der vorverarbeitung zu speichern 🤔 was mich noch interessieren würde: ein Vergleich mit sqlite
Die Frage ist immer, was man hinterher mit den Daten machen will. Will man im eigenen Programm im Speicher Berechnungen anstellen, kann feather Vorteile bringen, weil man weniger Platz auf dem Datenspeicher braucht und Zugriffe auf diesen in der Regel hohe Zeitkosten haben. Will man hingegen Sachen machen, die eine SQL-Datenbank leisten kann, ist diese in der Regel viel schneller, weil in den üblichen SQL-Datenbanksystemen viele Mann-Jahrtausende an Optimierungsarbeit drinstecken.
Feather als Binärformat dürfte viel von den Daten einfach kopieren, während CSV in eine Textdarstellung konvertieren muss und die beim Lesen dann wieder parst. Ich gehe davon aus, dass die beiden die meiste Zeit fressen. Nebenbei sind Feather-Dateien dadurch (und durch zusätzliche Kompression) kleiner, was auf modernen SSD vielleicht nicht mehr so viel ausmacht.
Da feather in der Regel LZ4-komprimierte (alternativ auch Zstandard) Binärdaten sind, dürften der Plattenplatzbedarf in der Regel bei unter 25% der Menge liegen, die eine CSV-Datei braucht, sofern man es mit Zahlen zu tun hat.
@@mafa5534 natürlich sind extreme Datenmengen der Grenzfall. Wenn du jetzt zum Beispiel mit bestimmten Wissenschaftlern redest, finden die etliche GB von Excel Tabellen noch handlich. Ich musste selbst schon mal einen exporter für messreihen in Excel bauen und da war meine einzige, sinnvolle Lösung der zwischenstopp via CSV und der automatische Import in ein Excel Dokument.
![Quando Rondo - Life Goes On [Official Music Video]](http://i.ytimg.com/vi/eIf3fhMXAow/mqdefault.jpg)
Die Zuweisung 'df = read_feather()' überschreibt die alte Referenz zur Dataframe in df, sodass die alte Dataframe gelöscht wird, dh. es würde hier noch zusätzliche Zeit für das freigeben des Speichers der Dataframe eingerechnet werden. Ein 'del df' oder auch 'df = None' könnte hier vor dem starten des Timers eingebaut werden, sodass das Löschen der großen Dataframe nicht erst bei der Zuweisung geschieht. Genau so könnte man hier auch verschiedene Variablennamen nutzen.
Bei riesigen Datensätzen fällt das Editieren von Hand in der Datei sowieso in den Hintergrund, dass lasse ich lieber meinen Rechner erledigen... sehr nice erklärt
Mich hätte noch die Dateigröße und der Vergleich mit z.B. Pickle interessiert. Danke
Bei mir hat die gleiche Ausführung 850MB mit csv und 321MB mit feather.
Ich kann mich noch an ein Data Science/ML Modul im Studium erinnern, als ich das erste Mal auf Feather gestoßen bin und was für ein Segen das war :D
Für alle, die R und Python nutzen: Feather ist interoperabel! Es gibt das package "feather" für R, das ihr nutzen könnt. Daher ist feather ne gute bridge für beide systeme! Die Frage, die schon mal genannt wurde bleibt dennoch: Derzeit ist für sehr viele csv noch das Standardformat. CSV in R hat zB das Problem, dass es durch öffnen in anderen apps geändert wird und dann die R Funktionen zum Einlesen gerne spinnen. Insofern ist feather hier besser, da man gezwungen ist, es in der IDE oder eben der Console aufzumachen. Schöne Sache!
Dass feather-Dateien nicht im Klartext lesbar und editierbar sind, hätte ich gleich am Anfang des Videos gesagt. Daher sind sie kein Ersatz für CSV's, können aber ggf. eine effizientere Alternative sein. Interessanter wäre m.E. gewesen, die Vor- und Nachteile der Feathers gegenüber anderen Binärformaten aufzuzeigen.
Die Tatsache, dass man in uncodierte CSV jederzeit reinschauen und herum editieren kann, sollte man nicht unterschätzen.
Kannst du mit einem Hexeditor auch :P
Editierbarkeit ist bei einem unterspezifierten Format wie CSV eher Fluch als Segen. Da ist nix festgelegt, kein Trennzeichen, keine Quotierung von Steuerzeichen etc. Ergo kann man eine CSV Datei schnell kaputt machen wenn man sie in einem Tabellenkalkulation lädt und dann wieder falsch rausspeichert. Von der Datenstruktur ganz zu schweigen - ob ein Zahlenfeld int sein muss oder auch Floats enthalten kann, lässt sich in CSV nicht definieren. Streng genommen könnte das Format Zeile für Zeile wechseln.
Ich nutze für große Datenmengen auch gerne das Parquet-Format. Das hat auch eine eingebaute Komprimierung.
Ich hätte in der Schleife die Reihenfolge von Feather und CSV nach jeder Iteration getauscht bzw. in allen Kombinationen gleichverteilt ausgeführt, da durch Caches womöglich ein Bias entsteht.
Der Knackpunkt bei .feather ist, welche Programmiersprachen/Tools dieses Dateiformat überhaupt übersetzen können. einen .csv - parser kann ich mir theoretisch in jeder Programmiersprache mit verhältnismäßig geringem Aufwand selbst schreiben und auch die meisten Tabellenprogramme, wie excel oder libre calc, können damit etwas anfangen. Vor allem dann, wenn auch Naturwissenschaftler mit den Daten etwas anfangen wollen und dann mit Excel ankommen, stelle ich mir das schwierig vor. Bei Wissenschaft geht es auch darum, Daten einer möglichst breiten Masse zur Verfügung zu stellen.
Hier geht es aber nicht unbedingt um Datensätze, die von Menschen wieder gelesen werden sollen. Z.B. hat eine CSV Datei eines IOT-Netzwerks mit 1 Millionen Geräten, dass 4 verschiedene uint8 Parameter für jede Sekunde eines tages abspeichert eine Größe von 350 MB. Wenn ich das für ein ganzes Jahr speichern möchte, um danach CNNs zu trainieren muss ich 130 GB speichern, die mir das ganze Jahr über den Speicher belegen, bis ich sie dann mal 2 Wochen lang nutze. Den Datensatz händisch auszulesen ist bei solchen Datenmengen eh zwecklos und eine csv Datei lässt sich in dieser Größe auch nicht mehr mit Excel öffnen. Aber eine Millionen Geräte ist ja nicht das Limit. Wenn ich in 20 verschiedenen Ländern je 5 Millionen Geräte habe sind das bereits 13 Terabyte, die auf einen herkömmlichen Arbeitsrechner gar nicht gespeichert werden können und dann verdoppeln wir das ganze noch einmal wegen der Back Ups. Und das ganze nur um ein paar 8-bit Integer als Rohdaten zu sammeln.
Naja, intern kann man das nutzen. Aber wen die Dateien noch irgendwo anders verwendet werden dann ist csv immer noch ein gute Wahl. Fraglich wieviel Programme feather als Datenformat unterstützen.
Super Video und gut erklärt, ich hätte nur die letzten beiden print statements in print(f"{duration_feather / runs = }") und print(f"{duration_csv / runs = }") geändert. Dadurch wird die Ausgabe meiner Meinung nach deutlich übersichtlicher, weil man auch gleich sieht, auf welche Variablen sich das Ergebnis bezieht :)
Ich verwende feather immer um große Datenmengen zu speichern wenn das Programm läuft. Während der Entwicklung nutze ich jedoch manchmal csv files damit ich mir die Prozedur erst mit kleineren Datensets in Tabellenkalulaltionsprogrammen überlegen kann. Einige davon unterstützen den Import von feather leider nicht.
Naja Textformat vs Binary war jetzt nicht so sonderlich überraschend
Generell wäre ein Vergleich der Datenformate eventuell interessant und wann und warum man welches davon Verwenden sollte / könnte.
Also Feather / Parquet / HDF5 / usw.
Ehrenmorpheus
Unabhängige Zufallsgrößen sind vielleicht nicht das Beste, um ein komprimierendes Datenformat wie Feathers zu testen. Echte Daten haben für gewöhnlich weniger Entropie, da spielt Kompression seine Stärke besser aus.
Ich habe das Video nach ein paar Minuten nicht weiter anschauen wollen. Es hat einfach gefehlt, um was es eigentlich geht - was Feather überhaupt ist. Stattdessen wilde Tests und wenig Theorie. Da habe ich lieber selber nachgelesen.
Ein Wort zur Dateigröße wäre auch angebracht gewesen.
Ist Feathers auch für andere Programmiersprachen verfügbar ?
Ja ;)
In fast allen Anwendungsfällen müssen Daten human readable sein. Damit sind Formate wie feather, ONNX usw. keine Lösung.
Warum sollten sie human readable gespeichert werden, wenn man sie auch einfach wieder einlesen kann?
Welche Vorteile bietet Feather gegenüber Parquet?
Feather ist ein bissl schneller beim schreiben, langsamer beim lesen. Bei parquet ist es genau umgekehrt. Schreibst du genau so oft wie du liest, nimm feather. Wenn du einmal schreibst und 5 mal liest, nimm Parquet.
Interessant wäre auch der Vergleich mit Datenbankenlösungen wie MySQL und derm Schreiben und Lesen mittels Cursor zum Beispiel.
Hi Morpheus, es wäre sehr interessant wie ich eine bestehende csv Datei in feather konvertieren kann. Ich habe das Problem , dass ich alle App Store Apps gescrapt habe und die jetzt gerne analysieren würde in Notebook, aber die csv Datei ist zu groß und wenn ich das in Chunks verwandle kann ich die Daten nicht mehr analysieren. Gibt es dazu eine Lösung? Würde mich über eine schnelle antwort sehr freuen
Irgendeinen Tod muss man bekanntlich sterben und je nach Szenario kann das eine oder andere eben besser sein. Außerdem: Dario Radecic hätte sich bestimmt gefreut, mit seinem Artikel v. Sep. 2021 (auf towardsdatascience) verlinkt zu werden, wenn der Source schon "adaptiert" wird.
Gibt es Feather eigl auch für nodeJS? Alle npms, die ich dazu gefunden habe, sind was anderes.
Ich empfehle immer hdf5, damit lassen grosse Datenmengen effizient speichern und laden.
Werde mir das aber gleich mal anschauen, rufe gerade Daten aus verschiedene Quellen ab und führe diese zusammen.
Klingt nach einer guten Möglichkeit, die Daten aus der vorverarbeitung zu speichern 🤔
was mich noch interessieren würde: ein Vergleich mit sqlite
Die Frage ist immer, was man hinterher mit den Daten machen will. Will man im eigenen Programm im Speicher Berechnungen anstellen, kann feather Vorteile bringen, weil man weniger Platz auf dem Datenspeicher braucht und Zugriffe auf diesen in der Regel hohe Zeitkosten haben. Will man hingegen Sachen machen, die eine SQL-Datenbank leisten kann, ist diese in der Regel viel schneller, weil in den üblichen SQL-Datenbanksystemen viele Mann-Jahrtausende an Optimierungsarbeit drinstecken.
Wie ist der Vergleich zu PyArrow?
Wie ist's im Vergleich mit pickle?
Warum ist Feather so viel schneller? Kann es nicht sein, dass die Implementation von CSV write und read einfach extrem ineffizient ist?
Feather als Binärformat dürfte viel von den Daten einfach kopieren, während CSV in eine Textdarstellung konvertieren muss und die beim Lesen dann wieder parst. Ich gehe davon aus, dass die beiden die meiste Zeit fressen.
Nebenbei sind Feather-Dateien dadurch (und durch zusätzliche Kompression) kleiner, was auf modernen SSD vielleicht nicht mehr so viel ausmacht.
Parquet anstatt von CSQ war zu verwenden war auch sein Segen … so viel schneller so viel weniger benötigter Speicher
Wie groß ist denn der Grössenunterschied der Dateien??
Da feather in der Regel LZ4-komprimierte (alternativ auch Zstandard) Binärdaten sind, dürften der Plattenplatzbedarf in der Regel bei unter 25% der Menge liegen, die eine CSV-Datei braucht, sofern man es mit Zahlen zu tun hat.
Mit der Schütze erstmal lecker Zucchini Grillen 👍
Python kommt von Monty Python, also wird es genauso ausgesprochen.
Eigentlich zeigt das Ganze doch nur das Python einfach ne miese Programmiersprache (in punkto performance) ist....
Das ist ja federleicht 😂
csv verwendet man eh nur wenn es per Texteditor bearbeitbar sein soll....
Das ist nicht genormt, sondern gemittelt.
Ganz wichtigrr grund pro csv... import in excel
Wenn du wirklich große Daten mit Millionen Spalten hast, kannst du Excel vergessen. Und genau das ist ja der Use Case in diesem Fall.
@@mafa5534 natürlich sind extreme Datenmengen der Grenzfall. Wenn du jetzt zum Beispiel mit bestimmten Wissenschaftlern redest, finden die etliche GB von Excel Tabellen noch handlich.
Ich musste selbst schon mal einen exporter für messreihen in Excel bauen und da war meine einzige, sinnvolle Lösung der zwischenstopp via CSV und der automatische Import in ein Excel Dokument.
Ich nutze meist hdf5 oder pickle.
Vergleich beider Dateigrößen.
Erster