📦 Data Engineer

1.1 Data Engineer — rôle, responsabilités, KPI, maturité

Mission (version “réalité prod”)

Rendre les données utilisables : fiables, documentées, accessibles, au bon coût.
Réduire le “time-to-data” : du signal brut → table/feature exploitable rapidement.
Garantir la confiance : qualité, tests, contrats, traçabilité, audit.
Industrialiser : code, CI/CD, observabilité, runbooks, gestion d’incidents.
Optimiser : performance (IO/compute), coûts (stockage, requêtes, streaming).

Livrables attendus

Livrable	Concret	Pourquoi
Pipelines	Jobs batch/stream, incrémental, backfills.	Data fraîche.
Modèle analytique	Staging → marts → semantic/metrics.	BI/ML stable.
Qualité	Tests, contracts, alerting, RCA.	Confiance.
Doc	Catalog, lineage, owners, SLA.	Autonomie.
Gouvernance	RBAC, PII, retention.	Risque ↓

Le modèle mental : “data supply chain”

Sources -> Ingestion -> (Bronze) -> (Silver) -> (Gold) -> Serving | | | | | CDC/APIs Orchestration Cleaning Modeling BI/ML/Apps \------------------- Observability & Quality ------------------/

ETL vs ELT (très simplement)

ETL : transformer avant d’écrire dans le DWH (plus “ancien” / on-prem).
ELT : charger d’abord puis transformer dans le DWH (cloud moderne, dbt).
Dans les faits : on mixe selon sources/volumes/latence.

Interfaces avec les autres métiers

Data Analyst : besoins métriques + sémantique + refresh + granularité.
ML Engineer / DS : features, training/serving parity, drift, labels.
Platform/DevOps : IAM, infra, observabilité, coûts, SRE.
Security/Legal : PII, RGPD, retention, audit.

KPI “data” (ceux qui comptent)

KPI	Définition	Pourquoi
Freshness	Âge de la donnée vs SLA.	Décisions à temps.
Completeness	% lignes attendues reçues.	Pas de trous.
Accuracy	Règles de cohérence (ex: totaux).	Confiance.
Timeliness	Durée pipeline / latence.	UX produit data.
Reliability	Fail rate, retry storms.	Stabilité.
Cost/Query	Coût par requête/table.	FinOps.

SLO data (exemple)

Table: fact_orders (Gold) - Freshness: < 30 min (P95) - Completeness: >= 99.8% daily - Validity: null_rate(order_id) = 0 - Uniqueness: order_id unique - Availability: 99.9% (read) Owner: Data Platform

Incident data (mode opératoire)

Étape	Action	Livrable
1	Qualifier impact (tables/produits).	Scope + priorité.
2	Stopper l’hémorragie (pause, fallback).	Mitigation.
3	Diagnostiquer (logs + lineage).	Cause probable.
4	Fix + backfill contrôlé.	Data restaurée.
5	RCA + actions préventives.	Runbook + tests.

Dette data typique

Jobs “script” sans idempotence → doublons.
Pas de contrats → breaking changes silencieux.
“SELECT *” partout → explosion schéma.
Pas de partitioning/clustering → coûts x10.

Le paradigme Senior (data)

Un senior ne “fait pas un job” : il construit un système fiable avec garanties.
Il pense contrats, observabilité, coûts, backfills, évolution.
Il conçoit une plateforme où l’analyste/DS devient autonome.
Il réduit la charge on-call avec tests + automation + runbooks.

Règle d’or : “Les données cassent tout le temps.” Donc : détecter vite, isoler, restaurer, prévenir.

Échelle de maturité (L1→L5)

L1 : scripts ponctuels, pas de tests, pas de logs.
L2 : orchestration basique, retries, doc minimal.
L3 : incrémental, idempotence, tests & alerting.
L4 : contracts, lineage, CI/CD, finops, gouvernance.
L5 : plateforme (self-serve), SLO data, stratégie lakehouse.

Le “senior checklist” avant prod

- Idempotent ? (re-run safe) - Incrémental ? (watermark / CDC) - Backfill plan ? (range, costs) - Data contracts ? (schema expectations) - Tests ? (schema + business rules) - Observability ? (freshness, volume, error) - Ownership ? (owner, on-call, runbook) - Cost guardrails ? (partitioning, limits) - Security ? (PII, access, audit)

Différence “Data product” vs “tables”

Un data product = dataset + définition (sémantique) + SLO + doc + owner + accès + tests. C’est ce qui rend la data réutilisable sans tribal knowledge.

