Perché serve una governance centralizzata
In un data estate distribuito tra Azure Data Lake Storage Gen2, Azure SQL Database, Synapse e Databricks, sapere dove si trovano i dati sensibili, chi vi accede e come fluiscono è un problema di scala. La governance manuale — fogli Excel di inventario, classificazioni fatte a mano, diagrammi di lineage disegnati e subito obsoleti — non regge il ritmo di un data engineer: si desincronizza appena qualcuno crea una nuova tabella. Microsoft Purview risolve il problema catalogando automaticamente le sorgenti, classificandole e ricostruendo il lineage a partire dai metadati, mantenendo un’unica source of truth aggiornata dagli scan.
Data Map e scanning delle sorgenti
Il cuore di Purview è il Data Map: un grafo di metadati che rappresenta asset, schemi, classificazioni e relazioni. Lo si popola registrando le sorgenti e lanciando degli scan.
- La registrazione definisce la sorgente (es. un account ADLS Gen2 o un workspace Synapse) e la collection in cui i suoi asset finiranno — le collection sono anche l’unità su cui si applicano i permessi.
- Lo scan legge lo schema, estrae i metadati e applica un scan rule set (system o custom) che decide quali classificazioni cercare.
- Puoi eseguire uno scan full o incremental e schedularlo (settimanale, mensile) per mantenere il Data Map allineato senza ripartire ogni volta da zero.
L’autenticazione tipica è la managed identity di Purview (system-assigned o user-assigned), che deve avere i permessi corretti sulla sorgente: Storage Blob Data Reader su ADLS, db_datareader su SQL, e via dicendo. Senza questi ruoli lo scan fallisce o resta parziale.
Classificazione e sensitivity label
Durante lo scan Purview esegue la classificazione automatica: campiona i dati e applica classification predefinite (Credit Card Number, EU passport, codice fiscale, ecc.) o custom basate su pattern regex e dizionari. Sopra le classification puoi mappare le sensitivity label definite in Microsoft Purview Information Protection (le stesse di Microsoft 365): questo estende l’etichettatura Confidential / Highly Confidential anche ai dati strutturati nel data estate, non solo a documenti e mail.
Il business glossary aggiunge il livello semantico: termini di business (Customer, Revenue) con definizione, owner ed esperto, associati agli asset tecnici. Colma il divario tra il nome fisico di una colonna e il suo significato per l’organizzazione.
Data lineage end-to-end
Purview costruisce il data lineage tracciando il movimento del dato attraverso le pipeline:
- Azure Data Factory e le Synapse pipeline: le attività di Copy, Data Flow ed Execute emettono lineage automaticamente, purché il servizio ADF/Synapse sia connesso a Purview.
- Azure Databricks / Spark: il lineage arriva tramite l’integrazione OpenLineage / connettore Spark che pubblica gli eventi sul Data Map.
Il risultato è una vista source-to-report navigabile, fondamentale per l’impact analysis (cosa si rompe se cambio questa tabella) e per la root cause analysis. Attenzione: il lineage copre le attività supportate — trasformazioni fatte in codice arbitrario o SQL non tracciato non compaiono automaticamente.
Integrazione con RBAC e compliance
L’accesso a Purview è governato dai data plane roles assegnati sulle collection: Collection Admin, Data Source Admin, Data Curator, Data Reader. Sono distinti dai ruoli Azure RBAC del control plane (chi gestisce la risorsa Purview). Le classificazioni e le sensitivity label alimentano poi report di compliance e possono guidare policy di protezione, offrendo evidenza documentata per audit GDPR e simili.
Purview vs governance manuale
| Aspetto | Governance manuale | Microsoft Purview |
|---|---|---|
| Inventario asset | statico, si desincronizza | aggiornato dagli scan schedulati |
| Classificazione | soggettiva, incompleta | automatica su pattern |
| Lineage | diagrammi obsoleti | ricostruito dai metadati delle pipeline |
| Scalabilità | non regge la crescita | cataloga l’intero estate |
Il rovescio della medaglia: gli scan hanno un costo (vCore-ora di scansione + storage del Data Map) e richiedono setup di identità e permessi. Non è “gratis e automatico”.
Trappole tipiche d’esame
- Scenario: lo scan di un account ADLS Gen2 fallisce o non trova asset → verifica che la managed identity di Purview abbia il ruolo Storage Blob Data Reader sulla sorgente. Un problema di permessi, non di configurazione dello scan.
- Scenario: devi ridurre il costo mantenendo il catalogo aggiornato → schedula scan incremental invece di full ricorrenti; ricorda che gli scan si fatturano a consumo.
- Scenario: serve tracciare il flusso da un file sorgente fino al report di BI attraverso ADF e Databricks → è data lineage nel Data Map, non la classification né il glossary.
- Scenario: vuoi estendere le etichette Confidential di Microsoft 365 anche alle colonne di un database → sensitivity label di Purview Information Protection applicate durante lo scan, non classification custom.
- Scenario: un utente deve poter curare asset di una sola collection → assegna il ruolo Data Curator sulla collection, non un ruolo Azure RBAC sull’intera risorsa Purview.