Testen von Datenpipelines

1) Warum Datenpipelines testen

• Zuverlässigkeit (Korrektheit) und Stabilität (Resilienz).
• Vorhersagbarkeit von Änderungen (schema/logic evolution).
• Einhaltung der SLO in Frische, Fülle, Latenz.
• Schnelle Freigabe (Freigabegeschwindigkeit) durch automatisierte Validierung.

2) Datenprüfungspyramide

Bottom-up: Viele lokale Schnelltests → weniger Integrations- → ein bisschen End-to-End.

1. Unit-Tests von Transformationen (Funktionen, UDFs, SQL-Ansichten, dbt-Modelle).
2. Die Prüfungen der Qualität der Daten (die Regel sweschesti/polnoty/unikalnosti/diapasonow).
3. Verträge und Schemata (Schema/Vertragstests, Evolution).

4. Integrationstests von Pipelines (DAG: ingest ↔ storage ↔ transform ↔ marts)

5. E2E-Tests (von der Quelle bis zum Showcase/API) inklusive Rechte (RLS/CLS) und Export.
6. Last/Leistung (Volumen, Geschwindigkeit, Cost-to-Serve).
7. Datenchaos-Tests (Latenzen, Duplikate, Out-of-Order, Nichtverfügbarkeit).

3) Arten von Tests: was genau wir überprüfen

3. 1 Unit-Tests der Logik

Reine Transformationsfunktionen; property-based (Invarianten: Idempotenz, Monotonie).
SQL/DBT: Vergleich des Ergebnisses mit der Referenz (goldener Satz), Verbot 'SELECT', Überprüfung des Filters nach Zeit.

3. 2 Datenqualitätstests (DQ)

Frische: Verzögerung der Vitrinen ≤ der Zielschwelle.
Vollständigkeit: erwartete Menge/Anteil der Belegung.
Einzigartig: Schlüssel ohne Duplikate.
Domänenregeln: Bereiche, referenzielle Integrität, Geschäftsinvarianten.
Anomalien: Ausreißer, Ausbrüche von Duplikaten, Zeitlücken.

3. 3 Verträge und Regelungen

Kompatibilität der Änderungen (SemVer: MAJOR/MINOR/PATCH).
Das Vorhandensein von obligatorischen Spalten, Typen, Einschränkungen.
Festgeschriebene KPI-Semantik: Formeln und Aggregationsfenster.

3. 4 Integration und E2E

DAG-Integrität: Auslöser, Abhängigkeiten, idempotente Wiederholung.
Vollständiger Pfad: Quelle → raw → curated → marts → BI/API; RLS/CLS.

3. 5 Leistung und Kosten

p95/p99 Joblatenz, Durchlauf (Zeilen/s), Volumen/Kosten.
Leistungs-Regressionstests und Scanlimits.

3. 6 Sicherheit und Privatsphäre

PII/PCI-Maskierung (deterministische Tokenisierung).
RLS/CLS-Validierung: Benutzer sehen nur ihre eigenen.
Export/Snepshots: keine „rohen“ persönlichen Felder.

4) Besonderheiten des Streamings (Kafka/Flink/Spark Structured Streaming)

Wasserzeichen und Latenz: Zeitfenstertests mit verspäteten Ereignissen (T + Δ), korrekte Neuberechnungen.
Exactly-once im Sinne von: dedup by 'event _ id', idempotent record (upsert/merge).
Out-of-order: Invarianten zu Aggregaten durch 'event _ time'; Wir fixieren 'ingested _ at'.
Verlust/Wiederholung: Wir simulieren den Drop/Retro der Parties, überprüfen die Richtigkeit der Vitrinen.

5) Idempotenz und Determinismus (was und wie zu testen)

Ein erneuter Start des Schrittes ergibt das gleiche Ergebnis (bei gleichen Fensterparametern).
Die Aufnahme erfolgt über Staging und Atomic Swap.
Die Merge-Logik mit SCD1/SCD2 wird durch Konflikttests (last-write-wins, Quellenpriorität) abgedeckt.
Determinität von UDF/Aggregaten: gleiche Eingänge → gleiche Ausgänge.

6) Testdatenmanagement

Golden Datasets: Kleine Benchmarks mit manueller Validierung.
Synthetik + Datenfabriken: Abdeckung der Domänenränder (Nulls, Extremwerte, Unicode, TZ).
De-identifizierte Prod-Samples: Datenschutz-Compliance.
Geschichtete Fixturen: Rohveranstaltungen, Zwischenschichten, abschließende Vitrinen.

7) Datenverträge: Beispiel und Regeln

yaml dataset: orders schema:
- name: order_id; type: string; unique: true
- name: user_id; type: string; not_null: true
- name: amount; type: decimal(18,2); min: 0
- name: event_time; type: timestamp; tz: UTC freshness_sla: 10m dq_rules:
- "pct_null(user_id) < 0. 1%"
- "duplicates(order_id) = 0"
- "sum(amount) >= 0"
evolution:
allowed_minor_additions: true breaking_changes_require: approval: 'data-governance'
actions_on_violation:
- quarantine_partition
- replay_last_60m

8) Beobachtbarkeit und SLO-Tests

