1. qteasy Gesamtarchitektur und Designansatz

1.1. 1. 引言：为什么需要从“架构”理解 qteasy

qteasy ist ein lokalisiertes, reproduzierbares Toolkit für den quantitativen Handel. Über das Benutzerhandbuch und die API-Dokumentation hinaus hilft Ihnen das Verständnis, wie die Module geschichtet sind und aus der Perspektive der Systemarchitektur und Entwurfsprinzipien zusammenarbeiten, dabei, die Schnittstellen genauer zu nutzen, Probleme zu beheben und Umwege bei der Erweiterung benutzerdefinierter Strategien oder Daten zu vermeiden. Dieses Kapitel bietet eine Gesamtzusammenfassung der Architektur von qteasy und drei Hauptdesign-Threads; In den folgenden Kapiteln wird jedes Modul ausführlicher erläutert.

1.2. 2. 三条设计主线（简述）

2.1 Daten: Von „Rohtabellen“ zu „typisierten Informationen“ (DataType)

Nachdem rohe Markt-, Finanz- und andere Daten abgerufen und bereinigt wurden, werden sie mithilfe eines einheitlichen Tabellenschemas in DataSource (Dateien oder einer Datenbank) gespeichert. qteasy lässt nicht zu, dass Strategien diese Tabellen direkt lesen oder schreiben; Stattdessen abstrahiert es „von Strategien nutzbare Informationen“ in DataType (bestehend aus Name, Häufigkeit, Asset-Typ usw., entsprechend einer eindeutigen dtype_id). Eine Strategie deklariert lediglich, welche DataTypes sie benötigt und wie lange ein historisches Fenster (window_length) sie benötigt; Zur Laufzeit ruft die Engine gemäß der Deklaration Daten aus DataSource ab, organisiert sie in einem Datenfenster und fügt sie in die Strategie ein. Zu den Zwecken gehören: die Verwendung derselben Datenansicht für Backtesting und Live-Handel, die Vereinheitlichung der Strategieschnittstelle und die Verhinderung von „Look-Ahead-Bias“ auf Mechanismusebene (eine Strategie kann bei jedem Zeitschritt nur vergangene Daten sehen, die von der Engine eingegeben wurden).

2.2 Strategie: Vier Schlüsselelemente und eine einheitliche realisieren()

Konzeptionell enthält eine Strategie vier Kategorien von Elementen:

Ausführungszeitpunkt: wann und wie oft ausgeführt werden soll (z. B. täglich zum Marktschluss) – in qteasy 2.0 wird dies von der Gruppe der Strategie verwaltet und ist nicht innerhalb der Strategieklasse fest codiert.
Erforderliche Daten: Welche DataTypes werden benötigt, wie lang ist das Fenster (Datentypen, Fensterlänge usw.), deklariert während der Strategieinitialisierung.
Anpassbare Parameter: definiert durch Parameter, eingestellt vor der Ausführung über „set_parameter“ und dergleichen; Während der Optimierung durchsucht der Optimierer den Parameterraum.
Logik: implementiert über ein parameterloses realize(); Verwenden Sie innerhalb der Methode „get_pars()“ und „get_data(dtype_id)“, um die Parameter und Daten des aktuellen Schritts abzurufen, Handelssignale zu berechnen und zurückzugeben.

Dasselbe „realize()“ wird sowohl beim Backtesting als auch beim Live-Handel wiederverwendet, um ein konsistentes Verhalten sicherzustellen.

2.3 Ausführung: Operator und Gruppe, gesteuert durch Zeitschritte, Unified run(config)

