Mastering Modern Pandas

Hallo, hier ist Alex von DEV STORIES DOT EU. Mastering Modern Pandas, Folge 1 von 8. Du ziehst zwei Spalten mit Finanzdaten, addierst sie, und die finale Summe ergibt keinen Sinn. Die Zeilen haben sich verschoben, und du hast einfach den gestrigen Schlusskurs zum heutigen Volumen addiert. Das passiert, wenn du Daten wie ein dummes Raster behandelst, anstatt auf die Core Abstraction zu setzen: DataFrames und Label Alignment. Viele schauen sich pandas an und denken, es ist nur ein programmierbares Spreadsheet oder ein standardmäßiges zweidimensionales NumPy-Array. Ist es aber nicht. Ein einfaches NumPy-Array basiert auf striktem Positional Indexing. Wenn du zwei Arrays addierst, wird das Item an Position null zum Item an Position null addiert. Wenn in deinen Daten eine Zeile fehlt, verschiebt sich alles, und deine Berechnungen werden unbemerkt verfälscht. pandas löst genau dieses Problem, indem es die Daten von ihrer physischen Position im Memory entkoppelt. Es nutzt Intrinsic Data Alignment, das heißt, es richtet Daten nach Labels aus, niemals nach Position. Um das zu verstehen, schau dir die Basis der Library an: die Series. Eine Series ist ein eindimensionales Array, das jeden Data Type aufnehmen kann. Im Gegensatz zu einer Standard-List ist jedes Item in einer Series fest mit einem Label verknüpft. Diese Labels bilden zusammen das, was pandas den Index nennt. Du kannst Integers als Labels verwenden, aber meistens nutzt du Strings oder Timestamps. Ein DataFrame ist einfach eine Collection dieser Series-Objekte, die als Spalten fungieren, die alle denselben Index teilen und nebeneinanderliegen. Hier ist die wichtigste Erkenntnis: Wenn du eine Operation in pandas ausführst, diktiert der Index das Verhalten. Angenommen, du hast zwei Series mit täglichen Aktienrenditen. Series A hat Daten für Montag, Dienstag, Mittwoch und Donnerstag. Series B hat Daten für Mittwoch, Donnerstag und Freitag. Wenn du pandas anweist, diese beiden Series zu addieren, ignoriert es ihre physische Reihenfolge. Es schaut sich die Date-Labels an. Es findet den Mittwoch in Series A und addiert ihn zum Mittwoch in Series B, obwohl Mittwoch das dritte Item im ersten Dataset und das allererste Item im zweiten Dataset ist. Das bringt uns zum Problem der nicht überlappenden Tage. Montag existiert in der ersten Series, aber nicht in der zweiten. Freitag existiert in der zweiten, aber nicht in der ersten. pandas crasht nicht, und es rät ganz sicher auch keinen Wert. Stattdessen erstellt es einen neuen Index, der die Union aller Labels aus beiden Inputs ist. Für jedes Label, das nicht an beiden Stellen existiert, fügt pandas ein NaN ein, was Not a Number bedeutet. Die Operation wird erfolgreich abgeschlossen, und du siehst sofort, wo deine Daten unvollständig sind. Du musst nie einen Loop schreiben, um zu checken, ob die Dates matchen. Das Alignment ist automatisch und direkt in die Datenstruktur selbst eingebaut. Genau diese Logik skaliert direkt auf DataFrames. Ein DataFrame richtet sich auf beiden Dimensionen gleichzeitig aus. Wenn du Operationen auf zwei DataFrames ausführst, matcht pandas Row-Label mit Row-Label und Column-Name mit Column-Name. Es richtet die gesamte Struktur perfekt aus, bevor auch nur eine einzige mathematische Operation ausgeführt wird. Alles, was sich nicht über die Zeilen und Spalten hinweg überschneidet, wird als Missing Data markiert. Die wahre Power von pandas ist nicht die Mathematik, die es ausführt, sondern die Tatsache, dass das Label immer mit den Daten mitreist, was Positional Mismatches strukturell unmöglich macht. Wenn du die Show unterstützen möchtest, findest du uns, indem du auf Patreon nach DevStoriesEU suchst. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. Mastering Modern Pandas, Episode 2 von 8. Du extrahierst einen Slice deiner Daten, updatest einen einzelnen Wert, und plötzlich ist dein Original-Dataset corrupted. Oder noch schlimmer: Du bekommst eine unvorhersehbare Warnung und hast keine Ahnung, ob dein Update eigentlich auf den Slice oder die Source angewendet wurde. Version 3.0 löst dieses Chaos endlich, indem Copy-on-Write zum Default-Verhalten wird. Copy-on-Write schreibt grundlegend neu, wie pandas Memory managt. In früheren Versionen erstellte pandas häufig Defensive Copies, um zu verhindern, dass du aus Versehen das Original-Dataset modifizierst. Wenn du ein Dataset gefiltert hast, hat pandas es kopiert. Wenn du eine Column gedroppt hast, hat pandas den Rest kopiert. Das verschwendete massive Mengen an Memory und CPU-Cycles. Wenn es nicht kopiert hat, hat es eine View zurückgegeben, was bedeutete, dass das Modifizieren des neuen Objekts stillschweigend den Parent verändert hat. Unter Copy-on-Write teilen sich alle DataFrames oder Series, die von einem anderen abgeleitet wurden, exakt denselben zugrunde liegenden Memory. Das bedeutet, dass das Erstellen eines Subsets, das Droppen einer Column oder das Resetten eines Index nahezu sofort passiert. Es werden keine Daten upfront dupliziert. Hier ist die wichtigste Erkenntnis: Verwechsle eine Legacy-View nicht mit einer Copy-on-Write Lazy Copy. Bei einer traditionellen View zeigen sowohl der Parent als auch das Child auf denselben Memory, und eine Änderung an einem ändert auch das andere. Copy-on-Write ist anders. Der Shared Memory ist temporär und streng geschützt. Das Sharing hält nur so lange an, bis du versuchst, etwas zu ändern. Stell dir ein konkretes Szenario vor. Du hast einen DataFrame, der User-Profile enthält. Du wählst die Age-Column aus und weist sie einer neuen Variable namens age subset zu. In genau diesem Moment verbraucht age subset null zusätzlichen Memory. Es zeigt direkt auf den originalen User-Profiles-DataFrame. Als Nächstes updatest du den ersten Wert in deinem age subset auf neunundneunzig. Hier passiert der Write-Part von Copy-on-Write. Pandas erkennt die Modification. Bevor dein Update ausgeführt wird, checkt es, ob irgendein anderes Objekt diesen spezifischen Datenblock teilt. Weil der Parent-DataFrame ihn noch verwendet, allokiert pandas sofort neuen Memory, kopiert die Daten rüber und schreibt dann den Wert neunundneunzig an die neue Location. Dein Parent-DataFrame bleibt sicher unverändert. Das Mutieren eines Subsets mutiert niemals den Parent. Dieser Mechanismus kaskadiert perfekt über Chained Operations hinweg. Wenn du Operationen wie das Droppen leerer Rows, das Replacen von Values und das Renamen von Columns aneinanderreihst, haben ältere pandas-Versionen bei jedem einzelnen Schritt eine physische Copy erstellt. Unter Copy-on-Write teilen sich diese Zwischenschritte einfach den Memory. Eine physische Copy wird nur getriggert, wenn ein Schritt die zugrunde liegenden Data Arrays tatsächlich mutiert. Wenn eine Operation nur Referenzen neu anordnet, passiert keine Copy. Das eliminiert versehentliche Data Corruption komplett. Du musst nicht mehr raten, ob eine Operation eine View oder eine Copy zurückgegeben hat, und du wirst die Setting With Copy Warnung nie wieder sehen. Die Regel ist absolut: Ein Parent- und ein Child-Objekt werden sich niemals gegenseitig modifizieren. Indem Copies bis auf die exakte Millisekunde verzögert werden, in der eine Modification passiert, gibt pandas dir die schnelle Performance und den geringen Memory Footprint von Views, gepaart mit der strikten Sicherheit von Deep Copies. Das war’s für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Mastering Modern Pandas, Folge 3 von 8. Du lädst ein Dataset mit ein paar Millionen Rows, und plötzlich schnellt deine Memory Usage durch die Decke. Die Zahlen sind völlig in Ordnung, aber die Text-Columns und die Missing Values zerstören klammheimlich deinen RAM. Der Fix ist ein fundamentaler Wechsel darin, wie pandas Daten speichert, und genau darum geht es in dieser Episode: Der PyArrow Engine Room. Wenn du schon mal von Apache Arrow gehört hast, denkst du vielleicht, es ist strikt für große verteilte Systeme wie Spark oder Hadoop gedacht. Ist es aber nicht. Arrow ist jetzt ein First-Class, natives Memory-Format und eine Execution Engine direkt in pandas. Jahrelang hat sich pandas komplett auf NumPy verlassen. NumPy ist unglaublich schnell für dense numerische Berechnungen, hat aber einen massiven blinden Fleck, was Missing Data angeht. NumPy hat kein natives Konzept für einen Missing Integer oder einen Missing Boolean. Wenn du eine Integer-Column hast und ein einziger Wert fehlt, war pandas historisch dazu gezwungen, die gesamte Column in Floating-Point Numbers umzuwandeln, nur damit es den Not-a-Number-Marker verwenden kann. Das ändert deine Datentypen, ruiniert Exact Matches und verbraucht mehr Memory. PyArrow löst das mit einer Validity Bitmap. Anstatt den Datentyp zu ändern, um einen Missing Value unterzubringen, behält Arrow deine Integers als Integers. Es fügt ein verstecktes, hochkomprimiertes Array aus Einsen und Nullen neben deinen Daten hinzu. Eine Eins bedeutet, der Wert ist valid. Eine Null bedeutet, er ist missing. Dein Datentyp bleibt intakt, und das Tracking der Missing Values kostet fast null Memory. Hier ist der Key Insight: Die Memory-Ersparnisse sind noch extremer, wenn man mit Text arbeitet. Traditionell speichert pandas Strings mit dem NumPy Object Datentyp. Das bedeutet, die Column hält eigentlich gar nicht deinen Text. Sie hält Memory Pointers. Jede Row zeigt auf ein Standard-Python-String-Objekt, das irgendwo anders in deinem Computer-Memory verstreut ist. Wenn du zehn Millionen Rows an Text hast, hast du zehn Millionen Pointers und zehn Millionen separate String-Objekte. Der Memory-Overhead ist enorm, und darüber zu iterieren ist furchtbar langsam. PyArrow ändert die Architektur komplett. Wenn du deine pandas-Columns so einstellst, dass sie einen PyArrow-String-Datentyp nutzen, wird der Text in einem einzigen, zusammenhängenden Memory-Block gespeichert. Die Column trackt einfach nur die Byte-Offsets. Sie speichert exakt, wo jedes Wort in diesem großen, durchgehenden Block startet und stoppt. Stell dir ein High-Cardinality Dataset vor. Du hast eine Column mit User-Agent-Strings oder Unique Transaction IDs. Viele der Rows sind leer. Wenn du das auf die traditionelle Art in pandas einliest, ist der Default ein NumPy Object Array. Sag pandas nun, stattdessen die PyArrow-Engine zu nutzen, indem du während deines Read-Steps explizit einen PyArrow-backed String-Datentyp zuweist. Sofort sinkt der Memory Footprint, oft um fünfzig Prozent oder mehr. Die Verbesserung geht über RAM-Limits hinaus. Weil die Daten jetzt dicht zusammengepackt in einer Struktur liegen, die für Analytics gebaut wurde, beschleunigen sich String-Matching-Operations. Wenn du eine Regular Expression Search über diese Column laufen lässt, verarbeitet die Arrow-Engine die Raw Bytes direkt auf Systemebene. Sie umgeht den langsamen Python Object Overhead komplett. Du bekommst Integer-Columns, die tatsächlich Integers bleiben, wenn Daten missing sind, und String-Operations, die deine Hardware nicht in die Knie zwingen. Wenn du Text oder Messy Data verarbeitest, ist es obsolet, sich auf das NumPy Object Array zu verlassen. PyArrow-backed Datentypen zu nutzen, ist der absolut schnellste Weg, eine schwere pandas-Pipeline sofort leichter zu machen. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. Mastering Modern Pandas, Folge 4 von 8. Du hast eine mehrere Gigabyte große Parquet-Datei mit hundert Spalten. Für deine Metriken benötigst du nur vier davon. Wenn du als Erstes die gesamte Datei in einen Dataframe lädst und dann die Spalten filterst, verschwendest du Unmengen an RAM und CPU-Zyklen, noch bevor deine Analyse überhaupt beginnt. Die Lösung liegt darin, moderne Data Ingestion zu meistern. Der Hauptengpass bei der Data Ingestion ist Disk Input und Output. Pandas Read-Funktionen, wie read underscore csv und read underscore parquet, scannen Daten von der Disk in den Memory. Um diesen Transfer zu minimieren, verwendest du ein Argument namens usecols. Du übergibst eine Liste mit den exakten Spaltennamen, die du benötigst. Der Parser liest nur diese spezifischen Spalten aus der Datei. Der Performance-Gewinn, den du siehst, hängt stark von deinem Dateiformat ab. CSV-Dateien speichern Daten zeilenweise. Wenn du usecols mit einer CSV verwendest, muss der Parser zwar immer noch die gesamte Textdatei Zeile für Zeile scannen, aber er verwirft die nicht benötigten Spalten sofort, bevor er Memory für den Dataframe allokiert. Parquet-Dateien hingegen speichern Daten spaltenweise. Bei einer Parquet-Datei mit hundert Spalten, bei der du nur vier Metrik-Spalten brauchst, bedeutet das Übergeben von usecols, dass der Parser die Dateiblöcke mit den anderen sechsundneunzig Spalten komplett ignoriert. Er liest nur die Bytes von der Disk, die er absolut braucht. Das reduziert sowohl deine Lesezeit als auch deinen Memory Footprint drastisch. Das Einschränken der Spalten ist nur der erste Schritt. Die nächste Optimierung passiert dabei, wie Pandas diese Spalten im Memory ablegt. Historisch gesehen verließ sich Pandas komplett auf NumPy Arrays. NumPy ist exzellent für dichte numerische Berechnungen, hat aber Probleme mit Textdaten und fehlenden Werten. Es speichert Strings als verstreute Python-Objekte im Memory und zwingt Integer-Spalten dazu, Floats zu werden, nur um fehlende Daten darzustellen. Um das zu lösen, hat Pandas das dtype backend Argument eingeführt. Wenn du dieses Argument auf den String pyarrow setzt, nutzt Pandas stattdessen Apache Arrow als Backend für deine Daten. Arrow speichert Strings in hocheffizienten, zusammenhängenden Memory-Blöcken und nutzt eine separate Bitmaske, um fehlende Werte zu tracken, wodurch deine Integers intakt bleiben. Hier ist die wichtigste Erkenntnis. Du denkst vielleicht, Pandas liest die Daten zuerst in NumPy Arrays und konvertiert sie dann zu Arrow. Das ist nicht der Fall. Wenn du das PyArrow-Backend in der Read-Funktion angibst, umgeht Pandas NumPy während der Parse-Phase komplett. Die Daten fließen direkt von der Datei auf der Disk in PyArrow Arrays im Memory. Das vermeidet die massiven Performance-Einbußen durch intermediäre Memory Allocations. Lass uns die komplette Pipeline anschauen. Du rufst read underscore parquet auf. Erstens übergibst du deinen Dateipfad. Zweitens übergibst du usecols mit einer Liste deiner vier Metrik-Spalten. Drittens setzt du das dtype backend Argument auf pyarrow. Der Parser springt direkt zu den vier Spalten auf der Disk, extrahiert sie und streamt sie direkt in den Arrow-backed Memory. Du erhältst am Ende einen schlanken, blitzschnellen Dataframe, der genau das enthält, was du brauchst, basierend auf modernen Datentypen. Das Filtern von Spalten auf dem IO Layer anstatt auf dem Application Layer ist der effektivste Weg, um Out-of-Memory Crashes in Pandas zu verhindern. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Mastering Modern Pandas, Folge 5 von 8. Du hast eine Liste mit zehn Millionen Transaktionen, und jede davon hat nur eine Customer ID. Du brauchst aber die tatsächlichen Kundennamen zu diesen Transaktionen. Wenn du eine Python-Schleife schreibst oder ein Dictionary Mapping verwendest, um diese IDs den Namen zuzuordnen, verschwendest du CPU-Zyklen und Memory. Pandas hat eine optimierte Engine, die speziell für SQL-Style-Operationen in einer einzigen Zeile gebaut wurde. Heute sprechen wir über relationale Algebra: Merge und Join. Bevor wir weitermachen, lass uns ein häufiges Missverständnis klären. Leute verwechseln Merging oft mit Concatenating. Concatenation ist einfach nur das physische Stapeln von Arrays übereinander oder nebeneinander. Merge ist etwas völlig anderes. Merge ist für relationale Database Joins. Es richtet Rows aus zwei verschiedenen Tabellen basierend auf den Werten gemeinsamer Keys aus. Die Kernfunktion dafür ist pandas dot merge. Sie nimmt zwei DataFrames, die wir die linke Tabelle und die rechte Tabelle nennen. Denk zurück an unser Transaktionsszenario. Dein linker DataFrame ist eine riesige Fact Table mit Millionen von Käufen. Dein rechter DataFrame ist eine kleinere Dimension Table mit Kundendetails wie Namen und E-Mail-Adressen. Beide Tabellen teilen sich eine Column namens Customer ID. Dieses spezifische Setup wird als Many-to-One Join bezeichnet. Du hast viele Transaktionen, die zu einem einzigen Kunden gehören. Wenn du sie über den Customer ID Key mergest, nimmt pandas den einzelnen Customer Record aus der rechten Tabelle und broadcastet ihn über alle passenden Transaktionen in der linken Tabelle. Hier ist die wichtigste Erkenntnis. Der wichtigste Parameter, den du kontrollierst, ist das how Argument. Das diktiert, welche Keys den Merge überleben und es ins finale Ergebnis schaffen. Standardmäßig verwendet pandas einen Inner Join. Wenn du das how Argument nicht angibst, behält das Ergebnis nur Rows, bei denen die Customer ID in beiden Tabellen existiert. Wenn ein Kunde eine Transaktion gemacht hat, sein Record aber aus der Kundendatenbank gelöscht wurde, verschwindet diese Transaktion komplett aus deinem gemergten Ergebnis. Um zu verhindern, dass du Daten aus deiner primären Tabelle verlierst, verwendest du einen Left Join. Indem du left an das how Argument übergibst, behält pandas jede einzelne Row aus deiner linken Tabelle, also deiner riesigen Transaktionsliste. Wenn eine Transaktion eine Customer ID hat, die in der rechten Tabelle nicht existiert, behält pandas die Transaktions-Row trotzdem, füllt aber die fehlenden Kundendetails mit Not a Number Werten auf. Das ist genau die Logik, die du willst, wenn du Dimension Details an eine primäre Fact Table anhängst. Das genaue Gegenteil ist ein Right Join. Wenn du right übergibst, bleiben alle Rows aus der Customer Dimension Table erhalten, unabhängig davon, ob sie passende Transaktionen in der linken Tabelle haben. Du landest bei einer Liste aller Kunden, und diejenigen, die nichts gekauft haben, zeigen einfach Missing Values für die Transaktionsdaten. Schließlich gibt es noch den Outer Join. Übergib outer an das how Argument, und pandas behält alles. Es nimmt die Union der Keys aus beiden Frames. Jede Transaktion und jeder Kunde schafft es in das finale Dataset, wobei Missing Values die Lücken füllen, wo kein perfekter Match gefunden wird. Der standardmäßige Inner Join droppt nicht gematchte Daten stillschweigend. Wenn du also nicht explizit Rows herausfiltern willst, solltest du immer einen Left Join angeben, wenn du Lookup Tables an dein primäres Dataset anhängst. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Mastering Modern Pandas, Folge 6 von 8. Du denkst wahrscheinlich, dass es beim Gruppieren von Daten nur darum geht, Zahlen zusammenzufassen, um eine Summe oder einen Durchschnitt zu berechnen. Was aber, wenn du eine einzelne Zeile anhand des Verhaltens der Gruppe, zu der sie gehört, auswerten musst, ohne die ursprüngliche Form deines Datasets zu verlieren? Dafür musst du über einfache Zusammenfassungen hinausgehen und das Split-Apply-Combine-Pattern verwenden. Wenn du in pandas eine groupby-Methode aufrufst, löst du einen sequenziellen dreistufigen Prozess aus. Zuerst kommt der Split. pandas nimmt dein gesamtes Dataset und teilt es anhand eines Keys, den du übergibst, in unabhängige Gruppen auf. Als Nächstes kommt der Apply-Schritt, bei dem eine Funktion auf jede Gruppe völlig unabhängig von den anderen ausgeführt wird. Zum Schluss nimmt der Combine-Schritt die Ergebnisse aller Gruppen und fügt sie wieder zu einer einzigen Datenstruktur zusammen. Viele Entwickler denken, der Apply-Schritt ist nur für Aggregation da. Aggregation nimmt eine Gruppe von Werten und gibt eine einzelne Zahl zurück, wie die Summe oder den Mittelwert. Wenn du ein Kundensupport-Dataset nach Agent gruppierst und die durchschnittliche Bearbeitungszeit abfragst, bekommst du ein neues Dataset mit einer Zeile pro Agent. Das ist nützlich, aber es ist nur ein Drittel der Geschichte. Hier ist die wichtigste Erkenntnis: Der Apply-Schritt wird genauso oft für Transformation und Filterung verwendet. Eine Transformation führt eine Berechnung auf der Gruppe aus, gibt aber ein Objekt zurück, das exakt so indiziert ist wie die Originaldaten. Sie reduziert die Zeilenanzahl nicht. Gehen wir zurück zu unserem Kundensupport-Dataset. Du willst wissen, ob die Bearbeitung eines bestimmten Tickets ungewöhnlich lange gedauert hat. Aber eine ungewöhnliche Zeit für einen Junior-Agenten könnte eine ganz normale Zeit für einen Senior-Agenten sein, der hochkomplexe Probleme bearbeitet. Du brauchst den Z-Score der Bearbeitungszeit, und zwar nur relativ zum historischen Durchschnitt dieses spezifischen Agenten. Du splittest die Daten nach Agent und wendest eine Transformationsfunktion an, die den Z-Score berechnet. pandas berechnet den Mittelwert und die Standardabweichung für Agent A, standardisiert die Tickets von Agent A, macht genau das Gleiche für Agent B und kombiniert sie dann. Du bekommst dein ursprüngliches Dataset Zeile für Zeile zurück, aber jetzt hat jedes Ticket einen standardisierten Score, der streng auf seinem spezifischen Gruppenkontext basiert. Die dritte Kernanwendung ist Filterung. Damit kannst du ganze Gruppen basierend auf einer kollektiven Eigenschaft verwerfen, anstatt einzelne Zeilen auszuwerten. Angenommen, du möchtest diese Ticket-Z-Scores analysieren, aber einige Agenten in deinem Dataset haben nur zwei oder drei Tickets bearbeitet. Ihre Durchschnittswerte sind statistisch bedeutungslos. Du kannst eine Filterfunktion auf dein gruppiertes Objekt anwenden, um die Größe jeder Gruppe zu überprüfen. Wenn eine Gruppe weniger als zehn Tickets hat, gibt die Filterlogik False zurück, und pandas droppt jede einzelne Zeile, die zu diesem Agenten gehört. Der Combine-Schritt gibt dann ein Dataset zurück, das nur die Tickets von Agenten mit einer validen Stichprobengröße enthält. Du splittest die Daten anhand eines Keys, wendest eine Logikregel an, die die Gruppe auswertet, und kombinierst die übrig gebliebenen Daten. Aggregation reduziert Daten. Transformation standardisiert Daten innerhalb ihres lokalen Kontexts. Filterung verwirft Daten basierend auf Gruppenregeln. Die wahre Stärke des Split-Apply-Combine-Patterns ist, dass es dir erlaubt, einzelne Zeilen mit Hilfe des Group-Level-Kontexts zu manipulieren, ohne jemals einen manuellen Loop schreiben zu müssen. Wenn du diese Deep Dives hilfreich findest und die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Ich möchte mir einen Moment Zeit nehmen, um dir fürs Zuhören zu danken – das hilft uns sehr. Mach's gut!

