Documento di Giustificazione delle Scelte Architetturali

Obiettivo

Realizzare un'infrastruttura Big Data portabile, in grado di:

• Gestire il caricamento e l'elaborazione di file CSV fino a 1 GB al giorno o 1000 GB ogni tre mesi.
• Garantire un tempo massimo di elaborazione inferiore a 24 ore.
• Essere deployabile sia come servizio SaaS che on-premise.

---

Scelte Architetturali e Giustificazioni

1. Framework di Elaborazione: Apache Spark

Tecnologia	Pro	Contro
Hadoop	Soluzione consolidata per il processamento di grandi volumi di dati. Supporta un ecosistema ampio (es. HDFS, Hive).	Prestazioni inferiori a Spark (dipende dal disco per calcoli intermedi). Configurazione complessa.
Apache Flink	Eccellente per streaming data e workload real-time. Supporta anche batch processing.	Curva di apprendimento ripida. Meno ottimizzato per carichi batch puri rispetto a Spark.
Apache Beam	Modello unificato per batch e streaming. Portabilità su diversi backend (Spark, Flink, ecc.).	Maggiore complessità nell'implementazione iniziale. Meno maturo per carichi batch pesanti rispetto a Spark.
Dask	Libreria Python semplice e integrabile con l'ecosistema scientifico (es. NumPy, Pandas). Ideale per workload distribuiti moderati.	Meno performante di Spark su dataset molto grandi. Non progettato per cluster su larga scala.

Scelta Finale: Apache Spark

• Motivazione:
  • Migliore compromesso tra prestazioni, flessibilità e supporto batch.
  • Ecosistema maturo e ampio supporto per deployment su cloud e on-premise.
  • Ottimizzato per pipeline batch-intensive come richiesto nel nostro scenario.

---

2. Gestione dei File CSV: Libreria PySpark

Tecnologia	Pro	Contro
PySpark	Supporto nativo per CSV. API intuitive. Ecosistema distribuito.	Richiede conoscenze di Spark per configurazioni avanzate.
Pandas	Facile da usare per piccoli dataset. Grande supporto per analisi avanzate.	Non adatto per dataset grandi (>10 GB). Non distribuito.
Koalas	API Pandas-like per Spark. Combina facilità d'uso di Pandas con scalabilità Spark.	Ancora in sviluppo attivo. Meno feature rispetto a PySpark.
Dask	Buona alternativa Python distribuita per carichi moderati.	Meno ottimale rispetto a Spark per carichi di grandi dimensioni.

Scelta Finale: PySpark

• Motivazione:
  • Supporto nativo per CSV e distribuzione automatica su cluster.
  • Maggiore integrazione con l'ecosistema Big Data rispetto a Pandas o Dask.

---

3. Formato di Output: Parquet

Formato	Pro	Contro
Parquet	Formato colonnare, compresso. Ottimizzato per query e analisi.	Non leggibile direttamente da strumenti semplici come Excel.
CSV	Semplice da leggere. Ampio supporto.	Grande occupazione di spazio. Lento da elaborare.
Avro	Buona compressione. Supporto per schemi evolutivi.	Non ottimizzato per workload analitici.
ORC	Ottimizzato per query Hive e Spark. Alta compressione.	Meno flessibile rispetto a Parquet per ecosistemi non-Hive.

Scelta Finale: Parquet

• Motivazione:
  • Efficienza, compressione e compatibilità con query analitiche complesse.

---

4. Containerizzazione: Docker

Tecnologia	Pro	Contro
Docker	Portabilità, leggerezza, supporto cloud ampio.	Richiede conoscenze iniziali per setup avanzati.
Podman	Alternativa a Docker senza daemon centrale.	Ecosistema più piccolo rispetto a Docker.
Singularity	Ideale per ambienti HPC. Sicuro e performante.	Non ottimale per architetture Big Data general-purpose.

Scelta Finale: Docker

• Motivazione:
  • Ampia adozione e compatibilità con ambienti SaaS e on-premise.

---

5. Orchestrazione: Docker Compose (o Kubernetes)

Tecnologia	Pro	Contro
Docker Compose	Semplice da configurare. Ideale per piccoli cluster.	Non adatto a gestire grandi infrastrutture distribuite.
Kubernetes	Scalabilità dinamica. Ampio supporto per orchestrazioni complesse.	Configurazione complessa per ambienti piccoli.
Apache Mesos	Alta scalabilità e gestione avanzata delle risorse.	Meno popolare e documentato rispetto a Kubernetes.

