Zipline Backtesting Engine

Hallo, hier ist Alex von DEV STORIES DOT EU. Zipline Backtesting Engine, Folge 1 von 7. Die meisten Handelsalgorithmen sehen auf dem Papier brillant aus, verlieren aber in Live-Märkten sofort Geld. Der übliche Verdächtige ist der Look-Ahead-Bias. Dein Code schaut versehentlich auf den morgigen Schlusskurs, um den heutigen Trade zu machen. Die Event-Driven Backtesting Engine in Zipline 3.0 verhindert das komplett. Bei einem Standard-Vectorized-Backtester lädst du einen riesigen Dataframe mit historischen Kursen und wendest Pandas-Operationen auf die gesamte Timeline auf einmal an. Das ist zwar schnell, aber extrem fehleranfällig für die Simulation der Realität. Du kannst leicht Logik schreiben, die heute eine Buy-Order auslöst, basierend auf einem Rolling Average, der versehentlich Daten von nächster Woche enthält. Zipline nimmt dir diese Möglichkeit, indem es dich in einen strikten Event-Driven Stream zwingt. Es simuliert eine echte Börse. Wenn du einen Backtest ausführst, fungiert die Engine als strikter Timekeeper. Sie geht durch die Historie, Tick für Tick oder Minute für Minute. Bei jedem Schritt feuert sie ein Event. Dein Code empfängt nur die Daten, die in genau dieser Mikrosekunde verfügbar sind. Du prüfst den aktuellen State, platzierst deine Orders und wartest dann, bis die Engine die Uhr weiterdreht. Du kannst nicht in die Zukunft schauen, weil die zukünftigen Daten noch nicht an die Engine gestreamt wurden. Diese Architektur garantiert, dass dein Backtest die tatsächlichen Constraints des Live-Tradings widerspiegelt. Eine Finanz-Timeline Event für Event in purem Python zu verarbeiten, erzeugt allerdings einen massiven Bottleneck. Du verarbeitest vielleicht jahrelange Pricing-Daten auf Minutenbasis für Tausende einzelner Aktien. Um diesen Event Loop rechentechnisch machbar zu machen, lagert Zipline extrem viel Arbeit an C-Extensions aus. Die Core-Engine verlässt sich auf vorkompilierte Routinen, um die Zahlen schnell genug zu crunchen, damit das Ganze nutzbar ist. Diese Abhängigkeit von C-Extensions bringt allerdings einen großen Reibungspunkt mit sich. Eine robuste quantitative Environment von Grund auf neu aufzusetzen, ist bekanntermaßen schwierig. Zipline ist kein Standalone-Python-Tool. Es erfordert eine tiefe Integration mit wissenschaftlichen Libraries auf Systemebene. Zum Beispiel nutzt es TA-Lib, eine Standard-Library zur Generierung technischer Marktindikatoren. Es verlässt sich auch auf Packages, die LAPACK und BLAS für rechenintensive lineare Algebra-Berechnungen brauchen. Das sind komplexe Legacy-Codebases in C und Fortran. Wenn du versuchst, diese Environment mit einem einfachen pip install Befehl zu bauen, wirst du fast sicher gegen eine Wand von Compilation Errors laufen. Pip zieht sich den Source Code für diese Dependencies und versucht, sie lokal zu kompilieren. Das setzt voraus, dass dein Betriebssystem einen richtig konfigurierten C-Compiler, einen Fortran-Compiler und die korrekten System-Header-Files bereits installiert hat. Die meisten Basis-Betriebssysteme haben das nicht out of the box. Deshalb empfiehlt die Zipline-Dokumentation ausdrücklich, conda statt pip zu verwenden. Conda ist nicht nur ein Python Package Manager. Es ist ein Environment- und System-Level Binary Manager. Wenn du eine Conda-Environment erstellst und Zipline über den conda-forge Channel installierst, kompilierst du nichts aus dem Source Code. Conda lädt vorkompilierte Binaries für dein spezifisches Betriebssystem herunter. Es kümmert sich nahtlos um die C-Extensions, TA-Lib und LAPACK. Der Dependency Tree wird für dich aufgelöst, was dir eine stabile Environment liefert, die bereit für die Algorithmenentwicklung ist. Hier ist der entscheidende Punkt. Der strikte Event Loop, der Zipline mathematisch ehrlich macht, ist genau das, was es zwingt, sich auf schwere, kompilierte C-Dependencies zu verlassen, um at scale zu laufen. Wenn du diese Architektur verstehst, verstehst du auch, warum die Installation komplex ist und warum conda der einzige sinnvolle Weg ist, deine Environment zu bauen. Wenn du helfen willst, die Show am Laufen zu halten, kannst du uns unterstützen, indem du auf Patreon nach DevStoriesEU suchst. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Zipline Backtesting Engine, Folge 2 von 7. Du richtest in deiner Trading-Logik einen einfachen Counter mit einer globalen Python-Variable ein, und mitten im Backtest wird er zurückgesetzt oder wirft einen Fehler. Beim Event-Driven Backtesting sind normale globale Variablen eine Falle. Um Tausende von simulierten Market-Events zu überstehen, brauchst du einen sicheren Weg, um den State zu tracken. Genau hier kommen der Zipline Algorithm Lifecycle und das State Management ins Spiel. Jeder Zipline-Algorithmus braucht mindestens zwei grundlegende Funktionen: initialize und handle data. Zipline ist ein event-gesteuertes System. Es geht historische Daten chronologisch durch und triggert für jeden Zeitabschnitt ein Event. Die initialize Funktion läuft genau einmal, wenn dein Backtest startet. Sie nimmt ein einziges Argument namens context. Stell dir context als den persistenten Speicher deines Algorithmus vor. Unter der Haube ist es ein einfaches Python-Dictionary, aber es fungiert als eigener Namespace. Anstatt normale globale Variablen zu deklarieren, hängst du deinen State direkt an context. Wenn du ein bestimmtes Asset, wie die Apple-Aktie, tracken willst, suchst du es in initialize und weist es context dot asset zu. Das stellt sicher, dass die Referenz vom ersten bis zum letzten Tag des Backtests erhalten bleibt. Als Nächstes kommt die handle data Funktion. Diese wird jedes Mal aufgerufen, wenn es ein neues Market-Event gibt, wie zum Beispiel einen neuen täglichen Trading-Bar. Sie nimmt zwei Argumente: context und data. context kennst du schon. Dort liest du den State aus, den du vorher eingerichtet hast, oder updatest laufende Variablen. Das zweite Argument, data, repräsentiert das aktuelle Marktumfeld. Es ist deine Linse in die Simulation in genau diesem Moment. Du nutzt data, um zu checken, ob ein Asset gerade handelbar ist, um seinen aktuellen Preis abzurufen, oder um ein historisches Fenster von Preisen anzufordern. Nehmen wir eine Standard Dual Moving Average Crossover Strategie. In deiner initialize Funktion definierst du dein Target-Asset und hängst es an context an. Innerhalb von handle data fragst du das data Objekt nach den Preisen der letzten dreißig Tage, um einen Short Moving Average zu berechnen, und nach den letzten dreihundert Tagen für einen Long Moving Average. Du vergleichst die beiden Averages. Wenn der Short Average den Long Average nach oben kreuzt, ist das ein Buy-Signal. Du führst das aus, indem du die order Funktion aufrufst und dein context dot asset sowie eine Zielanzahl an Shares übergibst. Trading ist nur die halbe Miete. Du musst auch tracken, wie deine Indikatoren über die Zeit performen. Zipline bietet dafür eine eingebaute Funktion namens record. Am Ende deines handle data Blocks rufst du record auf und übergibst deinen Short Moving Average, Long Moving Average und den aktuellen Preis. Zipline sammelt diese recordeten Werte bei jedem Schritt und hängt sie an den finalen Performance-Dataframe an, der am Ende des Backtests zurückgegeben wird. Wenn dein Code fertig ist, hast du zwei Möglichkeiten, ihn auszuführen. Die erste ist über das Command Line Interface. Du übergibst dein Python-Skript an den Zipline run Befehl und gibst dein Start- und Enddatum, dein Startkapital und eine Output-Datei für die Performance-Ergebnisse an. Das ist ideal für automatisierte Pipelines oder Remote Execution. Die zweite Methode ist interaktiv. Wenn du Jupyter Notebooks nutzt, kannst du den eingebauten Zipline Magic Command verwenden. Indem du percent percent zipline ganz oben in eine Notebook-Zelle tippst, definierst und führst du den Algorithmus inline aus, wobei du deine Datumsangaben und dein Kapital als Argumente an den Magic Command übergibst. Die Ergebnisse werden direkt in einen lokalen Dataframe injiziert, bereit für die sofortige Analyse. Hier ist die wichtigste Erkenntnis. Zipline zwingt dich, deinen Algorithmus in zwei separate Objekte aufzuteilen: context für den internen State, den du kontrollierst, und data für das externe Marktumfeld. Respektiere diese Grenze, und dein State Management bleibt über Tausende von Trades hinweg perfekt synchronisiert. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Zipline Backtesting Engine, Folge 3 von 7. Deine Trading-Logik mag komplett fehlerfrei sein, aber wenn du bei jedem Run einer Simulation riesige CSV-Files in den Memory lädst, geht deine Iteration Speed in den Keller. Das Bottleneck ist selten dein Algorithmus. Es ist deine Data Pipeline. Zipline löst dieses Problem mit Market Data Bundles und Custom Ingestion. Ein Data Bundle ist eine Sammlung von Asset Pricing und Metadaten, die in ein hochoptimiertes Storage-Format pre-compiled wurde. Anstatt während eines Runs Raw Text Files zu parsen, liest Zipline aus einem komprimierten Binary Storage und einer schnellen lokalen Datenbank. Diese Trennung von Data Processing und Strategy Execution macht Backtests außergewöhnlich schnell. Du triggerst diese Compilation über die Command Line mit dem zipline ingest Command, gefolgt vom Bundle-Namen. Zipline wird mit einem Default Bundle namens Quandl ausgeliefert, das standardmäßige historische Daily Equities Data aus dem Internet zieht und direkt auf deine Local Disk schreibt. Die meisten professionellen Environments verlassen sich auf proprietäre Daten. Um deine eigenen Daten zu nutzen, musst du ein Custom Bundle bauen. Das Erstellen eines Custom Bundles erfordert das Schreiben einer Ingest Function. Diese Funktion fungiert als dedizierter Übersetzer zwischen deiner Raw Data Source und Ziplines internem Storage-Format. Hier ist die Key Insight. Die Ingest Function gibt kein customized Dataset zurück. Stattdessen übergibt Zipline mehrere Writer-Objekte an deine Funktion, und dein Code füttert Raw Data in diese Writer. Die Signatur der Ingest Function erfordert spezifische Parameter, um dieses Routing zu handhaben. Sie nimmt eine Environment Configuration, den Trading Calendar, die Start und End Sessions und die Writer-Objekte entgegen. Die beiden kritischen Objekte, mit denen du interagieren wirst, sind der Asset Database Writer und der Daily Bar Writer. Der Asset Database Writer kümmert sich um deine Metadaten. Du übergibst ihm eine strukturierte Tabelle, die deine Symbole, ihre Start und End Dates und ihre Exchange Names enthält. Der Writer kompiliert das in eine lokale Datenbank, damit die Engine genau weiß, welche Assets in einer bestimmten Trading Session existieren. Der Daily Bar Writer verarbeitet die eigentliche Price Action. Du übergibst ihm einen Iterator, der Blöcke von Pricing Data liefert. Jeder Block enthält einen internen Asset Identifier, gepaart mit einer Tabelle seiner Open, High, Low, Close und Volume Data. Der Writer nimmt diese Blöcke und komprimiert sie auf die Disk. Zipline bietet einen Built-in-Mechanismus, um Standard Flat Files mithilfe des CSV Directory Bundles, oft csvdir genannt, zu verarbeiten. Du richtest deine proprietären Daten ein, indem du einzelne CSV-Files in einem einzigen Ordner speicherst und jedes File nach seinem Ticker Symbol benennst. Anschließend registrierst du dieses Directory in einem speziellen Zipline Configuration Script, dem sogenannten Extension File. Die Registrierung verknüpft einfach deinen Custom Bundle-Namen mit der zugrunde liegenden Ingest Function, damit das Command Line Tool weiß, dass sie existiert. Wenn du zipline ingest mit deinem neuen Custom-Namen ausführst, richtet das System die Ingest Function auf deinen Ordner. Es loopt durch die CSV-Files, extrahiert die Metadaten, füttert den Asset Database Writer und pumpt die Historical Pricing Rows in den Daily Bar Writer. Das langsame, teure Text Parsing passiert genau einmal. Nach der Ingestion sind deine proprietären Daten dauerhaft im optimierten Format gespeichert und sofort für Tausende von High-Speed Backtest Iterations verfügbar. Die wahre Power der Custom Ingestion liegt darin, dass sie deine Data Preparation strikt von deiner Strategy Execution entkoppelt und so sicherstellt, dass langsame Parsing-Logik niemals deine Testing Environment beeinträchtigt. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Zipline Backtesting Engine, Folge 4 von 7. Asset-Splits und Dividenden können deine Kurshistorie sofort ungültig machen. Bei einem Aktiensplit im Verhältnis zwei zu eins würde ein naiver Backtesting Loop fälschlicherweise annehmen, der Kurs sei gerade um fünfzig Prozent eingebrochen. Das vermeidest du, indem du die Algorithm API und die BarData-Interaktionen verwendest, die Point-in-Time-Anpassungen automatisch vornehmen. In Zipline interagiert der Kern deiner Algorithmus-Logik mit einem Objekt, das typischerweise data genannt wird und eine Instanz von BarData ist. Es wird an deine Event Handler übergeben, wie zum Beispiel deinen Main Data Handler oder deine Scheduled Functions. Seine Hauptaufgabe besteht darin, Preis- und Volumendaten exakt so bereitzustellen, wie sie in genau diesem Moment in der Simulation vorlagen, wodurch Look-Ahead-Bias vollständig verhindert wird. Wenn du data dot current aufrufst, übergibst du ein Asset und ein Field, wie zum Beispiel Preis oder Volumen. Es gibt dir den aktuellsten verfügbaren Wert für genau diese Simulationsminute oder diesen Simulationstag. Wenn du ein Lookback Window benötigst, um einen Moving Average oder die historische Volatilität zu berechnen, rufst du data dot history auf. Du übergibst das Asset, das Field, die Anzahl der Bars und die Frequenz, wie einen Tag oder eine Minute. Hier ist die wichtigste Erkenntnis. Sowohl current als auch history passen die zurückgegebenen Daten automatisch an Corporate Actions an, jedoch nur bis zur aktuellen Simulationszeit. Deine Moving Averages werden an einem Ex-Dividenden-Tag nicht wild ausschlagen, da die historischen Kurse exakt an den aktuellen Preisrahmen angepasst werden. Du erhältst eine mathematisch kontinuierliche Zeitreihe, ohne die Multiplikatoren für Corporate Actions selbst verwalten zu müssen. Bevor du auf Basis dieser Preisdaten handelst, musst du prüfen, ob das Asset in genau diesem Moment tatsächlich handelbar ist. Wenn du dein Asset an data dot can trade übergibst, wird geprüft, ob die Börse für dieses Asset geöffnet ist und ob es aktiv gelistet ist. Wurde eine Aktie gestern vom Handel ausgesetzt oder hat sie ihren Börsengang noch nicht durchgeführt, gibt das false zurück. Als Nächstes hast du data dot is stale. Ist ein Asset sehr illiquide und wurde während der aktuellen Bar nicht gehandelt, macht Zipline ein Forward-Fill des letzten bekannten Preises, um Fehler durch fehlende Daten zu vermeiden. Wenn du jedoch eine Mean-Reversion-Strategie auf forward-filled Preisen ausführst, handelst du mit Geisterdaten. Data dot is stale gibt true zurück, wenn der angezeigte Preis aus einer vorherigen Periode übernommen wurde und kein frischer Trade ist. Die Überprüfung von Handelbarkeit und Staleness vor der Orderaufgabe verhindert eine riesige Klasse von Simulationsfehlern. Damit sind die Inputs abgedeckt, kommen wir nun zum Execution Timing. Standardmäßig ruft Zipline deinen Main Data Handler in jeder einzelnen Simulations-Bar auf. Wenn du eine Strategie auf Minutenbasis ausführst, wird die Ausführung komplexer Rebalance-Logik alle sechzig Sekunden deinen Backtest extrem verlangsamen und unrealistische Transaktionskosten auslösen. Die Lösung ist die schedule function Methode. Du verwendest diese innerhalb der Initialisierungsphase deines Algorithmus, um eine spezifische Custom Function zu registrieren, die nach einem präzisen Zeitplan ausgeführt wird. Sie nimmt drei Hauptargumente entgegen. Erstens die Funktion, die du ausführen möchtest. Zweitens eine Date Rule. Drittens eine Time Rule. Angenommen, du möchtest ein Portfolio-Rebalance genau dreißig Minuten vor Börsenschluss durchführen. Du übergibst deine Rebalance-Funktion als erstes Argument. Für die Date Rule verwendest du die date rules dot every day Helper Methode. Für die Time Rule verwendest du time rules dot market close und übergibst dreißig Minuten als Offset Argument. Anstatt nun hunderte Male am Tag auszulösen, läuft deine Rebalance-Logik genau einmal, direkt wenn die Handelssitzung zu Ende geht. Die Trennung zwischen dem BarData-Objekt für sicheren Datenzugriff und der Scheduling API für das Execution Timing garantiert, dass deine Core-Algorithmus-Logik nur dann ausgeführt wird, wenn sie es soll, und zwar mit Preisen, die in genau diesem Moment tatsächlich existierten. Ich möchte mir kurz die Zeit nehmen, dir fürs Zuhören zu danken – das hilft uns sehr. Mach's gut!

