Come accedere

Leggendo la documentazione ufficiale è possibile costruire alcuni esempi base.

Il primo tipo di query è per odonimi (l’odonimo è il nome di una strada) e si può fa a partire dal codice Belfiore del Comune di interesse (è un codice alfanumerico di 4 caratteri usato in Italia per identificare in modo univoco ogni comune). Quello di Palermo è ad esempio G273.

Se si vuole cercare l’elenco delle strade che contengono ROMA nel nome, si può fare una richiesta come questa:

curl -X GET "https://anncsu.open.agenziaentrate.gov.it/age-inspire/opendata/anncsu/querydata.php?resource=odonimi&codicecomune=G273&denominazione=ROMA"

Si può aprire anche nel browser ed è composta da:

• resource=odonimi
• codicecomune=G273
• denominazione=ROMA

In output un JSON, che per ogni strada ha questo tipo di schema:

{
  "Progressivo_nazionale": "576388",
  "Codice_comunale": "",
  "DUG": "VIA",
  "DUF": "ROMA",
  "Denominazione_localita": "",
  "Denominazione_lingua1": "",
  "Denominazione_lingua2": ""
}

Se si vuole cercare l’elenco degli accessi (i numeri civici) di questa strada, si deve partire dal codice numerico della strada. La strada di sopra ha il codice 576388 e si può fare una richiesta come questa:

curl -X GET "https://anncsu.open.agenziaentrate.gov.it/age-inspire/opendata/anncsu/querydata.php?resource=accessi&progressivoodonimo=576388&accesso=1"

Anche questa si può consultare via browser e dà in output un JSON con questo schema:

{
  "Progressivo_nazionale_accesso": "1885499",
  "Codice_comunale_accesso": "",
  "Civico": "179",
  "Esponente": "",
  "Specificita": "",
  "Metrico": "",
  "CoordX": "",
  "CoordY": "",
  "Quota": "",
  "Metodo": "4"
}

La lista delle strade di una città

Guardando la documentazione non sembra possibile ottenerla. Però forse (da verificare) è possibile utilizzare questo hack: denominazione=%20%20%20.

Quindi per Palermo, la query potrebbe essere:

curl -X GET "https://anncsu.open.agenziaentrate.gov.it/age-inspire/opendata/anncsu/querydata.php?resource=odonimi&codicecomune=G273&denominazione=%20%20%20"

Non ci sono le coordinate geografiche

Al momento non sono leggibili le coordinate geografiche dei numeri civici. E siccome non è possibile e non è sensato pubblicare questi dati senza queste informazioni, è ipotizzabile e sperabile che sia un errore e che a breve saranno leggibili.

Del resto l’ANNCSU, deve ancora annunciare il rilascio del servizio.

Documentazione ufficiale

La documentazione ufficiale è leggibile in formato JSON in questa pagina:
https://anncsu.open.agenziaentrate.gov.it/age-inspire/opendata/anncsu/querydata.php?help_show

Si riporta a seguire tradotta in italiano (fatto con un LLM).

.../querydata.php?resource=odonimi&codicecomune=H501&denominazione=VIA%20MILANO
.../querydata.php?resource=accessi&progressivoodonimo=2000083&accesso=1

.../querydata.php/odonimi/H501/MILANO
.../querydata.php/accessi/2000083/1

{"resource":"odonimi","codicecomune":"H501","denominazione":"VIA MILANO"}
{"resource":"accessi","progressivoodonimo":"2000083","accesso":"1"}

Come interrogare il database

Il file in formato DuckDB si può scaricare da qui. È leggibile con decine di software, per tutti i sistemi operativi.

Uno degli strumenti che si possono utilizzare è DBeaver, un client SQL open source per tutte le principali piattaforme, che consente di interrogare database di diversi tipi, tra cui DuckDB.

Una volta installato e lanciato, si potrà scegliere a che tipo di database connettersi: in questo caso DuckDB (vedi Figura 1).

Nei passaggi successivi della configurazione si dovrà indicare a quale file DuckDB connettersi. Qui sarà il file pnrr.db scaricato in precedenza.
Una volta connessi, il database sarà visibile sulla sinistra, nel navigatore dei database. E facendo clic sui vari segni >, sarà possibile vedere le 1️⃣ tabelle e le 2️⃣ viste, ecc. in cui è strutturato (vedi Figura 2).

La tabella è soltanto una, si chiama info_viste e contiene l’elenco di tutte le viste presenti nel database. In questa tabella, per ogni vista:

• il nome della vista;
• il titolo del dataset;
• l’URL della pagina del dataset;
• il file che ha fatto da sorgente;
• la descrizione del dataset;
• la data di osservazione dei dati che hanno fatto da sorgente.

Questa tabella è quindi una tabella di metadati. Mentre per accedere ai dati bisogna utilizzare una o più delle viste presenti.

E una prima query potrebbe essere quella per conteggiare il numero di progetti del PNRR:

SELECT COUNT() conteggio from pnrr.main.PNRR_Progetti;

Sono, al momento, 269.300 progetti. La cosa interessante è che il risultato è molto rapido, nonostante il db non contenga i dati, ma solo dei puntatori.

Ed è molto comodo, che strumenti come DBeaver abbiano l’auto-completamento delle query, come è possibile vedere in Figura 3.

Il PNRR è suddiviso in Missioni e la query per conteggiare il numero di progetti per Missione - che viene eseguita in 0.5 secondi, è:

SELECT
  "Descrizione Missione",
  COUNT() conteggio
FROM
  pnrr.main.PNRR_Progetti
GROUP BY
  ALL
ORDER BY
  conteggio DESC;

Ma per dare un’idea più efficace della comodità, di poter utilizzare un piccolo file da 500 kB, si può costruire una query più complessa che mette in relazione due viste, ovvero due dataset: quello dei Progetti e quello delle Localizzazioni.
L’obiettivo è quello di creare una tabella di sintesi, una tabella pivot, per restituisca il numero di progetti per Missione per ogni Regione.

La query è

PIVOT (
  SELECT
    loc."Descrizione Regione" AS Regione,
    p.Missione
  FROM
    "pnrr"."PNRR_Progetti" p
    LEFT JOIN (
      SELECT
        DISTINCT CUP,
        "CODICE Locale Progetto",
        "Descrizione Regione"
      FROM
        "pnrr"."PNRR_Localizzazione"
    ) loc ON p.CUP = loc.CUP
    AND p."Codice Locale Progetto" = loc."CODICE Locale Progetto"
) ON Missione

E in pochi secondi viene restituito il risultato (vedi Figura 4).

Come è stato creato il database

L’ispirazione per la creazione di questa modalità di accesso ai dati del PNRR, viene dalla lettura di questo ottimo articolo, in cui si spiega come DuckDB possa diventare un catalogo portatile per la gestione dei dati, da fonti diverse (file parquet da fonti Amazon S3, database PostgreSQL, tabelle su Google Cloud, ecc.).

Per questo file è stata replicata la logica descritta nell’articolo, ma sono state necessarie delle pre-lavorazioni dei dati.

Sul sito Italiadomani i file sono disponibili in formato CSV (JSON e XLSX) e una query SQL tramite DuckDB si può fare puntando direttamente all’URL del file. Per sapere ad esempio quanti sono i progetti del PNRR la query sarebbe:

SELECT COUNT(*) FROM read_csv_auto('https://www.italiadomani.gov.it/content/dam/sogei-ng/opendata/PNRR_Progetti.csv')

Questo è possibile grazie all’estensione httpfs di DuckDB, che consente di leggere file da URL HTTP o da Amazon S3. Ci sono però dei problemi:

• a volte il server di Italiadomani non risponde in modo adeguato, e la query fallisce;
• il formato CSV non è ottimizzato per query su file “grandi”, che non risiedano sul proprio PC, perché è necessario scaricare tutto il file per fare la query.

Entrambi i punti sono abbastanza bloccanti e, per superarli, sono state fatte due cose:

1. pubblicare i file con i dati in uno spazio web che rispondesse meglio alle chiamate HTTP;
2. convertire i file CSV in un formato più adatto per fare query su file “grandi” remoti, come il formato parquet.

Lo spazio web creato, che ospita i file è GitHub, e la cartella è questa:
https://github.com/ondata/italian-public-sector-pnrr-data-guide/tree/main/data/italia-domani/parquet

L’URL di accesso diretto ai file ha questa struttura:
https://raw.githubusercontent.com/ondata/italian-public-sector-pnrr-data-guide/refs/heads/main/data/italia-domani/parquet/Nome_File.parquet

Quindi ad esempio l’URL del dataset dei progetti è:
https://raw.githubusercontent.com/ondata/italian-public-sector-pnrr-data-guide/refs/heads/main/data/italia-domani/parquet/PNRR_Progetti.parquet

E la query per conteggiare i progetti è quindi:

SELECT COUNT(*) AS numero_progetti
FROM
'https://raw.githubusercontent.com/ondata/italian-public-sector-pnrr-data-guide/refs/heads/main/data/italia-domani/parquet/PNRR_Progetti.parquet';

Il database DuckDB è stato implementato creando una vista per ogni file parquet presente nella suddetta cartella:

CREATE
OR replace view "PNRR_Progetti" AS
SELECT
  *
FROM
  read_parquet(
    'https://raw.githubusercontent.com/ondata/italian-public-sector-pnrr-data-guide/refs/heads/main/data/italia-domani/parquet/PNRR_Progetti.parquet'
  );

Due esempi di accesso “live”

Un database così strutturato, dà la possibilità di abilitare l’accesso ai dati in modo “live”, ovvero senza dover scaricare il file e interrogarlo in locale.

Due applicazioni web, che consentono di accedere a risorse remote e interrogarle, lanciando una versione di DuckDB nel browser, senza dovere installare nulla sono queste due:

• la DuckDB Shell;
• il SQL Workbench.

In entrambi i casi basta prima dare il comando di ATTACH per collegare il database DuckDB remoto, e poi fare tutte le query che si vogliono.

Ad esempio, per la tabella pivot vista sopra, basterà per entrambi i casi:

ATTACH 'https://raw.githubusercontent.com/ondata/italian-public-sector-pnrr-data-guide/refs/heads/main/data/italia-domani/parquet/pnrr.db' as pnrr (READ_ONLY);

PIVOT (
  SELECT
    loc."Descrizione Regione" AS Regione,
    p.Missione
  FROM
    "pnrr"."PNRR_Progetti" p
    LEFT JOIN (
      SELECT
        DISTINCT CUP,
        "CODICE Locale Progetto",
        "Descrizione Regione"
      FROM
        "pnrr"."PNRR_Localizzazione"
    ) loc ON p.CUP = loc.CUP
    AND p."Codice Locale Progetto" = loc."CODICE Locale Progetto"
) ON Missione ORDER BY REGIONE;

Ed è interessante il fatto che le query costruite in questo modo, possano essere condivise con altre persone con un link, come questi due (sotto le immagini con l’anteprima dei risultati):

• DuckDB shell;
• SQL Workbench.

Lo strumento consigliato

Una cosa comodissima di questa modalità di accesso ai dati PNRR, è che è possibile leggerli nel modo preferito: con un client SQL come DBeaver da installare sulla propria macchina, con un client web come DuckDB Shell o SQL Workbench, con un linguaggio di programmazione come Python o R, ecc. e anche da riga di comando.

Per chi è abituato a lavorare da riga di comando, un ottimo strumento è il sorprendente e comodissimo Harlequin, gratuito e open source, installabile su qualsiasi sistema operativo, e in grado di accedere a decine di database, tra cui DuckDB.

Note conclusive

In questo post si vuole sottolineare la comodità di accedere a una banca dati, a partire da un file piccolo e senza rinunciare alla possibilità di costruire analisi complesse e ricche.
Non è la modalità facile e unica con cui capire tutto sui numeri del PNRR, ma si ha la possibilità di fare un primo passo, e di farlo in modo molto più semplice di quanto si possa pensare.

Ci sono alcuni requisiti propedeutici: approfondire come è strutturato il PNRR, leggere i metadati delle tabelle (in ogni pagina dei dati, c’è un link ai metadati, vedi Figura 8), e conoscere il linguaggio SQL.

Questo è un primo rilascio del database, per mostrare un caso d’uso “tecnico”. Al momento non è una risorsa su cui è pianificato un aggiornamento automatico e non è stato fatto alcun controllo di qualità.
In prospettiva è probabile che verrà creata una procedura automatica per aggiornare il database, e verrà migliorata la qualità dei dati con verifiche sulla coerenza dello schema dati.

I file sorgente, pubblicati su Italiadomani hanno alcuni problemi, di facile risoluzione, a da conoscere:

• l’encoding dei file CSV. È nella gran parte dei casi UTF-8, ma in alcuni casi non è così e bisogna fare attenzione per l’accesso e l’eventuale conversione;
• l’importante file CSV sui “Soggetti dei progetti del PNRR” - che fra l’altro è uno di quelli di dimensioni maggiori - contiene diverse righe non corrette, con un numero di colonne non compatibile con lo schema.

Riprendo infine una riflessione già fatta nell’apprezzato post “Gestire file CSV grandi, brutti e cattivi”: con uno sforzo piccolo e un po’ di cura, è possibile pubblicare dati in modalità che ampliano di molto il numero di persone che possono accedervi e utilizzarli in modo efficace.
Ad esempio:

• questi file potrebbero pure essere pubblicati su un bucket di Amazon S3 (o altre modalità simili), e DuckDB (o altri client) potrebbe leggerli da lì, con grande rapidità;
• si potrebbero pubblicare anche in formato compresso, ad esempio in csv.gz, o ancora meglio in formati efficienti e specializzati per l’analisi, come il parquet;
• si potrebbe pubblicare anche un unico file in formato DuckDB, con tutte le tabelle del PNRR, con la corretta definizione dei tipi di campo, con definite le chiavi primarie, le chiavi esterne, ecc..

Scaricare i file

L’ho fatto in blocco. Ho prima esplorato un po’ la pagina e ho notato che tutti i file hanno un URL che inizia con la stringa /modules e termina per .zip. Allora ho iniziato dall’estrarre la lista di questi file, usando l’espressione regolare /modules.+.zip:

Supponiamo di lavorare in una cartella immobili_pubblici:

mkdir immobili_pubblici
cd immobili_pubblici

# usiamo la variabile $folder per tener traccia della cartella di lavoro

folder=$(pwd)

URL="https://www.de.mef.gov.it/it/attivita_istituzionali/patrimonio_pubblico/censimento_immobili_pubblici/open_data_immobili/dati_immobili_2019.html"

# Otteniamo il file con i cookies del sito per poter accedere successivamente
mkdir tmp
curl -c "${folder}/tmp/cookies.txt" "$URL"

curl -s -b "${folder}/tmp/cookies.txt" -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36' "$URL" | grep -P -o '/modules.+.zip' | tee "${folder}/tmp/filelist.txt"

In output si ottiene (ne metto soltanto una piccola parte):

/modules/documenti_it/attivo_patrimonio/2019/open_data_imm/Imm_Camere_di_commercio_ed_Unioni_di_Camere_di_Commercio_2019.zip
/modules/documenti_it/attivo_patrimonio/2019/open_data_imm/Imm_Province_e_Citta_Metropolitane_2019.zip
/modules/documenti_it/attivo_patrimonio/2019/open_data_imm/Imm_Enti_Locali_del_Servizio_Sanitario_Nazionale_2019.zip
/modules/documenti_it/attivo_patrimonio/2019/open_data_imm/Imm_Amministrazioni_Regionali_2019.zip
/modules/documenti_it/attivo_patrimonio/2019/open_data_imm/Imm_Universita_2019.zip
/modules/documenti_it/attivo_patrimonio/2019/open_data_imm/Imm_Amministrazioni_Comunali_ABRUZZO_2019.zip
/modules/documenti_it/attivo_patrimonio/2019/open_data_imm/Imm_Amministrazioni_Comunali_BASILICATA_2019.zip

Con la lista degli URL dei file disponibile, basta generare un while loop per scaricarli tutti (sempre con curl o wget).

