Playbook PoC di Synapse: esplorazione di Data Lake con pool SQL serverless in Azure Synapse Analytics

Articolo
04/26/2024

Questo articolo presenta una metodologia generale per la preparazione e l'esecuzione di un progetto di modello di verifica di Azure Synapse Analytics efficace per il pool SQL serverless.

Nota

Questo articolo fa parte della serie di articoli Playbook del modello di verifica Azure Synapse. Per una panoramica della serie, vedere Playbook del modello di verifica Azure Synapse.

Prepararsi per il modello di verifica

Un progetto di modello di verifica consente di prendere una decisione aziendale informata sull'implementazione di un ambiente di analisi avanzata e Big Data in una piattaforma basata sul cloud che sfrutta un pool SQL serverless in Azure Synapse. Se è necessario esplorare o acquisire informazioni dettagliate sui dati nel data lake, o ottimizzare l'attuale pipeline di trasformazione dei dati, è possibile trarre vantaggio dall'uso del pool SQL serverless. Il servizio è indicato per gli scenari seguenti:

Individuazione ed esplorazione di base: è possibile ragionare rapidamente sui dati archiviati in vari formati (Parquet, CSV, JSON) nel data lake, in modo da pianificare come sbloccare informazioni dettagliate.
Data warehouse logico: è possibile produrre un'astrazione relazionale su dati non elaborati o disparati senza spostarli o trasformarli, fornendo una visualizzazione sempre aggiornata.
Trasformazione dei dati: eseguire query data lake semplici, scalabili e ad alte prestazioni usando T-SQL. È possibile inviare i risultati delle query agli strumenti di Business Intelligence (BI) o caricarli in un database relazionale. I sistemi di destinazione possono includere pool SQL dedicati di Azure Synapse o database SQL di Azure.

Diversi ruoli professionali possono trarre vantaggio dal pool SQL serverless:

I data engineer possono esplorare il data lake, trasformare e preparare i dati usando il pool SQL serverless e semplificare le pipeline di trasformazione dei dati.
I data scientist possono ragionare rapidamente sul contenuto e sulla struttura dei dati archiviati nel data lake usando la funzione T-SQL OPENROWSET e l'inferenza automatica dello schema.
Gli analisti dei dati possono scrivere query T-SQL negli strumenti di query preferiti, che possono connettersi al pool SQL serverless. Possono esplorare i dati nelle tabelle esterne Spark create da data scientist o data engineer.
I professionisti di Business Intelligence possono creare rapidamente report di Power BI che si connettono a tabelle di Data Lake o Spark.

Un progetto PoC del pool SQL serverless identificherà gli obiettivi chiave e i driver aziendali che il pool SQL serverless è progettato per supportare. Testerà anche le funzionalità principali e raccoglierà le metriche per supportare le decisioni di implementazione. Un modello di verifica non è progettato per essere distribuito in un ambiente di produzione. Si tratta piuttosto di un progetto a breve termine incentrato sulle domande chiave e il suo risultato può essere ignorato.

Prima di iniziare a pianificare il progetto PoC del pool SQL serverless:

Identificare eventuali restrizioni o linee guida dell'organizzazione in merito allo spostamento dei dati nel cloud.
Identificare gli sponsor esecutivi o di business per un progetto di piattaforma di analisi avanzata e Big Data. Garantire il loro supporto per la migrazione al cloud.
Identificare la disponibilità di esperti tecnici e utenti aziendali per supportare l'utente durante l'esecuzione del modello di verifica.

Prima di iniziare a preparare il progetto del modello di verifica, è consigliabile leggere la documentazione del pool SQL serverless.

Suggerimento

Se non si ha familiarità con i pool SQL serverless, è consigliabile usare il percorso di apprendimento Compilare soluzioni di analisi dei dati usando pool SQL serverless di Azure Synapse.

Impostare gli obiettivi

Un progetto di modello di verifica successo richiede una pianificazione. Per iniziare, identificare il motivo per cui si sta creando un modello di verifica per comprendere appieno le motivazioni reali. Le motivazioni possono includere modernizzazione, risparmio dei costi, miglioramento delle prestazioni o esperienza integrata. Assicurarsi di documentare obiettivi chiari per il modello di verifica e i criteri che ne definiranno il successo. Chiediti:

Cosa si desidera come output del modello di verifica?
Cosa si farà con questi output?
Chi userà gli output?
Cosa definirà un modello di verifica di successo?

Tenere presente che un modello di verifica deve essere un'iniziativa breve e mirata per dimostrare rapidamente un set limitato di concetti e funzionalità. Questi concetti e funzionalità devono essere rappresentativi del carico di lavoro complessivo. Se si dispone di un lungo elenco di elementi da dimostrare, è consigliabile pianificare più di un modello di verifica. In tal caso, definire i controlli tra i modelli di verifica per determinare se sia necessario continuare con quello successivo. Considerati i diversi ruoli professionali che possono usare un pool SQL serverless (e i diversi scenari supportati dal pool SQL serverless), è possibile scegliere di eseguire più modelli di verifica. Ad esempio, un modello di verifica può concentrarsi sui requisiti per il ruolo del data scientist, come l'individuazione e l'esplorazione dei dati in formati diversi. Un altro potrebbe concentrarsi sui requisiti per il ruolo di progettazione dei dati, ad esempio la trasformazione dei dati e la creazione di un data warehouse logico.