Hallo, hier ist Alex von DEV STORIES DOT EU. Zipline Backtesting Engine, Folge 5 von 7. Dein Algorithmus erkennt ein perfektes Exit-Signal und feuert eine massive Sell-Order ab. Das Problem ist, es ist Samstag. Wenn deine Backtesting-Engine nicht weiß, dass die Exchange geschlossen ist, wird diese Order entweder in einem Phantom-Markt ausgeführt oder crasht deine gesamte Simulation. Custom Trading Calendars bilden die Realität der globalen Marktzeiten ab, um genau dieses Szenario zu verhindern. Ein Trading Calendar in Zipline ist die absolute Source of Truth für Market Sessions. Er legt fest, wann Daten ingested und Orders verarbeitet werden können. By default geht Zipline von einem Standard-Schedule für US-Equities aus. Wenn du internationale Equities, Futures oder alternative Assets traden willst, musst du die spezifischen Regeln dieser Exchanges definieren. Das machst du, indem du eine Custom Class erstellst, die von Ziplines Base Class Trading Calendar erbt. Du musst nur ein paar spezifische Properties konfigurieren, um die Grenzen des Trading-Tages festzulegen. Erstens setzt du die Open Time. Das bestimmt die genaue Stunde und Minute, ab der der Markt Orders annimmt. Zweitens setzt du die Close Time, die die letzte Minute der Trading Session markiert. Drittens definierst du Regular Holidays. Das ist eine Collection von spezifischen Daten, an denen die Exchange komplett geschlossen ist, wie zum Beispiel nationale Feiertage. Zipline führt diese ganzen Datumsberechnungen nicht from scratch durch. Es nutzt intensiv die pandas Library, genauer gesagt die Klassen pandas Holiday Calendar und Custom Business Day. Wenn du deine Liste von Regular Holidays übergibst, befüllst du im Grunde ein pandas Holiday Calendar Object. Zipline kombiniert diese pandas-Logik mit deinen definierten Open und Close Times, um einen riesigen, vorberechneten Index jeder einzelnen gültigen Trading-Minute für die gesamte Dauer deines Backtests zu generieren. Diese Upfront-Berechnung ist entscheidend. Das bedeutet, dass dein Algorithmus nicht bei jedem einzelnen Tick der Simulation komplexe Date-Math evaluieren muss. Er fragt einfach ein hochoptimiertes Array ab. Das ist der Teil, auf den es ankommt. Nicht alle Märkte schlafen. Wenn du Cryptocurrency-Trades simulierst, werden Standardannahmen über Wochenenden dein Data Alignment ruinieren. Du musst einen kontinuierlichen 24/7-Kalender bauen. Lass uns mal einen bauen, den wir TFS Exchange Calendar nennen. Du definierst deine neue Class und erbst von der Standard Base Class. Für die Open Time gibst du Mitternacht an. Für die Close Time gibst du 23:59 Uhr an, was dir einen vollen Daily Cycle gibt. Weil Cryptocurrency Exchanges keine traditionellen Feiertage haben, setzt du die Regular Holidays Property so, dass sie eine leere List zurückgibt. Der letzte Schritt ist die Anpassung des Weekly Schedules. Traditionelle Trading Calendars nutzen ein pandas Custom Business Day Object, das strikt für Montag bis Freitag konfiguriert ist. Für deinen TFS-Kalender überschreibst du diese Weekmask Property, um Samstag und Sonntag explizit einzuschließen. Sobald die Class komplett ist, registrierst du sie mit einem Custom String Identifier in der Zipline-Umgebung. Ab diesem Zeitpunkt erkennen sowohl deine Data Ingestion Bundles als auch deine Trading-Algorithmen den kontinuierlichen Schedule. Orders werden sequenziell verarbeitet, ohne Wochenenden zu überspringen, und Minute-Level Data wird perfekt auf Real-World Timestamps gemappt. Wenn deine Calendar Rules falsch konfiguriert sind, sind deine Preisdaten misaligned und deine Performance Metrics komplett fiktiv. Time Boundaries diktieren jede Aktion in einer Event-driven Engine, und Trading Calendars sind genau der Weg, wie du diese Boundaries erzwingst. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Zipline Backtesting Engine, Folge 6 von 7. Die Berechnung komplexer Risk Metrics bei jedem Tick kann deinen Backtest extrem verlangsamen. Du willst schnelle Simulationen, musst aber auch genau wissen, wie sich deine Strategie unter Stress verhält. Du kannst das Default-Tracking während des Debuggings tatsächlich deaktivieren oder hochoptimierte Custom Tracker schreiben. Diese Folge behandelt Risk Performance Metrics und Custom Evaluation. Zipline gruppiert seine Built-in-Risiko- und Performance-Berechnungen in einer Struktur namens Metric Set. Das Default Set generiert automatisch Standardstatistiken wie Beta, Sharpe Ratio und Total Returns. Wenn deine Simulation durchgelaufen ist, packt Zipline all diese Berechnungen in den Performance DataFrame. Jede getrackte Metric wird zu einer Spalte, und jede Zeile repräsentiert einen Time Step in deiner Simulation. Wenn du nicht all diese Default Metrics brauchst, kannst du beim Start der Engine ein reduziertes Metric Set übergeben und so deutlich Rechenzeit sparen. Wenn die Default Metrics dein spezifisches Risikomodell nicht abbilden, definierst du eine Custom Metric. Das machst du, indem du eine Subclass von Ziplines Base Metric Object erstellst. Eine Custom Metric zu schreiben bedeutet, sich direkt in die interne Simulation Clock einzuklinken. Du steuerst genau, wann deine Logik ausgeführt wird, indem du drei spezifische Lifecycle-Methoden implementierst: Start of Simulation, End of Session und End of Bar. In Start of Simulation initialisierst du Variablen und setzt den Initial State auf. End of Session läuft einmalig zum Handelsschluss. End of Bar wird nach jedem einzelnen Price Update ausgeführt, was für Minute-Level-Strategien extrem wichtig ist. Jedes Mal, wenn einer dieser zeitbasierten Hooks triggert, übergibt Zipline zwei Required Arguments: das Ledger und das Packet. Das Ledger hält den mathematischen Live-State deiner Simulation. Es enthält deinen aktuellen Portfolio Value, Cash Balances und alle offenen Positionen. Du behandelst das Ledger als Read-Only-Daten. Das Packet hingegen ist ein leeres Dictionary, das die Data Payload für diesen spezifischen Time Step repräsentiert. Du schreibst in das Packet. Jedes Key-Value-Pair, das du dem Packet-Dictionary zuweist, wird sofort zu einer Spalte in deinem finalen Performance DataFrame. Lass uns das Tracking des maximalen Intraday Drawdowns mithilfe des End-of-Bar-Hooks durchgehen. Zuerst definierst du deine Custom Metric Class. In der Start-of-Simulation-Methode erstellst du zwei Variablen: eine, um den bisher höchsten Portfolio Value zu tracken, und eine weitere für den aktuellen Maximum Drawdown. Beide starten bei Null. Hier ist der entscheidende Punkt: Weil Intraday Drops unsichtbar sind, wenn du nur tägliche Closing Prices checkst, musst du deine Logik innerhalb der End-of-Bar-Methode ausführen. In dieser Methode liest du den aktuellen Portfolio Value aus dem Ledger-Argument. Wenn der aktuelle Wert höher ist als dein aufgezeichneter Höchstwert, updatest du die High Water Mark. Ist er niedriger, berechnest du den prozentualen Drop. Wenn dieser Drop deinen aufgezeichneten Maximum Drawdown übersteigt, updatest du die Maximum-Drawdown-Variable. Schließlich nimmst du deine Maximum-Drawdown-Variable und weist sie einem Key im Packet-Argument zu. Indem du am Ende jedes Bars in das Packet schreibst, wird dein finaler Performance DataFrame einen granularen, minutengenauen Record des schlimmsten erlebten Intraday Drops enthalten. Custom Metrics sind im Grunde nur Observer, die das Simulation Ledger lesen und in das Output Packet schreiben, wodurch du die volle Kontrolle darüber hast, was gemessen wird und wann. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Zipline Backtesting Engine, Folge 7 von 7. Du verbringst Monate damit, einen Algorithmus in einem Simulator zu perfektionieren, aber der echte Markt akzeptiert keine simulierten Trade-Orders. Zipline wurde primär fürs Backtesting entwickelt, aber dank der modularen Architektur kannst du die interne Simulation komplett umgehen und direkt an eine echte Execution Engine routen. Die Zipline-Architektur zu erweitern, macht diesen Übergang möglich. Out of the box arbeitet Zipline als Closed Loop. Du fütterst es mit historischen Preisdaten, es berechnet Signale und matcht deine Orders intern gegen das vergangene Marktverhalten. Das System isoliert deinen Algorithmus ganz bewusst von externen Netzwerken. Aber ein modernes Trading-System muss irgendwann mit der Außenwelt sprechen. Du brauchst einen Weg, die internen Simulationskomponenten gegen Custom-Module auszutauschen, die Live-Daten und echtes Kapital verarbeiten. Zipline löst das über einen Extension-Mechanismus, der um eine spezielle Initialisierungsdatei namens extension dot py herum aufgebaut ist. Diese Datei dient als lokale Registry für deine Environment. Wenn das Zipline-Framework startet, sucht es hier sofort nach User-defined Overrides. Du nutzt diese Datei, um neue Data Bundles, Custom-Commission-Modelle und alternative Execution Engines zu registrieren. Die wichtigste Komponente, die du für das Live-Trading austauschen musst, ist der Blotter. Der Blotter fungiert als internes Order-Management-System. Er trackt offene Orders, cancelt sie auf Anweisung und verarbeitet Trade-Fills. Der Default-Simulation-Blotter tut so, als würde er Trades ausführen, basierend auf historischen Volumen- und Slippage-Algorithmen. Fürs Live-Trading musst du das komplett umgehen. Das erreichst du, indem du eine Custom-Blotter-Klasse schreibst. Anstatt die Execution zu simulieren, machen deine Klassenmethoden Network Calls an eine echte Broker-API. Wenn der Algorithmus einen Trade anfordert, formatiert dein Custom-Blotter diesen Request in eine Live-Order und überträgt sie an die Exchange. Hier ist der entscheidende Punkt: Du musst keine einzige Zeile des originalen Zipline-Source-Codes ändern, um das zu implementieren. Du definierst deine Custom-Blotter-Klasse in deinem eigenen Workspace. Dann öffnest du extension dot py. Du importierst die Blotter-Registrierungsfunktion aus dem Zipline-Utilities-Modul. Du übergibst dieser Funktion einen eindeutigen String-Namen für deinen Broker, zusammen mit deiner Custom-Blotter-Klasse. Das registriert deine Execution Engine global. Wenn du schließlich dein Trading-Script über die Command Line oder ein Notebook ausführst, übergibst du einfach den String-Namen deines Custom-Blotters als Launch-Parameter. Das Framework tauscht die interne Maschinerie automatisch aus. Exakt derselbe Algorithmus, der in der Simulation lief, tradet jetzt mit Live-Kapital. Dieses Level an Modularität zu unterstützen, erfordert eine extrem stabile Core-Foundation. Zipline verlässt sich stark auf schnelle numerische Dataframes und relationalen Database-Storage, um Informationen zwischen dem Algorithmus und dem Blotter zu bewegen. Mit dem Release von Zipline 3.0 hat die Core-Architektur ein signifikantes strukturelles Update erhalten, um diese Foundation zu modernisieren. Die gesamte Plattform wurde migriert, um Pandas 2.0 und SQLAlchemy 2.0 zu unterstützen. Das Upgrade auf Pandas 2.0 bringt ein wesentlich besseres Memory Management und schnellere Execution-Zeiten für die massiven Time-Series-Arrays, die Zipline bei jedem Tick verarbeitet. SQLAlchemy 2.0 modernisiert komplett, wie die Engine mit den zugrundeliegenden SQL-Datenbanken interagiert. Es erzwingt strengere, explizitere Query-Execution-Paths, wenn das System Asset-Metadaten verwaltet und Trading-Ergebnisse speichert. Diese grundlegenden Upgrades stellen sicher, dass die Engine auf dem modernen Standard der Python-Data-Infrastructure arbeitet – egal, ob du einen massiven historischen Backtest laufen lässt oder Live-Orders über eine Custom-Broker-Extension routest. Durch die Trennung der Trading-Logik von den Execution-Mechanics garantiert die Architektur, dass dein Algorithmus komplett unangetastet bleibt, während sich der zugrundeliegende Execution-Layer an die Realität anpasst. Ich kann dir nur wärmstens empfehlen, die offizielle Documentation zu erkunden und hands-on zu versuchen, deine eigenen Extensions zu schreiben. Wenn du Ideen hast, was wir als Nächstes behandeln sollten, besuche dev stories dot eu, um Themen für unsere zukünftigen Serien vorzuschlagen. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.