mkdir -p "${folder}/data/raw" && cd "${folder}/data/raw/"

# Scarico tutti i file in filelist.txt
xargs -I '{}'  wget -c 'https://www.de.mef.gov.it{}' < "${folder}/tmp/filelist.txt"

cd "${folder}"

Elaborazione dei file scaricati

A partire dalla lista dei file zip scaricati, ancora una volta si può generare un while loop per estrarli tutti in una cartella temporanea.

find "${folder}/data/raw" -type f -name "*.zip" -exec unzip -j '{}' -d "${folder}/data/raw" \;

Una volta estratti tutti i file e in presenza di uno schema dati comune, è molto semplice creare un unico file di output, usando duckdb.
Il comando di base è:

duckdb --csv -c "SELECT * FROM read_csv_auto('${folder}/data/raw/*.csv')" >output.csv

Al primo tentativo però duckdb è andato in errore, per ragioni legate all’encoding dei caratteri dei file CSV, perché DuckDB supporta solo file CSV con encoding UTF-8.

Ma qual è l’encoding dei file CSV dell’Elenco dei beni immobili dichiarati dalle Amministrazioni Pubbliche? Purtroppo sul sito del Dipartimento non c’è traccia di questa informazione.
Nelle linee guida open data dell’Agenzia per l’Italia Digitale (AgID) è riportato:

è sempre necessario utilizzare una codifica standardizzata dei caratteri. In genere, UTF-8 è la codifica utilizzata nel web. È utile, in ogni caso, indicare qual è la codifica dei caratteri utilizzata.

In assenza dell’informazione si può provare a estrarre l’encoding facendo inferenza dai dati. Io in questi casi uso l’ottimo chardet, che per questi file ha dato come risultato la codifica Windows-1252.

Mappata la codifica di input li ho convertiti in UTF-8 con iconv:

mkdir -p "${folder}/data/raw/utf8"
cd "${folder}/data/raw"
find -type f -name "*.csv" -exec iconv -f Windows-1252 -t UTF-8 '{}' >'utf8/{}' \;

r=2830855
r_ita=r.toLocaleString('it-IT');
c=51
c_ita=c.toLocaleString('it-IT');
celle=(r*c).toLocaleString('it-IT');

Con la conversione di encoding fatta, si può lanciare il comando visibile in Lista 1 e ottenere il file output.csv con tutti i dati “uniti”.
Ma sono righe per colonne, ovvero di celle ed è meglio comprimere l’output, così come consigliato qui.

Si può modificare il comando di Lista 1 in questo modo:

duckdb -c "COPY (SELECT * FROM read_csv_auto('${folder}/data/raw/utf8/*.csv'))
TO 'beni_immobili_pubblici.csv.gz'"

In 20 secondi si ottiene un file CSV compresso di circa 68 MB. Non è un formato comodo per rapide elaborazioni, ma con gli strumenti giusti può sempre sorprendere.
Il summarize di duckdb viene eseguito ad esempio in 2 secondi, con una comodissima sintesi su di celle. Il file csv.gz di output è disponibile qui.

Per altri tipi di query, i tempi sarebbero molto più lunghi.

Se si vuole conciliare un’ottima compressione, con una grande velocità di interrogazione e analisi dei dati, si può scegliere come formato di output il Parquet.

Il comando per creare un file in questo formato è molto simile a quello per il CSV:

duckdb -c "COPY (
  SELECT
    *
  FROM
    read_csv_auto('${folder}/data/raw/utf8/*.csv')
) TO 'beni_immobili_pubblici.parquet'
(
  FORMAT PARQUET,
  COMPRESSION 'zstd',
  ROW_GROUP_SIZE 100_000
)"

In circa 25 secondi si ha in output un file Parquet di circa 55 MB, che si può interrogare molto rapidamente con tanti strumenti ed essenzialmente da tutti i linguaggi di programmazione; su questo Davide Taibi e io abbiamo scritto un articolo di approfondimento.

Creato il file Parquet, ho iniziato a fare le prime query e subito mi hanno dato fastidio tre cose:

1. i nomi delle colonne sono troppo human readable, con spazi, caratteri speciali e mescola di maiuscole e minuscole (Sup. aree pertinenziali (mq), Vinc. culturale/paesaggistico, Immobile Geo-Ref., ecc.);
2. alcuni campi numerici, come superficie e cubatura dei beni, risultano in output come stringhe;
3. si perde la traccia dei file di origine (il record xxx, da che file CSV di input ha origine?).

Per il punto 1, c’è l’eccezionale parametro normalize_names, che se impostato a TRUE converte i nome delle colonne in snake_case, con tutte le lettere minuscole, gli spazi sostituiti da _ e con rimossi i caratteri speciali.

Per il punto 2, si possono forzare i tipi di campo (parametro types) e il separatore dei decimali (parametro decimal_separator che per questi file di input è la ,).

Per il punto 3 si può usare il parametro filename, che se impostato a TRUE aggiunge una colonna con il nome del file di origine.

Mettendo tutto insieme, il comando per creare un file Parquet diventa:

duckdb -c "COPY (
  SELECT
    * REPLACE (regexp_replace(filename, '^.+/', '') AS filename)
  FROM
    read_csv_auto(
      '${folder}/data/raw/utf8/*.csv',
      filename = TRUE,
      types = { 'id_bene': 'VARCHAR',
      'id_compendio': 'VARCHAR',
      'latitudine': 'FLOAT',
      'longitudine': 'FLOAT',
      'superficie_mq': 'FLOAT',
      'cubatura_mc': 'FLOAT',
      'sup_aree_pertinenziali_mq': 'FLOAT',
      'superficie_di_riferimento_mq': 'FLOAT' },
      normalize_names = TRUE,
      decimal_separator = ','
    )
) TO 'beni_immobili_pubblici.parquet' (
  FORMAT PARQUET,
  COMPRESSION 'zstd',
  ROW_GROUP_SIZE 100_000
)"

Nella Lista 2 è stato aggiunto il comando REPLACE (regexp_replace(filename, '^.+/', '') AS filename). Questo comando rimuove il percorso del file e lascia solo il suo nome.

Il file parquet di output è disponibile qui.

Analisi geografica dei dati

Il 99% dei dati è associato a una coppia di coordinate geografiche, con le colonne latitudine e longitudine. Non entro qui nel merito sulla qualità (tutta da verificare) di questi dati, ma voglio mostrare come può esser comodo anche in questo caso duckdb.
Questa applicazione ha infatti anche l’estensione spaziale ed è quindi possibile fare delle interrogazioni geografiche.

Quanti sono ad esempio i beni immobili che ricadono in provincia di Bergamo?

Con questa banca dati c’è un modo “tradizionale” per farlo, perché è presente la colonna provincia_del_bene e basta fare una query come quella di sotto, per sapere in 0,1 secondi che sono 39.154:

duckdb -c "SELECT count(*) conteggio
FROM read_parquet('beni_immobili_pubblici.parquet')
WHERE provincia_del_bene = 'BERGAMO'"

Ma immaginiamo di non avere la colonna provincia_del_bene e avere soltanto le coordinate dei beni e il poligono che rappresenta la provincia di Bergamo.
Questo poligono si può ottenere in formato geojson dal comodo confini-amministrativi.it e ha questo URL:
https://confini-amministrativi.it/api/v2/it/20240101/unita-territoriali-sovracomunali/16.geo.json

Voglio arricchire il risultato e conteggiare i beni per epoca di costruzione e suddividerli per utilizzo del bene. La query spaziale che in pochi secondi restituisce il risultato è la seguente:

duckdb -c "PIVOT (
  SELECT
    id_bene,
    epoca_costruzione,
    utilizzo_del_bene
  FROM
    'beni_immobili_pubblici.parquet' AS immobili
    JOIN ST_READ(
      'https://confini-amministrativi.it/api/v2/it/20240101/unita-territoriali-sovracomunali/16.geo.json'
    ) AS bergamo ON ST_Within(ST_POINT(longitudine, latitudine), bergamo.geom)
) ON utilizzo_del_bene USING COUNT(id_bene)
GROUP BY epoca_costruzione
ORDER BY epoca_costruzione"

A partire da un sottoinsieme di colonne - id_bene, epoca_costruzione e utilizzo_del_bene - viene creata una tabella pivot (vedi Tabella 1). Questa organizza i dati in modo che ogni tipologia di utilizzo dei beni (utilizzo_del_bene) diventi una colonna separata. Le celle della tabella mostrano il numero di beni per ciascuna combinazione di epoca di costruzione (epoca_costruzione) e utilizzo, utilizzando la funzione di aggregazione COUNT(id_bene). Infine, i risultati vengono raggruppati per epoca di costruzione e ordinati in base a questa colonna.

È un esempio di base, in cui è evidente come è possibile combinare dati geografici e non, in modo molto semplice e veloce, anche da fonti remote da raggiungere in HTTP.

Nel contesto “spaziale” può essere utile creare un file in formato geografico, da usare su un sistema GIS.
Ad esempio per creare un file in formato FlatGeobuf, progettato per memorizzare dati geografici in modo efficiente e compatto, si può usare una sintassi simile a quella vista sopra:

duckdb -c "COPY (
  SELECT
    *,
    ST_POINT(longitudine, latitudine) geom
  FROM
    'beni_immobili_pubblici.parquet'
  WHERE
    longitudine IS NOT NULL
    OR latitudine IS NOT NULL
) TO 'output.fgb' WITH (FORMAT GDAL, DRIVER 'FlatGeobuf', SRS 'EPSG:4326')"

Il formato parquet ha anche la sua versione geografica, il GeoParquet, molto compresso e molto veloce da interrogare. Per crearlo non si può ancora usare duckdb, ma si può usare il comando ogr2ogr di GDAL:

ogr2ogr -f parquet -lco COMPRESSION=ZSTD beni_immobili_pubblici_geo.parquet output.fgb

Il file GeoParquet è disponibile qui, pesa soltanto 80 MB, ed è visualizzabile con QGIS e altre applicazioni GIS.

Alcune considerazioni sui dati

È possibile combinare rapidamente e facilmente questi file per creare una base di dati efficiente e pronta per l’analisi e le interrogazioni. Questo avviene non solo grazie a strumenti come DuckDB, ma anche perché i file di input condividono uno schema unico, che permette di unire i file CSV senza difficoltà.

E come scritto nelle conclusioni di un “famoso” articolo:

Con le dovute precauzioni, con gli strumenti giusti, con un corredo informativo adeguato e per dimensioni non eccessive, (il CSV) può essere un formato comodo e pratico. Descrivendolo, “standardizzandolo” e comprimendolo, diventa molto più usabile.

A proposito di “descrizione”, il Dipartimento dell’Economia pubblica un file dizionario, uno schema, ma soltanto in formato PDF. Quindi non è possibile creare una procedura automatica di importazione dei dati, in cui sono ad esempio impostati correttamente i tipi di campo (testuali, numerici, ecc.).

Sui CSV sarebbe ideale:

• documentare qual è l’encoding dei caratteri;
• avere come encoding l’UTF-8;
• evitare l’utilizzo di spazi, virgolette o altri caratteri speciali nei nomi dei campi;
• dichiarare quali sono i separatori di campo e dei decimali;
• pubblicarli anche non separati in 30 file, ma in unico file compresso gzip.

Questi preziosi dati inoltre non sono ancora disponibili anche nel portale nazionale dei dati aperti. Ed è un peccato in termini di valorizzazione e diffusione degli stessi. Questo è anche un requisito previsto dalle linee guida nazionali sui dati aperti.

Interrogando la banca dati si ha evidenza di alcuni beni con coordinate geografiche incoerenti con gli attributi territoriali dichiarati in altri campi. Ad esempio il bene con id_bene=2442321, ha coordinate YX 37.926914 e 15.28337, ovvero in provincia di Messina; ma nel campo comune_del_bene il valore è “Frascati”.

Aggiungo anche una nota sull’opportunità di un formato aggiuntivo di pubblicazione: il tante volte citato Parquet.
È diventato uno dei formati standard per consentire a chiunque di fare analisi rapide ed efficienti, anche su grandi quantità di dati, quasi su qualsiasi PC. E sarebbe ideale pubblicare la banca dati degli immobili pubblici anche in formato Parquet.
Un buon esempio da emulare è quello di OpenCoesione - uno dei portali di dati aperti più importanti in Italia - che da febbraio 2024 pubblica anche in questo formato.

Sono dati al 2019. Sarebbe interessante che fossero aggiornati con una frequenza maggiore, magari annuale.
Sul portale del Tesoro si legge “Fissata al 27 settembre 2024 la chiusura della rilevazione dei dati dei beni immobili pubblici riferiti al 31/12/2023” e quindi c’è da aspettarsi un prossimo aggiornamento.

Cosa cambia con DuckDB v1.1.0.

Oggi, 9 settembre 2024, a una settimana dalla pubblicazione di questo articolo, è stata rilasciata la versione 1.1.0 di DuckDB.

Risolve un bug che non consentiva di utilizzare pienamente il comodissimo parametro decimal_separator: si era costretti comunque a dichiarare esplicitamente il tipo di campo FLOAT come in Lista 2. Se si impostava decimal_separator = ',', DuckDB non era in grado di inferire correttamente i tipi campo FLOAT e li considerava sempre delle stringhe.
Ora, con la versione 1.1.0, basta dichiarare il separatore decimale e DuckDB sarà in grado di inferire correttamente i tipi campo FLOAT.

Sotto le due versioni del comando per creare il file Parquet:

duckdb -c "COPY (
  SELECT
    * REPLACE (regexp_replace(filename, '^.+/', '') AS filename)
  FROM
    read_csv_auto(
      '${folder}/data/raw/utf8/*.csv',
      filename = TRUE,
      normalize_names = TRUE,
      decimal_separator = ','
    )
) TO 'beni_immobili_pubblici.parquet' (
  FORMAT PARQUET,
  COMPRESSION 'zstd',
  ROW_GROUP_SIZE 100_000
)"

duckdb -c "COPY (
  SELECT
    * REPLACE (regexp_replace(filename, '^.+/', '') AS filename)
  FROM
    read_csv_auto(
      '${folder}/data/raw/utf8/*.csv',
      filename = TRUE,
      types = { 'id_bene': 'VARCHAR',
      'id_compendio': 'VARCHAR',
      'latitudine': 'FLOAT',
      'longitudine': 'FLOAT',
      'superficie_mq': 'FLOAT',
      'cubatura_mc': 'FLOAT',
      'sup_aree_pertinenziali_mq': 'FLOAT',
      'superficie_di_riferimento_mq': 'FLOAT' },
      normalize_names = TRUE,
      decimal_separator = ','
    )
) TO 'beni_immobili_pubblici.parquet' (
  FORMAT PARQUET,
  COMPRESSION 'zstd',
  ROW_GROUP_SIZE 100_000
)"

L’esempio di OpenCoesione

OpenCoesione è un progetto nazionale il cui obiettivo è promuovere trasparenza, collaborazione e partecipazione riguardo alle politiche di coesione nel paese.

È da sempre uno dei progetti di riferimento per l’apertura dei dati in Italia, che ha fatto sempre scuola.
E lo ha fatto ancora una volta: dal 21 febbraio 2024 ha iniziato a pubblicare la propria banca dati anche in formato Parquet.

Ed è probabilmente il primo progetto italiano di una Pubblica Amministrazione a farlo, e sicuramente il primo con una banca dati di questa ricchezza e dimensione.

➡️ Stiamo parlando del catalogo dei Progetti con tracciato esteso, disponibile qui, anche in formato Parquet: https://opencoesione.gov.it/it/opendata/#!progetti_section

Abbiamo sottolineato come il formato Parquet sia molto più efficiente per l’accesso e l’analisi dei dati, rispetto al CSV.
Questa caratteristica è molto evidente, soprattutto per tabelle molto grandi, come questa dei progetti di OpenCoesione, composta da circa 2.000.000 di righe x 200 colonne.

È possibile ad esempio interrogarla, per avere restituito il totale di finanziamento pubblico per ogni ciclo di finanziamento (vedi Tabella 1), e avere la risposta in 0,07 secondi.