Anti-patterns (à éviter)

Full refresh partout (coût + temps + risque).
Pas d’idempotence (doublons, inconsistences).
Pas de tests (découverte par les utilisateurs).
Pas d’ownership (personne responsable, incidents éternels).
Transformation hors repo (SQL “à la main” dans le DWH).
Schema drift ignoré (colonnes qui apparaissent/disparaissent).

Red flags production

Signal	Cause probable	Fix
Coûts explosent	Scans full tables	Partition/cluster + pruning
Doublons	Upserts absents	MERGE + keys + dedup
Retards	Backlog / skew	Scale + repartition
Changements silencieux	Pas de contracts	Schema validation

À retenir : “Sans tests & freshness monitoring, tu ne sais pas quand ta donnée ment.”

1.2 Pipelines ETL/ELT — orchestration, incrémental, idempotence, backfills, CI/CD

Orchestration (pattern moderne)

Scheduler (Airflow/Dagster/Prefect) -> Extract (API/DB/Files/CDC) -> Land (Bronze) -> Transform (dbt/Spark) : Bronze->Silver->Gold -> Validate (tests/contracts) -> Publish (marts/semantic layer) -> Observe (freshness/volume/errors)

Dépendances (le vrai problème)

Ordonnancement (upstream/downstream) + SLA (P95).
Gestion des échecs : retries contrôlés, dead-letter, alerting.
Idempotence : relancer ne doit pas “réécrire n’importe quoi”.
Versioning : schémas & transformations évoluent (compat).

Data lineage (usage)

“Pourquoi le dashboard est faux ?” → remonter jusqu’à la source + job fautif.
“Quel impact si je change cette colonne ?” → blast radius.

ETL/ELT : choix pragmatiques

Cas	Approche	Pourquoi
Volumes énormes	ELT + partition	Pushdown SQL
Transformations complexes	Spark	Distribué
APIs rate-limit	Land raw + retry	Rejouable
PII	Mask tôt	Réduire risque

Idempotence (2 patterns)

A) Append-only + dedup (key, latest) B) Upsert / MERGE (natural key + watermark)

SLA vs SLO

SLA = promesse. SLO = objectif interne mesuré (freshness, completeness). Le senior instrumente les deux.

Incrémental : stratégies

Stratégie	Principe	Limites
Watermark	max(updated_at)	Late events
CDC	log changes	Opérations + schema
Partition delta	rebuild partitions	Skew partitions
Hash diff	compare row hash	Coût compute

Late events (fenêtre de sécurité)

Watermark = now - 48h On reprocess les 48h glissantes → absorbe les retards (late arriving data)

MERGE (concept)

MERGE target USING staging ON target.pk = staging.pk WHEN MATCHED THEN UPDATE... WHEN NOT MATCHED THEN INSERT...

Déduplication (propre)

Dédup = règle business + clé + ordre. Ex: - key = (user_id, event_id) - order = event_time desc - keep = first

Pièges incrémental

Horodatage non fiable (timezones, clocks, updates massifs).
Deletes : il faut gérer le “tombstone” ou soft delete.
Schema drift : colonnes nouvelles → contracts + compat.
Skew : une partition devient énorme (ex: “today”).

Observabilité minimale

- rows_in / rows_out - late_events_count - null_rate(key) - freshness - cost per run

Backfill : la compétence “senior”

Rejouer 3 ans de données = risque : coûts + temps + cohérence.
Un senior prépare un plan : fenêtres, priorités, validation, rollback.

Plan de backfill (template)

1) Définir période (ex: 2023-01 -> 2023-12) 2) Découper (jour/semaine) + paralléliser 3) Écrire dans une zone "shadow" (staging/backfill) 4) Valider (counts, checksums, business rules) 5) Switch atomique (rename/partition swap/view) 6) Monitor & post-mortem

Technique : partition swap

Rebuild une partition isolée, valider, puis swap → minimise impact.

Backfill guardrails (coûts)

Risque	Symptôme	Protection
Coût compute	Jobs x100	Limiter parallélisme
Impact prod	Queries lentes	Fenêtres off-peak
Incohérence “double write”	Doublons	Idempotence + locks
Explosion storage	Tables gigantesques	TTL + compaction

Règle d’or : Ne backfill jamais “direct” dans Gold sans shadow + validation.

CI/CD data (pattern)

