Metodologia di successo dell'implementazione di Synapse: Valutare la progettazione dell'area di lavoro

Nota

Questo articolo fa parte della serie di articoli Successo dell'implementazione di Azure Synapse da progettazione. Per una panoramica della serie, vedere Successo dell'implementazione di Azure Synapse da progettazione.

L'area di lavoro di Synapse è un'esperienza utente grafica unificata che riunisce i motori di elaborazione dati e analitici, data lake, database, tabelle, set di dati e artefatti di creazione di report insieme all'orchestrazione del codice e del processo. Considerando il numero di tecnologie e servizi integrati nell'area di lavoro di Synapse, assicurarsi che i componenti chiave siano inclusi nella progettazione.

Revisione della progettazione dell'area di lavoro di Synapse

Identificare se la progettazione della soluzione prevede un'area di lavoro Synapse o più aree di lavoro. Determinare i driver di questa progettazione. Anche se potrebbero esserci motivi diversi, nella maggior parte dei casi il motivo per più aree di lavoro è la separazione della sicurezza o la separazione della fatturazione. Quando si determina il numero di aree di lavoro e limiti del database, tenere presente che è previsto un limite di 20 aree di lavoro per sottoscrizione.

Identificare gli elementi o i servizi all'interno di ogni area di lavoro da condividere e con quali risorse. Le risorse possono includere data lake, runtime di integrazione (IR), metadati o configurazioni e codice. Determinare il motivo per cui questo particolare design è stato scelto in termini di potenziali sinergie. Chiediti se queste sinergie giustificano il costo aggiuntivo e il sovraccarico di gestione.

Revisione della progettazione di Data Lake

È consigliabile che il data lake (se parte della soluzione) sia a livelli corretto. È necessario dividere il data lake in tre aree principali correlate a set di dati Bronze, Silvere Gold. Bronze, o il livello non elaborato, potrebbe risiedere nel proprio account di archiviazione separato perché dispone di controlli di accesso più rigorosi a causa di dati sensibili non mascherati che potrebbe archiviare.

Revisione della progettazione della sicurezza

Esaminare la progettazione della sicurezza per l'area di lavoro e confrontarla con le informazioni raccolte durante la valutazione. Assicurarsi che tutti i requisiti siano soddisfatti e che tutti i vincoli siano stati presi in considerazione. Per semplificare la gestione, è consigliabile organizzare gli utenti in gruppi con la profilatura delle autorizzazioni appropriate: è possibile semplificare il controllo di accesso usando gruppi di sicurezza allineati ai ruoli. In questo modo, gli amministratori di rete possono aggiungere o rimuovere utenti dai gruppi di sicurezza appropriati per gestire l'accesso.

I pool SQL serverless e le tabelle Apache Spark archiviano i dati in un contenitore Azure Data Lake Gen2 (ADLS Gen2) associato all'area di lavoro. Anche le librerie di Apache Spark installate dall'utente vengono gestite nello stesso account di archiviazione. Per abilitare questi casi d'uso, sia gli utenti che l'identità del servizio gestito dell'area di lavoro devono essere aggiunti al ruolo Collaboratore ai dati dei BLOB di archiviazione del contenitore di archiviazione ADLS Gen2. Verificare questo requisito in base ai requisiti di sicurezza.

I pool SQL dedicati offrono un set completo di funzionalità di sicurezza per crittografare e mascherare i dati sensibili. I pool SQL dedicati e serverless consentono l'intera superficie di attacco delle autorizzazioni di SQL Server, inclusi i ruoli predefiniti, i ruoli definiti dall'utente, l'autenticazione SQL e l'autenticazione Di Microsoft Entra. Esaminare la progettazione della sicurezza per il pool SQL dedicato della soluzione e l'accesso e i dati del pool SQL serverless.

Esaminare il piano di sicurezza per il data lake e tutti gli account di archiviazione di ADLS Gen2 (e altri) che faranno parte della soluzione Azure Synapse Analytics. L'archiviazione di ADLS Gen2 non è un motore di calcolo e quindi non ha la possibilità predefinita di mascherare in modo selettivo gli attributi dei dati. È possibile applicare le autorizzazioni di ADLS Gen2 a livello di account di archiviazione o contenitore usando il controllo degli accessi in base al ruolo e/o a livello di cartella o file usando elenchi di controllo di accesso (ACL). Esaminare attentamente la progettazione e cercare di evitare complessità non necessarie.

Ecco alcuni punti da considerare per la progettazione della sicurezza.

• Assicurarsi che i requisiti di configurazione di Microsoft Entra ID siano inclusi nella progettazione.
• Verificare la presenza di scenari tra tenant. Questi problemi possono verificarsi perché alcuni dati si trovano in un altro tenant di Azure o devono essere spostati in un altro tenant oppure devono essere accessibili dagli utenti di un altro tenant. Assicurarsi che questi scenari siano considerati nella progettazione.
• Quali sono i ruoli per ogni area di lavoro? Come useranno l'area di lavoro?
• Come viene progettata la sicurezza all'interno dell'area di lavoro?
  • Chi può visualizzare tutti gli script, i notebook e le pipeline?
  • Chi può eseguire script e pipeline?
  • Chi può creare/sospendere/riprendere pool SQL e Spark?
  • Chi può pubblicare le modifiche nell'area di lavoro?
  • Chi può eseguire il commit delle modifiche nel controllo del codice sorgente?