E questa rapidità si ottiene sul proprio computer di lavoro, senza che sia necessario mettere in campo risorse di calcolo particolarmente potenti e dispendiose sul cloud.
O senza che sia necessario importare il file in un database relazionale, con tutte le operazioni di trasformazione e pulizia dei dati che questo comporta evitando anche l’installazione e la configurazione di un db relazionale.

Come leggere un file Parquet

Se non hai mai sentito parlare di questo formato, probabilmente penserai che per te sia impossibile usarlo per leggere, filtrare, analizzare, ecc. i dati di OpenCoesione. Penserai che è un formato solo per “tecnici”.
Niente di più sbagliato! Leggere un file Parquet è facile e veloce, e paradossalmente è più necessario l’aiuto di un tecnico per leggere un file CSV di 4,5 Gigabyte (come quello dei progetti di OpenCoesione). Per la gran parte degli utenti è infatti impossibile leggere un file di queste dimensioni, anche con un buon Personal Computer.
E non pensare di utilizzare programmi come Excel, hanno un limite di circa 1.000.000 di righe per foglio di lavoro (tante ma non sufficienti nel nostro caso in cui ne abbiamo circa 2.000.000).

Al doppio click

Per visualizzare un file Parquet con un semplice doppio click, puoi usare Tad, un visualizzatore di file Parquet (e anche CSV, SQLite e DuckDB) open source, gratuito e disponibile per Windows, Mac e Linux.

Una volta installato, basterà fare doppio click sul file per aprirlo e visualizzarne il contenuto (vedi Figura 1). Questo di OpenCoesione è un file grande e sarà necessario qualche secondo.

Tra le funzionalità di Tad c’è anche la possibilità di filtrare i dati. Nell’immagine di sopra:

1. il filtro applicato;
2. il modulo per costruire il filtro;
3. il mini report sul numero di righe filtrate.

Con un client visuale SQL

SQL è uno dei linguaggi più diffusi e standard per l’interrogazione e la manipolazione dei dati. È nato 50 anni fa, quindi c’è un gran numero di libri, tutorial, corsi, forum, cheatsheet, ecc. per imparare a usarlo, e ci sono centinaia di applicazioni, librerie, framework, dedicati.

Un file Parquet è interrogabile con SQL, quindi tutti possono usarlo per interrogare e analizzare i dati in questo formato.

Un’applicazione SQL “visuale”, open source e multi-piattaforma, che puoi usare per interrogare un file Parquet è DBeaver. Questi i passi che dovrai seguire per interrogare un file Parquet con DBeaver:

• scaricarla e installarla (https://dbeaver.io/download/);
• lanciarla, aprire il menu Database e selezionare New Database Connection;
• cercare DuckDB, selezionarlo e fare click su Next;

• impostare :memory: come Path;

• fare click su Test Connection, che verificherà la necessità di installare eventuali componenti mancanti. Se manca qualcosa, installarla facendo click su Download.

A questo punto, nel riquadro di sinistra “Database Navigator” dovrebbe apparire una connessione al database DuckDB memory.

Per lanciare una query non ti resta che fare click con il pulsante destro del mouse su memory, selezionare SQL Editor, poi New SQL script e scrivere la tua prima query, per leggere ad esempio le prime 5 righe del file Parquet:

SELECT  *
1FROM "c:\tmp\progetti_esteso_20230831.parquet"
LIMIT 5

1

Per puntare al file, è stato inserito il percorso del file Parquet.

La query di esempio di sopra, con i dati per ciclo di finanziamento di Tabella 1, è invece il risultato di questa query, che puoi provare a lanciare in DBeaver:

SELECT oc_descr_ciclo Ciclo, SUM(finanz_totale_pubblico) "Totale finanziamento pubblico (€)"
FROM "C\tmp\progetti_esteso_20230831.parquet"
GROUP BY oc_descr_ciclo
ORDER BY ciclo;

A riga di comando con DuckDB

Se preferisci lavorare da riga di comando, puoi usare lo straordinario DuckDB, un sistema di gestione di database relazionali (RDBMS), che supporta il formato Parquet.

Per installarlo, puoi seguire le istruzioni disponibili qui: https://duckdb.org/docs/installation.

Per usarlo non ti resta che lanciare il comando duckdb e scrivere la tua prima query.

Potrebbe essere diversa dalle precedenti, come quella comodissima per avere un riepilogo rapido dei dati, basata sul comando SUMMARIZE di DuckDB: restituisce per ogni campo, il tipo di campo e una ricca serie di calcoli, il numero di valori distinti, la percentuali di valori nulli, il minimo, il massimo, la media, ecc..
Qui sotto la sintassi della query e un esempio di output in Figura 6.

SUMMARIZE select * from 'progetti_esteso_20231231.parquet';

È un comando di grande comodità, che si può usare ad esempio per sapere quali sono le colonne che hanno meno del 10% di valori nulli:

SELECT * FROM (summarize select * from 'progetti_esteso_20231231.parquet')
WHERE
null_percentage <10;

Sono 86 colonne su circa 200 e si potrebbe scegliere di concentrarsi su questo campione più ristretto e velocizzare ulteriormente le operazioni.

E sempre da SUMMARIZE ci si può fare un’idea delle colonne più “datose”, ovvero quelle con meno valori distinti, che sono spesso quelle più interessanti per fare analisi e visualizzazioni, perché consentono di definire categorie (le regioni, il settore, la natura, ecc.).

SELECT * FROM (summarize select * from 'progetti_esteso_20231231.parquet')
WHERE
approx_unique <30;

Nota

SUMMARIZE restituisce in realtà un valore approssimativo, ma molto vicino al reale, dei valori distinti. Questo per ottimizzare i tempi di esecuzione.

A riga di comando con VisiData

VisiData è “il coltellino svizzero per i dati, che probabilmente non conosci”. E proprio con il formato Parquet se ne ha un’idea.

Basta scrivere vd nome_file.parquet e premere INVIO, per aprire il file e iniziare a esplorarlo, filtrarlo, analizzarlo, ecc..
Con il file di OpenCoesione ci mette qualche secondo, perché è un file grande, ma poi si può iniziare a esplorarlo e ad esempio avere restituito il totale di finanziamento pubblico per regione.

# importa modulo duckdb
import duckdb

# definisci la query
query= """
  SELECT oc_descr_ciclo Ciclo, SUM(finanz_totale_pubblico) "Totale finanziamento pubblico (€)"
  FROM 'progetti_esteso_20231231.parquet'
  GROUP BY oc_descr_ciclo
  ORDER BY ciclo;
  """

# esegui la query e trasforma il risultato in un DataFrame
riepilogo_finanziamento=duckdb.query(query).df()

db = DuckDBClient.of({
  progetti: FileAttachment("progetti_esteso_20231231.parquet")
})

viewof tbl_stato_proggetti = {
  const data = await db.query(`SELECT
  OC_STATO_PROGETTO AS "Stato Progetto", count(*) Conteggio FROM progetti
  GROUP BY OC_STATO_PROGETTO
  ORDER BY Conteggio DESC`)
  return Inputs.table(data, {height: 200, layout: "auto",locale: "it-IT"})
}

data = FileAttachment("observable.csv").csv({ typed: true })
Inputs.table(data,{locale: "it-IT"})

viewof graficoStatoProgetti = {
  const data = await db.query(`SELECT
  OC_STATO_PROGETTO AS "Stato Progetto", count(*) AS Conteggio FROM progetti
  GROUP BY OC_STATO_PROGETTO
  ORDER BY Conteggio DESC`);

  // Definisci una funzione di formattazione per il locale "it-IT"
  const formatter = new Intl.NumberFormat("it-IT").format;

  // Crea il grafico a barre utilizzando Plot con formattazione personalizzata
  return Plot.plot({
    marks: [
      Plot.barY(data, {x: "Stato Progetto", y: "Conteggio", fill: "Stato Progetto"}),
    ],
    width: 600,
    height: 400,
    marginLeft: 50,
    color: {
      legend: true
    },
    x: {
      label: "Stato Progetto"
    },
    y: {
      label: "Conteggio",
      // Usa la funzione di formattazione per le etichette dell'asse Y
      tickFormat: formatter
    },
    style: {
      overflow: "visible"
    }
  });
}

viewof graficoStatoProgetti = {

  // Definisci una funzione di formattazione per il locale "it-IT"
  const formatter = new Intl.NumberFormat("it-IT").format;

  // Crea il grafico a barre utilizzando Plot con formattazione personalizzata
  return Plot.plot({
    marks: [
      Plot.barY(data, {x: "Stato Progetto", y: "Conteggio", fill: "Stato Progetto"}),
    ],
    width: 600,
    height: 400,
    marginLeft: 50,
    color: {
      legend: true
    },
    x: {
      label: "Stato Progetto"
    },
    y: {
      label: "Conteggio",
      // Usa la funzione di formattazione per le etichette dell'asse Y
      tickFormat: formatter
    },
    style: {
      overflow: "visible"
    }
  });
}

Note finali

Abbiamo scritto questo post, perché crediamo che il formato Parquet sia un’opportunità per molte persone di migliorare la propria esperienza con i dati. E non solo per chi è “esperto”, ma anche per chi ha delle competenze di base con SQL. Perché come è evidente le modalità di accesso sono molteplici e adatte a diversi livelli di competenza.

Il fatto che OpenCoesione sia stato il primo progetto a scegliere di pubblicare i propri dati in formato Parquet è un segnale molto importante: siamo confidenti che possa essere seguito presto da altre amministrazioni e organizzazioni.

Non avremmo mai immaginato che la scrittura di questo altro post avrebbe contribuito a generare questa bella conseguenza. E per questo gli autori del post e tutta l’associazione onData ringraziano OpenCoesione e il suo staff per essere stati prima in ascolto e poi protagonisti di questa scelta.

Gli Open Data di OpenCUP

Sul sito di OpenCUP, è disponibile da tempo la sezione OpenData. Con questo aggiornamento, sono stati pubblicati i nuovi dati, in formato CSV e XML.
Bisogna scorrere la pagina e guardare la sezione “Progetti OpenData”.

In questo post, mostreremo rapidamente come esplorare il file “Complessivo” di tutti i progetti.

È un file “grande”. Quello in formato CSV è compresso come zip: pesa circa 2.9 GB, e decompresso 23 GB. È probabilmente il file CSV più grande (o uno dei più grandi), pubblicato in una sezione open data di un sito di una Pubblica Amministrazione italiana.

Non è gestibile con un comune foglio di calcolo, né con tanti altri strumenti.
A riga di comando invece si può osservare, filtrare, e analizzare, con grande leggerezza e rapidità.

unzip -p "OpenData Complessivo.zip"  | awk '{if(gsub(/\|/,"&") == 90) print}' >open_cup_corrette.csv

La prima lettura

Un file così grande richiede un po’ di tempo per il download e poi per la decompressione.
Per fortuna però è possibile fare una prima lettura immediata, dopo il download, senza decomprimere per intero il file.

Si può usare l’utilty unzip e lanciare il comando unzip -p nomefile.zip. Ma per una prima esplorazione, l’ideale è leggere soltanto le prime righe. E per fortuna esiste il comando head, che fa proprio questo e di default legge le prime 10 righe.:

unzip -p "OpenData Complessivo.zip"  | head

E subito si vedrà qualcosa come in Figura 2, che ci restituisce già elementi interessanti:

• i nomi dei campi;
• il separatore è il |

Estrazione di un campione

Viste le prime 10 righe e mappate le caratteristiche del CSV, il passo consigliato successivo è quello dell’estrazione di un campione di righe più ampio, per fare un’analisi più approfondita.
Con una piccola modifica al comando soprastante, si possono ad esempio estrarre le prime 10.000 righe e salvarle in un nuovo file CSV (in 0.055 secondi):

unzip -p "OpenData Complessivo.zip"  | head -n 10000 > campione.csv

E questo nuovo file sarà esplorabile con foglio elettronico o con altri strumenti. A me ad esempio piace usare VisiData per queste cose, con cui di solito subito osservo un po’ di dati sui campi (i valori nulli, i valori distinti, ecc.).

Filtrare l’intero file

L’esplorazione del campione consente di farsi un’idea di quali sono quei campi/colonne che fanno un po’ da elementi “categorici”, da usare come filtro per estrarre solo le righe che ci interessano.
Tra questi ad esempio il campo SOGGETTO_TITOLARE, con il nome della Pubblica Amministrazione, titolare del progetto, che posso usare per estrarre ad esempio tutti i progetti in cui la PA titolare è “REGIONE AUTONOMA DELLA SICILIA”.

L’utility grep - una delle più importanti di tutti i tempi - è perfetta per questo scopo.

unzip -p "OpenData Complessivo.zip"  | grep -P '\|REGIONE AUTONOMA DELLA SICILIA\|' >regione_siciliana.csv

Si applica un filtro al file CSV zippato di input, e per ogni riga in cui è presente la stringa REGIONE AUTONOMA DELLA SICILIA tra due caratteri |, viene salvata nel file regione_siciliana.csv. Nel filtro è stato inserito il carattere \ prima del |, perché | è un carattere speciale.
E in un minuto e mezzo circa, sul mio buon (ma normale) PC ottengo 392.395 progetti associati alla Regione Siciliana, dopo aver letto 9,5 milioni di righe.

Ma così c’è un problema: si perde l’intestazione del file, si perdono i nomi delle colonne. C’è allora da modificare il filtro ed estrarre anche la prima riga. E tutto questo è facile, grazie all’esplorazione fatta, in cui ho visto che la prima riga contiene ad esempio la stringa “ANNO_DECISIONE”.
Il nuovo comando sarà:

unzip -p "OpenData Complessivo.zip"  | \
grep -P '(ANNO_DECISIONE|\|REGIONE AUTONOMA DELLA SICILIA\|)' >regione_siciliana.csv

Così vengono cercate tutte le righe che contengono o ANNO_DECISIONE o |REGIONE AUTONOMA DELLA SICILIA| e quindi viene restituito un CSV con i nomi delle colonne e le righe filtrate.

Un file parquet a partire dai dati filtrati

Questo ultimo passo, perché è utile avere a disposizione questi dati anche in un formato più efficiente, come il parquet, che è un formato di file binario, compresso e colonnare, che permette di ridurre notevolmente lo spazio occupato e di velocizzare le operazioni di lettura e analisi.
Per chi non ne ha mai sentito parlare, ne ho scritto lungamente qui.

L’utility stavolta è DuckDB. E il comando è:

unzip -p "OpenData Complessivo.zip"  | \
grep -P '(ANNO_DECISIONE|\|REGIONE AUTONOMA DELLA SICILIA\|)' | \
duckdb -c "COPY(
  SELECT * FROM read_csv_auto('/dev/stdin', delim = '|')
) TO 'regione_siciliana.parquet' (
  FORMAT 'parquet',
  COMPRESSION 'ZSTD',
  ROW_GROUP_SIZE 100000
)"

Alcune note su questo comando (messo su più righe, per migliorare la leggibilità):

• si parte dal comando precedente, con il filtro per estrarre il campione;
• si passa l’output a duckdb, che legge il CSV da stdin e nel SELECT al posto del nome del file è necessario inserire '/dev/stdin', che è il file virtuale che rappresenta lo standard input;
• si usa il comando COPY per copiare questa selezione in un file parquet chiamato regione_siciliana.parquet, con compressione ZSTD e con un ROW_GROUP_SIZE di 100000.

Tutto circa sempre in un minuto e mezzo, con un file di output che pesa circa 33 MB, contro i 530 MB del file CSV.

Importazione dell’intero file

Il file CSV completo ha, alla data di oggi (15 Febbraio 2024) un problema a 2 righe (su 17.065.848), che hanno un numero errato di colonne (91 anziché 90). Per poterlo importare occorre filtrare solo le linee che hanno un numero di colonne corretto.

È possibile importare il file in un DB in formato DuckDB con i seguenti comandi (occorre avere il file CSV su disco per limitare l’occupazione di RAM):

