Test de convoyeurs de données

1) Pourquoi tester les convoyeurs de données

• Validité (correctness) et stabilité (resilience).
• Prévisibilité des changements (schema/évolution logique).
• Respect de SLO par la fraîcheur, l'exhaustivité, la latence.
• Sortie rapide (vitesse de sortie) grâce à une vérification automatisée.

2) Pyramide de test de données

De bas en haut : beaucoup de tests locaux rapides → moins d'intégrations → un peu de bout en bout.

1. Tests unitaires de transformation (fonctions, UDF, vues SQL, modèles dbt).
2. Les tests de la qualité des données (les règles свежести/полноты/уникальности/диапазонов).
3. Contrats et schémas (tests schema/contract, evolution).
4. Tests d'intégration de pipline (DAG : ingest ↔ storage ↔ bou ↔ marts).
5. Tests E2E (de la source à la vitrine/API), y compris les droits (RLS/CLS) et l'exportation.
6. Charge/performance (volume, vitesse, cost-to-serve).
7. Tests de données chaos (retards, doublons, out-of-order, indisponibilité).

3) Types de tests : exactement ce que nous vérifions

3. 1 Tests unitaires de logique

Fonctions pures de transformation ; property-based (invariants : idempotence, monotonie).
SQL/DBT : comparaison du résultat avec la référence (golden set), interdiction de 'SELECT', vérification temporelle du filtre.

3. 2 Tests de qualité des données (DQ)

Fraîcheur : retarder les vitrines ≤ le seuil cible.
Exhaustivité : nombre attendu/proportion d'occupation.
Unicité : clés sans doublons.
Règles de domaine : fourchettes, intégrité référentielle, invariants commerciaux.
Anomalies : outliers, éclats de doublons, discontinuités de temps.

3. 3 Contrats et régimes

Compatibilité des modifications (BouVer : MAJOR/MINEUR/PATCH).
Avoir des colonnes obligatoires, des types, des restrictions.
Sémantiques KPI fixes : formules et fenêtres d'agrégation.

3. 4 Intégration et E2E

Intégrité DAG : déclencheurs, dépendances, répétition idempotent.
Chemin complet : source → raw → curated → marts → BI/API ; RLS/CLS.

3. 5 Performances et coûts

p95/p99 latence job, throughput (rows/s), volume/coût.
Tests de régression des performances et limites de balayage.

3. 6 Sécurité et vie privée

Masquage PII/PCI (Tokenisation déterministe).
Vérification RLS/CLS : les utilisateurs ne voient que le leur.
Exportation/démolition : pas de champs personnels « crus ».

4) Spécificité du streaming (Kafka/Flink/Spark Structured Streaming)

Watermarks et lateness : tests de fenêtres avec événements tardifs (T + Δ), recalculations correctes.
Exactly-once au sens : dédup par 'event _ id', entrée idempotent (upsert/merge).
Out-of-order : invariants par agrégats par 'event _ time' ; on fixe 'ingested _ at'.
Perte/répétition : simulons le drop/reigre des lots, vérifient l'exactitude des vitrines.

5) Idempotence et déterminisme (quoi et comment tester)

Redémarrer l'étape donne le même résultat (avec les mêmes paramètres de fenêtre).
L'enregistrement est via staging et swap atomique.
La logique merge est SCD1/SCD2 couverte de tests de conflit (last-write-wins, source priority).
Déterminisme UDF/agrégats : entrées identiques → sorties identiques.

6) Gestion des données de test

Datasets d'or : petites références avec validation manuelle.
Synthétique + Data Factory : couverture des bords du domaine (nulls, extreme values, Unicode, TZ).
De-identified prod-samples : conformité à la vie privée.
Fictions en couches : événements bruts, couches intermédiaires, vitrines finales.

7) Contrats de données : exemple et règles

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) Observation et tests SLO

Métriques d'exportation : Freshness, Completeness, Uniqueness, Latinity à Grafana/Prometheus.
SLO-alertes en tant que tests unitaires « rouges » dans la vente (Synthetics).
Retour de régression : « Après la sortie de X p95 ↑ de 40 % ».

