Regole di Business - Data Engineering

Questo documento elenca le regole di business fondamentali del dominio Data Engineering, identificate con codice univoco BR-NNN. Ogni regola è technology-independent e descrive un vincolo invariante sul comportamento di una piattaforma dati.

---

BR-001 - Idempotenza delle esecuzioni di pipeline

Codice: BR-001 Nome: Ogni esecuzione di una PipelineDati deve essere idempotente Descrizione: Rieseguire la stessa pipeline sullo stesso intervallo di partizione (es. la stessa data logica) deve produrre lo stesso Dataset di output, senza duplicati né effetti collaterali cumulativi. Le scritture devono usare pattern overwrite-partition, merge/upsert su chiave, o insert-if-not-exists, mai append cieco. Motivazione: Permettere retry sicuri dopo guasti transienti e backfill ripetibili senza corrompere i dati. Priorità: CRITICA Attori: Data Engineer, Scheduler Violazione: duplicazione di righe nel Dataset; il QualityCheck di unicità fallisce e blocca la pubblicazione. Tracciabilità: glossary Idempotenza, Scrittura Idempotente, Backfill; Apache Airflow idempotency guidelines.

---

BR-002 - Validazione di qualità prima della pubblicazione

Codice: BR-002 Nome: Nessun Dataset passa allo stato published senza superare i QualityCheck bloccanti Descrizione: Prima di promuovere un dataset a published, la pipeline deve eseguire i controlli di qualità definiti (non-null sulle colonne chiave, unicità della chiave primaria logica, freshness entro SLA, range/dominio dei valori, conteggio righe entro soglie attese). I controlli marcati blocking arrestano la promozione; quelli warning la consentono ma emettono un alert. Motivazione: Impedire che dati corrotti o incompleti raggiungano i consumatori a valle. Priorità: ALTA Attori: Data Steward, Data Engineer Violazione: evento DataQualityFallita; il Dataset resta in validated e non transita a curated/published. Tracciabilità: glossary Data Quality, Great Expectations; BR-001.

---

BR-003 - Compatibilità di schema verso l'indietro

Codice: BR-003 Nome: Un'evoluzione di schema non può introdurre cambiamenti breaking senza versionamento Descrizione: L'aggiunta di una colonna opzionale o la promozione di tipo compatibile (int → long) è permessa in-place. La rimozione di una colonna, la ridenominazione, il cambio di tipo non compatibile o l'irrigidimento di un vincolo sono cambiamenti breaking: richiedono una nuova versione del Dataset (o una SchemaEvolution esplicita con periodo di coesistenza) per non rompere i consumatori esistenti. Motivazione: Proteggere job e query a valle da rotture silenziose del contratto dati. Priorità: ALTA Attori: Data Engineer, Data Consumer Violazione: evento SchemaBreakingChange; deploy del nuovo schema bloccato dallo Schema Registry in modalità BACKWARD. Tracciabilità: glossary Schema Evolution, Schema Registry, Apache Avro; Confluent Schema Registry compatibility modes.

---

BR-004 - SLA di freshness per ogni dataset pubblicato

Codice: BR-004 Nome: Ogni Dataset in stato published dichiara e rispetta un SLA di freshness Descrizione: Ogni dataset esposto ai consumatori deve avere un SLA esplicito (es. "aggiornato entro le 06:00 UTC con dati fino a T-1"). Il sistema monitora il timestamp dell'ultima partizione valida; se supera la soglia di tolleranza, lo SLA è violato e i consumatori devono essere avvisati. Motivazione: Garantire ai consumatori aspettative affidabili sull'attualità dei dati. Priorità: ALTA Attori: Data Engineer, Data Consumer, Scheduler Violazione: eventi SLAViolato e DataFreshnessDegradata; alert al team owner. Tracciabilità: glossary SLA, Data Freshness, Partitioning; BR-002.

---

BR-005 - Lineage tracciabile end-to-end

Codice: BR-005 Nome: Ogni Dataset registra il proprio DataLineage a monte e a valle Descrizione: Per ogni dataset prodotto deve essere registrata la lista delle sorgenti di input (upstream) e delle trasformazioni applicate, in modo che sia ricostruibile l'origine di ogni colonna. La rimozione o modifica di una sorgente deve propagare un aggiornamento di lineage ai dataset derivati. Motivazione: Abilitare impact analysis, debugging, compliance (GDPR data provenance) e fiducia nei dati. Priorità: ALTA Attori: Data Steward, Data Engineer Violazione: lineage incompleto → impossibile valutare l'impatto di un SchemaBreakingChange. Tracciabilità: glossary Data Lineage, Data Catalog; OpenLineage spec; Regolamento UE 2016/679 (GDPR) art. 30.

---

BR-006 - Minimizzazione e classificazione dei dati personali

Codice: BR-006 Nome: I dati personali devono essere classificati, minimizzati e mascherati nelle zone non-protette Descrizione: Ogni colonna che contiene dati personali (PII) deve essere etichettata nel DataCatalog. Nelle zone di consumo generale (es. dataset published per analisi self-service) i campi sensibili devono essere mascherati, pseudonimizzati o esclusi, salvo che il consumatore abbia un legittimo accesso autorizzato. Motivazione: Conformità GDPR (minimizzazione, limitazione delle finalità) e riduzione del rischio di data breach. Priorità: CRITICA Attori: Data Steward, Data Consumer Violazione: PII esposta in chiaro a consumatori non autorizzati → incidente di compliance. Tracciabilità: glossary Data Governance, Data Catalog; Regolamento UE 2016/679 art. 5, art. 25.

---

BR-007 - Separazione delle zone (raw / curated / published)

Codice: BR-007 Nome: I dati transitano attraverso zone con responsabilità distinte e non saltano stadi Descrizione: L'architettura adotta zone di maturità progressiva: raw (ingest fedele alla sorgente, immutabile), validated/curated (puliti, conformi, tipizzati) e published (modellati per il consumo, documentati). Un consumatore di analytics non legge mai direttamente la zona raw; ogni promozione tra zone è esplicita e tracciata. Motivazione: Isolare i guasti, garantire riproducibilità (la zona raw permette il re-processing) e disaccoppiare ingest da consumo. Priorità: ALTA Attori: Data Engineer, Data Consumer Violazione: consumo diretto della zona raw → dipendenza fragile da formati grezzi non garantiti. Tracciabilità: glossary Data Lake, Data Lakehouse, Medallion Architecture; state-machine dataset-lifecycle.md.

---

BR-008 - Costo e partizionamento sotto controllo

Codice: BR-008 Nome: Le tabelle di grandi dimensioni devono essere partizionate e le query devono usare il partition pruning Descrizione: I dataset che superano una soglia di volume devono essere partizionati su una chiave selettiva (tipicamente temporale). Le query di lettura devono filtrare sulla colonna di partizione per abilitare il pruning ed evitare full scan costosi. Lo storage colonnare (Parquet/ORC) è obbligatorio per i dataset analitici. Motivazione: Controllare costi di calcolo/storage e latenza delle query analitiche. Priorità: MEDIA Attori: Data Engineer, Data Consumer Violazione: full table scan ricorrenti → costi e tempi di query fuori budget. Tracciabilità: glossary Partitioning, Storage Colonnare, Apache Parquet; evento PartitionCreated.