unzip "OpenData Complessivo.zip"
awk -F\| '{if (NF-1 == 90) { print } }' < TOTALE.csv > TOTALEfix.csv
duckdb OpenCUP.db -c "CREATE TABLE OpenCUP AS SELECT * FROM read_csv_auto('TOTALEfix.csv',delim='|',header = true,dateformat='%d-%b-%y',parallel=FALSE,types={'DATA_ULTIMA_MODIFICA_SSC':'DATE','DATA_ULTIMA_MODIFICA_UTENTE':'DATE','DATA_CHIUSURA_REVOCA':'DATE','DATA_GENERAZIONE_CUP':'DATE'});"

Notare che è stato esplicitato il formato delle date, e quali sono i campi di tipo DATE, in modo che DuckDB converta correttamente i campi relativi, che sono del tipo 01-JAN-15. Questo permette sia una migliore gestione dei dati, che una rappresentazione più efficiente in termini di spazio su disco.

Il file DuckDB risultante, a fronte di un CSV di 23.946.237.777 byte, è 4.431.294.464 byte, con una riduzione a circa 1/6, merito del formato binario contro quello ASCII.

time duckdb OpenCUP.db -c "SELECT ANNO_DECISIONE, COUNT(*) FROM OpenCUP GROUP BY ANNO_DECISIONE" > /dev/null

real    0m0,039s
user    0m0,156s
sys 0m0,063s

duckdb OpenCUP.db  -c "COPY (SELECT * FROM OpenCUP) TO 'OpenCUP.parquet' (FORMAT 'PARQUET', CODEC 'ZSTD');

duckdb OpenCUP.db  -c "SET preserve_insertion_order=false;COPY (SELECT * FROM OpenCUP) TO 'OpenCUP.parquet' (FORMAT 'PARQUET', CODEC 'ZSTD');"

time duckdb -s 'SELECT ANNO_DECISIONE, COUNT (*) FROM read_parquet("OpenCUP.parquet") GROUP BY ANNO_DECISIONE;' > /dev/null

real    0m0,074s
user    0m0,372s
sys 0m0,043s

Vendor ID:               GenuineIntel
  Model name:            12th Gen Intel(R) Core(TM) i7-1280P
    CPU family:          6
    Model:               154
    Thread(s) per core:  2
    Core(s) per socket:  10

duckdb -c "SET preserve_insertion_order=false;COPY(SELECT * FROM read_csv_auto('TOTALE.csv',delim='|',header = true,ignore_errors=true,dateformat='%d-%b-%y',parallel=FALSE,types={'DATA_ULTIMA_MODIFICA_SSC':'DATE','DATA_ULTIMA_MODIFICA_UTENTE':'DATE','DATA_CHIUSURA_REVOCA':'DATE','DATA_GENERAZIONE_CUP':'DATE'})) TO 'opencup.parquet' WITH (FORMAT PARQUET, COMPRESSION ZSTD,ROW_GROUP_SIZE 100000)"

Note finali

Questa descritta è soltanto una modalità per fare soprattutto una prima esplorazione e analisi di questo nuovo e importante aggiornamento dei dati di OpenCUP.
È utilissima per capire per cosa è possibile usare questi dati, quali sono le informazioni che ci interessano di più, che storia poter raccontare, che mappa creare, che dashboard realizzare, come usare l’intelligenza artificiale per arricchirli, come metterli in relazione con altri dati, ecc..

Ma sono dati grandi, e in produzione bisognerà andare un po’ oltre l’utilizzo delle eccezionali utility a riga di comando. In ogni caso DuckDB, se usato bene, fa già tanta tanta roba (partizionando il dataset originario in più file parquet, si ha disposizione tutto il dataset con una grandissima facilità di accesso e lettura).

Introduzione

Google ha lanciato a inizio dicembre del 2023 Gemini, il suo modello di intelligenza artificiale migliore. Può comprendere e combinare diversi tipi di informazioni, come testo, codice, audio, immagini e video.

Da poco sono disponibili le API e ho voluto fare qualche test di base, usando la riga di comando.

A seguire una mini guida per testarle

Connessione alla VPN

Per prima cosa bisogna connettersi alla VPN e scegliere come paese di connessione gli Stati Uniti.

Generare una chiave API

Una volta connessi dagli Stati Uniti è necessario generare una chiave API, per autenticarsi. Si può fare da questa pagina: https://makersuite.google.com/app/apikey.

Una volta generata - è una lunga stringa - è da archiviare da qualche parte.

Accesso alle API in REST, via cURL

È il modo più immediato e diretto. Si apre la shell e si manda una richiesta come questa, in cui si definisce prima una variabile con la chiave API e poi si lancia la chiamata.

# Una variabile dove inserire la chiave API
API_KEY="AIxxSyCnBOUyPuDLtjWY11HOwxxxxxxx"

# Lanciare la chiamata
curl -s "https://generativelanguage.googleapis.com/v1beta/models/gemini-pro:generateContent?key=$API_KEY" \
-H 'Content-Type: application/json' \
-X POST -d '{"contents": [{"parts":[{"text": "Creami tre nomi buffi per un gatto siamese con le orecchie molto grandi"}]}]}'

{
  "candidates": [
    {
      "content": {
        "parts": [
          {
            "text": "1. Dumbo\n2. Flitzer\n3. Elicottero"
          }
        ],
        "role": "model"
      },
      "finishReason": "STOP",
      "index": 0,
      "safetyRatings": [
        {
          "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
          "probability": "NEGLIGIBLE"
        },
        {
          "category": "HARM_CATEGORY_HATE_SPEECH",
          "probability": "NEGLIGIBLE"
        },
        {
          "category": "HARM_CATEGORY_HARASSMENT",
          "probability": "NEGLIGIBLE"
        },
        {
          "category": "HARM_CATEGORY_DANGEROUS_CONTENT",
          "probability": "NEGLIGIBLE"
        }
      ]
    }
  ],
  "promptFeedback": {
    "safetyRatings": [
      {
        "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
        "probability": "NEGLIGIBLE"
      },
      {
        "category": "HARM_CATEGORY_HATE_SPEECH",
        "probability": "NEGLIGIBLE"
      },
      {
        "category": "HARM_CATEGORY_HARASSMENT",
        "probability": "NEGLIGIBLE"
      },
      {
        "category": "HARM_CATEGORY_DANGEROUS_CONTENT",
        "probability": "NEGLIGIBLE"
      }
    ]
  }
}

Se si espande l’esempio di JSON qui sopra, la parte con la risposta alla chiamata è quella contenuta in .candidates[0].content.parts[0].text.
Si può modifcare il comando di sopra e usare jq per estrarla:

curl -s "https://generativelanguage.googleapis.com/v1beta/models/gemini-pro:generateContent?key=$API_KEY" \
-H 'Content-Type: application/json' \
-X POST -d '{"contents": [{"parts":[{"text": "Creami tre nomi buffi per un gatto siamese con le orecchie molto grandi"}]}]}' | \
jq '.candidates[0].content.parts[0].text' -r

In output si avrà qualcosa come:

1. Dumbo
2. Flitzer
3. Elicottero

Non vi resta che testare e divertirvi, con esempi migliori del mio. La cosa interessante è che è un’API REST, quindi si può usare da qualsiasi linguaggio di programmazione.

Utilizzare l’eccezionale LLM via cli

LLM è un’utility a riga di comando e una libreria Python per interagire con Large Language Models (LLM), ovvero modelli di linguaggio avanzati.
Permette di utilizzare sia API remote per accedere a modelli ospitati su server esterni, sia modelli installati e eseguiti localmente sul proprio computer.

Ed è possibile quindi usarlo per connettersi con il Large Language Models di Google Gemini.

🙏 L’autore della cli LLM è quel genio di Simon Willison.

pip3 install llm

llm install llm-gemini

pip3 install llm-gemini

llm keys set gemini

llm -m gemini-pro "Creami tre nomi buffi per un gatto siamese con le orecchie molto grandi"

- Dumbo
- Elio
- Pipistrello

echo 'Dieci nomi per un blog che parla della riga di comando' | llm -m gemini-pro

1. Il Comando Centrale
2. Padronanza del Terminale
3. Il Mago della Riga di Comando
4. Il Domatore di Terminale
5. Il Maestro del Prompt
6. La Guida alla Riga di Comando
7. Il Tutorial del Terminale
8. Il Manuale del Terminale
9. Le Avventure di un SysAdmin
10. La Linea di Comando per Tutti

Linux MSI 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 GNU/Linux

llm -m gemini-pro "Questo è il mio sistema operativo: $(uname -a). Dimmi qualcosa di più, e dimmelo in markdown."

* **Kernel**: Linux 5.15.133.1-microsoft-standard-WSL2
    * Questo è il kernel Linux utilizzato per eseguire WSL2. È una versione modificata del kernel Linux 5.15 che è stato ottimizzato per l'esecuzione in un ambiente Windows.
* **Nome Host**: MSI
    * Questo è il nome del computer WSL2.
* **Versione**: #1 SMP Thu Oct 5 21:02:42 UTC 2023
    * Questa è la versione della build del kernel Linux utilizzata per eseguire WSL2.
* **Architettura**: x86_64
    * Questa è l'architettura del processore del computer WSL2.
* **Sistema Operativo**: GNU/Linux
    * Questo è il sistema operativo utilizzato per eseguire WSL2. GNU/Linux è una distribuzione Linux basata sul kernel Linux.

Chattare in modo interattivo

Per attivare una modalità interattiva, domande e risposte, come una chat, il comando è:

llm chat -m gemini-pro

Una volta attivato, si potrà attivare il dialogo in modalità chat (vedi Figura 1).

Il costo di Gemini Pro

Right now, developers have free access to Gemini Pro and Gemini Pro Vision through Google AI Studio, with up to 60 requests per minute, making it suitable for most app development needs. Vertex AI developers can try the same models, with the same rate limits, at no cost until general availability early next year, after which there will be a charge per 1,000 characters or per image across Google AI Studio and Vertex AI.

Fonte: https://blog.google/technology/ai/gemini-api-developers-cloud

Conclusioni

Il bello di questo tipo di accesso, è quello di poter creare in modo diretto e semplici, un utilizzo programmatico di questi strumenti. E la cosa è applicabile alla gran parte dei “Large Language Model” (LLM), ovvero questi tipi di AI che si concentrano sulla comprensione e generazione del linguaggio naturale umano.

Questo post ha lo scopo soltanto di farvi due passi - non di più - nel nuovo motore di AI di Google, Gemini.
L’utility llm è un gioiellino e consente di fare molto, ma molto di più.

😉 Su entrambi lascio a chi legge tutti i necessari e divertenti approfondimenti del caso.

TL;DR (una breve introduzione)

Il formato CSV, con tutti i suoi difetti, è ancora uno dei formati più diffusi per lo scambio di dati. Ci sono modalità di gestire questi file ed eccezionali strumenti, che possono rendere molto semplice, efficace e rapido il loro utilizzo. Anche quando sono di grandi dimensioni.
E per fortuna ci sono banche dati “grosse” e importanti come OpenCoesione che danno l’opportunità di fare pratica con questi strumenti.

In questo lungo post farò una carrellata della compressione dei file CSV, dell’importanza di descriverli, dell’utilizzo di DuckDB per analizzarli e del formato Parquet come alternativa al CSV.

⚠️ QUESTO POST NON È UN TUTORIAL (ma doping omeopatico per i tuoi criceti e per chi pubblica dati).

I CSV sono brutti e cattivi

Il formato CSV è uno dei formati più diffusi per lo scambio di dati. È un formato testuale, che può essere letto e scritto da quasi tutti i linguaggi di programmazione e da quasi tutti gli strumenti di analisi dati (i “quasi” si potrebbero levare).
Non è consigliabile utilizzarlo come formato di lavoro, perché le operazioni di lettura e scrittura sono lente e costose in termini di risorse (tempo e memoria) e perché è in generale un formato “povero”.

Un file CSV è “brutto e cattivo” ad esempio per queste ragioni:

• non consente di definire il tipo di campo (stringa, numero, data, ecc.). Tipicamente si è costretti a fare l’inferenza, che può essere errata;
• non consente di definire il separatore di campo (virgola, punto e virgola, tabulazione, ecc.). Si può fare l’inferenza e/o si può leggere (e si possono fare errori);
• non consente di definire il separatore dei decimali (virgola, punto, ecc.). Si può fare l’inferenza e/o si può leggere (e si possono fare errori);
• non consente di definire l’encoding (UTF-8, ISO-8859-1, ecc.). Tipicamente si è costretti a fare l’inferenza, che può essere errata.

E per questo chi pubblica dati in questo formato, dovrebbe a maggior forza descriverli con dei metadati. Ma purtroppo nella gran parte dei casi, non ci resta che “morire di inferenza”.

E si potrebbero aggiungere altre brutture sul formato e di come spesso viene reso disponibile. Ma non è il tema del post.

CSV “standard”

Qui utilizzo l’aggettivo “standard” per alcune caratteristiche che rendono (nella gran parte dei casi) un CSV “subito pronto”, per essere letto da applicazioni e linguaggi di scripting per l’analisi dei dati.
Queste sono quelle consigliate e più tipiche:

• UTF-8 come codifica dei caratteri;
• , come separatore di campi;
• . come separatore dei decimali. In Italia il separatore è la ,, e ci può stare usarla, ma usando il . e documentandolo, si mette a disposizione un file che sarà più pronto per una lettura automatica;
• presenza della riga di intestazione (una sola);
• date nello standard ISO 8601 (ad esempio la data “8 marzo 2023” rappresentata come “2023-03-08”);
• ogni colonna un solo tipo di campo (es. solo numeri, solo testo, solo date, ecc.). Questo sembra inutile evidenziarlo, ma capita spesso di trovare colonne che contengono valori di tipo diverso (es. numeri e testo) nella stessa colonna;
• evitare l’utilizzo di spazi, virgolette o altri caratteri speciali nei nomi dei campi;
• non inserire il separatore delle migliaia nei valori delle celle dei campi numerici.

