Feature Pipeline (Feature Engineering + Feature‑QA)

---

Kurzzusammenfassung

• Diese Seite beschreibt die Feature Pipeline als Detailansicht zum Schritt Feature Pipeline in der Gesamtarchitektur: Aus einem freigegebenen, validierten Curated Dataset wird ein versioniertes Feature‑Set erzeugt und im Feature Store publiziert.
• Der Fokus liegt auf reproduzierbarer Feature‑Ableitung (EOD/long‑term) und einem schlanken Feature‑QA‑Layer (Leakage, Verteilungen, Stabilität) – nicht auf Raw‑Ingestion oder zentralen DQ‑Gates.
• Inputs sind ein Validated Curated Dataset Contract (aus der Ingestion) plus ein normalisierter Run‑Kontext (run_id, trigger_reason, universe_id).
• Output ist ein Feature Set Version Contract (Referenz für Training/Scoring) sowie ein Feature QA Report (Artefakt + Status).
• BPMN‑Leitpfad (Detail): Input Mode → Normalize Run Context → Curate + Standardize → Feature Engineering → Feature‑QA → Version + Publish → Update Metadata → Log Artifacts → Downstream Ready.

Einordnung: Diese Detailansicht gehört zum Call‑Activity‑Knoten „Feature Pipeline“ in der Gesamtarchitektur. Sie startet erst nachdem der Datensatz durch Purpose (Gate A) und das Data Quality Gate freigegeben ist. Upstream‑Schritte sind Scheduling und Ingestion (Data Pipeline: ELT + Validierung).

Ziel

1. Einheitliche Feature‑Definitionen für Training, Backtests und tägliches Scoring (Score‑basiertes Stock‑Picking, EOD/long‑term).
2. Reproduzierbarkeit: Feature‑Versionen sind eindeutig referenzierbar und an dataset_version / as_of_date gebunden.
3. Frühzeitiges Erkennen von Feature‑Problemen (z. B. Leakage, unerwartete Verteilungs‑Shifts), bevor Downstream‑Schritte (Labels/Training) laufen.
4. Saubere Lineage: Curated Dataset → Feature‑Set Version (OpenMetadata) und Run‑Artefakte (MLflow).

Scope & Abgrenzung

In Scope (diese Seite / BPMN‑Detailansicht):

• Normalisierung des Run‑Kontexts (einheitlicher Input über verschiedene Einstiegspfade)
• Feature‑relevante Harmonisierung auf Curated‑Input (Mapping/Alignment/Universe‑Filter)
• Feature Engineering (deterministisch, versioniert)
• Feature‑QA (Leakage/Distribution/Stability) und Publikation von QA‑Artefakten
• Versionierung + Publish in den Feature Store
• Lineage/Metadaten in OpenMetadata, Artefakt‑Logging in MLflow

Out of Scope (separate Schritte / Seiten):

• Ingestion (Extract/Load/Transform/Validate): Data Pipeline
• Purpose/Entitlements/Freigabe: Purpose (Gate A)
• Zentrales DQ‑Gate / Quarantine‑Pfad: Data Quality Gate
• Label Construction, Training, Backtesting, Portfolio Construction (Downstream‑Schritte der Architektur)
• Operatives Runbook, Retries/Incidents/Backfills im Detail: Failure Handling, Incident Management, Backfills

Inputs und Voraussetzungen

Voraussetzung: Freigegebenes Input‑Dataset

Die Feature Pipeline setzt voraus, dass das Input‑Dataset bereits:

• in der Internal Curated Zone verfügbar ist (aus der Ingestion),
• im Katalog (OpenMetadata) erfasst ist,
• durch Purpose (Gate A) und das DQ Gate freigegeben wurde (oder via Exception‑Pfad explizit zugelassen wurde).

Input‑Contracts

Die Pipeline arbeitet bewusst contract‑basiert. Sie „rät“ nicht, welche Daten zu verwenden sind, sondern bekommt Referenzen/IDs übergeben.

InputContract_ValidatedDataset

• dataset_id
• dataset_version
• as_of_date
• schema_version
• quality_status
• openmetadata_entity_ref

