Ingestion (Data Pipeline: ELT + Validierung)

Kurzzusammenfassung

Diese Seite beschreibt die Ingestion von externen Marktdaten und öffentlichen Unternehmensdaten in die ML‑Plattform (Investment Management / Stock Picking): kontrolliert, nachvollziehbar und reproduzierbar.
Der Fokus liegt auf technischer Harmonisierung und Validierung (Schema/Typen/DQ‑Checks) – kein Feature‑Engineering.
Merksatz: Data Pipeline „T“ = technische Harmonisierung, Feature Pipeline „T“ = modellnahe Ableitung/Features.
Ergebnis ist ein validated curated dataset in der Internal Data Zone (siehe Warehouse) plus ein Output‑Contract (Run‑Metadaten, Versionierung, Quality‑Status). Beides wird in OpenMetadata katalogisiert und im Hauptprozess über Gate A und das DQ‑Gate freigegeben.
BPMN‑Leitpfad (Detail): Ingestion Triggered → Extract (ELT) → Load to Raw Data Lake → Transform to Internal Curated Format → Data Validation → Pipeline Complete.

Einordnung: Diese Detailansicht gehört zum Call‑Activity‑Knoten Datapipeline (ELT + Validierung) in der Gesamtarchitektur.

Ziel

Verlässliche Datengrundlage für Training, Backtests und Portfolio Construction (Upstream‑Step für den ML‑Lifecycle).
Nachvollziehbarkeit und Governance: Lizenzen/Entitlements, Zugriffskontrollen, Data Separation, Lineage und Run‑Historie.
Standardisierte Schnittstelle für Downstream‑Pipelines (Feature Pipeline, Label Construction, Training): klarer Contract, Versionierung, Quality‑Status.

Scope & Abgrenzung

In Scope (diese Seite / BPMN‑Detailansicht):

Controlled acquisition aus externen Datenprovidern (Allowlist + Vault/IAM)
Landing in Raw Data Lake (append‑only, unverändert)
Technische Harmonisierung in ein kuratiertes Format (Curated, domänenneutral)
Validierung (Konformität + Datenqualität) und Erzeugung eines Validated Curated Dataset Contracts
Publikation der Metadaten inkl. Lineage in OpenMetadata

Out of Scope (separate BPMN‑Schritte / Seiten):

Purpose + Entitlement Check (Gate A) (Use‑Case‑Freigabe, Allowed Use, Owner/Steward)
Data Quality Gate (Regeln) als Go/No‑Go‑Entscheidung und Quarantine‑Pfad
Feature Engineering, Label Construction, Model Training, Backtesting, Portfolio Construction

Quelltypen und Ingestion‑Frequenz (Investment Management)

Das Modell ist langfristig ausgelegt; die Ingestion ist entsprechend auf tägliche bzw. wöchentliche Läufe optimiert (keine minütlichen Abfragen).

Quelltyp	Beispiele	Primäre Quellen/APIs	Frequenz
Preise (EOD)	Daily OHLCV, Adjusted Close, Volumen	Financial Modeling Prep (FMP) API	täglich (nach Börsenschluss)
Corporate Actions	Dividenden, Splits, Symbol‑Changes	FMP API	täglich (Abgleich/Updates)
Fundamentals	Financial Statements, Key Metrics, Ratios, ggf. Estimates	FMP API	wöchentlich (Refresh) + implizit quartalsweise durch neue Reports
Filings / Reports	10‑K, 10‑Q, 8‑K (Publikationsereignisse)	SEC EDGAR API (plus optional FMP als Ergänzung)	täglich oder wöchentlich (Abgleich neuer Filings; Backfill nach Bedarf)
Macro / Rates	CPI, Zinsen, Yield‑Kurven, FX‑Indikatoren	FRED API (plus optional FMP Macro Endpoints)	täglich (gemäss Release‑Zyklus der Serien)

Hinweis: Keine Client‑Daten. Die Ingestion ist auf Markt‑/Makro‑Daten sowie öffentliche Unternehmensinformationen begrenzt.

Technische Metadaten pro Ingestion‑Run

Jeder Run erzeugt technische Metadaten (Teil des Output‑Contracts und als Run‑Artefakte), um Runs, Datasets und DQ‑Ergebnisse eindeutig referenzieren zu können:

run_id (Referenz auf Orchestrator‑Run; z. B. Prefect Flow Run ID)
pipeline_id / pipeline_version (z. B. Git‑Commit oder SemVer)
provider / source_system und dataset_id
as_of_date und (falls verwendet) extraction_window
ingestion_started_at, ingestion_finished_at, status, error_class
schema_version, schema_hash
row_count, zusammengefasste DQ‑Statistiken (z. B. Missing‑Rates/Outlier‑Counts)
quality_status (PASS/WARN/FAIL) plus Referenz zum DQ‑Report
lineage_ref (OpenMetadata Entity IDs / Lineage Edges)