Scelta Finale: Docker Compose (o Kubernetes per grandi deployment)

• Motivazione:
  • Equilibrio tra semplicità e flessibilità.

---

6. Storage: Sistema Distribuito o Cloud Storage

Tecnologia	Pro	Contro
S3 (Cloud)	Scalabilità automatica. Query dirette su dati.	Costo ricorrente legato all'uso cloud.
HDFS (on-premise)	Affidabilità grazie alla replica.	Richiede gestione manuale di infrastruttura.
Google Cloud Storage	Integrato con ecosistema Google. Buona scalabilità.	Dipendenza dal vendor.

Scelta Finale: S3 (per SaaS), HDFS (per on-premise)

• Motivazione:
  • Scelta basata su scenari specifici di deployment.

---

Funzionamento dell'Applicativo

L'applicativo attuale segue un processo strutturato per elaborare i dati in formato CSV e produrre output ottimizzati. Ecco i passaggi principali:

1. Ingestione dei Dati:

   • I file CSV vengono caricati in un sistema di storage (es. S3 o HDFS, in base al deployment).
   • L'applicativo identifica i file da processare attraverso un job scheduler o script di avvio manuale.

2. Elaborazione con Apache Spark:

   • I file CSV vengono letti utilizzando PySpark, che suddivide i dati in partizioni per garantire un'elaborazione distribuita.
   • I dati subiscono trasformazioni (es. pulizia, filtraggio e aggregazioni) secondo logiche definite nel codice.

3. Output:

   • I risultati vengono salvati in formato Parquet, garantendo alta compressione e compatibilità con query analitiche successive.
   • Gli output possono essere salvati nello stesso sistema di storage dei file sorgenti o in un repository separato.

4. Containerizzazione e Esecuzione:

   • L'applicativo è containerizzato usando Docker, garantendo consistenza dell'ambiente.
   • L'esecuzione avviene in un container isolato che si avvia, esegue il job e termina al completamento.

5. Orchestrazione e Monitoraggio:

   • Per ambienti piccoli, Docker Compose gestisce l'orchestrazione dei container.
   • Per ambienti più complessi, Kubernetes viene considerato per garantire scalabilità automatica e resilienza.

6. Configurazione e Parametrizzazione:

   • Un file di configurazione YAML permette di personalizzare le pipeline (es. specificare percorsi di input/output, parametri di elaborazione e risorse).

---

Considerazioni Finali

Vantaggi dell'Architettura

• Portabilità: Docker garantisce un deployment uniforme su diverse piattaforme.
• Efficienza: L'uso di Spark e Parquet ottimizza il tempo di elaborazione e lo spazio di storage.
• Scalabilità: L'infrastruttura può essere facilmente scalata su cloud o cluster locali.
• Flessibilità: PySpark e YAML permettono di personalizzare il job ETL in base a specifiche esigenze aziendali.

Prossimi Passi

• Testare l'infrastruttura con carichi reali per validare i tempi di elaborazione.
• Integrare strumenti di monitoraggio (es. Prometheus, Grafana) per tracciare le performance.
• Valutare l'orchestrazione con Kubernetes per deployment su larga scala.

---

Appendice

• Tecnologie Utilizzate: Apache Spark, PySpark, Parquet, Docker, Docker Compose, YAML.
• Requisiti Minimi Hardware: 8 core CPU, 32 GB RAM, 500 GB storage (on-premise).

graph TD
    subgraph User Interaction
        F[User / Client] --> |Uploads CSV| G[API Gateway]
        F --> |Monitors| J[Spark UI]
        F --> |Checks Jobs| K[Dashboard Web]
    end

    subgraph API Layer
        G --> |Validated Request| A[FastAPI Container]
        A --> L[Auth Server - OAuth 2.0]
        A --> |File Upload| B[Uploaded CSV Directory]
    end

    subgraph Ingestion Layer
        B --> |Process CSV| C[Apache Spark Container]
    end

    subgraph Storage Layer
        D[Uploaded CSV Directory]
        E[Parquet Files]
        C --> |Output| E
    end

    subgraph Security & Observability
        A --> M[Centralized Logging - ELK Stack]
        G --> N[Encrypted S3 Bucket]
    end

    subgraph Optimization
        H[Load Balancer] --> G
        C --> O[Cluster Autoscaler]
    end

Loading