Export von Metriken: Frische, Vollständigkeit, Uniqueness, Latenz nach Grafana/Prometheus.
SLO-Alerts als „rote“ Unit-Tests in der Produktion (Synthetik).
Regressionsberichte: „nach der Veröffentlichung von X p95 ↑ 40%“.

9) CI/CD und Medien

CI: Einheit + DQ + PR-Verträge; schema-diff; statische SQL-Analyse (Linter).
Sandbox/Staging: Run auf Integrationen und e2e, Chaos-Tests mit sicheren Daten.
Feature-flags: Kanarienjobs/Modelle/Formeln.
Katalogisierung: Version von Schemata, KPI-Formeln, Lineage; automatische Aktualisierung der Dokumentation.

10) Chaos-Datentest (Chaos-Data)

Injektion von Duplikaten/Lücken, Verzögerungen, Out-of-Order.
Der Fall des Maklers/der Partei, „zerbrochene“ Dateien, Schema drift.
Wir validieren: Auto-Reparatur (Replay/Backfill), Quarantine und Alerts, MTTR-Daten.

11) Belastung und Kosten

Verkehrserzeuger mit p95/peak Profil.
Scan-/Schrittlimits (Bytes gescannt, Zeitkappen).
A/B Value Profiler: „altes“ vs „neues“ Modell/Anfrage.

12) Werkzeuge (Beispielklassen)

DQ/Verträge: dbt tests, Great Expectations, Deequ, Soda, Custom linters.
Orchestrierung: Airflow/Dagster/Argo/Prefect (Operatoren für Tests in jedem Schritt).
Plattformen: BigQuery/Snowflake/Redshift/ClickHouse/Delta/Iceberg/Hudi.
Streaming: Kafka, Flink, Spark Streaming; TestContainer für lokale Umgebungen.
Observability: Prometheus/Grafana/Otel; DataHub/Amundsen/Collibra Verzeichnisse.

13) Antipatterns

„Es gibt nichts zu testen - es ist nur SQL“: Es gibt keine Einheiten und DQs brechen → Metriken.
Nur E2E: langsam, instabil, die Ursachen der Pannen sind nicht klar.
SELECT: bricht bei MINOR-Evolution.
Live-Lesung von OLTP in Tests: Instabilität und Flakes.
Keine Golden Sets: Nichts, um die Ergebnisse zu vergleichen.
Keine Idempotenztests: Ein Neustart verdirbt die Daten.
Vergessenes Streaming: Latenz/Out-of-Order/Nachlieferung wird nicht getestet.

14) Fahrplan für die Umsetzung

1. Basis: Unit-Tests der Transformationen, Golden-Sets, SQL-Linter, DQ-Regeln der Top-10-Vitrinen.
2. Verträge: schema-diff in CI, SemVer, automatische Kompatibilitätsprüfungen.
3. Integrationen: DAG-Tests, idempotency, e2e für kritische Threads.
4. Streaming: Wasserzeichen Tests/Latenz, dedup/idempotent sinks.
5. SLO und Chaos: Qualitätsmetriken in der Produktion, Alerts, Chaos-Szenarien, MTTR-Ziele.
6. Optimierung: Perf-Regressionen, Budget-Wachen, kanarische Releases.

15) Checkliste vor Veröffentlichung

• Unit-Tests decken wichtige Transformationen und UDFs ab.
• DQ-lenkte für sweschesti/polnoty/unikalnosti/diapasonow gehen.
• Verträge und schema-diff grün; Ohne Appruv gibt es keine brechenden Veränderungen.
• Idempotenz geprüft; atomic sink/merge funktioniert.
• Streaming: watermarks/late data/out-of-order abgedeckt; dedup vor Ort.
• SLO-Metriken werden belichtet; Alerts konfiguriert sind; Die Runbooks sind da.
• Die Testdaten sind sicher; PII sind maskiert; RLS/CLS geprüft.
• Es gibt keine Perf-Regressionen; Scan-/Zeitlimits eingehalten werden.
• Die Chaos-Tests der Basisszenarien sind bestanden; Das MTTR-Ziel ist erreichbar.

16) Beispiele für Mini-Vorlagen

16. 1 SQL Unit Test (Pseudo-dbt):

sql
-- tests/assert_positive_amount. sql select count() as c from {{ ref('fct_payments') }}
where amount < 0 having c = 0

16. 2 Regel der Frische (Great Expectations-Stil):

yaml expect_table_row_count_to_be_between:
min_value: 1000 mostly: 0. 99 expect_column_values_to_not_be_null:
column: user_id expect_column_values_to_be_unique:
column: txn_id

16. 3 Überprüfung der Latenz im Stream (Pseudocode):

python emit(events_out_of_window <= threshold)
emit(reprocessed_events == late_events_detected)

16. 4 Contract-test (schema-diff CI):

bash schema-diff --current models/orders. yml --target prod_schema. yml --semver

17) Das Ergebnis

Das Testen von Datenpipelines ist eine Systemdisziplin und keine Sammlung von disparaten Prüfungen. Verbinden Sie die Testpyramide, Verträge und Beobachtbarkeit mit Praktiken der Idempotenz, der Entwicklung von Schemata und Streaming-Invarianten. Dann werden die Releases schnell, die Vorfälle selten und kurz und das Vertrauen in die Daten nachhaltig.