Quando si considerano gli obiettivi del modello di verifica, porre le domande seguenti per definirli:

Si sta eseguendo la migrazione da una piattaforma di analisi avanzata e Big Data esistente (locale o cloud)?
Si sta eseguendo la migrazione ma si vuole apportare il minor numero possibile di modifiche all'inserimento e all'elaborazione dei dati esistenti?
Si sta eseguendo la migrazione ma si vogliono apportare alcuni miglioramenti approfonditi nel corso del processo?
Si sta creando una piattaforma di analisi avanzata e Big Data completamente nuova (progetto greenfield)?
Quali sono le problematiche correnti? Ad esempio scalabilità, prestazioni o flessibilità.
Quali nuovi requisiti aziendali è necessario supportare?
Quali sono i contratti di servizio che è necessario soddisfare?
Quali saranno i carichi di lavoro? Ad esempio, l'esplorazione dei dati su formati di dati diversi, l'esplorazione di base, un data warehouse logico, la preparazione e/o la trasformazione, l'analisi interattiva T-SQL, l'esecuzione di query T-SQL di tabelle Spark o la creazione di report su data lake.
Quali sono le competenze degli utenti che possiedono il progetto (per capire se debba essere implementato il modello di verifica)?

Ecco alcuni esempi di impostazioni di obiettivi del modello di verifica:

Perché stiamo effettuando un modello di verifica?
- È necessario sapere se è possibile esplorare tutti i formati di file non elaborati archiviati usando il pool SQL serverless.
- È necessario sapere se i data engineer possono valutare rapidamente nuovi feed di dati.
- È necessario sapere se le prestazioni delle query di Data Lake tramite il pool SQL serverless soddisfano i requisiti di esplorazione dei dati.
- È necessario sapere se il pool SQL serverless è una scelta ottimale per alcune visualizzazioni e requisiti di creazione di report.
- È necessario sapere se il pool SQL serverless è una scelta ottimale per alcuni dei requisiti di inserimento ed elaborazione dei dati.
- È necessario sapere se il passaggio ad Azure Synapse soddisfa il budget.
Alla conclusione di questo modello di verifica:
- I dati saranno disponibili per identificare le trasformazioni dei dati adatte al pool SQL serverless.
- I dati verranno identificati quando il pool SQL serverless potrà essere usato al meglio durante la visualizzazione dei dati.
- I dati saranno disponibili per conoscere la facilità con cui i data engineer e i data scientist possono adottare la nuova piattaforma.
- Verranno acquisite informazioni dettagliate per stimare meglio lo sforzo necessario per completare il progetto di implementazione o migrazione.
- Sarà disponibile un elenco di elementi che potrebbero richiedere più test.
- Il modello di verifica avrà esito positivo se si avranno i dati necessari e se saranno stati completati i test che determinano in che modo il pool SQL serverless supporterà la piattaforma big data basata sul cloud e la piattaforma di analisi avanzata.
- Determineremo se è possibile passare alla fase successiva o se è necessario eseguire più test PoC per finalizzare la decisione.
- Saremo in grado di prendere una decisione aziendale solida supportata da punti dati specifici.

Pianificare il progetto

Usare gli obiettivi per identificare test specifici e fornire gli output identificati. È importante assicurarsi di avere almeno un test per supportare ogni obiettivo e output previsto. Identificare anche attività specifiche di esplorazione e analisi dei dati, trasformazioni specifiche e specifiche elaborazioni esistenti da testare. Identificare un set di dati e una codebase specifici che è possibile usare.

Di seguito è riportato un esempio del livello di specificità necessario nella pianificazione:

Obiettivo: è necessario sapere se i data engineer possono ottenere l'elaborazione equivalente del processo ETL esistente denominato "Convalida file non elaborati del batch giornaliero" all'interno del contratto di servizio richiesto.
Output: i dati saranno disponibili per determinare se è possibile usare query T-SQL per eseguire il processo ETL "Convalida file non elaborati del batch giornaliero" all'interno del contratto di servizio richiesto.
Test: le query di convalida A, B e C sono identificate dall'ingegneria dei dati e rappresentano le esigenze complessive di elaborazione dei dati. Confrontare le prestazioni di queste query con il benchmark ottenuto dal sistema esistente.

Valutare il set di dati del modello di verifica

Usando i test specifici identificati, selezionare un set di dati per supportare i test. Prendersi del tempo per esaminare questo set di dati. È necessario verificare che il set di dati rappresenti adeguatamente l'elaborazione futura in termini di contenuto, complessità e scalabilità. Non usare un set di dati troppo piccolo perché non offrirebbe prestazioni rappresentative. Al contrario, non usare un set di dati troppo grande perché il modello di verifica non deve diventare una migrazione completa dei dati. Assicurarsi di ottenere i benchmark appropriati dai sistemi esistenti in modo da poterli usare per i confronti delle prestazioni.