• Le pipeline accederanno ai dati usando le credenziali archiviate o l'identità gestita dell'area di lavoro?
• Gli utenti hanno l'accesso appropriato al data lake per esplorare i dati in Synapse Studio?
• Il data lake è protetto correttamente usando la combinazione appropriata di controllo degli accessi in base al ruolo e ACL?
• Le autorizzazioni utente del pool SQL sono state impostate correttamente per ogni ruolo (data scientist, sviluppatore, amministratore, utente aziendale e altri)?

Revisione della progettazione della rete

Ecco alcuni punti da considerare per la progettazione di rete.

• La connettività è progettata tra tutte le risorse?
• Qual è il meccanismo di rete da usare (Azure ExpressRoute, Internet pubblico o endpoint privati)?
• È necessario essere in grado di connettersi in modo sicuro a Synapse Studio?
• L'esfiltrazione dei dati è stata presa in considerazione?
• È necessario connettersi alle origini dati locali?
• È necessario connettersi ad altre origini dati cloud o motori di calcolo, ad esempio Azure Machine Learning?
• Sono stati esaminati componenti di rete di Azure, ad esempio i gruppi di sicurezza di rete (NSG), per verificare la connettività e lo spostamento dei dati appropriati?
• L'integrazione con le zone DNS private è stata presa in considerazione?
• È necessario essere in grado di esplorare il data lake dall'interno di Synapse Studio o semplicemente eseguire query sui dati nel data lake con SQL serverless o PolyBase?

Infine, identificare tutti i consumer di dati e verificare che la connettività sia in considerazione nella progettazione. Verificare che gli outpost di rete e sicurezza consentano al servizio di accedere alle origini locali necessarie e che siano supportati i protocolli e i meccanismi di autenticazione. In alcuni scenari potrebbe essere necessario avere più di un runtime di integrazione self-hosted o un gateway dati per soluzioni SaaS, ad esempio Microsoft Power BI.

Revisione della progettazione del monitoraggio

Esaminare la progettazione del monitoraggio dei componenti di Azure Synapse per assicurarsi che soddisfino i requisiti e le aspettative identificati durante la valutazione. Verificare che il monitoraggio delle risorse e dell'accesso ai dati sia stato progettato e che identifichi ogni requisito di monitoraggio. Una soluzione di monitoraggio affidabile deve essere inserita come parte della prima distribuzione nell'ambiente di produzione. In questo modo, gli errori possono essere identificati, diagnosticati e risolti in modo tempestivo. Oltre all'infrastruttura di base e alle esecuzioni della pipeline, è consigliabile monitorare anche i dati. A seconda dei componenti di Azure Synapse in uso, identificare i requisiti di monitoraggio per ogni componente. Ad esempio, se i pool di Spark fanno parte della soluzione, monitorare l'archivio record in formato non valido. 

Ecco alcuni punti da considerare per la progettazione del monitoraggio.

• Chi può monitorare ogni tipo di risorsa (pipeline, pool e altri)?
• Quanto tempo devono essere conservati i log attività del database?
• La conservazione dei log dell'area di lavoro e del database userà Log Analytics o Archiviazione di Azure?
• Gli avvisi verranno attivati in caso di errore della pipeline? In tal caso, chi dovrebbe ricevere una notifica?
• Quale livello di soglia di un pool SQL deve attivare un avviso? Chi deve ricevere una notifica?

Revisione della progettazione del controllo del codice sorgente

Per impostazione predefinita, un'area di lavoro di Synapse applica le modifiche direttamente al servizio Synapse usando la funzionalità di pubblicazione predefinita. È possibile abilitare l'integrazione del controllo del codice sorgente, che offre molti vantaggi. I vantaggi includono una migliore collaborazione, controllo delle versioni, approvazioni e pipeline di versione per promuovere le modifiche in ambienti di sviluppo, test e produzione. Azure Synapse consente un singolo repository di controllo del codice sorgente per ogni area di lavoro, che può essere Azure DevOps Git o GitHub.

Ecco alcuni punti da considerare per la progettazione del controllo del codice sorgente.

• Se si usa Azure DevOps Git, l'area di lavoro di Synapse e il relativo repository sono nello stesso tenant?
• Chi sarà in grado di accedere al controllo del codice sorgente?
• Quali autorizzazioni verranno concesse a ogni utente nel controllo del codice sorgente?
• È stata sviluppata una strategia di diramazione e unione?
• Le pipeline di versione verranno sviluppate per la distribuzione in ambienti diversi?
• Verrà usato un processo di approvazione per l'unione e per le pipeline di versione?

Nota

La progettazione dell'ambiente di sviluppo è di importanza fondamentale per il successo del progetto. Se è stato progettato un ambiente di sviluppo, verrà valutato in una fase separata di questa metodologia.

Passaggi successivi

Nell'articolo successivo della serie Successo di Azure Synapse in base alla progettazione, vedere come valutare la progettazione dell'integrazione dei dati e verificare che soddisfi le linee guida e i requisiti.