🇮🇹 Italiano
🇮🇹 Italiano
Appearance
Appendice A1 — Motivazioni delle scelte tecnologiche
Questa appendice documenta le motivazioni dettagliate delle scelte tecnologiche adottate per la piattaforma MAPS, con confronti quantitativi tra le alternative considerate per ciascun componente. Il documento è un supporto alla lettura del Documento di Progettazione Tecnica Data-Lake.
1. PostgreSQL + PostGIS vs BigQuery/Cloud Data warehouse
La scelta di PostgreSQL 17 con estensione PostGIS 3.5, in esercizio self-hosted, nasce dalla combinazione di tre fattori specifici al progetto MAPS. Il primo è la scala dei dati: il dataset di riferimento è composto da circa 10.000 comuni con fino a 1.000 attributi ciascuno — un volume nell'ordine delle decine di gigabyte, non dei petabyte per cui sono progettati i data warehouse cloud come BigQuery. Il secondo è la centralità delle operazioni spaziali: calcolo di isocrone, buffer geografici, intersezioni tra geometrie sono operazioni di routine nel progetto, e PostGIS è lo standard di settore per questo tipo di elaborazioni, con un ecosistema di strumenti e documentazione incomparabilmente più maturo rispetto a BigQuery GIS. Il terzo è il controllo dei costi: PostgreSQL ha costi infrastrutturali fissi e prevedibili (circa €2.400/anno), mentre BigQuery applica una tariffazione per query che, con pattern di accesso intensivi, può variare tra €600 e oltre €6.000/anno senza possibilità di pianificazione.
| Criterio | PostgreSQL + PostGIS | BigQuery | Decisione |
|---|---|---|---|
| Scala dati | Ottimizzato 10⁴-10⁶ righe | Ottimizzato petabyte | PostgreSQL (scala MAPS: ~10⁴ comuni × ~10³ attributi) |
| Operazioni spaziali | PostGIS = industry standard | BigQuery GIS = limitato | PostgreSQL (isocrone, buffer, intersezioni native) |
| Costi | Prevedibili (infra fissa) | Per-query pricing | PostgreSQL (~€2.4k/anno vs €600-6k+/anno imprevedibili) |
| Vendor lock-in | Zero | Alto | PostgreSQL (principio indipendenza) |
| Maturità | 30+ anni | ~15 anni | PostgreSQL (affidabilità consolidata) |
| Integrazione | Universale | Ecosistema GCP | PostgreSQL (funziona con ogni tool) |
BigQuery sarebbe giustificato in scenari con volumi superiori ai 100 GB per singola query, con centinaia di utenti concorrenti, con necessità di un servizio completamente gestito senza overhead operativo, o con un budget dedicato all'analytics superiore ai €5.000 annui. Nessuna di queste condizioni vale per MAPS.
2. DuckDB vs BigQuery per analytics
Per l'analisi esplorativa dei dati, DuckDB in modalità embedded è la scelta adottata in alternativa a BigQuery. Il motivo principale è la capacità di federazione diretta con PostgreSQL: DuckDB legge le tabelle Gold senza necessità di esportare i dati, eliminando un passaggio ETL intermedio e mantenendo i dati nel sistema di riferimento. A questo si aggiunge l'assenza di costi di licenza — BigQuery fattura circa €5 per terabyte di dati analizzati — e la semplicità d'uso in contesti Python: DuckDB si installa come libreria e non richiede infrastruttura separata. Sui volumi di MAPS (circa 50 GB), le query analitiche tipiche si eseguono in meno di 10 ms, prestazioni equivalenti a quelle di BigQuery su dataset di questa dimensione.
| Criterio | DuckDB | BigQuery | Decisione |
|---|---|---|---|
| Dimensionamento | GB scale | TB/PB scale | DuckDB (volumi MAPS: ~50GB) |
| Costi | Zero | €5/TB query | DuckDB (risparmio €600-1.200/anno) |
| Performance | ms su GB | ms su TB | DuckDB (query < 10ms sul volume MAPS) |
| Federation | Legge da PostgreSQL | Richiede export | DuckDB (no ETL aggiuntivo) |
| Portabilità | File auto-contenuto | Vendor lock-in | DuckDB (export Parquet portabile) |
| Developer UX | Embedded Python | API REST | DuckDB (zero overhead setup) |
3. Prefect vs Airflow/Dagster
Prefect 3.x è stato scelto come orchestratore delle pipeline in ragione del basso overhead di adozione rispetto alle alternative. Airflow è lo strumento più diffuso nel settore, ma richiede un'infrastruttura complessa, una curva di apprendimento ripida e un carico operativo elevato, difficilmente giustificabile per un progetto delle dimensioni di MAPS. Dagster offre un'architettura moderna e una buona esperienza utente, ma ha anch'esso una curva di apprendimento più impegnativa. Prefect consente di passare da zero a pipeline operative in poche ore, con decoratori Python semplici, un'interfaccia web moderna e un'architettura che separa nettamente server di orchestrazione e worker di esecuzione.
| Criterio | Prefect | Airflow | Dagster | Decisione |
|---|---|---|---|---|
| Setup complexity | Basso | Alto | Medio | Prefect |
| Learning curve | Gentile | Ripida | Ripida | Prefect |
| Python-native | Completo | Parziale | Completo | Prefect |
| Time-to-value | Rapido (ore) | Lento (giorni) | Medio | Prefect |
| UI/UX | Moderna | Datata | Moderna | Prefect/Dagster |
| Overhead operativo | Basso | Alto | Medio | Prefect |
4. Docling vs alternative PDF extraction
Una parte significativa dei dataset acquisiti dal progetto è distribuita in formato PDF, spesso con tabelle complesse. La libreria Docling di IBM, basata sul modello TableFormer, raggiunge una precisione del 97,9% sull'estrazione di tabelle da PDF in un benchmark indipendente su documenti finanziari complessi. Camelot e Tabula, le librerie tradizionalmente più diffuse per questo tipo di operazioni, sono entrambe in modalità manutenzione e non più in sviluppo attivo; le valutazioni comparative disponibili indicano prestazioni significativamente inferiori su tabelle complesse rispetto a Docling. Docling è rilasciata con licenza MIT, integra nativamente l'esportazione in formato Pandas DataFrame, ed è interamente self-hosted, senza dipendenze da servizi cloud. Per i PDF senza tabelle complesse viene utilizzato PyMuPDF come fallback, e pdfplumber per i documenti con layout multi-colonna o strutture particolarmente problematiche. Azure Document Intelligence, pur con prestazioni paragonabili (~95%), è stata esclusa per il vincolo di vendor lock-in e i costi imprevedibili.
| Libreria | Accuracy | Licenza | Sviluppo attivo | Pandas nativo | Decisione |
|---|---|---|---|---|---|
| Docling (TableFormer AI) | 97.9% | MIT | Sì (2025, LF AI) | Sì | Primary |
| pdfplumber | 85-90% | MIT | Sì | Parziale | Fallback |
| PyMuPDF | 75-80% | AGPL-3.0 | Sì | Parziale | Fallback |
| Camelot | ~70% | MIT | Maintenance mode | No | Escluso |
| Tabula | ~70% | MIT | Maintenance mode | No | Escluso |
| Azure Doc Intelligence | ~95% | Commercial | Sì | Sì | Escluso (vendor lock-in) |
5. OpenMetadata vs DataHub/Atlan/Atlas
OpenMetadata 1.x è lo strumento scelto per la governance interna dei dati. Rispetto alle alternative, combina un costo infrastrutturale contenuto (circa €1.200/anno per una VM dedicata), un'installazione su singola macchina, un'interfaccia moderna e un'integrazione diretta con lo stack PostgreSQL/Prefect del progetto. DataHub richiede due o tre macchine virtuali e ha costi leggermente superiori; Atlan offre un'esperienza utente eccellente ma con licenze commerciali nell'ordine di €12.000-30.000/anno; Apache Atlas è progettato per ecosistemi Hadoop e richiederebbe oltre dieci macchine virtuali per funzionare correttamente, risultando del tutto sproporzionato. OpenMetadata è operativo in uno-due giorni e non introduce dipendenze da fornitori.
| Criterio | OpenMetadata | DataHub | Atlan | Atlas | Decisione |
|---|---|---|---|---|---|
| Costo annuale | €1.2k (infra) | €1.8-2.4k | €12-30k (lic.) | €3-5k | OpenMetadata |
| Setup | 1 VM | 2-3 VMs | 1 VM | 11+ VMs | OpenMetadata |
| UI/UX | Moderna | Funzionale | Eccellente | Datata | OpenMetadata |
| Stack fit | PostgreSQL/Prefect | Buono | Buono | Hadoop-only | OpenMetadata |
| Vendor lock-in | Zero | Zero | Alto | Zero | OpenMetadata |
| Time-to-value | 1-2 giorni | 2-4 giorni | Medio | Settimane | OpenMetadata |
6. CKAN per Open Data vs uso esteso OpenMetadata
La pubblicazione open data richiede uno strumento distinto da OpenMetadata, che è ottimizzato per la governance interna e non supporta lo standard DCAT-AP_IT né l'integrazione con il portale nazionale dati.gov.it. CKAN 2.11, self-hosted, è la scelta adottata per il catalogo pubblico: implementa nativamente DCAT-AP_IT, include un harvester verso dati.gov.it, espone un portale web ottimizzato per utenti non tecnici, e gestisce download multi-formato con anteprima dei dati. Estendere OpenMetadata per coprire questi requisiti richiederebbe uno sviluppo custom stimato in due o tre mesi-persona, senza garanzie di conformità agli standard.
| Criterio | CKAN | OpenMetadata esteso | Decisione |
|---|---|---|---|
| Target audience | Pubblico esterno | Data operators interni | CKAN (separation of concerns) |
| Standard DCAT-AP_IT | Nativo | Non supportato | CKAN (requisito WP6 D6.3) |
| Integrazione dati.gov.it | Built-in harvester | Richiede sviluppo custom | CKAN (API standard CSW/DCAT) |
| Portale user-friendly | Web UI ottimizzata pubblico | UI tecnica data engineers | CKAN (esperienza utente) |
| Rate limiting & API keys | Nativo | Limitato | CKAN (controllo accessi pubblici) |
| Dataset downloads | Multi-formato con preview | Solo metadata | CKAN (full data access) |
| SEO e discoverability | Ottimizzato motori ricerca | Non ottimizzato | CKAN (findability pubblica) |
| Licensing metadata | Completo (Creative Commons) | Basic | CKAN (compliance open data) |
I due strumenti svolgono ruoli complementari e non sovrapposti. OpenMetadata riceve i metadati tecnici da Prefect durante l'esecuzione delle pipeline, traccia la lineage Bronze → Silver → Gold, registra i risultati delle validazioni Great Expectations e fornisce al team interno un catalogo operativo. CKAN riceve dal Gold layer i soli dataset approvati per la pubblicazione, li arricchisce con metadati DCAT-AP_IT completi (licenza, copertura temporale, estensione geografica, metodologia) e li rende accessibili a cittadini, ricercatori e sviluppatori terzi, con harvesting automatico verso dati.gov.it.
graph LR
subgraph "Internal - Data Operators"
A[Prefect Pipeline] --> B[OpenMetadata]
B --> C[Lineage Tracking]
B --> D[Data Quality Metrics]
B --> E[Schema Profiling]
end
subgraph "Public - External Users"
F[Gold Layer] --> G[CKAN]
G --> H[DCAT-AP_IT Metadata]
G --> I[dati.gov.it Harvester]
G --> J[Public Downloads]
end
F -.selected datasets.-> A
Dal punto di vista dei costi, aggiungere CKAN all'infrastruttura comporta un incremento di circa €600/anno per la VM dedicata, a fronte di un risparmio di €15.000-20.000 in sviluppo custom che sarebbe altrimenti necessario per adeguare OpenMetadata agli standard open data.
| Voce | OpenMetadata solo | OpenMetadata + CKAN | Delta |
|---|---|---|---|
| Infra (VM) | €1.2k/anno | €1.8k/anno | +€600/anno |
| Sviluppo custom | €15-20k (DCAT-AP_IT) | €0 | -€15-20k |
| Manutenzione | Alta (custom code) | Bassa (standard stack) | Significativo |