etl-designer

ETL Designer

Workflow en étapes

1. Analyse des sources et destinations

• Inventorier chaque source : type (SGBD, API REST, fichier plat, Kafka, SaaS), volume moyen/max, fréquence de rafraîchissement, contraintes d'accès réseau, latence acceptable.
• Identifier la destination : data warehouse (Snowflake, BigQuery, Redshift, SQL Server DWH), data lake (S3, ADLS), data mart ou base opérationnelle.
• Consigner les SLA de fraîcheur (batch quotidien, quasi-temps-réel <5 min, streaming) et les fenêtres de maintenance source.

2. Choix ETL vs ELT

Critère	ETL	ELT
Puissance de la destination	faible (on-prem DWH)	forte (Snowflake, BigQuery)
Données sensibles	masquage/anonymisation tôt	plus difficile à isoler
Flexibilité exploration	faible	forte (raw zone conservée)
Coût compute	moteur ETL dédié	warehouse paie la transformation

Décision à documenter : justifier le choix dans un ADR ou un commentaire de pipeline.

3. Extraction

Full load — snapshot complet ; simple, utiliser quand la table source est petite (<1 M lignes) ou sans colonne de delta fiable.

Incrémental par timestamp/ID :

-- Extraction SQL incrémentale
SELECT *
FROM source_table
WHERE updated_at > :last_run_ts
  AND updated_at <= :current_run_ts
ORDER BY updated_at;

CDC (Change Data Capture) — Debezium sur PostgreSQL/MySQL/SQL Server, Oracle GoldenGate, AWS DMS. Capturer INSERT/UPDATE/DELETE sans polling. Nécessite que le WAL ou le binlog soit activé.

Extraction API paginée (Python) :

def extract_all_pages(url, headers, page_size=200):
    results, cursor = [], None
    while True:
        params = {"limit": page_size, **({"cursor": cursor} if cursor else {})}
        r = requests.get(url, headers=headers, params=params, timeout=30)
        r.raise_for_status()
        data = r.json()
        results.extend(data["items"])
        cursor = data.get("next_cursor")
        if not cursor:
            break
    return results