git push -> lint (SQL/Python) -> unit tests -> build (images) -> integration (sandbox DWH) -> data tests (schema + business rules) -> deploy -> post-checks -> tag release

dbt : conventions de base

Staging (stg_) = normaliser sources ; Marts = tables métiers.
Tests : unique, not_null, relationships + tests custom business.
Docs + exposures (dashboards) + owners.

Release safe

Déploiement par “version” (views / semantic layer).
Feature flags data (basculer un dashboard sur v2).
Rollbacks : garder N versions, switch rapide.

Le senior mesure : - change failure rate (data) - MTTR incidents data - coverage de tests

1.3 Streaming — Kafka, fenêtres, ordering, late events, CDC, exactly-once (approche)

Kafka (les concepts qui comptent)

Topic : flux logique ; partition : parallélisme + ordering.
Key : garantit l’ordre par clé (même partition).
Consumer group : scalabilité (1 partition → 1 consumer actif).
Retention : temps ou taille ; permet replays.
Schema registry : compat backward/forward (Avro/Protobuf/JSON).

Pièges

Skew : une key domine → hotspot partition → lag.
Too many partitions : overhead & opérations.
Pas de contracts : consumers cassés au moindre changement.

Pattern streaming → lakehouse

Producers -> Kafka -> Stream Processor (Flink/Spark/KStreams) -> Bronze (raw) -> Silver (clean) -> Gold (aggregates) -> Metrics/alerts (lag, late, errors)

KPI streaming

- consumer lag (P95) - processing time - late events count - error rate / DLQ rate - throughput (msg/s)

At-least-once vs at-most-once vs exactly-once

Mode	Risque	Quand
At-most-once	Perte	Logs non critiques
At-least-once	Doublons	Très courant
Exactly-once	Complexité	Besoin strict

Réalité : “exactly-once” = design

Souvent : at-least-once + idempotence (dedup keys) = résultat correct.
Transactions end-to-end : plus difficile (source → sink).

Dedup streaming

Event has: - event_id (unique) - event_time Store "seen(event_id)" in state (TTL) If seen -> drop Else -> process

DLQ (Dead Letter Queue)

Si parsing/validation échoue : -> envoyer événement en DLQ -> alerter -> rejouer après fix

Stateful streaming

Fenêtres (tumbling/sliding/session) pour agrégations.
Late events : watermark + allowed lateness.
State store : checkpointing, recovery.

Window 5 min tumbling: - group by key - sum(amount) - emit on window close (watermark)

Le vrai danger : explosion de state

Trop de keys uniques → state énorme → coûts / instabilité.
Solution : TTL, compaction, dimensionnement, clé mieux choisie.

Guardrails : - TTL sur state - limites cardinalité - monitor memory & checkpoints

CDC (Change Data Capture)

Capture inserts/updates/deletes depuis logs DB.
Permet sync near real-time vers lake/DWH.
Besoin : gestion schema evolution + ordering + replays.

Tombstones

Pour les deletes : événement “delete” ou soft-delete + règles downstream.

Pièges CDC

Changements de PK → casse la dédup.
Transactions multi-tables → ordering subtil.
Schema drift non géré → consumers cassent.

Bon design CDC : - key stable - schema registry + compat - upsert sink (MERGE) - replay strategy

2.1 Modélisation analytique — Kimball, SCD, métriques, semantic layer

Grain : la décision n°1

Le grain = “une ligne représente quoi ?” (order, order_line, event…).
Si le grain est flou → métriques incohérentes, doublons, joins dangereux.
Documenter : clés, cardinalité, nullability, business meaning.

Star schema (classique)

fact_orders (grain = order_id) - order_id (PK) - customer_id (FK dim_customer) - order_date_id (FK dim_date) - amount, status, ... dimensions: dim_customer (SCD) dim_date dim_product (si besoin)

Joins : règles d’hygiène

Règle	But
FK explicites	Éviter many-to-many cachés.
Keys stables	Réconcilier sources.
Dimensions conformes	Comparables entre marts.
Surrogate keys	Gérer historiques SCD.

La modélisation est un contrat : elle protège la BI et évite les “dashboards qui mentent”.

SCD (Slowly Changing Dimensions)

Type	Principe	Usage
SCD1	Overwrite	Pas d’historique
SCD2	Versionner (valid_from/to)	Historique complet
SCD3	Colonnes “prev”	Historique limité

SCD2 : structure

dim_customer: - customer_sk (surrogate) - customer_id (natural key) - name, segment, ... - valid_from, valid_to - is_current