Operator ist sowohl der Container für Strategien als auch der Einstiegspunkt für die Ausführung: Es enthält mehrere Gruppen, und jede Gruppe ist eine Reihe von Strategien mit derselben run_freq und run_timing (sowie signal_type und blender). group_timing_table ist eine „Zeitschritt × Gruppe“-Tabelle, die angibt, welche Gruppen in jedem Zeitschritt ausgeführt werden müssen. Ein einstufiger Arbeitsablauf kann wie folgt zusammengefasst werden: Suchen Sie in der Tabelle nach dem aktuellen Schritt, um die Gruppen auszuführen → Bereiten Sie ein Datenfenster für jede Strategie in diesen Gruppen vor und fügen Sie es ein → Rufen Sie „generate()“ jeder Strategie auf (das intern „realize()“ aufruft) → Mischen Sie Signale innerhalb der Gruppe mithilfe des Blenders der Gruppe → Erhalten Sie das zusammengeführte Signal für diesen Schritt. Backtesting, Live-Handel und Optimierung basieren alle auf dem gleichen Mechanismus: „das Operator Schritt für Schritt gemäß der Gruppenzeittabelle ausführen“; Die Unterschiede liegen lediglich in der Datenquelle (historisch vs. Echtzeit) und der Ergebnisverarbeitung (simulierte Füllungen vs. reale Bestellungen vs. Parametersuche).

2.4 Visualisierung: HistoryPanel und Multi-Backend-Diagramme

Zusätzlich zu Daten und Ausführung bietet qteasy einen HistoryPanel-basierten Visualisierungsstapel:

Als 3D-Datencontainer (Shares × hdates × htypes) ist HistoryPanel sowohl der natürliche Rückgabewert von „get_history_data“ als auch die erforderliche Datenstruktur für die Visualisierung;
„HistoryPanel.plot(…)“ ist der einheitliche Plot-Einstiegspunkt. Es wählt automatisch den geeigneten Diagrammtyp (Kerze, Volumen, MACD, Liniendiagramm usw.) basierend auf H-Typen und Aktien aus und generiert Backend-agnostische Diagrammspezifikationen;
Das statische Backend (matplotlib) und das interaktive Backend (Plotly) rendern Diagramme auf der Grundlage derselben Spezifikationen und stellen so die Konsistenz zwischen statischen/interaktiven Ansichten in Farbschema, Layout und Semantik sicher;
Die APIs der oberen Ebene wie „qt.candle(…)“ sind lediglich Wrapper für „Daten abrufen → HistoryPanel erstellen → „hp.plot()“ aufrufen“.

Auf diese Weise wird die Visualisierungslogik vom Datenabruf und der Backtesting-Engine entkoppelt, was die unabhängige Weiterentwicklung und Tests erleichtert.

1.3. 3. 总体架构图（三层）

Nach Verantwortlichkeiten kann qteasy in drei Schichten unterteilt werden, wie in der folgenden Abbildung (Textversion) dargestellt:

flowchart TB subgraph dataLayer [数据层] DS[DataSource] Tables[数据表] DT[DataType / dtype_id] GHD[get_history_data] HP[HistoryPanel] DS --> Tables Tables --> DT DT --> GHD GHD --> HP end subgraph strategyLayer [策略层] BS[BaseStrategy 及子类] PAR[Parameter] DTL[data_types / window_length] BS --> PAR BS --> DTL HP --> BS end subgraph runLayer [运行层] OP[Operator] GR[Group] GTT[group_timing_table] BL[blender] BT[Backtester] TR[Trader] OPR[Optimizer] OP --> GR OP --> GTT GR --> BL OP --> BT OP --> TR OP --> OPR end subgraph vizLayer [可视化层] HPPlot[HistoryPanel.plot] SpecBuilder[图表规格/布局] StaticBackend[静态后端(matplotlib)] InteractiveBackend[交互后端(Plotly)] HP --> HPPlot HPPlot --> SpecBuilder SpecBuilder --> StaticBackend SpecBuilder --> InteractiveBackend end dataLayer --> strategyLayer strategyLayer --> runLayer dataLayer --> vizLayer