InputContract_RunContext

• run_id (Prefect Flow Run ID oder abgeleitetes Run‑Handle)
• trigger_reason (gate_pass | exception_override | iterate)
• universe_id (Referenz auf das verwendete Anlage‑Universum)
• pipeline_version (z. B. Git‑Commit/SemVer der Feature‑Pipeline)

Hinweis: as_of_date ist der Referenztag für Features (EOD‑basiert). Bei Montags‑Runs bedeutet „latest available“ typischerweise Freitag (abhängig von Handelskalender/Provider‑Verfügbarkeit).

Output

OutputContract_FeatureSetVersion

Das Feature‑Set wird als eigenständige, versionierte Entity publiziert. Der Contract ist die verbindliche Referenz für Downstream‑Schritte (Labels, Training, Scoring).

• feature_set_id (z. B. core_equity_features)
• feature_set_version (z. B. ${feature_set_id}:${as_of_date}:${pipeline_version})
• dataset_id
• dataset_version
• as_of_date
• universe_id
• run_id
• qa_status (PASS | WARN | FAIL)
• feature_manifest_uri (Definitionen/Schema/Windows als Artefakt)
• openmetadata_entity_ref (Feature‑Dataset / Table)
• mlflow_run_ref (Run‑ID oder URI)

Beispiel (JSON):

{
  "feature_set_id": "core_equity_features",
  "feature_set_version": "core_equity_features:2026-02-12:git-acde12",
  "dataset_id": "market_curated_bundle",
  "dataset_version": "2026-02-12T23:59Z",
  "as_of_date": "2026-02-12",
  "universe_id": "universe_sp500_eu_mix_v1",
  "run_id": "prefect-flow-run-3f2c8d",
  "qa_status": "PASS",
  "feature_manifest_uri": "artifacts://features/core_equity_features/2026-02-12/manifest.json",
  "openmetadata_entity_ref": {
    "service": "lakehouse",
    "database": "internal",
    "schema": "feature_store",
    "table": "core_equity_features__2026_02_12__git_acde12"
  },
  "mlflow_run_ref": "mlflow://runs/9a1f3b..."
}

OutputContract_FeatureQAReport

Der QA‑Report ist das zentrale Diagnose‑Artefakt der Feature Pipeline. Er wird unabhängig davon publiziert, ob ein Feature‑Publish stattfindet.

• run_id
• dataset_version
• as_of_date
• universe_id
• qa_status (PASS | WARN | FAIL)
• checks_summary (aggregiert: counts/threshold‑hits)
• report_uri (voller Report als Artefakt)

Beispiel (JSON):

{
  "run_id": "prefect-flow-run-3f2c8d",
  "dataset_version": "2026-02-12T23:59Z",
  "as_of_date": "2026-02-12",
  "universe_id": "universe_sp500_eu_mix_v1",
  "qa_status": "WARN",
  "checks_summary": {
    "leakage_checks": "PASS",
    "missingness_checks": "WARN",
    "distribution_checks": "PASS",
    "stability_checks": "WARN"
  },
  "report_uri": "artifacts://features/core_equity_features/2026-02-12/qa_report.json"
}

Feature Store (Versionierung & Struktur)

Der Feature Store ist die Ablage für publizierte Feature‑Versionen. Er ist so geschnitten, dass:

• eine Feature‑Version write‑once ist (kein „still ändern“ an einem veröffentlichten Stand),
• Downstream‑Jobs exakt referenzieren können, welches Feature‑Set verwendet wurde,
• Re‑Runs denselben Stand reproduzieren (bei gleicher dataset_version + pipeline_version + Parametern).

Pragmatisches Strukturprinzip (als Beispiel):

• Partition/Version über feature_set_version
• Partition zusätzlich über as_of_date und universe_id
• Feature‑Manifest (Schema + Definitionen) als Artefakt neben den Daten

Damit können Training/Backtests einen konsistenten Zeitraum aufbauen und Scoring kann „latest available“ laden, ohne Feature‑Logik neu zu implementieren.

Feature‑Logik (EOD / long‑term)