echo "COPY (SELECT *
REPLACE(
CAST(PROGRAMMATO_INDICATORE_1 AS FLOAT) AS PROGRAMMATO_INDICATORE_1,
CAST(PROGRAMMATO_INDICATORE_2 AS FLOAT) AS PROGRAMMATO_INDICATORE_2,
CAST(PROGRAMMATO_INDICATORE_3 AS FLOAT) AS PROGRAMMATO_INDICATORE_3,
CAST(PROGRAMMATO_INDICATORE_4 AS FLOAT) AS PROGRAMMATO_INDICATORE_4,
CAST(REALIZZATO_INDICATORE_1 AS FLOAT) AS REALIZZATO_INDICATORE_1,
CAST(REALIZZATO_INDICATORE_2 AS FLOAT) AS REALIZZATO_INDICATORE_2,
CAST(REALIZZATO_INDICATORE_3 AS FLOAT) AS REALIZZATO_INDICATORE_3,
CAST(REALIZZATO_INDICATORE_4 AS FLOAT) AS REALIZZATO_INDICATORE_4,
)
from read_csv_auto(
'progetti_esteso_20230430.csv.gz',SEP=';',dateformat='%Y%m%d',decimal_separator=',',sample_size=100000,
types={'OC_COD_ARTICOLAZ_PROGRAMMA':'VARCHAR','FINANZ_UE':'FLOAT','FINANZ_UE_FESR':'FLOAT','FINANZ_UE_FSE':'FLOAT','FINANZ_UE_FEASR':'FLOAT','FINANZ_UE_FEAMP':'FLOAT','FINANZ_UE_IOG':'FLOAT','FINANZ_STATO_FONDO_DI_ROTAZIONE':'FLOAT','FINANZ_STATO_FSC':'FLOAT','FINANZ_STATO_PAC':'FLOAT','FINANZ_STATO_COMPLETAMENTI':'FLOAT','FINANZ_STATO_ALTRI_PROVVEDIMENTI':'FLOAT','FINANZ_REGIONE':'FLOAT','FINANZ_PROVINCIA':'FLOAT','FINANZ_COMUNE':'FLOAT','FINANZ_RISORSE_LIBERATE':'FLOAT','FINANZ_ALTRO_PUBBLICO':'FLOAT','FINANZ_STATO_ESTERO':'FLOAT','FINANZ_PRIVATO':'FLOAT','FINANZ_DA_REPERIRE':'FLOAT','FINANZ_TOTALE_PUBBLICO':'FLOAT','ECONOMIE_TOTALI':'FLOAT','ECONOMIE_TOTALI_PUBBLICHE':'FLOAT','OC_FINANZ_UE_NETTO':'FLOAT','OC_FINANZ_UE_FESR_NETTO':'FLOAT','OC_FINANZ_UE_FSE_NETTO':'FLOAT','OC_FINANZ_UE_FEASR_NETTO':'FLOAT','OC_FINANZ_UE_FEAMP_NETTO':'FLOAT','OC_FINANZ_UE_IOG_NETTO':'FLOAT','OC_FINANZ_STATO_FONDO_ROT_NETTO':'FLOAT','OC_FINANZ_STATO_FSC_NETTO':'FLOAT','OC_FINANZ_STATO_PAC_NETTO':'FLOAT','OC_FINANZ_STATO_COMPL_NETTO':'FLOAT','OC_FINANZ_STATO_ALTRI_PROV_NETTO':'FLOAT','OC_FINANZ_REGIONE_NETTO':'FLOAT','OC_FINANZ_PROVINCIA_NETTO':'FLOAT','OC_FINANZ_COMUNE_NETTO':'FLOAT','OC_FINANZ_RISORSE_LIBERATE_NETTO':'FLOAT','OC_FINANZ_ALTRO_PUBBLICO_NETTO':'FLOAT','OC_FINANZ_STATO_ESTERO_NETTO':'FLOAT','OC_FINANZ_PRIVATO_NETTO':'FLOAT','OC_FINANZ_TOT_PUB_NETTO':'FLOAT','OC_COSTO_COESIONE':'FLOAT','IMPEGNI':'FLOAT','OC_IMPEGNI_GIURID_VINCOLANTI':'FLOAT','OC_IMPEGNI_TRASFERIMENTI':'FLOAT','OC_IMPEGNI_COESIONE':'FLOAT','TOT_PAGAMENTI':'FLOAT','OC_TOT_PAGAMENTI_BENEFICIARI':'FLOAT','OC_TOT_PAGAMENTI_TRASFERIMENTI':'FLOAT','COSTO_REALIZZATO':'FLOAT','COSTO_RENDICONTABILE_UE':'FLOAT','OC_TOT_PAGAMENTI_RENDICONTAB_UE':'FLOAT','OC_TOT_PAGAMENTI_FSC':'FLOAT','OC_TOT_PAGAMENTI_PAC':'FLOAT','OC_PAGAMENTI_COESIONE':'FLOAT','OC_DATA_INIZIO_PROGETTO':'DATE','OC_DATA_FINE_PROGETTO_PREVISTA':'DATE','OC_DATA_FINE_PROGETTO_EFFETTIVA':'DATE','DATA_INIZIO_PREV_STUDIO_FATT':'DATE','DATA_INIZIO_EFF_STUDIO_FATT':'DATE','DATA_FINE_PREV_STUDIO_FATT':'DATE','DATA_FINE_EFF_STUDIO_FATT':'DATE','DATA_INIZIO_PREV_PROG_PREL':'DATE','DATA_INIZIO_EFF_PROG_PREL':'DATE','DATA_FINE_PREV_PROG_PREL':'DATE','DATA_FINE_EFF_PROG_PREL':'DATE','DATA_INIZIO_PREV_PROG_DEF':'DATE','DATA_INIZIO_EFF_PROG_DEF':'DATE','DATA_FINE_PREV_PROG_DEF':'DATE','DATA_FINE_EFF_PROG_DEF':'DATE','DATA_INIZIO_PREV_PROG_ESEC':'DATE','DATA_INIZIO_EFF_PROG_ESEC':'DATE','DATA_FINE_PREV_PROG_ESEC':'DATE','DATA_FINE_EFF_PROG_ESEC':'DATE','DATA_INIZIO_PREV_AGG_BANDO':'DATE','DATA_INIZIO_EFF_AGG_BANDO':'DATE','DATA_FINE_PREV_AGG_BANDO':'DATE','DATA_FINE_EFF_AGG_BANDO':'DATE','DATA_INIZIO_PREV_STIP_ATTRIB':'DATE','DATA_INIZIO_EFF_STIP_ATTRIB':'DATE','DATA_FINE_PREV_STIP_ATTRIB':'DATE','DATA_FINE_EFF_STIP_ATTRIB':'DATE','DATA_INIZIO_PREV_ESECUZIONE':'DATE','DATA_INIZIO_EFF_ESECUZIONE':'DATE','DATA_FINE_PREV_ESECUZIONE':'DATE','DATA_FINE_EFF_ESECUZIONE':'DATE','DATA_INIZIO_PREV_COLLAUDO':'DATE','DATA_INIZIO_EFF_COLLAUDO':'DATE','DATA_FINE_PREV_COLLAUDO':'DATE','DATA_FINE_EFF_COLLAUDO':'DATE','COD_TIPO_PROCED_ATTIVAZIONE':'VARCHAR','OC_FLAG_REGIONE_UNICA':'INT','DATA_AGGIORNAMENTO':'DATE','OC_FLAG_CUP':'INT','PROGRAMMATO_INDICATORE_1':'VARCHAR','REALIZZATO_INDICATORE_1':'VARCHAR','PROGRAMMATO_INDICATORE_2':'VARCHAR','REALIZZATO_INDICATORE_2':'VARCHAR','PROGRAMMATO_INDICATORE_3':'VARCHAR','REALIZZATO_INDICATORE_3':'VARCHAR','PROGRAMMATO_INDICATORE_4':'VARCHAR','REALIZZATO_INDICATORE_4':'VARCHAR'}
)) TO 'progetti_esteso_20230430_standard.csv.gz' (HEADER, timestampformat '%Y-%m-%d');" |  duckdb

Descrivere i CSV

CSV is one of the most popular formats for publishing data on the web. It is concise, easy to understand by both humans and computers, and aligns nicely to the tabular nature of most data.

But CSV is also a poor format for data. There is no mechanism within CSV to indicate the type of data in a particular column, or whether values in a particular column must be unique. It is therefore hard to validate and prone to errors such as missing values or differing data types within a column.

Queste frasi sono presenti all’inizio di un lavoro di riferimento, per comprendere come si potrebbe descrivere un file in questo formato, in modo che sia utile, efficace e leggibile da umani, personal computer e applicazioni: CSV on the Web: A Primer.
Se non lo conosci, leggilo. Io qui non entrerò nei dettagli, perché non vale la pena ripetere quello che è già stato scritto molto bene.

Un altro progetto di riferimento per la descrizione di un file CSV è Frictionless Data e le sue specifiche per i dati tabellari. E ancora una volta, per le stesse ragioni non entrerò nei dettagli.

Molti dei dati pubblicati nei portali Open Data italiani in questo formato, sono accompagnati soltanto da un titolo e una descrizione. È un vuoto informativo e molto spesso una barriera a un pieno uso dei dati.
Alle volte, come nel caso di OpenCoesione, è presente un file con i nomi dei campi, la loro tipologia e altre note. Nella gran parte dei casi sono però file descrittivi leggibili soltanto a schermo da chi dovrà analizzare i file. Non sono leggibili da un personal computer o da un’applicazione, non sono machine readable.

E quando si hanno dati ricchi e complessi, questa diventa un’ulteriore barriera all’uso dei dati.

Farlo in una delle due modalità descritte sopra sarebbe perfetto. Non è a costo zero, ma se è uno dei processi (“automatici”) di un progetto di pubblicazione, è un costo che si può sostenere, che si ripaga in termini di usabilità e riusabilità dei dati.

CREATE TABLE progetti(COD_LOCALE_PROGETTO VARCHAR, CUP VARCHAR, OC_TITOLO_PROGETTO VARCHAR, OC_SINTESI_PROGETTO VARCHAR, OC_LINK VARCHAR, OC_COD_CICLO BIGINT, OC_DESCR_CICLO VARCHAR, OC_COD_TEMA_SINTETICO VARCHAR, OC_TEMA_SINTETICO VARCHAR, COD_GRANDE_PROGETTO VARCHAR, DESCRIZIONE_GRANDE_PROGETTO VARCHAR, OC_COD_FONTE VARCHAR, OC_DESCR_FONTE VARCHAR, FONDO_COMUNITARIO VARCHAR, OC_CODICE_PROGRAMMA VARCHAR, OC_DESCRIZIONE_PROGRAMMA VARCHAR, COD_OB_TEMATICO VARCHAR, DESCR_OB_TEMATICO VARCHAR, COD_PRIORITA_INVEST VARCHAR, DESCR_PRIORITA_INVEST VARCHAR, OC_COD_CATEGORIA_SPESA VARCHAR, OC_DESCR_CATEGORIA_SPESA VARCHAR, OC_ARTICOLAZIONE_PROGRAMMA VARCHAR, OC_SUBARTICOLAZIONE_PROGRAMMA VARCHAR, OC_COD_ARTICOLAZ_PROGRAMMA VARCHAR, OC_DESCR_ARTICOLAZ_PROGRAMMA VARCHAR, OC_COD_SUBARTICOLAZ_PROGRAMMA VARCHAR, OC_DESCR_SUBARTICOLAZ_PROGRAMMA VARCHAR, COD_STRUMENTO VARCHAR, DESCR_STRUMENTO VARCHAR, DESCR_TIPO_STRUMENTO VARCHAR, CUP_COD_NATURA VARCHAR, CUP_DESCR_NATURA VARCHAR, CUP_COD_TIPOLOGIA VARCHAR, CUP_DESCR_TIPOLOGIA VARCHAR, CUP_COD_SETTORE VARCHAR, CUP_DESCR_SETTORE VARCHAR, CUP_COD_SOTTOSETTORE VARCHAR, CUP_DESCR_SOTTOSETTORE VARCHAR, CUP_COD_CATEGORIA VARCHAR, CUP_DESCR_CATEGORIA VARCHAR, COD_ATECO VARCHAR, DESCRIZIONE_ATECO VARCHAR, OC_COD_TIPO_AIUTO VARCHAR, OC_DESCR_TIPO_AIUTO VARCHAR, COD_REGIONE VARCHAR, DEN_REGIONE VARCHAR, COD_PROVINCIA VARCHAR, DEN_PROVINCIA VARCHAR, COD_COMUNE VARCHAR, DEN_COMUNE VARCHAR, OC_MACROAREA VARCHAR, OC_COD_SLL BIGINT, OC_DENOMINAZIONE_SLL VARCHAR, FINANZ_UE FLOAT, FINANZ_UE_FESR FLOAT, FINANZ_UE_FSE FLOAT, FINANZ_UE_FEASR FLOAT, FINANZ_UE_FEAMP FLOAT, FINANZ_UE_IOG FLOAT, FINANZ_STATO_FONDO_DI_ROTAZIONE FLOAT, FINANZ_STATO_FSC FLOAT, FINANZ_STATO_PAC FLOAT, FINANZ_STATO_COMPLETAMENTI FLOAT, FINANZ_STATO_ALTRI_PROVVEDIMENTI FLOAT, FINANZ_REGIONE FLOAT, FINANZ_PROVINCIA FLOAT, FINANZ_COMUNE FLOAT, FINANZ_RISORSE_LIBERATE FLOAT, FINANZ_ALTRO_PUBBLICO FLOAT, FINANZ_STATO_ESTERO FLOAT, FINANZ_PRIVATO FLOAT, FINANZ_DA_REPERIRE FLOAT, FINANZ_TOTALE_PUBBLICO FLOAT, ECONOMIE_TOTALI FLOAT, ECONOMIE_TOTALI_PUBBLICHE FLOAT, OC_FINANZ_UE_NETTO FLOAT, OC_FINANZ_UE_FESR_NETTO FLOAT, OC_FINANZ_UE_FSE_NETTO FLOAT, OC_FINANZ_UE_FEASR_NETTO FLOAT, OC_FINANZ_UE_FEAMP_NETTO FLOAT, OC_FINANZ_UE_IOG_NETTO FLOAT, OC_FINANZ_STATO_FONDO_ROT_NETTO FLOAT, OC_FINANZ_STATO_FSC_NETTO FLOAT, OC_FINANZ_STATO_PAC_NETTO FLOAT, OC_FINANZ_STATO_COMPL_NETTO FLOAT, OC_FINANZ_STATO_ALTRI_PROV_NETTO FLOAT, OC_FINANZ_REGIONE_NETTO FLOAT, OC_FINANZ_PROVINCIA_NETTO FLOAT, OC_FINANZ_COMUNE_NETTO FLOAT, OC_FINANZ_RISORSE_LIBERATE_NETTO FLOAT, OC_FINANZ_ALTRO_PUBBLICO_NETTO FLOAT, OC_FINANZ_STATO_ESTERO_NETTO FLOAT, OC_FINANZ_PRIVATO_NETTO FLOAT, OC_FINANZ_TOT_PUB_NETTO FLOAT, OC_COSTO_COESIONE FLOAT, IMPEGNI FLOAT, OC_IMPEGNI_GIURID_VINCOLANTI FLOAT, OC_IMPEGNI_TRASFERIMENTI FLOAT, OC_IMPEGNI_COESIONE FLOAT, TOT_PAGAMENTI FLOAT, OC_TOT_PAGAMENTI_BENEFICIARI FLOAT, OC_TOT_PAGAMENTI_TRASFERIMENTI FLOAT, COSTO_REALIZZATO FLOAT, COSTO_RENDICONTABILE_UE FLOAT, OC_TOT_PAGAMENTI_RENDICONTAB_UE FLOAT, OC_TOT_PAGAMENTI_FSC FLOAT, OC_TOT_PAGAMENTI_PAC FLOAT, OC_PAGAMENTI_COESIONE FLOAT, OC_DATA_INIZIO_PROGETTO DATE, OC_DATA_FINE_PROGETTO_PREVISTA DATE, OC_DATA_FINE_PROGETTO_EFFETTIVA DATE, DATA_INIZIO_PREV_STUDIO_FATT DATE, DATA_INIZIO_EFF_STUDIO_FATT DATE, DATA_FINE_PREV_STUDIO_FATT DATE, DATA_FINE_EFF_STUDIO_FATT DATE, DATA_INIZIO_PREV_PROG_PREL DATE, DATA_INIZIO_EFF_PROG_PREL DATE, DATA_FINE_PREV_PROG_PREL DATE, DATA_FINE_EFF_PROG_PREL DATE, DATA_INIZIO_PREV_PROG_DEF DATE, DATA_INIZIO_EFF_PROG_DEF DATE, DATA_FINE_PREV_PROG_DEF DATE, DATA_FINE_EFF_PROG_DEF DATE, DATA_INIZIO_PREV_PROG_ESEC DATE, DATA_INIZIO_EFF_PROG_ESEC DATE, DATA_FINE_PREV_PROG_ESEC DATE, DATA_FINE_EFF_PROG_ESEC DATE, DATA_INIZIO_PREV_AGG_BANDO DATE, DATA_INIZIO_EFF_AGG_BANDO DATE, DATA_FINE_PREV_AGG_BANDO DATE, DATA_FINE_EFF_AGG_BANDO DATE, DATA_INIZIO_PREV_STIP_ATTRIB DATE, DATA_INIZIO_EFF_STIP_ATTRIB DATE, DATA_FINE_PREV_STIP_ATTRIB DATE, DATA_FINE_EFF_STIP_ATTRIB DATE, DATA_INIZIO_PREV_ESECUZIONE DATE, DATA_INIZIO_EFF_ESECUZIONE DATE, DATA_FINE_PREV_ESECUZIONE DATE, DATA_FINE_EFF_ESECUZIONE DATE, DATA_INIZIO_PREV_COLLAUDO DATE, DATA_INIZIO_EFF_COLLAUDO DATE, DATA_FINE_PREV_COLLAUDO DATE, DATA_FINE_EFF_COLLAUDO DATE, OC_STATO_FINANZIARIO VARCHAR, OC_STATO_PROGETTO VARCHAR, OC_STATO_PROCEDURALE VARCHAR, OC_COD_FASE_CORRENTE VARCHAR, OC_DESCR_FASE_CORRENTE VARCHAR, COD_PROCED_ATTIVAZIONE VARCHAR, DESCR_PROCED_ATTIVAZIONE VARCHAR, COD_TIPO_PROCED_ATTIVAZIONE VARCHAR, DESCR_TIPO_PROCED_ATTIVAZIONE VARCHAR, OC_CODFISC_PROGRAMMATORE VARCHAR, OC_DENOM_PROGRAMMATORE VARCHAR, OC_COD_FORMA_GIU_PROGRAMMATORE VARCHAR, OC_DESCR_FORMA_GIU_PROGRAMMATORE VARCHAR, OC_TOTALE_PROGRAMMATORI BIGINT, OC_CODFISC_ATTUATORE VARCHAR, OC_DENOM_ATTUATORE VARCHAR, OC_COD_FORMA_GIU_ATTUATORE VARCHAR, OC_DESCR_FORMA_GIU_ATTUATORE VARCHAR, OC_TOTALE_ATTUATORI BIGINT, OC_CODFISC_BENEFICIARIO VARCHAR, OC_DENOM_BENEFICIARIO VARCHAR, OC_COD_FORMA_GIU_BENEFICIARIO VARCHAR, OC_DESCR_FORMA_GIU_BENEFICIARIO VARCHAR, OC_TOTALE_BENEFICIARI BIGINT, OC_CODFISC_REALIZZATORE VARCHAR, OC_DENOM_REALIZZATORE VARCHAR, OC_COD_FORMA_GIU_REALIZZATORE VARCHAR, OC_DESCR_FORMA_GIU_REALIZZATORE VARCHAR, OC_TOTALE_REALIZZATORI BIGINT, OC_TOTALE_INDICATORI BIGINT, COD_INDICATORE_1 VARCHAR, DESCR_INDICATORE_1 VARCHAR, UNITA_MISURA_INDICATORE_1 VARCHAR, PROGRAMMATO_INDICATORE_1 FLOAT, REALIZZATO_INDICATORE_1 FLOAT, COD_INDICATORE_2 VARCHAR, DESCR_INDICATORE_2 VARCHAR, UNITA_MISURA_INDICATORE_2 VARCHAR, PROGRAMMATO_INDICATORE_2 FLOAT, REALIZZATO_INDICATORE_2 FLOAT, COD_INDICATORE_3 VARCHAR, DESCR_INDICATORE_3 VARCHAR, UNITA_MISURA_INDICATORE_3 VARCHAR, PROGRAMMATO_INDICATORE_3 FLOAT, REALIZZATO_INDICATORE_3 FLOAT, COD_INDICATORE_4 VARCHAR, DESCR_INDICATORE_4 VARCHAR, UNITA_MISURA_INDICATORE_4 VARCHAR, PROGRAMMATO_INDICATORE_4 FLOAT, REALIZZATO_INDICATORE_4 FLOAT, OC_FLAG_REGIONE_UNICA INTEGER, OC_FLAG_VISUALIZZAZIONE BIGINT, OC_FLAG_PAC BIGINT, DATA_AGGIORNAMENTO DATE, OC_FLAG_CUP INTEGER);

Parquet

Il formato CSV - con i suoi pregi e difetti - è molto diffuso. Un formato tabellare degno di nota che sta emergendo, è il Parquet.

È un formato open source progettato per l’archiviazione e l’analisi di grandi dataset.
Le principali caratteristiche sono:

• Struttura a colonne: i dati sono memorizzati per colonna e non per riga, per una migliore compressione;
• Compressione efficace: supporta compressione gzip, snappy e zstd;
• Prestazioni elevate: consente analisi molto veloci grazie alla struttura a colonne;
• Formato descritto: contiene metadati sullo schema;
• Partizionabile: un unico dataset di dimensioni molto molto grandi, può essere suddiviso in più file e cartelle, partizionate (ad esempio per anno, per regione, per provincia, ecc.);
• Accessibile in stream: invece di leggere o scrivere l’intero file in una volta sola, consente di lavorare con il file suddividendo i dati in pacchetti più piccoli;
• Supportato da molti data engine e da tutti i principali linguaggi di programmazione e librerie di elaborazione dati.

Tra le più interessanti, specie per chi è nuovo al concetto e al formato, è la struttura di archiviazione a colonne.

Formato colonnare

In molti dei formati tabellari più noti e comuni, i dati sono archiviati come sequenze di righe. Avviene per i CSV, ma anche per importanti database relazionali come PostgreSQL e MySQL.

Pizza	Cliente	Regione	Data	Costo
Margherita	Marco Stretto	Sicilia	2023-01-01	5
Parmigiana	Marco Stretto	Sicilia	2023-01-02	9
Romana	Guido La Vespa	Calabria	2023-01-01	7
Romana	Chiara Mente	Sicilia	2023-01-03	7
Parmigiana	Guido La Vespa	Calabria	2023-01-02	9
Romana	Marco Stretto	Sicilia	2023-01-05	7

A partire da una tabella con dei dati sulle vendite di una pizzeria, come Tabella 2, le domande che si potrebbero fare sono:

• quante pizze Margherita sono state vendute?
• quanti utenti che vengono dalla Sicilia hanno ordinato una pizza Parmigiana?
• quanto ha speso in totale Guido La Vespa?
• quante vendite sono state fatte il 2 gennaio 2023?

Per rispondere a queste domande, un motore di “tabelle” basato su righe, dovrà leggere tutte le righe della tabella, dall’inizio alla fine. Per sapere quanti utenti che vengono dalla Sicilia hanno ordinato una pizza Parmigiana, si dovrà scorrere la tabella come in Figura 1.

Basterebbe leggere soltanto i valori delle colonne Pizza e Regione, ma in uno schema di archiviazione basato su righe vengono lette anche le altre colonne.

Per rispondere a questa query è molto più efficiente un’archiviazione a colonne.
In questo caso, ogni colonna è un’entità, il che significa che ogni colonna è fisicamente separata dalle altre.
Tornando alla nostra precedente domanda: in uno schema a colonne il motore di analisi può leggere soltanto le colonne necessarie per la query (Pizza e Regione). E, nella maggior parte dei casi, questo migliorerà le prestazioni delle query analitiche.

Pizza	Cliente	Regione	Data	Costo
Margherita	Marco Stretto	Sicilia	2023-01-01	5
Parmigiana	Marco Stretto	Sicilia	2023-01-02	9
Romana	Guido La Vespa	Calabria	2023-01-01	7
Romana	Chiara Mente	Sicilia	2023-01-03	7
Parmigiana	Guido La Vespa	Calabria	2023-01-02	9
Romana	Marco Stretto	Sicilia	2023-01-05	7

Il formato Parquet è proprio un formato di archiviazione a colonne, anzi è più correttamente un formato di archiviazione a colonne, per gruppi di righe.

Le colonne sono memorizzate sempre come unità separate, ma Parquet introduce delle strutture aggiuntive chiamate “Row group” (vedi Figura 2).

Perché sono un vantaggio? Nella query di esempio di sopra, non solo bastano due colonne, ma il Gruppo 2 di righe è inutile (non c’è la “Parmigiana”).
Con questa struttura a gruppi di righe (qui semplificata per fini didattici) sarà possibile non tenere conto del “Gruppo 2” e la query sarà più rapida.

echo "COPY (SELECT *
REPLACE(
CAST(PROGRAMMATO_INDICATORE_1 AS FLOAT) AS PROGRAMMATO_INDICATORE_1,
CAST(PROGRAMMATO_INDICATORE_2 AS FLOAT) AS PROGRAMMATO_INDICATORE_2,
CAST(PROGRAMMATO_INDICATORE_3 AS FLOAT) AS PROGRAMMATO_INDICATORE_3,
CAST(PROGRAMMATO_INDICATORE_4 AS FLOAT) AS PROGRAMMATO_INDICATORE_4,
CAST(REALIZZATO_INDICATORE_1 AS FLOAT) AS REALIZZATO_INDICATORE_1,
CAST(REALIZZATO_INDICATORE_2 AS FLOAT) AS REALIZZATO_INDICATORE_2,
CAST(REALIZZATO_INDICATORE_3 AS FLOAT) AS REALIZZATO_INDICATORE_3,
CAST(REALIZZATO_INDICATORE_4 AS FLOAT) AS REALIZZATO_INDICATORE_4,
)
from read_csv_auto(
'progetti_esteso_20230430.csv.gz',SEP=';',dateformat='%Y%m%d',decimal_separator=',',sample_size=100000,
types={'OC_COD_ARTICOLAZ_PROGRAMMA':'VARCHAR','FINANZ_UE':'FLOAT','FINANZ_UE_FESR':'FLOAT','FINANZ_UE_FSE':'FLOAT','FINANZ_UE_FEASR':'FLOAT','FINANZ_UE_FEAMP':'FLOAT','FINANZ_UE_IOG':'FLOAT','FINANZ_STATO_FONDO_DI_ROTAZIONE':'FLOAT','FINANZ_STATO_FSC':'FLOAT','FINANZ_STATO_PAC':'FLOAT','FINANZ_STATO_COMPLETAMENTI':'FLOAT','FINANZ_STATO_ALTRI_PROVVEDIMENTI':'FLOAT','FINANZ_REGIONE':'FLOAT','FINANZ_PROVINCIA':'FLOAT','FINANZ_COMUNE':'FLOAT','FINANZ_RISORSE_LIBERATE':'FLOAT','FINANZ_ALTRO_PUBBLICO':'FLOAT','FINANZ_STATO_ESTERO':'FLOAT','FINANZ_PRIVATO':'FLOAT','FINANZ_DA_REPERIRE':'FLOAT','FINANZ_TOTALE_PUBBLICO':'FLOAT','ECONOMIE_TOTALI':'FLOAT','ECONOMIE_TOTALI_PUBBLICHE':'FLOAT','OC_FINANZ_UE_NETTO':'FLOAT','OC_FINANZ_UE_FESR_NETTO':'FLOAT','OC_FINANZ_UE_FSE_NETTO':'FLOAT','OC_FINANZ_UE_FEASR_NETTO':'FLOAT','OC_FINANZ_UE_FEAMP_NETTO':'FLOAT','OC_FINANZ_UE_IOG_NETTO':'FLOAT','OC_FINANZ_STATO_FONDO_ROT_NETTO':'FLOAT','OC_FINANZ_STATO_FSC_NETTO':'FLOAT','OC_FINANZ_STATO_PAC_NETTO':'FLOAT','OC_FINANZ_STATO_COMPL_NETTO':'FLOAT','OC_FINANZ_STATO_ALTRI_PROV_NETTO':'FLOAT','OC_FINANZ_REGIONE_NETTO':'FLOAT','OC_FINANZ_PROVINCIA_NETTO':'FLOAT','OC_FINANZ_COMUNE_NETTO':'FLOAT','OC_FINANZ_RISORSE_LIBERATE_NETTO':'FLOAT','OC_FINANZ_ALTRO_PUBBLICO_NETTO':'FLOAT','OC_FINANZ_STATO_ESTERO_NETTO':'FLOAT','OC_FINANZ_PRIVATO_NETTO':'FLOAT','OC_FINANZ_TOT_PUB_NETTO':'FLOAT','OC_COSTO_COESIONE':'FLOAT','IMPEGNI':'FLOAT','OC_IMPEGNI_GIURID_VINCOLANTI':'FLOAT','OC_IMPEGNI_TRASFERIMENTI':'FLOAT','OC_IMPEGNI_COESIONE':'FLOAT','TOT_PAGAMENTI':'FLOAT','OC_TOT_PAGAMENTI_BENEFICIARI':'FLOAT','OC_TOT_PAGAMENTI_TRASFERIMENTI':'FLOAT','COSTO_REALIZZATO':'FLOAT','COSTO_RENDICONTABILE_UE':'FLOAT','OC_TOT_PAGAMENTI_RENDICONTAB_UE':'FLOAT','OC_TOT_PAGAMENTI_FSC':'FLOAT','OC_TOT_PAGAMENTI_PAC':'FLOAT','OC_PAGAMENTI_COESIONE':'FLOAT','OC_DATA_INIZIO_PROGETTO':'DATE','OC_DATA_FINE_PROGETTO_PREVISTA':'DATE','OC_DATA_FINE_PROGETTO_EFFETTIVA':'DATE','DATA_INIZIO_PREV_STUDIO_FATT':'DATE','DATA_INIZIO_EFF_STUDIO_FATT':'DATE','DATA_FINE_PREV_STUDIO_FATT':'DATE','DATA_FINE_EFF_STUDIO_FATT':'DATE','DATA_INIZIO_PREV_PROG_PREL':'DATE','DATA_INIZIO_EFF_PROG_PREL':'DATE','DATA_FINE_PREV_PROG_PREL':'DATE','DATA_FINE_EFF_PROG_PREL':'DATE','DATA_INIZIO_PREV_PROG_DEF':'DATE','DATA_INIZIO_EFF_PROG_DEF':'DATE','DATA_FINE_PREV_PROG_DEF':'DATE','DATA_FINE_EFF_PROG_DEF':'DATE','DATA_INIZIO_PREV_PROG_ESEC':'DATE','DATA_INIZIO_EFF_PROG_ESEC':'DATE','DATA_FINE_PREV_PROG_ESEC':'DATE','DATA_FINE_EFF_PROG_ESEC':'DATE','DATA_INIZIO_PREV_AGG_BANDO':'DATE','DATA_INIZIO_EFF_AGG_BANDO':'DATE','DATA_FINE_PREV_AGG_BANDO':'DATE','DATA_FINE_EFF_AGG_BANDO':'DATE','DATA_INIZIO_PREV_STIP_ATTRIB':'DATE','DATA_INIZIO_EFF_STIP_ATTRIB':'DATE','DATA_FINE_PREV_STIP_ATTRIB':'DATE','DATA_FINE_EFF_STIP_ATTRIB':'DATE','DATA_INIZIO_PREV_ESECUZIONE':'DATE','DATA_INIZIO_EFF_ESECUZIONE':'DATE','DATA_FINE_PREV_ESECUZIONE':'DATE','DATA_FINE_EFF_ESECUZIONE':'DATE','DATA_INIZIO_PREV_COLLAUDO':'DATE','DATA_INIZIO_EFF_COLLAUDO':'DATE','DATA_FINE_PREV_COLLAUDO':'DATE','DATA_FINE_EFF_COLLAUDO':'DATE','COD_TIPO_PROCED_ATTIVAZIONE':'VARCHAR','OC_FLAG_REGIONE_UNICA':'INT','DATA_AGGIORNAMENTO':'DATE','OC_FLAG_CUP':'INT','PROGRAMMATO_INDICATORE_1':'VARCHAR','REALIZZATO_INDICATORE_1':'VARCHAR','PROGRAMMATO_INDICATORE_2':'VARCHAR','REALIZZATO_INDICATORE_2':'VARCHAR','PROGRAMMATO_INDICATORE_3':'VARCHAR','REALIZZATO_INDICATORE_3':'VARCHAR','PROGRAMMATO_INDICATORE_4':'VARCHAR','REALIZZATO_INDICATORE_4':'VARCHAR'}
)) TO 'progetti_esteso_20230430.parquet' (FORMAT 'PARQUET', CODEC 'ZSTD');" |  duckdb

È come avere delle API

Il formato parquet - accoppiato a client come DuckDB - rende facile e universale l’accesso ai dati. Questo perché, una volta che un file è pubblico sul web (in HTTPS, come S3, ecc.), si ha a disposizione un’interfaccia SQL per interrogarlo, in modalità streaming, ovvero rendendo disponibili solo le porzioni di dati necessarie per rispondere alle query, invece che tutto il file.

È un po’ come avere delle API, ma senza doverle creare. E, da utente, senza dovere studiare una nuova documentazione di API, perché basta conoscere l’“universale” SQL e accedere al file parquet dal linguaggio di scripting e/o client preferiti.

Mi spiego con un esempio, basato sui dati sui progetti del PNRR. È un dataset “piccolo” (200.000 righe per 50 colonne), ma mi è comodo qui a fini didattici.
Voglio sapere per ogni Missione, il numero dei progetti e il valore del finanziamento PNRR (in euro).
Usando come client DuckDB, e abilitando l’estensione httpfs (vedi sezione estensioni), basta conoscere l’URL del file e lanciare questa query:

duckdb -c '
SELECT "Descrizione Missione" missione,COUNT(*) numero_progetti,
SUM("Finanziamento PNRR") finanziamento_pnrr
FROM "https://raw.githubusercontent.com/aborruso/aborruso.github.io//main/posts/duckdb-intro-csv/file/PNRR_Progetti-Universo_REGIS_v2.1.parquet"
GROUP by "Descrizione Missione"
ORDER BY finanziamento_pnrr desc;
'

E in circa 1 secondo (al primo lancio e in molto meno dal secondo in poi) ottengo:

missione	numero_progetti	finanziamento_pnrr
Rivoluzione verde e transizione ecologica	49621	22688516407.240803
Infrastrutture per una mobilità sostenibile	206	22563735313.390625
Istruzione e ricerca	65403	20129269029.008453
Digitalizzazione, innovazione, competitività e cultura	63025	19245334466.823135
Inclusione e coesione	11764	12998257338.579054
Salute	7527	8059988416.008047

E posso farlo anche da una pagina web che includa DuckDb come WebAssembly (vedi Figura 4).

Non è la soluzione definitiva

Questa dei file statici in formato parquet non è la soluzione definitiva per abilitare l’accesso ai dati in modo programmatico, in applicazioni web. Fino ad alcuni milioni di righe ha delle performance buone, poi diventa un po’ lento. E ci sono modalità più ottimizzate per richieste transazionali o atomiche, per dati relazionali con schemi complessi, per dataset “privati” con controllo granulare degli accessi, e per dati in rapido cambiamento.

Affiancarlo ai file CSV

Il formato parquet - per alcune delle sue caratteristiche - potrebbe affiancare (e alla lunga rimpiazzare?) il CSV, come formato di pubblicazione di dati aperti.

In contesti applicativi in cui le performance, lo spazio di archiviazione, le modalità di accesso sono parametri da tenere in alta considerazione, è già molto usato.
Un esempio per tutti è quello dei dataset di Hugging Face.

I dati aperti globali sugli edifici del progetto GlobalMLBuildingFootprints (1.2 miliardi di edifici), sono in formato parquet, nella sua estensione spaziale.
Anche i dataset geografici del progetto Overture Maps Foundation, sono in formato parquet.
I dati aperti sulle corse di taxi e veicoli con conducente di New York, sono anch’essi in questo formato.

L’ultimo esempio, per chiudere in bellezza, è quello dell’impareggiabile portale Open Data della Francia.
Pubblica un dataset in formato parquet, sono disponibili gli URL statici dei file, ed è possibile fare query in modo comodissimo, come se fossero disponibili delle API.
Ad esempio posso interrogare il file da 470 MB degli indirizzi, di 15 milioni di righe, per avere il numero di indirizzi per comune con questa semplicità (vedi Lista 4):

duckdb -c '
load httpfs;
SELECT code_commune_ref, sum(nb_adresses) sum
FROM "https://static.data.gouv.fr/resources/bureaux-de-vote-et-adresses-de-leurs-electeurs/20230626-135723/table-adresses-reu.parquet"
GROUP BY ALL ORDER by 2 DESC LIMIT 10;
'

E in pochi secondi si ha restituito il risultato (vedi Figura 5).

DuckDB

DuckDB è lo strumento più usato in questo post, perché riesce a fare utilizzare comodamente dati CSV brutti, sporchi, cattivi e “grossi”, e anche renderli belli (con una conversione in formato parquet).

È un database relazionale embedded e open source leggero e veloce, di facilissima installazione e gestione.
È progettato per l’analisi rapida di dati ed è basato su uno schema di archiviazione a colonne (vedi spiegazione correlata per il formato parquet).

È scritto in C++, ha un’interfaccia SQL standard, ed è integrabile facilmente in qualsiasi ambiente di lavoro (API per Python, R, Java, Julia, Swift, ecc.).

Per le sue caratteristiche e per l’uso che si fa tipicamente dei dati, ha contribuito a far emergere la frase “Big data is dead” (leggilo è molto interessante):

• I sistemi moderni possono gestire anche dati molto grandi in modo efficace ed economico.
• La maggior parte delle aziende ha pochi GB/TB di dati, non i PB prospettati dal marketing di alcune soluzioni.
• Storage e computing sono separati, ma lo storage tende ad aumentare più velocemente del computing richiesto.
• Le query analitiche usano di solito solo una piccola parte dei dataset, i record più recenti.
• Alcuni dati invecchiano velocemente, dopo poco tempo sono interrogati raramente e possono diventare un onere.
• Bisognerebbe dimostrare che i dataset rimangono realmente rilevanti anziché accumularli senza motivo.

DuckDB è “tanta roba” e sul sito ufficiale è tutto molto ben documentato.

Qui voglio sottolineare alcune cose che, da piccolo utente, mi sono piaciute molto.

Facilità di installazione e utilizzo

La pagina dedicata è molto comoda:

1. si sceglie la versione;
2. l’ambiente e le modalità di lavoro (io lo utilizzo soprattutto a riga di comando, come CLI);
3. la piattaforma;
4. vengono restituite le istruzioni per l’installazione.

E in pochissimo tempo si è pronti all’uso.

duckdb  --csv -c "FROM read_csv_auto('https://raw.githubusercontent.com/pcm-dpc/COVID-19/master/dati-regioni/dpc-covid19-ita-regioni.csv')
SELECT denominazione_regione,data,nuovi_positivi,AVG(nuovi_positivi)
OVER (
  PARTITION BY denominazione_regione
  ORDER BY data
  RANGE BETWEEN INTERVAL 7 DAYS PRECEDING
  AND INTERVAL 0 DAYS FOLLOWING
  ) AS media_mobile
ORDER BY 1,2;"

1duckdb -c 'load spatial;
SELECT ST_X(
  ST_Centroid(
    ST_MakeLine(
      ST_POINT(42.3471, 14.8454),ST_POINT(42.1471, 13.8454)
      )
    )
) test;'

SELECT * EXCLUDE (codice_progetto, codice_progetto_originale) FROM progetti;

SELECT * REPLACE (FINANZ_TOTALE_PUBBLICO/100 AS FINANZ_NORM) FROM miatabella;

SELECT missione,regione, COUNT(*) numero_progetti
FROM progetti
GROUP BY ALL

SELECT 'Quanto è bello DuckDB'[:-7] as slice;

┌────────────────┐
│     slice      │
├────────────────┤
│ Quanto è bello │
└────────────────┘

SELECT * FROM sqlite_scan('test.db', 'tbl_name');

SELECT * FROM st_read('test_excel.xlsx', layer='Sheet1');

-- usando la stringa di connessione vuota, di default
SELECT * FROM postgres_scan('', 'public', 'mytable');

import duckdb

# directly query a Pandas DataFrame
import pandas as pd
pandas_df = pd.DataFrame({'a': [42]})
duckdb.sql('SELECT * FROM pandas_df')

# directly query a Polars DataFrame
import polars as pl
polars_df = pl.DataFrame({'a': [42]})
duckdb.sql('SELECT * FROM polars_df')

# directly query a pyarrow table
import pyarrow as pa
arrow_table = pa.Table.from_pydict({'a':[42]})
duckdb.sql('SELECT * FROM arrow_table')

pnrrdb = DuckDBClient.of({
  progetti: FileAttachment("PNRR_Progetti-Universo_REGIS_v2.1.parquet")
})

pnrrdb = DuckDBClient.of({
  progetti: FileAttachment("file/PNRR_Progetti-Universo_REGIS_v2.1.parquet")
})

Inputs.table(
  pnrrdb.sql`SELECT Missione, SUM("Finanziamento PNRR") AS total_PNRR
  FROM progetti
  GROUP BY ALL`, {locale: "it-IT"}
)

Dati OpenCoesione

OpenCoesione è l’iniziativa nazionale di governo aperto (open government) sulle politiche di coesione¹, coordinata dal Dipartimento per le Politiche di Coesione della Presidenza del Consiglio dei Ministri. Nasce, nel 2012, per favorire un migliore uso delle risorse pubbliche attraverso la diffusione e il riutilizzo di dati e informazioni sugli interventi finanziati con risorse nazionali ed europee, che vengono pubblicati sul portale.

Il portale contiene i dati “a partire dal ciclo 2000-2006 limitatamente ai programmi FSC (Fondo per lo Sviluppo e la Coesione) a titolarità regionale e dal ciclo 2007-2013 per quanto riguarda tutti i programmi nazionali ed europei, aggiornati con cadenza bimestrale”.

👏 È un progetto che ha fatto e fa scuola. E a proposito di “scuola”, non si può non citare il progetto “A Scuola di OpenCoesione”, che ha coinvolto migliaia di scuole di tutta Italia, portando nelle classi, tra studenti e studentesse, insegnanti e famiglie, il tema della trasparenza e della partecipazione.

Nel portale è presente la sezione dei dati aperti, in cui il dataset più importante è quello dei Progetti con tracciato esteso.
Lo useremo come dataset di esempio, per mostrare come sia possibile lavorare comodamente con un file CSV di dimensioni “importanti” e di una certa complessità e ricchezza.

Esplorare il dataset

Il dataset Progetti con tracciato esteso (quello aggiornato al 30 aprile 2023) è un file CSV compresso in formato ZIP che pesa circa 200 MB; decompresso circa 4 GB e mezzo.

Lanciando unzip -l progetti_esteso_20230430.zip ottengo:

Archive:  progetti_esteso_20230430.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
4541980767  2023-07-05 23:34   progetti_esteso_20230430.csv
---------                     -------
4541980767                     1 file

È molto utile leggere qualche riga del CSV. Per farlo posso lanciare il comando di sotto, che invia il contenuto del file compresso all’utility head: mostra le prime 10 righe del file e si ferma.
Lo fa in 0.003 secondi - istantaneamente - perché il file non viene decompresso per intero, ma solo la parte che serve per mostrare le prime 10 righe.

unzip -p progetti_esteso_20230430.zip | head

Facendolo riesco a leggere che:

• il separatore di campo è il ;;
• la prima riga è una riga di intestazione;
• che ci sono decine di campi (questo lo si può leggere anche dal file dei metadati).

Con qualche sforzo in più di scorrimento a schermo, riesco a vedere che il separatore dei decimali è la , e che i campi con le date sono in un formato che sembra un numero intero, ma in realtà è YYYYMMDD (23 agosto 2021 è espresso come 20210823).

Modificando un po’ il comando di sopra, con unzip -p progetti_esteso_20230430.zip | wc -l, leggo che il file è composto da 1.936.840 righe.

Fatta questa prima esplorazione grezza, di solito voglio “guardare” in modo più “comodo” la tabella dei dati. Potrei salvare le prime 10 righe in un file, aggiungendo al comando di sopra > prime_dieci_righe.csv, e infine aprirlo con un foglio elettronico; io preferisco usare lo straordinario VisiData per farlo.
Con unzip -p progetti_esteso_20230430.zip | head | vd -f csv --csv-delimiter=";" ad esempio visualizzo le 10 righe di output e tutte le colonne (constatando che sono 199), ma soprattutto mi faccio una prima idea dei contenuti.

Ci sono tantissimi altri strumenti e modalità con cui potrei fare queste ed altre operazioni di esplorazione e analisi, ma questo è un post dedicato in modo particolare a DuckDB e alla sua applicazione a riga di comando. Quindi da qui in poi, utilizzerò soprattutto DuckDB e la sua cli.
Per replicare con DuckDB quanto visto sopra in Figura 7, il comando è (metto qualche “a capo” per renderlo più leggibile):

unzip -p progetti_esteso_20230430.zip | head | \
1duckdb -cmd '.mode box' -c '
2select * from read_csv_auto("/dev/stdin");
3' | less -S

1

-cmd '.mode box' abilita la vista “box”

2

L’input è lo stdin

3

L’output a less in modo che sia leggibile

A schermo ho un’anteprima leggibile e navigabile, come questa di Figura 8.

Come detto sopra DuckDB può leggere nativamente file compressi in formato GZIP (e ZSTD).
Allora per comodità, ho creato la versione GZIP del file Progetti con tracciato esteso di OpenCoesione.

La posso interrogare in modo diretto, applicando la funzione read_csv_auto, che prova a fare l’inferenza della presenza (o no) della linea di intestazione, del separatore dei campi, del separatore dei decimali, del tipo di campo, ecc.:

duckdb -c '
SELECT * from read_csv_auto("progetti_esteso_20230430.csv.gz") LIMIT 10
'

In output ho un’anteprima ben leggibile a schermo, in cui vedo 10 righe, alcuni dei campi e il loro tipo e il numero di colonne.

Per vedere tutti i campi posso forzare l’output in CSV, aggiungendo --csv e infine leggerlo con VisiData:

duckdb --csv -c '
SELECT * from read_csv_auto("progetti_esteso_20230430.csv.gz") LIMIT 10
' | vd -f csv

Un comando comodissimo di DuckDB è SUMMARIZE, che restituisce una tabella esplorativa di sintesi che è una piccola gemma.
Per ogni campo restituisce:

• tipo di campo;
• valore minimo;
• valore massimo;
• numero di valori univoci approssimato;
• valore medio;
• deviazione standard;
• valore al 25°, 50° e 75° percentile;
• conteggio dei valori.

Qui sotto in Tabella 4 un esempio di output per alcune delle colonne del dataset di OpenCoesione.
È una tabella di gran valore, perché consente di fare delle prime scelte di analisi e di trasformazione dei dati e avere restituito degli elementi di qualità dei dati.

column_name	column_type	min	max	approx_unique	avg	std	q25	q50	q75	count	null_percentage
OC_TOT_PAGAMENTI_RENDICONTAB_UE	FLOAT	-450519.72	1433693200.0	449379	48410.75611172828	1908955.4857718376	455.01105803437605	1815.3021594409709	9166.19804364237	1936839	8.22%
CUP_DESCR_SETTORE	VARCHAR		SERVIZI PER LA P.A. E PER LA COLLETTIVITA’	12						1936839	0.0%
DESCR_INDICATORE_2	VARCHAR		tematiche oggetto di approfondimento a favore dei beneficiari potenziale ed effettivi	600						1936839	0.0%
FINANZ_DA_REPERIRE	FLOAT	0.0	929000000.0	241	19124433.744656816	79954584.61051819	42872.88574218749	408335.86328125	4609128.875	1936839	99.99%
OC_FINANZ_UE_FESR_NETTO	FLOAT	-209719.28	1024941760.0	155171	48779.41458696303	2049515.9863344613	0.0	0.0	180.9459324096726	1936839	42.73%

Il comando si lancia anteponendolo alla lista di record di cui si vuole ottenere una preziosa sintesi:

duckdb --csv -c '
SUMMARIZE SELECT * from read_csv_auto("progetti_esteso_20230430.csv.gz")
'

Ma se lo faccio, ottengo un errore:

Error: Invalid Input Error: Could not convert string 'a.001'
to INT64 in column "OC_COD_ARTICOLAZ_PROGRAMMA", at line 25439.

Questo avviene per un problema legato all’inferenza automatica del campo OC_COD_ARTICOLAZ_PROGRAMMA che nelle prime righe contiene valori numerici, ma che in realtà contiene anche caratteri non numerici, con una struttura molto variabile.
Ecco alcuni valori di esempio di questo campo: 01 ; 08 ; III ; 04 ; 02 ; 1 ; 03 ; a ; 2 ; I ; 05 ; POCMOLISE ; VIII.
Nel file dei metadati questo campo è dichiarato coerentemente come char.