Datenschicht: DataSource, Datentabellen, DataType und die nach außen gerichteten get_history_data / HistoryPanel, die historische Informationen „nach Typ, nach Fenster“ für die Strategie- und Laufzeitebenen bereitstellen.
Strategieschicht: BaseStrategy und seine Unterklassen (z. B. RuleIterator, FactorSorter, GeneralStg), Parameter, data_types / window_length, verantwortlich für die Deklaration von Anforderungen und die Implementierung von real().
Laufzeitebene: Operator, Group, group_timing_table, blender und Backtester / Trader / Optimizer, verantwortlich für die Steuerung von Strategien im Laufe der Zeit, die Aggregation von Signalen und die Durchführung von Backtesting / Live-Handel / Optimierung.

1.4. 4. 核心对象关系图

flowchart LR subgraph operator [Operator] G1[Group A] G2[Group B] end G1 --> S1[Strategy 1] G1 --> S2[Strategy 2] G2 --> S3[Strategy 3] S1 --> DT[DataType] S1 --> PAR[Parameter] S2 --> DT S2 --> PAR S3 --> DT S3 --> PAR OP_RUN[op.run] CFG[config] DSRC[datasource] OP_RUN --> operator CFG --> OP_RUN DSRC --> OP_RUN

Ein Operator enthält mehrere Gruppen und jede Gruppe enthält mehrere Strategien.
Jede Strategie deklariert den DataType (und die Fensterlänge), von der sie abhängt, und definiert einstellbare Parameter über Parameter.
Der Einstiegspunkt ist „op.run(config, datasource, logger)“, gesteuert durch config und datasource.

1.5. 5. 数据与信号的大致流向

Von Datenquellen über Strategien bis hin zu Backtesting/Live-Handel/Optimierung kann der Gesamtablauf wie folgt vereinfacht werden:

sequenceDiagram participant User participant DataSource participant Operator participant Strategy participant Backtester User->>Operator: qt.run(op, mode=1/0/2, ...) Operator->>DataSource: 按策略声明请求历史/实时数据 DataSource-->>Operator: 数据窗口 loop 每个时间步 Operator->>Strategy: 注入数据窗口，调用 realize() Strategy-->>Operator: 信号 Operator->>Operator: blender 混合 end Operator-->>Backtester: 信号序列（回测时） Backtester-->>User: 资金曲线、绩效等

Benutzer geben Backtesting (1), Live-Handel (0) oder Optimierung (2) über „qt.run(op, mode=…)“ ein.
Basierend auf den Konfigurations- und Strategiedeklarationen fordert der Operator Daten vom DataSource an, ruft dann Schritt für Schritt Strategien gemäß der group_timing_table auf und mischt die Signale.
Beim Backtesting wird die Signalsequenz zur simulierten Füllung und Auswertung an den Backtester übergeben; im Live-Handel wird es zur Ausführung an den Trader/Broker übergeben; Bei der Optimierung führt der Optimierer mehrere Backtests durch und aggregiert die Ergebnisse.

1.6. 6. 本系列各章与教程、API、示例的阅读顺序建议

Diese Reihe (Architektur und Design): Es wird empfohlen, zuerst dieses Kapitel (00) und Kernkonzepte auf einen Blick zu lesen und dann bei Bedarf Datenschicht, Daten in Strategien, Operator und Gruppen, [Strategie Ausführung und Parameter] (05-strategy-lifecycle.md) und [Backtesting/Live Trading/Optimierung] (06-backtest-live-optimization.md), um ein Gesamtbild zu erstellen.
Benutzerhandbuch: Konzentriert sich auf „praktische“ Schritt-für-Schritt-Vorgänge. Es ist geeignet, nach dem Verständnis der Architektur nach Bedarf selektiv zu lesen, um bestimmte Aufgaben zu erledigen (z. B. Daten herunterladen, Strategien schreiben und Backtests ausführen).
Historische Finanzdaten herunterladen und verwalten, API-Referenz: Wird zum Nachschlagen von Datenkonfigurationen, Schnittstellenparametern und Rückgabewerten verwendet; Diese Reihe behandelt nur „Struktur und Mechanismen“ und ersetzt nicht die API-Dokumentation.
Beispiele: Stellen Sie vollständige ausführbare Beispiele bereit, die zusammen mit den Tutorials und dieser Serie verwendet werden können.