Pièges SCD

Natural key pas stable → explosions de versions.
Late updates → corriger périodes (backfill dimension).
Join fact/dim sur mauvaise clé (ou sans date) → métriques fausses.

Règle : facts join sur dim via surrogate key ou via (natural key + date) selon design.

Métriques : rendre le BI stable

Définir les métriques une fois (revenue, active users, churn…).
Éviter “10 définitions de revenue” selon dashboard.
Semantic layer : métriques + dimensions + règles (filtres).

Template métrique

Metric: "Net Revenue" - Definition: sum(amount) where status='paid' minus refunds - Grain: order_id - Time: order_date - Owner: Finance Analytics - Tests: non-negative, reconciliation with accounting

Réconciliation (finance)

Le senior prévoit les checks : totals vs systèmes source, écarts tolérés, et “reconciliation tables” (audit-friendly).

Checks utiles : - totals daily vs source - refunds vs payments - outliers (amount > P99) - duplication rate

Data Vault (quand ?)

Beaucoup de sources, schémas instables, besoin d’audit/traçabilité.
Hub (keys), Links (relations), Satellites (attributs/historique).
Souvent : Vault en “silver” + marts Kimball en “gold”.

Trade-off

Data Vault: + excellent lineage/audit - plus complexe à requêter → marts indispensables pour BI

2.2 Qualité & Observabilité — contracts, tests, alerting, lineage, SLO data

Data contracts : pourquoi c’est “game changer”

Un contrat définit : schéma, types, nullability, clés, SLA, owners.
Le producer s’engage ; le consumer peut se fier (ou alerte).
Réduit drastiquement les breaking changes silencieux.

Contrat (exemple)

Dataset: events_clicks - columns: event_id (string, not null, unique) user_id (string, not null) event_time (timestamp, not null) url (string, not null) - freshness: < 10 min (P95) - expected_volume: 5M/day ±10% - owner: Web Tracking

Schema evolution : règles

Changement	Compat	Action
Ajout colonne nullable	OK	Mettre à jour docs/tests
Renommer colonne	Danger	Deprecation + dual write
Changer type	Risque	Versionner
Supprimer colonne	Breaking	Deprecation window

Sans contrats : les consumers découvrent le problème “après coup”.

Tests data (minimum viable)

Test	Exemple	But
Schema	colonnes/types	Compat
Nulls	not_null(order_id)	Clés
Unique	unique(order_id)	Doublons
Relationships	FK vers dim	Intégrité
Business	amount >= 0	Validité

Test “volume” & “freshness”

- volume_today within [P10..P90] - freshness P95 < 30 min - spike/drop alerts

Great Expectations / dbt tests (idées)

Checksums par partition (ex: total_amount par jour).
Outliers : P99, anomalies par segment.
Reconciliation : totals vs source système.
Drift de distribution : KS-test / PSI (selon besoin).

Bon pattern : tests “cheap” à chaque run + tests “deep” en nightly.

Observabilité data = logs + metrics + lineage

Metrics : freshness, volume, null_rate, dedup_rate, cost/run.
Logs : erreurs parsing, retries, DLQ, timeouts.
Lineage : impact analysis (qui dépend de quoi).

Dashboard on-call (idéal)

- Top failing pipelines - Freshness heatmap (datasets) - Volume anomalies - Cost per dataset (trend) - Lineage (blast radius)

Alerting : éviter le bruit

Alertes “actionnables” (owner + runbook + lien logs).
Seuils dynamiques (baseline), pas du statique partout.
Regrouper incidents : “source X down” plutôt que 50 tables rouges.

Alerte parfaite : - quoi (dataset) - impact (dashboards) - pourquoi probable - comment corriger (runbook)

Incidents data (cas typiques)

Source API rate-limited → trous + retards.
Schema drift → colonnes manquantes, types changés.
Duplication → replays, non-idempotence.
Coût query → scans full table, partition pruning cassée.

RCA (template)

- Résumé impact - Timeline - Root cause (tech + process) - Pourquoi non détecté - Correctifs (tests/contracts/alerts) - Owners + dates

Actions préventives (les plus efficaces)

Data contracts + schema registry.
Idempotence + dedup + MERGE.
Freshness/volume monitoring + alerting owners.
Runbooks & backfill playbook.
FinOps guardrails (quotas, budgets, best practices).

Ce n’est pas “si” ça casse, c’est “quand” — prépare la restauration.