L’inferenza automatica di un CSV in di DuckDB lavora di default su 20.480 righe. Quando viene fatto su un file compresso, vengono lette le prime 20.480 righe a partire dall’inizio del file.
È possibile aumentare il numero di righe da leggere, con il parametro sample_size:

duckdb --csv -c '
SUMMARIZE SELECT * from read_csv_auto("progetti_esteso_20230430.csv.gz",sample_size=50000)
'

Anche se aumento l’inferenza a 50.000 righe, ho errori. Stavolta però per il campo COD_TIPO_PROCED_ATTIVAZIONE, che di base sembra contenere numeri, ma alle volte contiene il carattere ..
Nel file dei metadati questo campo è dichiarato come num. È un errore, dovrebbe essere char.

Portando il numero di righe a 100.000, non ho più errori. Ed è molto comodo - per un file “grande”, non ottimizzato per le performance e compresso - ottenere l’output di SUMMARIZE in circa 10 secondi.
Ma la velocità è niente senza qualità: tanti dei campi sono associati a un tipo di campo non corretto. Queste le ragioni principali:

• il separatore dei decimali è la , e non il . (che è un po’ uno standard). Quindi, campi che contengono valori come 5234,14 vengono interpretati come stringhe. Sono le decine di campi con suffisso OC_FINANZ_. Si mappano correttamente se si aggiunge il parametro decimal_separator="," alla funzione read_csv_auto, e se si definiscono tutti i campi numerici come tali.
• C’è però una difformità nell’uso dei separatori dei decimali. Per la grandissima parte dei campi numerici è la ,, ma in campi come PROGRAMMATO_INDICATORE_1 è il .. Quindi se si aggiunge decimal_separator="," (è una dichiarazione globale), si dovrà per campi come PROGRAMMATO_INDICATORE_1 definirli prima come campi di testo e fare poi il casting a FLOAT.
• I campi con le date vengono mappati come numeri interi. Questo in realtà non è un problema ed è coerente con i metadati ufficiali. Il 23 agosto 2021 è espresso come 20210823. Per potere però usare funzioni correlate alle date, è meglio definire i campi come date e non come int. Si fa definendo il formato dei valori delle date, aggiungendo il parametro dateformat='%Y%m%d' alla funzione read_csv_auto e dichiarando i relativi campi come DATE.

OpenCoesione pubblica un file dei metadati: oltre a contenere piccoli errori, non è disponibile anche in un formato che possa essere letto automaticamente da applicazioni e librerie software, non è in formato machine readable (vedi sezione sulla descrizione di un CSV).
Questa mancanza rende l’uso di questo CSV non immediato e non scevro da errori.

Per avere un output del comando SUMMARIZE corretto, in presenza di un CSV non standard (in questo senso) e con alcuni problemi, è necessario scrivere un comando molto “verboso”, come quello sottostante.

Procedura corretta per SUMMARIZE

duckdb --csv -c "
SUMMARIZE SELECT *
REPLACE(
CAST(PROGRAMMATO_INDICATORE_1 AS FLOAT) AS PROGRAMMATO_INDICATORE_1,
CAST(PROGRAMMATO_INDICATORE_2 AS FLOAT) AS PROGRAMMATO_INDICATORE_2,
CAST(PROGRAMMATO_INDICATORE_3 AS FLOAT) AS PROGRAMMATO_INDICATORE_3,
CAST(PROGRAMMATO_INDICATORE_4 AS FLOAT) AS PROGRAMMATO_INDICATORE_4,
CAST(REALIZZATO_INDICATORE_1 AS FLOAT) AS REALIZZATO_INDICATORE_1,
CAST(REALIZZATO_INDICATORE_2 AS FLOAT) AS REALIZZATO_INDICATORE_2,
CAST(REALIZZATO_INDICATORE_3 AS FLOAT) AS REALIZZATO_INDICATORE_3,
CAST(REALIZZATO_INDICATORE_4 AS FLOAT) AS REALIZZATO_INDICATORE_4,
)
from read_csv_auto(
'progetti_esteso_20230430.csv.gz',SEP=';',dateformat='%Y%m%d',decimal_separator=',',sample_size=100000,
types={'OC_COD_ARTICOLAZ_PROGRAMMA':'VARCHAR','FINANZ_UE':'FLOAT','FINANZ_UE_FESR':'FLOAT','FINANZ_UE_FSE':'FLOAT','FINANZ_UE_FEASR':'FLOAT','FINANZ_UE_FEAMP':'FLOAT','FINANZ_UE_IOG':'FLOAT','FINANZ_STATO_FONDO_DI_ROTAZIONE':'FLOAT','FINANZ_STATO_FSC':'FLOAT','FINANZ_STATO_PAC':'FLOAT','FINANZ_STATO_COMPLETAMENTI':'FLOAT','FINANZ_STATO_ALTRI_PROVVEDIMENTI':'FLOAT','FINANZ_REGIONE':'FLOAT','FINANZ_PROVINCIA':'FLOAT','FINANZ_COMUNE':'FLOAT','FINANZ_RISORSE_LIBERATE':'FLOAT','FINANZ_ALTRO_PUBBLICO':'FLOAT','FINANZ_STATO_ESTERO':'FLOAT','FINANZ_PRIVATO':'FLOAT','FINANZ_DA_REPERIRE':'FLOAT','FINANZ_TOTALE_PUBBLICO':'FLOAT','ECONOMIE_TOTALI':'FLOAT','ECONOMIE_TOTALI_PUBBLICHE':'FLOAT','OC_FINANZ_UE_NETTO':'FLOAT','OC_FINANZ_UE_FESR_NETTO':'FLOAT','OC_FINANZ_UE_FSE_NETTO':'FLOAT','OC_FINANZ_UE_FEASR_NETTO':'FLOAT','OC_FINANZ_UE_FEAMP_NETTO':'FLOAT','OC_FINANZ_UE_IOG_NETTO':'FLOAT','OC_FINANZ_STATO_FONDO_ROT_NETTO':'FLOAT','OC_FINANZ_STATO_FSC_NETTO':'FLOAT','OC_FINANZ_STATO_PAC_NETTO':'FLOAT','OC_FINANZ_STATO_COMPL_NETTO':'FLOAT','OC_FINANZ_STATO_ALTRI_PROV_NETTO':'FLOAT','OC_FINANZ_REGIONE_NETTO':'FLOAT','OC_FINANZ_PROVINCIA_NETTO':'FLOAT','OC_FINANZ_COMUNE_NETTO':'FLOAT','OC_FINANZ_RISORSE_LIBERATE_NETTO':'FLOAT','OC_FINANZ_ALTRO_PUBBLICO_NETTO':'FLOAT','OC_FINANZ_STATO_ESTERO_NETTO':'FLOAT','OC_FINANZ_PRIVATO_NETTO':'FLOAT','OC_FINANZ_TOT_PUB_NETTO':'FLOAT','OC_COSTO_COESIONE':'FLOAT','IMPEGNI':'FLOAT','OC_IMPEGNI_GIURID_VINCOLANTI':'FLOAT','OC_IMPEGNI_TRASFERIMENTI':'FLOAT','OC_IMPEGNI_COESIONE':'FLOAT','TOT_PAGAMENTI':'FLOAT','OC_TOT_PAGAMENTI_BENEFICIARI':'FLOAT','OC_TOT_PAGAMENTI_TRASFERIMENTI':'FLOAT','COSTO_REALIZZATO':'FLOAT','COSTO_RENDICONTABILE_UE':'FLOAT','OC_TOT_PAGAMENTI_RENDICONTAB_UE':'FLOAT','OC_TOT_PAGAMENTI_FSC':'FLOAT','OC_TOT_PAGAMENTI_PAC':'FLOAT','OC_PAGAMENTI_COESIONE':'FLOAT','OC_DATA_INIZIO_PROGETTO':'DATE','OC_DATA_FINE_PROGETTO_PREVISTA':'DATE','OC_DATA_FINE_PROGETTO_EFFETTIVA':'DATE','DATA_INIZIO_PREV_STUDIO_FATT':'DATE','DATA_INIZIO_EFF_STUDIO_FATT':'DATE','DATA_FINE_PREV_STUDIO_FATT':'DATE','DATA_FINE_EFF_STUDIO_FATT':'DATE','DATA_INIZIO_PREV_PROG_PREL':'DATE','DATA_INIZIO_EFF_PROG_PREL':'DATE','DATA_FINE_PREV_PROG_PREL':'DATE','DATA_FINE_EFF_PROG_PREL':'DATE','DATA_INIZIO_PREV_PROG_DEF':'DATE','DATA_INIZIO_EFF_PROG_DEF':'DATE','DATA_FINE_PREV_PROG_DEF':'DATE','DATA_FINE_EFF_PROG_DEF':'DATE','DATA_INIZIO_PREV_PROG_ESEC':'DATE','DATA_INIZIO_EFF_PROG_ESEC':'DATE','DATA_FINE_PREV_PROG_ESEC':'DATE','DATA_FINE_EFF_PROG_ESEC':'DATE','DATA_INIZIO_PREV_AGG_BANDO':'DATE','DATA_INIZIO_EFF_AGG_BANDO':'DATE','DATA_FINE_PREV_AGG_BANDO':'DATE','DATA_FINE_EFF_AGG_BANDO':'DATE','DATA_INIZIO_PREV_STIP_ATTRIB':'DATE','DATA_INIZIO_EFF_STIP_ATTRIB':'DATE','DATA_FINE_PREV_STIP_ATTRIB':'DATE','DATA_FINE_EFF_STIP_ATTRIB':'DATE','DATA_INIZIO_PREV_ESECUZIONE':'DATE','DATA_INIZIO_EFF_ESECUZIONE':'DATE','DATA_FINE_PREV_ESECUZIONE':'DATE','DATA_FINE_EFF_ESECUZIONE':'DATE','DATA_INIZIO_PREV_COLLAUDO':'DATE','DATA_INIZIO_EFF_COLLAUDO':'DATE','DATA_FINE_PREV_COLLAUDO':'DATE','DATA_FINE_EFF_COLLAUDO':'DATE','COD_TIPO_PROCED_ATTIVAZIONE':'VARCHAR','OC_FLAG_REGIONE_UNICA':'INT','DATA_AGGIORNAMENTO':'DATE','OC_FLAG_CUP':'INT','PROGRAMMATO_INDICATORE_1':'VARCHAR','REALIZZATO_INDICATORE_1':'VARCHAR','PROGRAMMATO_INDICATORE_2':'VARCHAR','REALIZZATO_INDICATORE_2':'VARCHAR','PROGRAMMATO_INDICATORE_3':'VARCHAR','REALIZZATO_INDICATORE_3':'VARCHAR','PROGRAMMATO_INDICATORE_4':'VARCHAR','REALIZZATO_INDICATORE_4':'VARCHAR'}
)
" >summarize.csv

Con questi dati di sintesi emerge ad esempio che circa 36 campi hanno almeno il 90% dei valori nulli.
O che in alcuni campi con le date ci sono valori (di minimo o di massimo) strani e probabilmente errati, come quelli in Tabella 5.

column_name	min	max
OC_DATA_INIZIO_PROGETTO	1899-12-30	2024-02-01
DATA_INIZIO_EFF_STIP_ATTRIB	1899-12-30	2025-12-31
DATA_INIZIO_EFF_AGG_BANDO	1900-01-01	2030-03-03
DATA_FINE_PREV_STUDIO_FATT	1987-07-28	2103-06-30
DATA_FINE_EFF_STUDIO_FATT	1987-07-28	2103-06-30
OC_DATA_FINE_PROGETTO_PREVISTA	1899-12-30	2103-12-31
DATA_FINE_PREV_ESECUZIONE	1899-12-30	2103-12-31
DATA_INIZIO_EFF_ESECUZIONE	1899-12-30	2211-01-20
OC_DATA_FINE_PROGETTO_EFFETTIVA	1899-12-30	2211-08-31
DATA_FINE_EFF_ESECUZIONE	1899-12-30	2211-08-31
DATA_FINE_EFF_STIP_ATTRIB	1899-12-30	4014-03-07
DATA_FINE_PREV_AGG_BANDO	1991-12-05	8012-10-08

Ma soprattutto è possibile constatare quali siano i campi “categorici”, quelli con un numero limitato di valori univoci, che possono essere usati per raggruppare e aggregare i dati e fare emergere elementi interessanti.

Tra i campi categorici OC_MACROAREA, che definisce le macroaree geografiche italiane. E per sapere ad esempio qual è il finanziamento pubblico totale per ciascuna, si può usare la query SQL:

SELECT OC_MACROAREA,
CAST(SUM(FINANZ_TOTALE_PUBBLICO) AS BIGINT) FINANZ_TOTALE_PUBBLICO
GROUP BY OC_MACROAREA
ORDER BY FINANZ_TOTALE_PUBBLICO DESC

Restituirà qualcosa come in Tabella 6.

Macro area	Finanziamento totale pubblico (€)
Mezzogiorno	182.919.710.550
Centro-Nord	61.964.843.697
Ambito Nazionale	8.808.650.456
Altro	3.684.521.639
Estero	287.153.594

data = FileAttachment("./risorse/sum-by-region.csv").csv({ typed: true })
Inputs.table(data, {locale: "it-IT"})

➡️ Purtroppo però non è possibile usare in modo comodo una query come quella di Lista 5.
Perché, come scritto sopra, il CSV ha alcuni problemi e non è “standard”.
Per eseguirla allora sarebbe necessario inserire la lunghissima lista di parametri per la funzione read_csv_auto e definire i tipi di campo, così come nel caso di SUMMARIZE. Ma sarebbe molto scomodo e poco pratico.

Due modi per risolvere il problema:

• creare un CSV “pulito” e standard, con i tipi di campo corretti, e lavorare su questo;
• trasformare il file CSV di input in un file PARQUET e lavorare su questo.

In conclusione

Con questo lungo post non voglio contribuire a rendere il mondo brutto e fare in modo che il formato CSV sia utilizzato ancora di più.
A parte gli scherzi, è certamente un formato con alcune problematicità, ma è ancora molto utilizzato come formato di scambio di dati in forma di testo strutturato.

Con le dovute precauzioni, con gli strumenti giusti, con un corredo informativo adeguato e per dimensioni non eccessive, può essere un formato comodo e pratico.
Descrivendolo, “standardizzandolo” e comprimendolo, diventa molto più usabile.
E questo è un invito a chiunque rende disponibili online dati in formato CSV.
Finché dura, usiamolo bene.

Un altro suggerimento (a me per primo) è quello di usare SQL per costruire processi di analisi e di trasformazione dei dati. È un vecchio e diffuso linguaggio, utilizzabile da quasi qualsiasi applicazione e/o linguaggio di programmazione, correlati ai dati. È super documentato, ci sono migliaia di tutorial, messaggi sui forum, libri, ecc.

E ci sono strumenti come DuckDB. Ok, non è vero che i “I Big Data” sono morti, ma con strumenti come questo, è possibile lavorare in modo comodo e rapido con dati di dimensioni importanti, senza dover ricorrere a infrastrutture complesse e costose.

Ho voluto suggerire l’opportunità di utilizzare il formato Parquet come uno dei formati principali di scambio e di lavoro con i dati.

E infine voglio sottolineare ancora una volta, che senza dataset come quelli di OpenCoesione, non avrei pensato di scrivere questo post e non sarei riuscito a dargli questo sviluppo.

Buone letture e fonti di ispirazione

• Big data is dead
• Why parquet files are my preferred API for bulk open data
• A Parquet File Is All You Need
• Performance Explorations of GeoParquet (and DuckDB)
• Parquet file format – everything you need to know!
• CSV Loading
• CSV on the Web: A Primer
• Parquet devrait remplacer le format CSV
• Geospatial DuckDB
• Even Friendlier SQL with DuckDB

Il piacere di vedere questo articolo “girare”