Pipeline ETL per Catalogo Veicoli Nazionale

Il Contesto

Un gruppo di concessionarie auto operante a livello nazionale gestiva l'inventario veicoli attraverso diversi sistemi DMS (Dealer Management System). Ogni concessionaria utilizzava software differenti, generando dati in formati eterogenei che rendevano impossibile avere una visione unificata del catalogo disponibile.

Le Sfide Principali

• Dati frammentati: ogni concessionaria con proprio DMS e formato dati
• Formati eterogenei: XML con strutture diverse da normalizzare
• Tracciabilità: necessità di sapere quale fonte ha fornito ogni dato
• Conflitti: stesso veicolo presente in più fonti con dati discordanti
• Scalabilità: soluzione che cresca con il numero di concessionarie
• Costi: minimizzare spesa infrastrutturale con approccio serverless

L'Architettura

Pipeline ETL Serverless

L'architettura è stata progettata con un approccio completamente serverless su AWS:

Flusso Dati

Organizzazione S3

I file seguono una convenzione di naming strutturata:

s3://bucket/corporate={id}/source={DMS}/data.xml.zip
    ↓ (dopo elaborazione)
s3://bucket/imported/corporate={id}/source={DMS}/YYYY/MM/DD/HH/

Stack Tecnologico

AWS Services

Python Stack

Data Model

Schema Database

Il modello dati gestisce la multi-sorgente con un pattern a layer:

Gestione Multi-Source

Vehicle (master)
    ├── VehicleLayer (fonte: DMS_A)
    ├── VehicleLayer (fonte: DMS_B)
    └── VehicleLayer (fonte: Manual)

Strategia conflitti: Last Writer Wins con audit trail completo.

Campi Principali Vehicle

ETL Job

Workflow di Elaborazione

Il job Glue Python Shell esegue le seguenti operazioni:

1. Download: Scarica file ZIP da S3
2. Decompress: Estrae XML dal file compresso
3. Parse: Converte XML in dizionario Python
4. Map: Applica mappatura campi da track file
5. Transform: Normalizza e valida dati
6. Compare: Confronta con dati esistenti (delta)
7. Upsert: Inserisce o aggiorna database
8. Archive: Sposta file in cartella processed

Track Files

I file di configurazione JSON definiscono il mapping XML → DB:

{
  "root": "Ad",
  "mappings": {
    "Public/Brand": "make",
    "Public/Model": "model",
    "Business/ListPrice": "list_price",
    "Codes/MakeCode": "make_code"
  }
}

Mapping complessi supportati:

• 1 campo XML → N campi DB
• N campi XML → 1 campo DB (fallback)
• Nested structures (Images, Options)

Infrastructure as Code

SAM Template

L'intera infrastruttura è definita in CloudFormation/SAM:

Deployment

# Prima installazione
sam build -cup && sam deploy --guided

# Deploy successivi
sam build -cup && sam deploy --config-env prod

# Cleanup
sam delete --config-env prod

Multi-Environment

Configurazione per ambienti multipli via samconfig.toml:

Sicurezza

Encryption

Accesso Database

L'accesso ad Aurora avviene esclusivamente tramite:

• Bastion Host EC2 con SSH tunneling
• Glue Connection via JDBC interno VPC
• Secrets Manager per credenziali (no hardcoding)

Sviluppo Locale

Docker Compose

Per testing locale senza AWS:

services:
  python:
    build: .
    volumes:
      - ./scripts:/app
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: vehicles

Testing

# Setup ambiente
python3 -m venv .env
source .env/bin/activate
pip install -r requirements.txt

# Esecuzione locale
python s3_etl.py --local --file test.xml.zip

Risultati

Performance

Benefici

• Zero server da gestire: architettura 100% serverless
• Scalabilità automatica: Glue scala con il carico
• Costi ottimizzati: paghi solo per l'uso effettivo
• Tracciabilità completa: ogni dato ha la sua fonte
• Disaster recovery: backup automatici Aurora 35 giorni
• IaC: infrastruttura versionata e riproducibile

Lezioni Apprese

1. Glue Python Shell: ideale per job ETL leggeri (< 1 DPU sufficiente)
2. Track files: configurazione esterna permette nuovi DMS senza codice
3. Layer pattern: gestire multi-source senza perdere dati
4. SAM templates: nested stacks per modularità
5. Local testing: Docker Compose essenziale per sviluppo rapido
6. Secrets Manager: mai credenziali in codice o variabili ambiente