3. Datenerfassung, -speicherung und Datentypen

3.1. 1. 数据层在整体中的位置

Die Datenschicht versorgt die Strategieschicht und die Laufzeitschicht mit historischen Informationen „nach Typ, nach Fenster“. Strategien greifen nicht direkt auf Rohdatentabellen zu; Stattdessen geben sie an, welche DataType sie benötigen und wie lang die window_length sein soll. Vor der Ausführung ruft die Engine die entsprechenden Daten aus DataSource ab, organisiert sie in Datenfenstern und fügt sie in die Strategie ein. Dadurch wird sichergestellt, dass Backtesting und Live-Handel dieselbe Datenansicht verwenden, und es wird außerdem verhindert, dass Strategien absichtlich „zukünftige Daten“ verwenden.

3.2. 2. 从原始数据到本地存储

2.1 Datenfluss

Externe Datenquellen (z. B. Tushare, Eastmoney usw.) → Abrufen und Bereinigen (Formatvereinheitlichung, Deduplizierung, Ausrichtung) → DataSource (Dateien oder Datenbank) → in mehrere Datentabellen in einer einheitlichen Struktur geschrieben.

2.2 Die Rolle von DataSource

Einheitliche Speicherabstraktion: Unabhängig davon, ob es sich bei der zugrunde liegenden Schicht um CSV-/HDF-/Feather-Dateien oder eine Datenbank wie MySQL handelt, wird in die obere Schicht immer „nach Tabellenname, nach Spalte“ gelesen und geschrieben.
Multi-Engine-Unterstützung: Kann als Datei (csv/hdf/fth) oder db (MySQL usw.) konfiguriert werden, um unterschiedliche Bereitstellungsanforderungen zu erfüllen.
Zieht Daten nicht proaktiv ab: DataSource ist nur für das Lesen und Schreiben von Daten verantwortlich, die bereits lokal vorhanden sind; Das Abrufen und Aktualisieren aus dem Netzwerk erfolgt durch den Benutzer oder geplante Aufgaben, die die Datenschnittstelle aufrufen und dann in DataSource schreiben.

Daher trennt das Datenschichtdesign „Abrufen“ und „Speichern“: Die beim Abrufen erhaltenen Daten werden nach der Bereinigung in den DataSource geschrieben, und Strategien und Backtests verbrauchen nur Daten, die bereits im DataSource vorhanden sind.

3.3. 3. 数据表

Integrierte Tabellenpartitionierung: qteasy definiert mehrere Datentabellen vor, die grob gesagt Marktdaten (z. B. Tagesbalken, Minutenbalken), Finanzdaten (Gewinn- und Verlustrechnung, Bilanz usw.), Makros und Indizes usw. umfassen. Jede Tabelle verfügt über einen festen Tabellennamen, einen festen Primärschlüssel und ein festes Spaltenschema.
Zuordnung zwischen Tabellenschema und DataType: Eine „Information, auf die eine Strategie verweisen kann“ entspricht häufig einer Spalte in einer Tabelle (oder einer oder mehreren Spalten nach der Berechnung). Die Zuordnung vom Namen (und der Häufigkeit, dem Asset-Typ) eines DataType zu Datentabellen/-spalten wird im System verwaltet. Strategien müssen Anforderungen nur über DataType oder dtype_id deklarieren, ohne sich um bestimmte Tabellennamen oder Spaltennamen zu kümmern.

3.4. 4. DataType：从“表里的数据”到“策略可引用的信息”

4.1-Name, Häufigkeit, Asset-Typ und Dtype-ID

Name: der Datentypname (z. B. close, open, total_mv, pe), der einer bestimmten Art verfügbarer Informationen entspricht.
Frequenz: Die Datenfrequenz (z. B. d/w/m/q), bezogen auf die Zeitgranularität der Datentabelle oder die Resampling-Methode.
asset_type: der anwendbare Vermögenswerttyp (z. B. E, IDX, ANY), der zur Unterscheidung von Aktien, Indizes usw. verwendet wird.
dtype_id: wird aus den drei oben genannten Elementen mit der Regel „name_assettype_freq“ generiert, zum Beispiel „close_E_d“, „total_mv_E_q“. Strategien verwenden diese ID, wenn sie „get_data(dtype_id)“ aufrufen.

4.2 Zuordnung zwischen integrierten DataTypes und Datentabellen/-spalten

Das System verfügt über einen großen Satz integrierter DataTypes, die jeweils Spalten oder abgeleiteten Spalten in verschiedenen Datentabellen zugeordnet sind. Spezifische Tabellennamen und Spaltennamen und wie Sie diese erhalten, finden Sie unter Herunterladen und Verwalten von historischen Finanzdaten und in der Dokumentation „Datentypen und Datentabellen“ in den API-Dokumenten. Diese Serie betont nur: Strategien referenzieren Daten nur über DataType (dtype_id) und hängen nicht direkt vom Tabellenschema ab. Auf diese Weise müssen Sie bei der Weiterentwicklung des Schemas nur die Zuordnung anpassen, ohne den Strategiecode zu ändern.

3.5. 5. 小结：为什么策略只接触 DataType 而不直接读表

Konsistenz: Sowohl Backtesting als auch Live-Handel rufen Daten über denselben Pfad ab – „deklarieren Sie DataType + Engine-Injektionen nach Fenster“ – und vermeiden so zwei separate Logiksätze.
Kein Look-Ahead-Bias: Die Engine bereitet das historische Datenfenster streng auf der Grundlage des aktuellen Zeitschritts und der Fensterlänge vor, sodass die Strategie nicht auf zukünftige Daten zugreifen kann, die nicht injiziert wurden.
Einheitliche Schnittstelle: Alle Strategien rufen Daten über „get_data(dtype_id)“ ab. Jede dtype_id entspricht eins zu eins einem DataType, was die Wartung und Erweiterung erleichtert.

Weitere Informationen zur Datenkonfiguration und API-Nutzung finden Sie unter Historische Finanzdaten herunterladen und verwalten und in der API-Referenz.