9) CI/CD et environnements

CI : unit + DQ + contrats PR ; schema-diff; analyse statique SQL (linter).
Sandbox/staging : course d'intégration et e2e, tests de chaos avec des données sécurisées.
Feature-flags : jobs/modèles/formules canaries.
Catalogage : version des schémas, formules KPI, lineage ; mise à jour automatique de la documentation.

10) Tests de données chaos (Chaos-Data)

Injection de doublons/sauts, retards, out-of-order.
Chute du courtier/lot, fichiers « battus », schema drift.
Nous validons : auto-réparation (replay/backfill), quarantine et alertie, MTTR-data.

11) Charge et coût

Générateurs de trafic avec profil p95/pics.
Limites par scan/pas (bytes scanned, time caps).
A/B profileur de valeur : « ancien » vs « nouveau » modèle/requête.

12) Outils (classes exemplaires)

DQ/Contrats : dbt tests, Grandes expositions, Deequa, Soda, linters personnalisés.
Orchestration : Airflow/Dagster/Argo/Prefect (opérateurs pour les tests à chaque étape).
Plates-formes : BigQuery/Snowflake/Redshift/ClickHouse/Delta/Iceberg/Hudi.
Streaming : Kafka, Flink, Spark Streaming ; TestsContainers pour les environnements locaux.
Observability: Prometheus/Grafana/Otel; catalogues DataHub/Amundsen/Collibra.

13) Anti-modèles

« Il n'y a rien à tester - c'est juste SQL » : il n'y a pas d'unités et DQ → les métriques se brisent.
Seulement le E2E : lentement, instable, les causes des pannes ne sont pas claires.
SELECT : se brise en évolution MINOR.
Lecture en direct OLTP dans les tests : instabilité et flocons.
Absence de kits golden : Rien à comparer les résultats.
Pas de tests d'idempotence : redémarrer gâche les données.
Le streaming oublié : pas de test de lateness/out-of-order/refonte.

14) Feuille de route pour la mise en œuvre

1. Base : tests unitaires de transformation, jeux golden, linter SQL, règles DQ de top-10 vitrines.
2. Contrats : schema-diff en CI, BouVer, contrôles de compatibilité automatiques.
3. Intégrations : Tests DAG, idempotency, e2e pour les flux critiques.
4. Streaming : tests watermarks/lateness, dedup/idempotent.
5. SLO et chaos : métriques de qualité dans la vente, alertes, scénarios de chaos, objectifs MTR.
6. Optimisation : régressions perf, garde du budget, sorties canaries.

15) Chèque-liste avant la sortie

• Les tests unitaires couvrent les transformations clés et l'UDF.
• DQ-gouvernait pour свежести/полноты/уникальности/диапазонов passent.
• Les contrats et les schémas sont verts ; Il n'y a pas de changement sans appel.
• L'idempotence a été testée ; le sink atomique/merge fonctionne.
• Streaming : watermarks/late data/out-of-order sont couverts ; dedup sur place.
• Les métriques SLO sont exposées ; Les alerts sont configurés ; les runbooks sont là.
• Les données de test sont sécurisées ; Les PII sont masqués ; RLS/CLS sont vérifiés.
• Il n'y a pas de régression perf ; les limites de temps/balayage ont été respectées.
• Les tests de chaos des scénarios de base sont passés ; MTTR cible est réalisable.

16) Exemples de mini-modèles

16. 1 Test unitaire SQL (pseudo-dbt) :

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

16. 2 Règle de fraîcheur :

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 Vérification de lateness dans la bande (pseudo-code) :

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) Résultat

Le test des pipelines de données est une discipline du système, pas un ensemble de vérifications disparates. Connectez la pyramide de tests, les contrats et l'observabilité aux pratiques de l'idempotence, de l'évolution des circuits et des invariants en streaming. Les sorties deviendront alors rapides, les incidents rares et courts et la confiance dans les données durable.