🇮🇹 Italiano
🇮🇹 Italiano
Appearance
Requisiti e Vincoli del Data Lake ​
Requisiti del Data Lake ​
Il data lake costituisce l'infrastruttura centrale del progetto, progettata per supportare l'acquisizione, la standardizzazione e l'analisi di dataset eterogenei su scala nazionale. I requisiti si articolano in due categorie: funzionali e non funzionali.
Requisiti funzionali ​
RF1: Acquisizione Dati Eterogenei
Il sistema deve supportare l'acquisizione di oltre 180 dataset provenienti da fonti pubbliche diverse, come censiti nel catalogo dati del progetto. La distribuzione per ente vede ISTAT come fonte principale con 113 dataset (62%), seguito dal Ministero dell'Istruzione con 35 dataset (19%). Le fonti complementari includono Agenas per le strutture sanitarie (6 dataset), ISPRA per i dati ambientali (6 dataset), la Ragioneria Generale dello Stato (4 dataset), il Ministero della Salute (3 dataset), il Ministero della Giustizia (2 dataset) e altri 8 enti pubblici con contributi minori. La varietà dei formati di distribuzione (CSV, XLSX, HTML, PDF) richiede capacità di parsing differenziate per ciascuna tipologia.
RF2: Gestione Serie Storiche
La dimensione temporale copre il periodo 2010-2025, per un totale di 15 anni di osservazioni. La granularità di riferimento è il livello comunale, che comporta la gestione di circa 8.000 comuni italiani. Il sistema deve gestire le discontinuità temporali introdotte dalla pandemia COVID-19 nel biennio 2020-2021, durante il quale molte rilevazioni hanno subito interruzioni o modifiche metodologiche. Inoltre, deve tracciare le fusioni e separazioni comunali avvenute nel periodo attraverso un sistema di lookup storico.
RF3: Standardizzazione Dati
Il processo di standardizzazione prevede diverse operazioni critiche. I codici ISTAT devono essere normalizzati per garantire la coerenza dei riferimenti territoriali. Le coordinate spaziali vengono uniformate al sistema di riferimento EPSG:32632 (WGS84 / UTM zone 32N). Il sistema deve distinguere tra valori mancanti e nulli semantici, applicando strategie di gestione differenziate. La riconciliazione delle fusioni e separazioni comunali garantisce la continuità delle serie storiche anche in presenza di modifiche amministrative.
RF4: Pattern Medallion
L'architettura dei dati segue il pattern Medallion, articolato in tre livelli distinti. Il livello Bronze conserva i dati grezzi immutabili, esattamente come acquisiti dalle fonti. Il livello Silver applica la standardizzazione attraverso uno schema EAV (Entity-Attribute-Value) che gestisce la variabilità degli attributi comunali nel tempo. Il livello Gold produce data mart analitici ottimizzati per le applicazioni business, con tabelle denormalizzate e geometrie PostGIS pronte per l'interrogazione spaziale. I dettagli dell'implementazione sono descritti nel capitolo 2.
Requisiti non funzionali ​
RNF1: Completeness
Il sistema deve garantire una copertura pari o superiore al 95% dei comuni italiani per ogni dataset prioritario. La metrica di riferimento è la percentuale di comuni con dati completi rispetto al totale dei comuni esistenti nel periodo di riferimento.
RNF2: Accuracy
L'accuratezza richiede che almeno il 99,9% dei record contenga un codice ISTAT valido. La validazione si basa sul confronto con il dataset di riferimento dei confini amministrativi ufficiali pubblicati da ISTAT.
RNF3: Timeliness
I dataset con frequenza di aggiornamento mensile devono essere processati entro 5 giorni dalla loro disponibilità . Le pipeline ETL prioritarie devono completare l'elaborazione con latenza inferiore alle 24 ore.
RNF4: Lineage
Ogni record deve essere tracciabile attraverso l'intera catena di trasformazione, dalla fonte originale al livello Bronze, quindi al livello Silver e infine al livello Gold. Il sistema deve mantenere il versionamento delle fonti dati per consentire la ricostruzione storica delle trasformazioni.
RNF5: ScalabilitÃ
Il sistema è dimensionato per supportare un volume di dati fino a 1TB nell'arco del triennio di progetto. Il throughput delle pipeline ETL deve essere pari o superiore a 100 record al secondo per garantire tempi di elaborazione accettabili.
RNF6: Governance
La governance richiede la catalogazione completa di tutti i dataset con metadati strutturati. Una dashboard in tempo reale deve monitorare la qualità dei dati, evidenziando anomalie e scostamenti rispetto alle soglie definite. Tutte le operazioni su dati sensibili devono essere registrate in log completi per scopi di audit.
Dati critici per MVP (Fase 1a) ​
La fase iniziale del progetto (mesi 1-4) si concentra sull'acquisizione e validazione di 5 dataset critici, che costituiscono la base informativa minima per lo sviluppo degli algoritmi SLO. La tabella seguente riassume le caratteristiche principali di ciascun dataset.
| Dataset | Fonte | Formato | Frequenza | Priorità |
|---|---|---|---|---|
| Confini comunali + metadata | ISTAT | Shapefile/JSON | Annuale | Alta |
| Popolazione residente | ISTAT | CSV | Annuale | Alta |
| Matrici pendolarismo | ISTAT | CSV | Decennale | Alta |
| Rete trasporto pubblico | GTFS | ZIP | Mensile | Media |
| Strutture sanitarie | Min. Salute | Excel | Annuale | Media |
Vincoli architetturali ​
L'architettura del sistema è soggetta a quattro vincoli fondamentali, derivanti sia da scelte strategiche che da requisiti tecnici specifici.
Vincolo V1: Self-Hosted Open Source
La scelta di utilizzare esclusivamente tecnologie open source in modalità self-hosted risponde all'esigenza di indipendenza dai fornitori e di prevedibilità dei costi. Lo stack tecnologico comprende PostgreSQL per lo storage primario, PostGIS per le operazioni spaziali, Prefect per l'orchestrazione delle pipeline, OpenMetadata per la governance dei dati e DuckDB per le analisi embedded. Sono esplicitamente esclusi i servizi managed offerti da BigQuery, Azure e AWS, che introdurrebbero dipendenze da fornitori e costi variabili difficili da prevedere.
Vincolo V2: Adeguatezza di Scala
La volumetria prevista si attesta nell'ordine di grandezza di 10^4 righe per 10^3 colonne, tipica dei progetti gestiti da DEPP. A questa scala, l'adozione di BigQuery rappresenterebbe un eccesso di capacità (overkill) rispetto alle reali necessità , con conseguente spreco di risorse e complessità gestionale non giustificata.
Vincolo V3: Standard Territoriali
PostGIS costituisce lo standard industriale de facto per la gestione di dati spaziali in ambiente PostgreSQL. Il sistema di riferimento adottato è EPSG:32632 (WGS84 / UTM zone 32N), che rappresenta il sistema standard per il territorio italiano e garantisce la compatibilità con i dataset geografici nazionali.
Vincolo V4: Compliance FAIR
I dataset rilasciati devono rispettare i principi FAIR. Findable: i dati devono essere catalogati con metadati strutturati che ne facilitino la scoperta. Accessible: le licenze adottate (CC-BY, CC0) garantiscono l'accesso libero e gratuito. Interoperable: i formati di distribuzione (GeoJSON, GeoParquet, CSV) sono standard aperti che assicurano l'interoperabilità con altri sistemi. Reusable: l'assegnazione di DOI garantisce la citabilità scientifica e la tracciabilità delle versioni.
Sfide specifiche ​
Il progetto affronta quattro sfide tecniche significative, ciascuna delle quali richiede soluzioni architetturali specifiche.
Sfida S1: Assenza Geolocalizzazione Puntuale
La maggior parte dei servizi analizzati (scuole, ospedali, uffici postali) non dispone di coordinate geografiche precise. L'approccio adottato si basa sulla rilevazione di presenza o assenza del servizio a livello comunale, rinunciando alla geolocalizzazione puntuale. Di conseguenza, i calcoli di isocrone operano su distanze municipality-to-municipality piuttosto che point-to-point.
Sfida S2: Evoluzione Confini Amministrativi
Nel periodo 2010-2025 si sono verificate circa 100 fusioni o separazioni comunali, che modificano la struttura territoriale di riferimento. La soluzione adottata prevede un lookup storico con validità temporale implementato secondo il pattern Slowly Changing Dimension Type 2 (SCD Type 2). Lo schema Silver include le colonne valid_from e valid_to che delimitano l'intervallo di validità di ciascuna configurazione territoriale.
Sfida S3: Gap Temporali COVID
I dati relativi al biennio 2020-2021 presentano discontinuità metodologiche dovute alle restrizioni imposte dalla pandemia. Il sistema applica un flag covid_affected ai dataset impattati, consentendo strategie di analisi differenziate. Le opzioni includono tecniche di imputation statistica per stimare i valori mancanti o l'esclusione esplicita dei periodi problematici dalle analisi longitudinali.
Sfida S4: Eterogeneità Formati
La presenza di 207 dataset distribuiti in formati diversi (CSV, XLSX, HTML, PDF) richiede uno stack di estrazione multistrato. Docling gestisce l'estrazione da PDF complessi con tabelle strutturate. Pandas elabora i file CSV ed Excel. BeautifulSoup effettua il parsing di tabelle HTML. La normalizzazione finale avviene attraverso lo schema EAV flessibile del livello Silver, che assorbe la variabilità strutturale delle fonti.
Obiettivi del WP2 ​
Al termine del Work Package 2, il data lake dovrà soddisfare cinque obiettivi misurabili:
- Acquisire gli oltre 180 dataset censiti nel catalogo dati del progetto, garantendo la diversità delle tipologie e dei formati di ingresso.
- Garantire una copertura pari o superiore al 95% dei comuni italiani per tutti i dataset prioritari identificati nella fase MVP.
- Fornire tracciabilità completa attraverso il lineage Bronze-Silver-Gold per ogni singolo record presente nel sistema.
- Validare le pipeline ETL attraverso report di data quality che documentino le metriche di completezza, accuratezza e tempestività .
- Preparare l'infrastruttura dati necessaria all'implementazione degli algoritmi SLO previsti nel Work Package 3.
Output attesi (Deliverable) ​
Il Work Package 2 produce cinque deliverable documentali: