Procedure consigliate per l'analisi di Microsoft Purview

Le soluzioni di governance di Microsoft Purview supportano l'analisi automatizzata delle origini dati locali, multicloud e software as a service (SaaS).

L'esecuzione di un'analisi richiama il processo per inserire metadati dalle origini dati registrate. I metadati curati al termine del processo di analisi e cura includono metadati tecnici. Questi metadati possono includere nomi di asset di dati, ad esempio nomi di tabella o file, dimensioni del file, colonne e derivazione dei dati. I dettagli dello schema vengono acquisiti anche per le origini dati strutturate. Un sistema di gestione di database relazionale è un esempio di questo tipo di origine.

Il processo di cura applica etichette di classificazione automatizzate negli attributi dello schema in base al set di regole di analisi configurato. Le etichette di riservatezza vengono applicate se l'account Microsoft Purview è connesso alla Portale di conformità di Microsoft Purview.

Importante

Se sono presenti criteri di Azure che impediscono gli aggiornamenti agli account di archiviazione, ciò causerà errori per il processo di analisi di Microsoft Purview. Seguire la guida ai tag di eccezione di Microsoft Purview per creare un'eccezione per gli account Microsoft Purview.

Perché sono necessarie procedure consigliate per gestire le origini dati?

Le procedure consigliate consentono di:

• Ottimizzare i costi.
• Creare l'eccellenza operativa.
• Migliorare la conformità alla sicurezza.
• Aumentare l'efficienza delle prestazioni.

Registrare un'origine e stabilire una connessione

Le considerazioni e le raccomandazioni di progettazione seguenti consentono di registrare un'origine e stabilire una connessione.

Considerazioni sulla progettazione

• Usare le raccolte per creare la gerarchia allineata alla strategia dell'organizzazione, ad esempio geografica, funzione aziendale o origine dei dati. La gerarchia definisce le origini dati da registrare e analizzare.
• Per impostazione predefinita, non è possibile registrare più volte le origini dati nello stesso account Microsoft Purview. Questa architettura consente di evitare il rischio di assegnare un controllo di accesso diverso alla stessa origine dati.

Consigli per la progettazione

• Se i metadati della stessa origine dati vengono utilizzati da più team, è possibile registrare e gestire l'origine dati in una raccolta padre. È quindi possibile creare analisi corrispondenti in ogni sottoraccolta. In questo modo, gli asset pertinenti vengono visualizzati in ogni raccolta figlio. Le origini senza elementi padre vengono raggruppate in una casella tratteggiata nella visualizzazione mappa. Nessuna freccia li collega ai genitori.

  

• Usare l'opzione Azure Multiple se è necessario registrare più origini, ad esempio sottoscrizioni di Azure o gruppi di risorse, nel cloud. Per altre informazioni, vedere la documentazione seguente:

  • Analizzare più origini in Microsoft Purview
  • Controllare l'idoneità dell'origine dati su larga scala
  • Configurare l'accesso alle origini dati per l'identità del servizio gestito di Microsoft Purview su larga scala

• Dopo aver registrato un'origine dati, è possibile analizzare più volte la stessa origine, nel caso in cui la stessa origine venga usata in modo diverso da vari team o business unit.

Per altre informazioni su come definire una gerarchia per la registrazione delle origini dati, vedere Procedure consigliate per l'architettura delle raccolte.

Analisi

Le considerazioni e le raccomandazioni di progettazione seguenti sono organizzate in base ai passaggi chiave coinvolti nel processo di analisi.

Considerazioni sulla progettazione

• Dopo aver registrato l'origine dati, configurare un'analisi per gestire l'analisi e la cura dei metadati automatizzate e sicure.
• La configurazione dell'analisi include la configurazione del nome dell'analisi, dell'ambito dell'analisi, del runtime di integrazione, della frequenza del trigger di analisi, del set di regole di analisi e del set di risorse in modo univoco per ogni origine dati per ogni frequenza di analisi.
• Prima di creare le credenziali, considerare i tipi di origine dati e i requisiti di rete. Queste informazioni consentono di decidere il metodo di autenticazione e il runtime di integrazione necessari per lo scenario.

Consigli per la progettazione

Dopo aver registrato l'origine nella raccolta pertinente, pianificare e seguire l'ordine mostrato qui quando si configura l'analisi. Questo ordine di processo consente di evitare costi imprevisti e rielaborare.

1. Identificare i requisiti di classificazione dalle regole di classificazione predefinite del sistema. In alternativa, è possibile creare regole di classificazione personalizzate specifiche, se necessario. Basarli su specifici requisiti di settore, aziendali o regionali, che non sono disponibili all'inizio:

   • Vedere le procedure consigliate per la classificazione.
   • Vedere come creare una regola di classificazione e classificazione personalizzata.

2. Creare set di regole di analisi prima di configurare l'analisi.

   

   Quando si crea il set di regole di analisi, verificare i punti seguenti:

   • Verificare se il set di regole di analisi predefinito del sistema è sufficiente per l'origine dati analizzata. In caso contrario, definire il set di regole di analisi personalizzato.

   • Il set di regole di analisi personalizzato può includere sia l'impostazione predefinita del sistema che quella personalizzata, quindi deselezionare le opzioni non rilevanti per gli asset di dati analizzati.

   • Se necessario, creare un set di regole personalizzato per escludere le etichette di classificazione indesiderate. Ad esempio, il set di regole di sistema contiene modelli di codice per enti pubblici generici per il pianeta, non solo il Stati Uniti. I dati potrebbero corrispondere al modello di un altro tipo, ad esempio "Belgium Driver's License Number".

   • Limitare le regole di classificazione personalizzate alle etichette più importanti e pertinenti per evitare confusione. Non si vuole avere troppe etichette contrassegnate per l'asset.

   • Se si modifica il set di regole di classificazione o analisi personalizzato, viene attivata un'analisi completa. Configurare il set di regole di classificazione e analisi in modo appropriato per evitare rielaborazioni e costose analisi complete.

     

     Nota

     Quando si analizza un account di archiviazione, Microsoft Purview usa un set di modelli definiti per determinare se un gruppo di asset forma un set di risorse. È possibile usare le regole del modello di set di risorse per personalizzare o ignorare il modo in cui Microsoft Purview rileva quali asset sono raggruppati come set di risorse. Le regole determinano anche la modalità di visualizzazione degli asset all'interno del catalogo. Per altre informazioni, vedere Creare regole del modello di set di risorse. Questa funzionalità include considerazioni sui costi. Per informazioni, vedere la pagina dei prezzi.

3. Configurare un'analisi per le origini dati registrate.

   • Nome analisi: per impostazione predefinita, Microsoft Purview usa la convenzione di denominazione SCAN-[A-Z][a-z][a-z], che non è utile quando si tenta di identificare un'analisi eseguita. Assicurarsi di usare una convenzione di denominazione significativa. Ad esempio, è possibile denominare l'ambiente di analisi environment-source-frequency-time come DEVODS-Daily-0200. Questo nome rappresenta un'analisi giornaliera a 0200 ore.

   • Autenticazione: Microsoft Purview offre vari metodi di autenticazione per l'analisi delle origini dati, a seconda del tipo di origine. Può trattarsi di origini cloud, locali o di terze parti di Azure. Seguire il principio dei privilegi minimi per il metodo di autenticazione in questo ordine di preferenza:

     • Identità del servizio gestito di Microsoft Purview (ad esempio, per le origini Azure Data Lake Storage Gen2)
     • Identità gestita assegnata dall'utente
     • Entità servizio
     • Autenticazione SQL (ad esempio, per origini locali o Azure SQL)
     • Chiave dell'account o autenticazione di base (ad esempio, per le origini SAP S/4HANA)

     Per altre informazioni, vedere la guida pratica per gestire le credenziali.

     Nota

     Se è abilitato un firewall per l'account di archiviazione, è necessario usare il metodo di autenticazione dell'identità gestita quando si configura un'analisi. Quando si configura una nuova credenziale, il nome delle credenziali può contenere solo lettere, numeri, caratteri di sottolineatura e trattini.

   • Runtime di integrazione

     • Per altre informazioni, vedere Procedure consigliate per l'architettura di rete.
     • Se il runtime di integrazione self-hosted (SHIR) viene eliminato, le analisi in corso che si basano su di esso avranno esito negativo.
     • Quando si usa SHIR, assicurarsi che la memoria sia sufficiente per l'origine dati analizzata. Ad esempio, quando si usa SHIR per l'analisi di un'origine SAP, se viene visualizzato "errore di memoria insufficiente":
       • Verificare che il computer SHIR disponga di memoria sufficiente. La quantità consigliata è 128 GB.
       • Nell'impostazione di analisi impostare la memoria massima disponibile come valore appropriato, ad esempio 100.
       • Per altre informazioni, vedere i prerequisiti in Analizzare e gestire SAP ECC Microsoft Purview.

   • Analisi dell'ambito

     • Quando si configura l'ambito per l'analisi, selezionare solo gli asset rilevanti a livello granulare o padre. Questa procedura garantisce che il costo dell'analisi sia ottimale e che le prestazioni siano efficienti. Tutti gli asset futuri in un determinato elemento padre verranno selezionati automaticamente se l'elemento padre viene controllato completamente o parzialmente.

     • Alcuni esempi per alcune origini dati:

       • Per Azure SQL database o Data Lake Storage Gen2, è possibile definire l'ambito dell'analisi per parti specifiche dell'origine dati. Selezionare gli elementi appropriati nell'elenco, ad esempio cartelle, sottocartelle, raccolte o schemi.
       • Per le origini Oracle, Hive Metastore Database e Teradata, è possibile specificare un elenco specifico di schemi da esportare tramite valori separati da punto e virgola o modelli di nome dello schema usando espressioni SQL LIKE.
       • Per google big query, è possibile specificare un elenco specifico di set di dati da esportare tramite valori separati da punto e virgola.
       • Quando si crea un'analisi per un intero account AWS, è possibile selezionare bucket specifici da analizzare. Quando si crea un'analisi per un bucket AWS S3 specifico, è possibile selezionare cartelle specifiche da analizzare.
       • Per Erwin, è possibile definire l'ambito dell'analisi fornendo un elenco separato da punto e virgola di stringhe del localizzatore di modelli Erwin.
       • Per Cassandra, è possibile specificare un elenco specifico di spazi chiave da esportare tramite valori separati da punto e virgola o tramite i modelli di nome degli spazi chiave usando espressioni SQL LIKE.
       • Per Looker, è possibile definire l'ambito dell'analisi fornendo un elenco di progetti Looker separati da punto e virgola.
       • Per il tenant di Power BI, è possibile specificare solo se includere o escludere l'area di lavoro personale.

       

     • In generale, usare "ignore patterns", dove sono supportati, in base a caratteri jolly (ad esempio, per data lake) per escludere temp, file di configurazione, tabelle di sistema RDBMS o tabelle di backup o STG.

     • Quando si analizzano documenti o dati non strutturati, evitare di analizzare un numero elevato di tali documenti. L'analisi elabora i primi 20 MB di tali documenti e potrebbe comportare una durata dell'analisi più lunga.

   • Set di regole di analisi

     • Quando si seleziona il set di regole di analisi, assicurarsi di configurare il sistema pertinente o il set di regole di analisi personalizzato creato in precedenza.
     • È possibile creare tipi di file personalizzati e compilare i dettagli di conseguenza. Attualmente, Microsoft Purview supporta un solo carattere nel delimitatore personalizzato. Se si usano delimitatori personalizzati, ad esempio ~, nei dati effettivi, è necessario creare un nuovo set di regole di analisi.

     

   • Tipo di analisi e pianificazione

     • Il processo di analisi può essere configurato per eseguire analisi complete o incrementali.
     • Eseguire le analisi durante le ore non aziendali o di punta per evitare sovraccarichi di elaborazione nell'origine.
     • La ricorrenza di inizio deve essere inferiore di almeno 1 minuto al tempo di analisi della pianificazione. In caso contrario, l'analisi verrà attivata nella ricorrenza successiva.
     • L'analisi iniziale è un'analisi completa e ogni analisi successiva è incrementale. Le analisi successive possono essere pianificate come analisi incrementali periodiche.
     • La frequenza delle analisi deve essere allineata alla pianificazione di gestione delle modifiche dell'origine dati o dei requisiti aziendali. Ad esempio:
       • Se la struttura di origine potrebbe cambiare potenzialmente ogni settimana, la frequenza di analisi deve essere sincronizzata. Le modifiche includono nuovi asset o campi all'interno di un asset che vengono aggiunti, modificati o eliminati.
       • Se si prevede che le etichette di classificazione o riservatezza siano aggiornate su base settimanale, ad esempio per motivi normativi, la frequenza di analisi deve essere settimanale. Ad esempio, se i file di partizioni vengono aggiunti ogni settimana in un data lake di origine, è possibile pianificare analisi mensili. Non è necessario pianificare le analisi settimanali perché non sono presenti modifiche nei metadati. Questo suggerimento presuppone che non siano presenti nuovi scenari di classificazione.
       • Quando si pianifica l'esecuzione di un'analisi nello stesso giorno in cui è stata creata, l'ora di inizio deve essere prima dell'ora di analisi di almeno un minuto.
       • La durata massima che l'analisi può eseguire è di sette giorni, probabilmente a causa di problemi di memoria. Questo periodo di tempo esclude il processo di inserimento. Se lo stato di avanzamento non è stato aggiornato dopo sette giorni, l'analisi viene contrassegnata come non riuscita. Il processo di inserimento (nel catalogo) attualmente non ha alcuna limitazione di questo tipo.

   • Annullamento delle analisi

     • Attualmente, le analisi possono essere annullate o sospese solo se lo stato dell'analisi è stato convertito in uno stato "In corso" da "In coda" dopo l'attivazione dell'analisi.
     • L'annullamento di un'analisi figlio singola non è supportato.

Punti da notare

• Se un campo o una colonna, una tabella o un file viene rimosso dal sistema di origine dopo l'esecuzione dell'analisi, verrà riflessa (rimossa) in Microsoft Purview solo dopo la successiva analisi completa o incrementale pianificata.
• Un asset può essere eliminato da un catalogo di Microsoft Purview usando l'icona Elimina sotto il nome dell'asset. Questa azione non rimuoverà l'oggetto nell'origine. Se si esegue un'analisi completa nella stessa origine, verrà reingerita nel catalogo. Se invece è stata pianificata un'analisi settimanale o mensile (incrementale), l'asset eliminato non verrà selezionato a meno che l'oggetto non venga modificato nell'origine. Un esempio è se una colonna viene aggiunta o rimossa dalla tabella.
• Per comprendere il comportamento delle analisi successive dopo aver modificato manualmente un asset di dati o uno schema sottostante tramite il portale di governance di Microsoft Purview, vedere Dettagli dell'asset del catalogo.
• Per altre informazioni, vedere l'esercitazione su come visualizzare, modificare ed eliminare gli asset.

Passaggi successivi

Gestire le origini dati