Questa pagina raccoglie i contratti operativi stabili del toolkit per la pipeline RAW -> CLEAN -> MART.
- I path relativi dichiarati in
dataset.ymlsono risolti rispetto alla directory che contiene il filedataset.yml. - Questo vale per
root,raw.*.args.path,clean.sql,mart.tables[].sqle gli altri campi path whitelisted dal loader.
- Il layer RAW scrive sempre
manifest.jsonnella directoryraw/<dataset>/<year>/. - Il manifest include sempre
primary_output_file, che rappresenta il file RAW canonico da usare a valle. primary_output_fileesources[].output_filesono path relativi al year-dir RAW, in formato POSIX.- Lo schema del manifest e` cross-layer: RAW lo produce, CLEAN lo legge.
- Gli artefatti di profiling vivono in
raw/<dataset>/<year>/_profile/. - Il file JSON canonico e
raw_profile.json, ma viene scritto solo per policystandard|debug`. profile.jsonresta un alias di compatibilitaopzionale, controllato daoutput.legacy_aliases`.suggested_read.ymleil contratto usato da CLEAN per i format hints e resta richiesto solo quandoclean.read.source: auto`.run rawpuoscrivere unsuggested_read.ymlconservativo gianel percorso canonico.profile rawpuorigenerare lo stesso file insieme ad artefatti diagnostici piuricchi.suggested_mapping.ymlresta un artefatto diagnostico opzionale per uso umano; non e` un input del runtime canonico del toolkit.
| Policy | Keep | Drop |
|---|---|---|
minimal |
file primario RAW, parquet finali, metadata.json, manifest.json, *_validation.json, suggested_read.yml solo con clean.read.source: auto |
raw_profile.json, profile.json, profile.md, suggested_mapping.yml, _run/*.sql |
standard |
tutto il required + raw_profile.json + _run/*.sql |
profile.md, suggested_mapping.yml; profile.json solo se output.legacy_aliases: true |
debug |
tutti gli artefatti, inclusi report e alias legacy | nulla |
- Config canonica:
output:
artifacts: standard
legacy_aliases: true- CLEAN usa una policy manifest-first: se
manifest.jsoncontiene unprimary_output_filevalido, quello ha precedenza. - Se il manifest manca, e` incompleto o punta a un file non valido, CLEAN usa il fallback legacy di selezione e logga un warning.
- Il fallback supporta
explicit,latest,largest,all.
- La forma canonica e`:
clean:
read:
source: auto # oppure config_only- L'alias scalare
clean.read: auto|config_onlye` ancora supportato ma deprecato.
- La configurazione finale del reader CLEAN segue sempre questo ordine:
defaults -> suggested(format-only) -> config_overrides - I suggerimenti letti da
_profile/suggested_read.ymlsono filtrati alle sole chiavi di formato.
clean.read_modegoverna la strategia di lettura:strictfallbackrobust
- I suggested hints non forzano mai il preset robusto.
- Il preset robusto viene applicato solo se richiesto da
clean.read_modeo dal fallback runtime del reader.
clean.read.columnsdichiara uno schema canonico per il reader CLEAN.clean.read.normalize_rows_to_columns: trueattiva una lettura CSV normalizzata lato toolkit:- richiede
clean.read.columns - salta l'header se
header: true - pad-da a destra le righe piu corte fino al numero di colonne atteso
- fallisce se una riga ha piu colonne di quelle dichiarate
- richiede
Usarlo quando:
- stai leggendo CSV pubblici multi-anno con schema quasi stabile ma non identico
- vuoi mantenere un mapping posizionale unico nel
clean.sql - alcune annualita hanno colonne finali assenti o vuote
Non usarlo quando:
- il file ha gia uno schema per nome colonna stabile
- il problema e solo di delimitatore o quoting
- non hai deciso esplicitamente uno schema canonico
- Ogni
metadata.jsonincludemetadata_schema_version. - Il metadata CLEAN include anche i campi di audit
read_params_source,read_source_used,read_params_used.
- Ogni validation report JSON include
validation_schema_version. - I path di output restano:
- RAW:
raw_validation.json - CLEAN:
_validate/clean_validation.json - MART:
_validate/mart_validation.json
- RAW:
Pattern ricorrenti su CSV e XLSX da portali pubblici italiani. Da considerare
prima di scrivere clean.sql e clean.read.
La maggior parte dei portali PA produce file in cp1252 (Windows-1252), non UTF-8.
Dichiarare sempre l'encoding esplicitamente:
clean:
read:
encoding: cp1252Se non dichiarato e il file contiene caratteri accentati, il run fallisce o produce artefatti silenziosi.
Alcune fonti (es. MEF/Finanze, ISTAT) distribuiscono un archivio ZIP che contiene uno o piu XLSX. Il toolkit non estrae ZIP automaticamente: il RAW extractor deve essere configurato per gestire il pattern ZIP → file interno.
Verificare con toolkit scout-url <url> se la sorgente e` un ZIP prima di
configurare l'extractor.
I CSV multi-anno di fonti come IRPEF, AIFA o SIOPE cambiano spesso:
- colonne aggiunte o rimosse tra un anno e l'altro
- nomi colonna con varianti ortografiche (maiuscolo/minuscolo, spazi vs underscore)
- righe di intestazione o footer aggiuntive in alcuni anni
Usare toolkit inspect schema-diff --config dataset.yml --json per confrontare
i segnali RAW tra anni prima di scrivere il clean.sql.
Per CSV con schema posizionale quasi stabile, usare normalize_rows_to_columns: true
(vedi sezione Positional Fixed Schema).
Alcuni CSV non hanno header o hanno un header non standard (riga 2, merged cell da XLSX). Dichiarare:
clean:
read:
header: false
skip: 1 # righe da saltare prima dell'header realeLe chiavi geografiche nei dataset PA italiani non sono sempre ISTAT-standard:
- codici ISTAT comuni a 6 cifre vs 3+3 (provincia+comune)
- nomi comune con varianti storiche (fusioni, cambio denominazione)
- codici regione con offset legacy
Dichiarare i limiti noti nel notes.md del candidate e nel README di analisi/.
Non tentare di normalizzare le chiavi nel clean.sql senza documentare la
scelta esplicitamente.