Die Pipeline ist bewusst auf langfristiges Stock‑Picking ausgelegt. Typische Feature‑Familien (Beispiele, nicht abschliessend):

Technische Features (EOD‑Preise)

• Returns/Log‑Returns über Fenster: 5d, 20d, 60d, 252d
• Volatilität (rolling std), Drawdown‑Metriken
• Momentum‑Signale (z. B. 12‑1 Momentum, Trend‑Indikatoren)
• Liquidity‑Nähe (z. B. Avg Dollar Volume, Turnover – sofern Daten vorhanden)

Fundamentale Features (Refresh wöchentlich, Werte „as‑of“)

• Bewertungsrelationen: P/E, P/B, EV/EBITDA (je nach Datenverfügbarkeit)
• Qualitäts-/Profitabilitätsmetriken: Margin‑, ROE/ROA‑nahe Kennzahlen
• Wachstum (YoY‑/QoQ‑nahe Ableitungen), Stabilitätsmetriken
• Filings‑nahe Flags/Last‑Update‑Timestamps (keine Text‑NLP nötig)

Makro/Regime Features (tägliche Updates)

• Rates/Inflation/FX‑Zeitreihen als Regime‑Kontext
• einfache Regime‑Indikatoren (z. B. Z‑Scores, Trend‑State)

Leitlinie: Feature‑Berechnung ist deterministisch und wird vollständig über as_of_date und Lookback‑Windows definiert. Die Pipeline nutzt keine Intraday‑Daten.

Feature‑QA (Leakage, Verteilungen, Stabilität)

Feature‑QA ist ein schlanker Schutzlayer, der speziell auf modellnahe Ableitungen zielt. Typische Checks:

Leakage‑Checks

• zeitliche Leakage (Features dürfen keine Information > as_of_date verwenden)
• target‑Leakage‑Heuristiken (z. B. verdächtig perfekte Korrelationen, „future joins“)

Distribution‑Checks

• Missingness‑Quoten pro Feature (Schwellenwerte)
• einfache Range‑Checks / extreme Ausreisser (nach Feature‑Definition)

Stability‑Checks

• Shift‑Indikatoren (z. B. PSI/ähnliche Summary) gegen Referenzfenster
• „Feature suddenly constant“ / „Feature explodes“ Heuristiken

Entscheidung in der Pipeline:

• PASS/WARN: Publish des Feature‑Sets ist erlaubt (mit QA‑Artefakt).
• FAIL: QA‑Report wird publiziert, es erfolgt kein Publish einer neuen Feature‑Version. Downstream bleibt auf der letzten gültigen Version.

Ablauf (BPMN‑Schritte → technische Umsetzung)

BPMN‑Element	Zweck	Output / Artefakte	Checks (pragmatisch)
StartEvent_GatePass / StartEvent_ExceptionOverride / StartEvent_Iterate	Einstieg je nach Main‑Flow (normal, Exception, Iteration)	Run‑Kontext + Dataset‑Referenzen	keine erneute Gate‑Entscheidung
Gateway_InputMerge	Vereinheitlichung der drei Einstiegspfade	ein Startpfad für die Pipeline	–
Normalize Run Context	Parameter/Context standardisieren	Normalized Run Context	Pflichtfelder vorhanden (dataset_version, as_of_date, universe_id, run_id)
Curate + Standardize	Feature‑relevante Harmonisierung auf Curated Input	Feature‑ready Input (staging)	deterministische Mappings, Universe‑Filter
Feature Engineering	Feature‑Berechnung & Materialisierung	Feature‑Matrix (staging) + Manifest‑Basis	deterministisch (Windows, Keys), konsistente Joins
Feature‑QA	Feature‑spezifische Qualitätstests	Feature QA Report + qa_status	Leakage/Distribution/Stability Heuristiken
Gateway_FeatureOk	Publish‑Entscheid auf Feature‑Ebene	OK/FAIL Pfad	qa_status
Publish Feature‑QA Report + Alert (FAIL)	Report publizieren & Team informieren	QA‑Report Artefakt	kein Feature‑Publish
Version + Publish to Feature Store (OK)	Versionieren und write‑once publizieren	Feature Set Version Contract	atomarer Publish pro Version
Update Lineage + Metadata	Lineage/Metadaten aktualisieren	OpenMetadata Update	Links auf Contract/QA
Log Dataset/Artifacts (MLflow)	Run‑Artefakte loggen	MLflow Run + Artefakte	Referenzen/URIs
Downstream Ready Signal	Handover an Main‑Prozess	„Features ready“ Signal/Status	–