Output: Validated Curated Dataset Contract

Der Validated Curated Dataset Contract ist das Übergabe‑Artefakt an Downstream‑Pipelines und enthält die Felder, die für Versionierung, Status und Verlinkung zu Metadaten/Reports benötigt werden:

dataset_id
dataset_version
as_of_date
run_id
pipeline_version
provider
schema_version
schema_hash
quality_status
row_count
content_hash
dq_report_uri
openmetadata_entity_ref
allowed_use
classification
retention_policy

Beispiel (JSON):

{
  "dataset_id": "market_prices_eod",
  "dataset_version": "2026-02-12",
  "as_of_date": "2026-02-12",
  "run_id": "prefect-flow-run-3f2c8d",
  "pipeline_version": "git:8c1a2f7",
  "provider": "fmp",
  "schema_version": "v3",
  "schema_hash": "sha256:…",
  "quality_status": "PASS",
  "row_count": 18234567,
  "content_hash": "sha256:…",
  "dq_report_uri": "evidence://dq/market_prices_eod/2026-02-12/run-3f2c8d.json",
  "openmetadata_entity_ref": {
    "service": "lakehouse",
    "database": "market",
    "schema": "curated",
    "table": "market_prices_eod"
  },
  "allowed_use": "research_and_modeling",
  "classification": "internal",
  "retention_policy": "standard"
}

OpenMetadata: minimaler Katalog‑Standard

Damit Gate A und das DQ‑Gate sauber arbeiten können, werden pro Entity mindestens folgende Felder gesetzt:

Entity	Pflichtfelder (Minimum)	Warum relevant
Raw Dataset (Raw Data Lake)	`name`, `service`, `databaseSchema`, `columns[]`, `description`, `owner`, `tags.classification`, `retention_policy`	Landing nachvollziehbar dokumentiert
Curated Dataset (Internal Zone)	wie Raw + `allowed_use`, `dq_status`, `lineage`	Downstream‑Nutzung + Status sichtbar
Pipeline (Prefect Flow)	`name`, `service`, `tasks`, `schedule`, `owner`, `upstream_entities[]`, `downstream_entities[]`	Lineage und Betriebskontext
DQ Report / Tests	`dq_suite_version`, `checks[]`, `results_summary`, `quality_status`	Gate‑Entscheidung und Diagnose

Push vs. Pull (Implementierungsprinzip)

Push‑Pattern: Die Prefect‑Pipeline publiziert Run‑Status, DQ‑Summary und Lineage‑Infos direkt nach dem Run (inkl. run_id und dq_report_uri).
Pull‑Pattern: Periodische Jobs synchronisieren Basismetadata aus Storage/Warehouse‑Strukturen (hilfreich bei Backfills oder wenn einzelne Runs Metadaten nicht pushen konnten).

Ablauf (BPMN‑Schritte → technische Umsetzung)

BPMN‑Element	Zweck	Output / Artefakte	Checks / Hinweise
StartEvent_DataPipeline – Ingestion Triggered	Start via Schedule / New Data / Backfill	Run‑Context (`run_id`), Parameter (`as_of_date`, optional Window)	deterministische Parameter; Wiederholbarkeit über `as_of_date`
ServiceTask_Extract – Extract (ELT)	Datenabruf vom Provider, inkl. Credential‑Handling	Raw Payload (staging), Source‑Manifest (Quelle, Zeitfenster)	Allowlist, Credentials via Vault/IAM, Retry/Backoff
ServiceTask_Load – Load to Raw Data Lake	Rohdaten unverändert persistieren	Append‑only Raw Dataset + Ingestion‑Metadata	klare Partitionierung (z. B. `as_of_date`), Checksums/Hashes
ServiceTask_Transform – Transform to Internal Curated Format	Technische Harmonisierung (Typen, Keys, Zeitzonen, Einheiten)	Curated Candidate Dataset (staging)	deterministische Transform‑Regeln; Mapping versioniert
ServiceTask_Validate – Data Validation	Konformität + DQ‑Suite ausführen, Status stempeln	DQ‑Report + Validated Curated Dataset Contract + Write in Internal Zone	Schema‑Checks, Missing‑/Duplikat‑/Range‑Checks; Report als Artefakt speichern
EndEvent_DataPipeline – Pipeline Complete	Run abschliessen	Finaler Status + Links zu Artefakten	bei Fail: Quarantine/Incident über Hauptprozess