Importante

Assicurarsi di controllare con i proprietari dell'azienda eventuali blocchi prima di spostare i dati nel cloud. Identificare eventuali problemi di sicurezza o privacy o eventuali esigenze di offuscamento dei dati da eseguire prima di spostare i dati nel cloud.

Creare un'architettura generale

In base all'architettura generale dello stato proposta, identificare i componenti che faranno parte del modello di verifica. L'architettura di stato futura generale probabilmente contiene molte origini dati, numerosi consumer di dati, componenti Big Data e possibilmente consumer di dati di Machine Learning e intelligenza artificiale. L'architettura del modello di verifica deve identificare in modo specifico i componenti che faranno parte del modello di verifica. Cosa importante, deve identificare tutti i componenti che non fanno parte del test del modello di verifica.

Se si usa già Azure, identificare le risorse già disponibili (Microsoft Entra ID, ExpressRoute e altri) che è possibile usare durante il modello di verifica. Identificare anche le aree di Azure usate dall'organizzazione. Questo è un ottimo momento per identificare la velocità effettiva della connessione ExpressRoute e verificare con altri utenti aziendali che il modello di verifica possa usare una certa velocità effettiva senza influire negativamente sui sistemi di produzione.

Identificare le risorse del modello di verifica

In particolare, identificare le risorse tecniche e gli impegni di tempo necessari per supportare il modello di verifica. Il modello di verifica avrà bisogno di:

Un rappresentante aziendale per supervisionare i requisiti e i risultati.
Un esperto di dati dell'applicazione, per estrarre i dati per il modello di verifica e fornire conoscenza di processi e logica esistenti.
Esperto del pool SQL serverless.
Un consulente esperto per ottimizzare i test del modello di verifica.
Risorse che saranno necessarie per componenti specifici del progetto del modello di verifica, ma non necessariamente durante il modello stesso. Queste risorse possono includere amministratori di rete, amministratori di Azure, amministratori di Active Directory, amministratori del portale di Azure e altri.
Assicurarsi che venga effettuato il provisioning di tutte le risorse dei servizi di Azure necessarie e che venga concesso il livello di accesso richiesto, incluso l'accesso agli account di archiviazione.
Assicurarsi di disporre di un account con autorizzazioni di accesso ai dati necessarie per recuperare i dati da tutte le origini dati nell'ambito del modello di verifica.

Suggerimento

Consigliamo di coinvolgere un consulente esperto per assistere con il modello di verifica. La Community partner Microsoft ha una disponibilità globale di consulenti esperti che possono aiutare a valutare o implementare Azure Synapse.

Configurare la sequenza temporale

Esaminare i dettagli di pianificazione del modello di verifica e le esigenze aziendali per identificare un intervallo di tempo per il modello. Effettuare stime realistiche del tempo necessario per completare gli obiettivi del modello di verifica. Il tempo necessario per completare il modello di verifica dipenderà dalle dimensioni del suo set di dati, dal numero e dalla complessità dei test e dal numero di interfacce da testare. Se si stima che il modello di verifica verrà eseguito per più di quattro settimane, è consigliabile ridurre l'ambito del modello di verifica per concentrarsi sugli obiettivi con priorità più alta. Assicurarsi di ottenere l'approvazione e l'impegno da tutte le risorse lead e gli sponsor prima di continuare.

Mettere in pratica il modello di verifica

È consigliabile eseguire il progetto del modello di verifica con la disciplina e il rigore di qualsiasi progetto di produzione. Eseguire il progetto in base al piano e gestire un processo di richiesta di modifica per impedire la crescita non controllata dell'ambito del modello di verifica.

Ecco alcuni esempi di attività generali:

Creare un'area di lavoro Synapse, gli account di archiviazione e le risorse di Azure identificate nel piano PoC.
Configurare rete e sicurezza in base alle esigenze.
Concedere l'accesso appropriato ai membri del team del modello di verifica. Vedere questo articolo sulle autorizzazioni per l'accesso ai file direttamente da Archiviazione di Azure.
Caricare il set di dati PoC.
Implementare e configurare i test e/o eseguire la migrazione del codice esistente a viste e script del pool SQL serverless.
Eseguire i test:
- Molti test possono essere eseguiti in parallelo.
- Registrare i risultati in un formato di consumo e facilmente comprensibile.
Monitorare per la risoluzione dei problemi e le prestazioni.
Valutare i risultati e presentare i risultati.
Collaborare con gli stakeholder tecnici e l'azienda per pianificare la fase successiva del progetto. La fase successiva potrebbe essere un modello di verifica di completamento o un'implementazione di produzione.

Interpretare i risultati del modello di verifica

Quando si completano tutti i test del modello di verifica, si valutano i risultati. Per iniziare, valutare se gli obiettivi del modello di verifica sono stati raggiunti e se gli output desiderati sono stati raccolti. Determinare se siano necessari altri test o se ci siano domande da affrontare.