Hallo, hier ist Alex von DEV STORIES DOT EU. Mastering Modern Pandas, Folge 7 von 8. Deine eigenen Time Aggregations von Hand zu bauen, ist ein Albtraum aus fehlenden Intervallen, Schaltjahren und Business Day Logik. Wenn du Custom Code schreibst, um rohe Timestamps in reguläre Buckets zu runden, machst du dir das Leben viel zu schwer. Die Lösung ist Time Series Mastery mit den nativen temporalen Strukturen von pandas. Das Rückgrat der Time Series Funktionalität in pandas ist der DatetimeIndex. Statt standardmäßiger Integer-Zeilennummern wird dein Dataframe Index zu einer strikten Sequenz präziser Timestamps. Wenn du deinen Index auf einen DatetimeIndex upgradest, ändert das grundlegend das Verhalten des Dataframes und macht die gesamte Struktur zeitbasiert. Das ermöglicht natives, zeitbasiertes Slicing. Wenn du nur Daten aus dem Oktober 2023 brauchst, übergibst du einfach den String "2023-10" an den Row Locator. Pandas berechnet automatisch die exakten Mikrosekunden-Grenzen für diesen Monat und gibt das korrekte Subset zurück. Du kannst partielle Date Strings bis auf die Stunde oder Minute genau übergeben, und der Index übernimmt die zugrundeliegende Timestamp-Mathematik. Sobald deine Daten zeitbasiert sind, musst du sie in der Regel aggregieren. Viele Entwickler verwechseln zeitbasiertes Resampling mit einfachem Grouping. Sie versuchen, Standard Group-by Operations auf eine Datumsspalte anzuwenden. Dieser Ansatz scheitert, wenn man es mit echten, unsauberen Time Series zu tun hat. Standard Grouping berücksichtigt nur die expliziten Rows, die aktuell in deinem Dataframe vorhanden sind. Wenn ein Server für eine Stunde offline geht, überspringt eine Standard Group-by Operation diese Stunde einfach komplett. Deine Output Timeline hat dann eine versteckte Lücke, die alle nachfolgenden zeitbasierten Berechnungen verfälscht. Hier ist die entscheidende Erkenntnis: Die dot resample Methode ist grundlegend anders, weil sie Kalenderlogik nativ versteht. Sie projiziert ein starres, kontinuierliches Zeitraster über deine Daten. Wenn du in Zehn-Minuten-Intervallen resampelst und in einem bestimmten Zehn-Minuten-Fenster keine Daten ankommen, generiert pandas diesen Bucket trotzdem. Es lässt die Values leer und bewahrt so die strikte mathematische Integrität deiner Timeline. Resampling versteht von Natur aus leere Intervalle, unregelmäßige Monatslängen und Business Day Kalender, die Wochenenden und Feiertage herausfiltern. Stell dir das Szenario eines quantitativen Analysten vor, der Trading Daten verarbeitet. Du erhältst hochfrequente Tick Daten von einer Exchange. Die einzelnen Trades kommen in völlig unregelmäßigen Intervallen an, manchmal drei pro Mikrosekunde, manchmal zwanzig Sekunden lang gar keiner. Dein Pricing Model kann dieses Chaos nicht verarbeiten. Es erfordert perfekt ausgerichtete Fünf-Minuten-Bars. Weil deine Trade-Preise auf einen DatetimeIndex gemappt sind, rufst du die dot resample Methode auf deinem Dataframe auf und übergibst den Frequency String "5min". Das mappt jeden unregelmäßigen Tick auf ein striktes Fünf-Minuten-Raster. Um ein Finanzmodell zu füttern, brauchst du speziell die Open, High, Low und Close Preise für jeden Bucket. Statt Custom Functions zu schreiben, um den ersten, maximalen, minimalen und letzten Trade jedes Windows zu extrahieren, chainst du die dot ohlc Methode direkt an deinen resample Call. Pandas berechnet alle vier Metriken auf einmal und gibt ein sauber strukturiertes Dataset aus Fünf-Minuten-Bars aus. Diese leeren Intervalle, die wir vorhin erwähnt haben, bleiben in diesem Output intakt. Du kannst dann eine weitere Methode chainen, um die vorherigen Close Preise per Forward-Fill in die leeren Lücken zu füllen, damit dein Model immer gültige Daten hat. Resampling verwandelt unregelmäßige, event-driven Records in eine vorhersagbare, mathematisch fundierte Timeline, ohne dass du eine einzige Zeile Kalenderlogik schreiben musst. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Mastering Modern Pandas, Folge 8 von 8. Bevor du eine riesige Cloud-Instanz anforderst oder auf einen Distributed Computing Cluster zurückgreifst, bist du vielleicht überrascht zu erfahren, dass du Terabytes an Daten direkt auf deinem Laptop verarbeiten kannst. Die meisten Out-of-Memory-Errors erfordern kein neues Framework, sondern lediglich eine Änderung der Art und Weise, wie du Dateien liest. Heute geht es um das Scaling auf Out-of-Core Datasets. Out-of-Core Processing bedeutet einfach, dass du mit Datensätzen arbeitest, die größer sind als dein verfügbarer System Memory. Eine häufige Reaktion auf einen Out-of-Memory-Crash ist die Annahme, dass pandas sein Hard Limit erreicht hat. Oft fangen die Leute dann sofort an, ihre Pipelines in PySpark oder Dask neu zu schreiben. Aber pandas kann riesige Datenmengen nativ verarbeiten, wenn du aufhörst zu versuchen, den gesamten Datensatz auf einmal in den RAM zu laden. Einfache Generator Patterns lösen die große Mehrheit dieser Scaling-Probleme. Der primäre Mechanismus für Out-of-Core Processing ist Chunking. Wenn du mit einer einzelnen, riesigen Textdatei arbeitest, akzeptiert die Standard-Read-Funktion ein Chunk-Size-Argument. Wenn du dieses Argument übergibst, gibt pandas keinen DataFrame mehr zurück. Stattdessen gibt es einen Iterator zurück. Jedes Mal, wenn dein Code den Iterator weiterbewegt, liest pandas nur die angegebene Anzahl von Rows von der Disk und liefert sie als normalen DataFrame. Du wendest deine Logik auf diesen Chunk an, extrahierst das Ergebnis und verwirfst den Chunk. Da die alten Daten aus dem Memory gelöscht werden, bevor der nächste Batch gelesen wird, bleibt deine Memory Usage komplett flach, unabhängig davon, wie groß die zugrunde liegende Datei ist. Hier wird es interessant. Moderne Data Infrastructure verlässt sich selten auf einzelne, riesige Textdateien. Normalerweise werden große Datensätze als Directories gespeichert, die Hunderte von kleineren, partitionierten Files enthalten, typischerweise in einem Binärformat wie Parquet. Parquet Files sind hochkomprimiert und laden sehr schnell, aber du kannst trotzdem keine fünfzig Gigabyte an Parquet Files in sechzehn Gigabyte RAM laden. Um das zu handhaben, wendest du das Chunking-Konzept manuell über die Files hinweg an. Stell dir vor, du hast ein Directory mit jährlichen Parquet Files und möchtest die Gesamthäufigkeit von Kategorien über den gesamten historischen Datensatz berechnen. Du baust eine einfache iterative Loop. Initialisiere zuerst eine leere pandas Series. Diese dient als dein Accumulator für die globalen Totals. Als Nächstes iterierst du File für File durch dein Directory. Innerhalb der Loop liest du das aktuelle File in einen DataFrame. Führe nun die value counts Funktion auf der spezifischen Column aus, die du analysierst. Das gibt dir eine Series, die die Häufigkeiten nur für dieses spezifische Jahr enthält. Der entscheidende Schritt ist die Kombination dieses lokalen Ergebnisses mit deinem globalen Accumulator. Das machst du, indem du die add Methode auf deiner globalen Series aufrufst und die lokale Series übergibst. Weil einige Kategorien in einem File existieren könnten, in einem anderen aber nicht, musst du das fill value Argument auf null setzen. Das stellt sicher, dass pandas die Indexes richtig ausrichtet und die Counts addiert, ohne Missing Values einzuführen. Sobald die Loop die Verarbeitung dieses Files abgeschlossen hat, geht sie zum nächsten über. Python führt automatisch eine Garbage Collection für den alten DataFrame durch. Du streamst effektiv einen riesigen Datensatz File für File durch den Memory und baust eine kontinuierliche globale Aggregation auf. Bei Out-of-Core Processing geht es nicht darum, einfach Hardware auf ein Problem zu werfen. Es geht darum, deinen Active State klein zu halten und die mathematischen Aggregationen auf die individuelle Chunk-Ebene zu verlagern. Da dies das Ende der Serie ist, empfehle ich dir dringend, die offizielle pandas Documentation zum Thema Scaling zu erkunden und diese Patterns hands-on mit deinen eigenen Daten auszuprobieren. Wenn du Themen hast, die wir in zukünftigen Serien behandeln sollen, besuche devstories dot eu und lass es uns wissen. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.