2.3 Sécurité & Conformité — PII, RBAC, masking, encryption, audit, retention

PII : identifier & classifier

Cartographier où se trouve la PII (sources → lake → marts → exports).
Minimiser : ne pas ingérer si inutile (data minimization).
Masquage : tokenization / hashing / partial masking selon usage.
Chiffrement : at-rest + in-transit + key management.

Risques majeurs

Risque	Cause	Fix
Exfiltration	Exports non contrôlés	RBAC + audit + DLP
Sur-collecte	“On prend tout”	Minimisation
Fuite logs	PII en logs	Scrubbing + policies

RBAC/ABAC : design

RBAC : rôles (analyst, engineer, finance…)
ABAC : attributs (pays, équipe, device, projet)
Principe : least privilege + séparation prod/dev

Service accounts & secrets

Secrets manager, rotation, scopes minimaux.
Interdire clés longues durées si possible.

Golden rules

- Pas d’accès direct aux raw PII pour la BI - Exports contrôlés (approval) + logs - Data sharing via datasets “curated” - Environnements séparés

RGPD : points durs côté data

Retention (durée de conservation) + purge.
Droit à l’effacement (suppression / anonymisation).
Traçabilité des accès (audit logs).
Transferts (zones géographiques), sous-traitants.

Audit logs

Qui a lu quoi, quand, depuis où, pour combien de lignes ? (selon capacités plateforme)

Data deletion (pattern)

Option A: hard delete Option B: anonymize/tokenize (irreversible) Option C: tombstone + exclude from serving + reprocess partitions impacted (backfill)

Patterns robustes

PII vault : dataset isolé, accès ultra restreint.
Curated views : exposer uniquement ce qui est nécessaire.
Row-level security : filtrer selon attributs (pays, équipe).
Masking dynamique : affichage masqué selon rôle.

Erreur classique : copier de la PII dans 10 datasets “temp”. Fix : centraliser + contrôler + tracer.

3.1 Lake / DWH / Lakehouse — formats, partitions, tables, compaction, coûts

Formats

Parquet : colonne, compression, pushdown → standard analytique.
JSON : flexible mais coûteux pour analytics (raw uniquement).
Avro/Protobuf : streaming + schema evolution (souvent avec registry).

Bronze/Silver/Gold

Bronze: raw, append-only, schema proche source Silver: cleaned, normalized, deduped Gold: marts, metrics, business-ready

Compaction (pourquoi)

Trop de petits fichiers = overhead énorme.
Compaction = fusionner fichiers + optimiser metadata.
Scheduling : nightly/weekly selon volumes.

Symptôme: queries lentes + “small files” Fix: compaction + partition strategy

Partitioning : règle simple

Partitionner sur colonne souvent filtrée (souvent date).
Éviter trop haute cardinalité (ex: user_id) → trop de partitions.
Partition pruning = clé pour coûts/perf.

Clustering / Z-order (selon engines)

Organiser physiquement pour améliorer scans (ex: par customer_id).
À appliquer après avoir stabilisé volumes.

Anti-pattern

Partition sur une colonne à millions de valeurs → metadata énorme, opérations lentes.

Heuristique

- date (day) souvent OK - hour si très temps réel - cluster sur key business - compaction régulière

Table formats (Iceberg/Delta/Hudi)

Fonction	Ce que ça apporte
ACID	Transactions sur data lake
Time travel	Revenir à une version
Schema evolution	Changements contrôlés
Upserts/Merge	CDC & idempotence

Pourquoi c’est clé

Permet d’appliquer des pratiques DWH “propres” sur un data lake (fiabilité & replays).

Time travel (usage incident)

- pipeline a écrit des données corrompues - rollback table to previous snapshot - patch + reprocess

C’est une arme anti-incidents très “senior”.

FinOps data : leviers

Partition pruning (le plus gros gain).
Clustering + statistiques (si supporté).
Limiter full scans : vues/semantic layer.
Budgets/quotas : alerting sur requêtes coûteuses.
Compaction, retention, tiering storage.

Cost guardrails (exemple)

- max bytes scanned per query - warn on SELECT * without filters - dashboards “cached extracts” - tables TTL (staging)

Si tu ne mesures pas les coûts, tu ne les contrôles pas.

3.2 Plateforme & DevOps Data — environnements, IaC, observabilité, runbooks, multi-tenant

Ce que fait un Data Engineer “platform-aware”