OpenMetadata: Was wird aktualisiert

Die Feature Pipeline aktualisiert in OpenMetadata mindestens:

• Lineage: dataset_version (Curated) → feature_set_version (derived)
• Beschreibung/Owner/Tags der Feature‑Entity (inkl. Verweis auf Manifest und QA‑Report)
• Referenzen auf die Pipeline‑Runs (Prefect Run ID) und Artefakt‑URIs

Die Freigabe‑Logik (Purpose/DQ) liegt nicht hier, sondern upstream:

• Purpose (Gate A)
• Data Quality Gate

MLflow: Was wird geloggt

Damit Downstream‑Schritte (Training/Backtesting) sauber referenzieren können, werden im MLflow‑Run typischerweise geloggt:

• dataset_id, dataset_version, as_of_date, universe_id
• feature_set_id, feature_set_version, qa_status
• Artefakte: feature_manifest.json, qa_report.json (und ggf. Summaries)

Betriebsaspekte (kurz)

• Idempotenz: Ein Re‑Run mit gleichen Parametern erzeugt dieselbe feature_set_version.
• Backfills: Werden bewusst als mode: backfill gefahren (siehe Backfills).
• Failures: QA‑Fail stoppt den Publish, aber liefert Diagnose‑Artefakte; operative Behandlung über Failure Handling / Incident Management.

BPMN‑Detailansicht

Diagramm wird geladen …

⋮⋮⋮

Glossar‑Begriffe

• Data Pipeline – orchestrierte Verarbeitungskette von Ingestion bis publiziertem Output
• Feature – reproduzierbar berechnete Eingangsvariable für Modelle
• Feature Store – versionierte Ablage publizierter Feature-Sets
• DQ – Data Quality inklusive Regeln, Schwellen und Entscheidungslogik
• Lineage – nachvollziehbare Herkunft und Transformation
• OpenMetadata – Katalog für Metadaten, Owner, Purpose und Lineage
• Prefect – Orchestrierungsplattform für Flows und Run-State-Management
• MLflow – Tracking von Runs und Artefakten
• Output Contract – versioniertes Übergabe-Artefakt zwischen Prozessschritten

BPMN-Kontext

• Main BPMN: Gesamtarchitektur
• Call Activity (Main): CallActivity_FeaturePipeline – „Feature Pipeline“
• Detail‑BPMN (Process): Process_FeaturePipeline
• BPMN‑IDs (Einstiege): StartEvent_GatePass, StartEvent_ExceptionOverride, StartEvent_Iterate
• BPMN‑IDs (Ablauf): Gateway_InputMerge → ServiceTask_NormalizeContext → ServiceTask_CurateStandardize → ServiceTask_FeatureEngineering → ServiceTask_FeatureQA → Gateway_QADecision → ServiceTask_VersionPublish → ServiceTask_UpdateMetadata → ServiceTask_LogArtifacts → EndEvent_DownstreamReady
• Input‑Bezug: Die Pipeline nutzt DataStoreRef_ValidatedDataset plus DataObjectRef_RunContext als verbindliche Inputs und startet erst nach Gate‑Pass/Override/Iteration.
• Entscheidungsbezug: Gateway_QADecision steuert den Pfad PASS|WARN (Publish erlaubt) versus FAIL (kein Publish, QA‑Report als Evidenz).
• Output‑Bezug: Bei erfolgreichem Pfad entstehen DataStoreRef_FeatureStoreVersioned, DataStoreRef_OpenMetadataCatalog, DataStoreRef_MLflowTracking und das Handover „Features Ready“ in den Main‑Prozess.