Was passiert nach der Detail‑Pipeline?

Die Detail‑Pipeline liefert Daten + Run‑Artefakte. Die Freigabe für Downstream‑Nutzung erfolgt im Hauptprozess über:

Bei Fail wird der Datensatz in Quarantine überführt und ein Incident / Ticket erstellt.

Kontrollen

Praktische Leitlinien

Secrets liegen nicht im Code: Zugriff auf Provider‑APIs ausschliesslich über Vault/IAM.
Raw und Curated sind getrennt: Raw bleibt unverändert; Curated ist die harmonisierte Basis für Downstream‑Pipelines.
Jede Ausgabe ist versioniert: dataset_version/as_of_date sind durchgängig (Partitionierung, Contract, Metadaten).
DQ‑Ergebnisse sind greifbar: DQ‑Report wird pro Run gespeichert und im Contract referenziert.
Lineage ist sichtbar: Upstream/Downstream‑Bezüge werden in OpenMetadata gepflegt.

Messbare Akzeptanzkriterien (Beispiele)

Kriterium	Erwartung	Verantwortlich	Reaktion
EOD‑Dataset verfügbar	täglich nach dem geplanten Lauf	Data Engineering	Retry/Backfill, Ticket bei wiederholtem Fail
Validierungs‑Fehlläufe	seltene Ausnahmen, nicht die Regel	Data Engineering	Analyse anhand DQ‑Report, Quarantine‑Pfad
Schema‑Änderungen	nur kontrolliert (Schema‑Versioning)	Data Owner + Data Engineering	Anpassung Mapping/Schema + erneute Validierung
Metadaten/Lineage	Datasets sind in OpenMetadata auffindbar	Platform Team	Fix der Metadata‑Publikation

Entscheidung (Publishable vs. Quarantine)

Ein Run gilt als publishable, wenn:

quality_status ∈ {PASS, WARN} und ein DQ‑Report referenziert ist,
das Dataset in der Internal Zone konsistent versioniert/partitioniert ist,
die OpenMetadata‑Referenz (openmetadata_entity_ref) gesetzt ist.

Ein Run wird nicht promoted (Quarantine/Incident), wenn:

quality_status = FAIL,
ein Breaking Schema Change ohne Versionierung/Update‑Pfad auftritt,
eine Policy‑Verletzung festgestellt wird (z. B. falsche Klassifikation/Allowed Use).

BPMN‑Detailansicht

Hier wird die BPMN‑Detailansicht „Datapipeline (ELT + Validierung) – Detail“ eingebettet (Datei z. B. site/static/bpmn/data-pipeline.bpmn, Definitions_DataPipeline).

⋮⋮⋮

Glossar‑Begriffe

Data Pipeline – technische Ingestion/Harmonisierung/Validierung (diese Seite)
DQ – Datenqualitätsmessung & Gate‑Entscheidung
OpenMetadata – zentraler Katalog für Owner/Purpose/Lineage/DQ‑Status
Quarantine – isolierte Zone für Fail‑Runs
Prefect – Orchestrierung der Pipeline
MLflow – Experiment‑/Artefakt‑Tracking (Downstream)

BPMN‑Kontext

Main BPMN (Call Activity): CallActivity_DataPipeline – „Datapipeline (ELT + Validierung)“
Detail‑BPMN (Process): Process_DataPipeline_Detail
Detail‑Tasks: ServiceTask_Extract, ServiceTask_Load, ServiceTask_Transform, ServiceTask_Validate
Daten‑Artefakte: DataStoreRef_Raw (Raw Data Lake), DataStoreRef_Internal (Internal Data Zone), DataObject_OutputContract_ValidatedCuratedDataset (Output‑Contract)
Message Flows: MessageFlow_DataRequest, MessageFlow_DataPayload, MessageFlow_GetCredentials, MessageFlow_CredentialToken

Kurzzusammenfassung​

Ziel​

Scope & Abgrenzung​

Quelltypen und Ingestion‑Frequenz (Investment Management)​

Technische Metadaten pro Ingestion‑Run​

Output: Validated Curated Dataset Contract​

OpenMetadata: minimaler Katalog‑Standard​

Push vs. Pull (Implementierungsprinzip)​

Ablauf (BPMN‑Schritte → technische Umsetzung)​

Was passiert nach der Detail‑Pipeline?​

Kontrollen​

Praktische Leitlinien​

Messbare Akzeptanzkriterien (Beispiele)​

Entscheidung (Publishable vs. Quarantine)​

BPMN‑Detailansicht​

Glossar‑Begriffe​

BPMN‑Kontext​