IaC (réseau, IAM, storage, compute), séparation dev/stage/prod.
CI/CD : images, jobs, dbt, migrations de schéma.
Observabilité : logs, metrics, traces pipelines.
Runbooks & on-call : playbooks incident/backfill.
FinOps : capacité, scheduling, autoscaling, budgets.

Multi-tenant (si plateforme interne)

Projets/teams isolés (IAM), quotas, naming conventions, catalog.
Templates & golden paths : “paver la route” pour les équipes.

Golden path (exemple)

Créer un nouveau dataset : 1) Repo template (dbt + tests + docs) 2) Data contract (yaml) 3) Pipeline (Airflow) + alerting 4) Catalog + owner + SLO 5) CI/CD + promotion stage->prod

Éviter la jungle

Sans standards : - 200 tables “temp” - personne ne sait quoi utiliser - incidents non assignés Fix : - catalog + ownership + conventions

4.0 Toolbox — patterns concrets : incrémental, idempotence, backfill, dedup, SCD

SQL (cheatsheet utile)

-- Dedup: garder la dernière ligne par key WITH x AS ( SELECT *, ROW_NUMBER() OVER(PARTITION BY key ORDER BY updated_at DESC) AS rn FROM staging ) SELECT * FROM x WHERE rn = 1; -- Incremental window WHERE updated_at >= :watermark_start AND updated_at < :watermark_end; -- Basic quality checks (ex) SELECT COUNT(*) AS rows, SUM(CASE WHEN order_id IS NULL THEN 1 ELSE 0 END) AS null_order_id FROM fact_orders;

Idempotence : options

MERGE/UPSERT (clé stable) + watermark.
Append-only + dedup (window function) + “latest wins”.
Partition rebuild + swap (pour corrections/backfills).

Backfill playbook (résumé)

- Shadow write (backfill tables) - Validate (counts + checksums + business rules) - Atomic switch (view/rename/partition swap) - Monitor - Post-mortem + runbook

SCD2 (pseudo)

If attribute changed: close current version (valid_to = now, is_current=false) insert new version (valid_from = now, is_current=true) Else: do nothing

Streaming dedup (idée)

state = set(event_id) with TTL if event_id in state: drop else: process + add(event_id)

4.1 Parcours & Interviews — compétences, portfolio, questions, senior mindset

Progression naturelle

Junior : SQL, pipelines simples, ingestion fichiers/APIs, conventions.
Confirmé : orchestration, incrémental, dbt, tests, partitioning.
Senior : streaming/CDC, observabilité, contracts, backfills, finops.
Staff/Lead : plateforme self-serve, gouvernance, stratégie lakehouse.

Compétences qui font la différence

Concevoir idempotence + backfills (replay safe).
Lire/optimiser plans (pruning, clustering, skew).
Mettre en place contrats + tests + alerting.
Gérer coûts & performance (FinOps).
Communication : doc, ownership, sémantique claire.

Idées de projets (très “senior”)

Pipeline CDC DB → lakehouse (MERGE + time travel + backfills).
Framework “data contracts” + validation schema + alerting.
Data observability : freshness/volume anomalies + lineage impact.
Optimisation coûts DWH : partitioning + guardrails + reporting.
Semantic layer : métriques centralisées + tests de réconciliation.

Ce que le recruteur veut voir

- “Comment tu garantis la qualité ?” - “Comment tu fais un backfill sans casser ?” - “Comment tu contrôles les coûts ?” - “Comment tu gères schema drift ?” - “Comment tu prouves une métrique ?”

Questions fréquentes

Explique idempotence et comment tu évites les doublons.
Watermark vs CDC : avantages/limites.
Comment tu fais un backfill d’un an sans exploser les coûts ?
Qu’est-ce qu’un data contract et comment tu gères schema evolution ?
Comment tu définis et mesures la freshness d’un dataset ?
Partitioning/clustering : comment tu choisis ?
Pourquoi les dashboards “mentent” et comment tu l’empêches ?

Réponse attendue (style senior)

- clarifier le grain & la sémantique - expliquer design incrémental + replay safe - détailler tests + contracts + observability - mentionner backfill strategy - parler coûts (pruning, compaction) - ownership + runbooks + RCA

Fondamentaux & rôle

Pipelines ETL/ELT

Streaming & temps réel

Modélisation analytique

Qualité, tests & observabilité

Sécurité & conformité

Lake / DWH / Lakehouse

Plateforme & DevOps data

Toolbox & patterns

Parcours & interviews