Playbook del modello di verifica di Synapse: data warehousing con pool SQL dedicato in Azure Synapse Analytics
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 dedicato.
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.
Suggerimento
Se non si ha familiarità con i pool SQL dedicati, è consigliabile usare il percorso di apprendimento Usare i data warehouse con Azure Synapse Analytics.
Prepararsi per il modello di verifica
Prima di decidere gli obiettivi del modello di verifica di Azure Synapse, è consigliabile leggere l'articolo Architettura di Azure Synapse SQL per acquisire familiarità con il modo in cui un pool SQL dedicato separa le risorse di calcolo e archiviazione per offrire prestazioni leader del settore.
Identificare sponsor e potenziali bloccanti
Dopo aver acquisito familiarità con Azure Synapse, è il momento di assicurarsi che il modello di verifica disponga del supporto necessario e che non vengano riscontrati problemi. È necessario effettuare le operazioni seguenti:
- Identificare eventuali restrizioni o criteri dell'organizzazione per spostare i dati e archiviare i dati nel cloud.
- Identificare la sponsorizzazione di dirigenti e business per un progetto di data warehouse basato sul cloud.
- Verificare che il carico di lavoro sia appropriato per Azure Synapse. Per altre informazioni, vedere Architettura del pool SQL dedicato in Azure Synapse Analytics.
Configurare la sequenza temporale
Un modello di verifica è un esercizio con ambito limitato a tempo con obiettivi e metriche specifici e misurabili che ne definiscono il successo. Idealmente, dovrebbe avere fondamenta nella realtà aziendale in modo che i risultati siano significativi.
I modelli di verifica hanno il risultato migliore quando sono effettuati in timebox. Il timeboxing alloca un'unità di tempo fissa e massima a un'attività. In questa esperienza, due settimane sono un tempo sufficiente per completare il lavoro senza il carico di troppi casi d'uso o matrici di test complesse. Lavorando entro questo periodo di tempo fisso, è consigliabile seguire questa sequenza temporale:
- Caricamento dati: tre giorni o meno
- Esecuzione di query: cinque giorni o meno
- Test a valore aggiunto: due giorni o meno
Di seguito sono riportati alcuni suggerimenti:
- Eseguire stime realistiche del tempo necessario per completare le attività nel piano.
- Riconoscere che il tempo necessario per completare il modello di verifica sarà correlato alle dimensioni del set di dati, al numero di oggetti di database (tabelle, viste e stored procedure), alla complessità degli oggetti di database e al numero di interfacce che verranno testate.
- Se si stima che il modello di verifica verrà eseguito per più di quattro settimane, è consigliabile ridurre l'ambito per concentrarsi solo sugli obiettivi più importanti.
- Ottenere supporto da tutte le risorse lead e gli sponsor per la sequenza temporale prima di avviare il modello di verifica.
Dopo aver stabilito che non ci sono ostacoli immediati e aver impostato la sequenza temporale, è possibile definire l'ambito di un'architettura generale.
Creare un'architettura generale con ambito
Un'architettura futura generale contiene probabilmente molte origini dati e consumer di dati, componenti Big Data e possibilmente consumer di dati di Machine Learning e intelligenza artificiale. Per poter raggiungere gli obiettivi del modello di verifica (ed entro i limiti della sequenza temporale impostata), decidere quale di questi componenti farà parte del modello di verifica e quali saranno esclusi.
Inoltre, se si usa già Azure, identificare quanto segue:
- Tutte le risorse di Azure esistenti che è possibile usare durante il modello di verifica. Ad esempio, le risorse possono includere l'ID Microsoft Entra o Azure ExpressRoute.
- Quali aree o aree di Azure preferisce l'organizzazione.
- Una sottoscrizione che è possibile usare per il lavoro del modello di verifica non di produzione.
- Velocità effettiva della connessione di rete ad Azure.
Importante
Assicurarsi di controllare che il modello di verifica possa usare una certa velocità effettiva senza influire negativamente sulle soluzioni di produzione.
Applicare le opzioni di migrazione
Se si esegue la migrazione da un sistema di data warehouse legacy ad Azure Synapse, ecco alcune domande da considerare:
- Si sta eseguendo la migrazione e si vuole apportare il minor numero possibile di modifiche ai processi ETL (Extract, Transform e Load) esistenti e al consumo del data warehouse?
- Si sta eseguendo la migrazione ma si vogliono apportare alcuni miglioramenti approfonditi nel corso del processo?
- Si sta creando un ambiente di analisi dei dati completamente nuovo (talvolta denominato progetto greenfield)?
Successivamente, è necessario considerare le problematiche.
Identificare le problematiche correnti
Il modello di verifica deve contenere casi d'uso per dimostrare potenziali soluzioni per risolvere le problematiche correnti. Di seguito vengono riportati alcune domande da considerare:
- Quali lacune nell'implementazione corrente si prevede verranno colmate da Azure Synapse?
- Quali nuove esigenze aziendali devono essere supportate?
- Quali contratti di servizio devono essere soddisfatti?
- Quali saranno i carichi di lavoro (ad esempio, ETL, query batch, analisi, query di report o query interattive)?
Successivamente, è necessario impostare i criteri di successo del modello di verifica.
Impostare i criteri di successo del modello di verifica
Identificare il motivo per cui si sta eseguendo un modello di verifica e assicurarsi di definire obiettivi chiari. È anche importante sapere quali output si vogliono ottenere dal modello di verifica e cosa si intende fare con questi.
Tenere presente che un modello di verifica deve essere un'iniziativa breve e mirata per dimostrare o testare rapidamente un set limitato di concetti. Se si dispone di un lungo elenco di elementi da dimostrare, è consigliabile pianificare più di un modello di verifica. I modelli di verifica possono avere controlli tra di essi in modo da determinare se procedere al successivo modello.
Ecco alcuni esempi di obiettivi del modello di verifica:
- È necessario sapere che le prestazioni delle query di report complesse di grandi dimensioni soddisfano i nuovi contratti di servizio.
- È necessario conoscere le prestazioni delle query per gli utenti interattivi.
- È necessario sapere se i processi ETL esistenti sono adatti e dove devono essere apportati miglioramenti.
- È necessario sapere se sia possibile abbreviare i runtime ETL e di quanto.
- È necessario sapere che Synapse Analytics dispone di funzionalità di sicurezza sufficienti per proteggere adeguatamente i dati.
A questo punto è necessario creare un piano di test.
Creare un piano di test
Usando gli obiettivi, identificare test specifici da eseguire per supportare tali obiettivi e fornire gli output identificati. È importante assicurarsi di avere almeno un test per ogni obiettivo e l'output previsto. Identificare query, report, ETL e altri processi specifici che verranno eseguiti per fornire risultati quantificabili.
Perfezionare i test aggiungendo più scenari per chiarire eventuali domande sulla struttura delle tabelle.
Una buona pianificazione definisce in genere un'esecuzione efficace del modello di verifica. Assicurarsi che tutti gli stakeholder accettino un piano di test scritto che leghi ogni obiettivo del modello di verifica a un set di test case e misurazioni di successo chiaramente dichiarate.
La maggior parte dei piani di test ruota intorno alle prestazioni e all'esperienza utente prevista. Di seguito è riportato un esempio di un piano di test. È importante personalizzare il piano di test per soddisfare i requisiti aziendali. Definire chiaramente ciò che si sta testando per ottenere risultati migliori più avanti nel processo.
| Goal | Test | Risultati previsti |
|---|---|---|
| È necessario sapere che le prestazioni delle query di report complesse di grandi dimensioni soddisfano i nuovi contratti di servizio | - Test sequenziale di query complesse - Test di concorrenza di query complesse rispetto ai contratti di servizio dichiarati |
- Query A, B e C completate rispettivamente in 10, 13 e 21 secondi - Con 10 utenti simultanei, query A, B e C completate in media in 11, 15 e 23 secondi |
| È necessario conoscere le prestazioni delle query per gli utenti interattivi | - Test di concorrenza delle query selezionate a un livello di concorrenza previsto di 50 utenti. - Eseguire la query precedente con la memorizzazione nella cache del set di risultati |
- A 50 utenti simultanei, il tempo medio di esecuzione dovrebbe essere inferiore a 10 secondi e senza memorizzazione nella cache dei set di risultati - A 50 utenti simultanei, il tempo medio di esecuzione dovrebbe essere inferiore a cinque secondi con la memorizzazione nella cache dei set di risultati |
| È necessario sapere se i processi ETL esistenti possono essere eseguiti all'interno del contratto di servizio | - Eseguire uno o due processi ETL per simulare i carichi di produzione | - Il caricamento incrementale in una tabella dei fatti principale deve essere completato in meno di 20 minuti (incluse la gestione temporanea e la pulizia dei dati) - L'elaborazione delle dimensioni deve richiedere meno di cinque minuti |
| È necessario sapere che il data warehouse ha funzionalità di sicurezza sufficienti per proteggere i dati | - Esaminare e abilitare la sicurezza di rete (reti virtuali ed endpoint privati) e il controllo degli accessi (sicurezza a livello di riga, maschera dati dinamica) | - Dimostrare che i dati non lasciano mai il tenant. - Assicurarsi che il contenuto del cliente sia facilmente protetto |
Successivamente, è necessario identificare e convalidare il set di dati del modello di verifica.
Identificare e convalidare il set di dati del modello di verifica
Usando i test con ambito, è ora possibile identificare il set di dati necessario per eseguire tali test in Azure Synapse. Esaminare il set di dati considerando quanto segue:
- Verificare che il set di dati rappresenti adeguatamente il set di dati di produzione in termini di contenuto, complessità e scalabilità.
- Non usare un set di dati troppo piccolo (inferiore a 1 TB) perché potrebbe non offrire prestazioni rappresentative.
- Non usare un set di dati troppo grande, perché il modello di verifica non è progettato per completare una migrazione completa dei dati.
- Identificare il modello di distribuzione, l'opzione di indicizzazione e il partizionamento per ogni tabella. In caso di domande sulla distribuzione, l'indicizzazione o il partizionamento, aggiungere test al modello di verifica per rispondere. Tenere presente che è possibile testare più opzioni di distribuzione o indicizzazione per alcune tabelle.
- Rivolgersi ai proprietari dell'azienda per eventuali blocchi allo spostamento del set di dati del modello di verifica nel cloud.
- Identificare eventuali problemi di sicurezza o privacy.
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.
Successivamente, è necessario assemblare il team di esperti.
Assemblare il team
Identificare i membri del team e il loro impegno a supportare il modello di verifica. I membri del team devono includere:
- Un Project Manager per eseguire il progetto del modello di verifica.
- Rappresentante aziendale per supervisionare i requisiti e i risultati.
- Un esperto di dati dell'applicazione per l'origine dei dati per il set di dati del modello di verifica.
- Uno specialista di Azure Synapse.
- Un consulente esperto per ottimizzare i test del modello di verifica.
- Qualsiasi persona che sarà necessaria per attività specifiche del progetto modello di verifica, ma non per la sua intera durata. Queste risorse di supporto possono includere amministratori di rete, amministratori di Azure o amministratori di Microsoft Entra.
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.
Ora che è stata completata la preparazione, è il momento di mettere in pratica il modello di verifica.
Mettere in pratica il modello di verifica
È importante tenere presente quanto segue:
- Implementare il progetto del modello di verifica con la disciplina e il rigore di qualsiasi progetto di produzione.
- Eseguire il modello di verifica in base al piano.
- Disporre di un processo di richiesta di modifica per impedire che l'ambito del modello di verifica si estenda o cambi.
Prima dell'avvio dei test, è necessario configurare l'ambiente di test. Include quattro fasi:
- Impostazione
- Caricamento dei dati
- Query
- Test con valore aggiunto
Impostazione
È possibile configurare un modello di verifica in Azure Synapse seguendo questa procedura:
- Usare questa guida introduttiva per effettuare il provisioning di un'area di lavoro Synapse e configurare l'archiviazione e le autorizzazioni in base al piano di test del modello di verifica.
- Usare questa guida introduttiva per aggiungere un pool SQL dedicato all'area di lavoro di Synapse.
- Configurare rete e sicurezza in base alle esigenze.
- Concedere l'accesso appropriato ai membri del team del modello di verifica. Vedere questo articolo sull'autenticazione e l'autorizzazione per l'accesso ai pool SQL dedicati.
Suggerimento
È consigliabile sviluppare codice e unit test usando il livello di servizio DW500c (o inferiore). È consigliabile eseguire test di carico e prestazioni usando il livello di servizio DW1000c (o superiore). È possibile sospendere il calcolo del pool SQL dedicato in qualsiasi momento per interrompere la fatturazione di calcolo, con un risparmio sui costi.
Caricamento dei dati
Dopo aver configurato il pool SQL dedicato, è possibile seguire questa procedura per caricare i dati:
- Caricare i dati nell'Archiviazione BLOB di Azure. Per un modello di verifica, è consigliabile usare un account di archiviazione V2 per utilizzo generico con archiviazione con ridondanza locale. Anche se sono disponibili diversi strumenti per la migrazione dei dati in Archiviazione BLOB di Azure, il modo più semplice consiste nell'usare Azure Storage Explorer, che può copiare i file in un contenitore di archiviazione.
- Caricare i dati nel pool SQL dedicato. Azure Synapse supporta due metodi di caricamento T-SQL: PolyBase e l'istruzione COPY. È possibile usare SSMS per connettersi al pool SQL dedicato per usare entrambi i metodi.
Quando si caricano i dati nel pool SQL dedicato per la prima volta, è necessario considerare quale modello di distribuzione e opzione di indice usare. Anche se un pool SQL dedicato supporta un'ampia gamma di entrambi, è consigliabile basarsi sulle impostazioni predefinite. Le impostazioni predefinite usano la distribuzione round robin e un indice columnstore cluster. Se necessario, è possibile modificare queste impostazioni in un secondo momento, come descritto più avanti in questo articolo.
Nell'esempio seguente viene illustrato il metodo di caricamento COPY:
--Note when specifying the column list, input field numbers start from 1
COPY INTO
test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
FILE_TYPE = 'CSV',
CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
FIELDQUOTE = '"',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '0x0A',
ENCODING = 'UTF8',
FIRSTROW = 2
);
Query
Lo scopo principale di un data warehouse è eseguire analisi, il che richiede l'esecuzione di query sul data warehouse. La maggior parte dei modelli di verifica inizia eseguendo un numero ridotto di query rappresentative sul data warehouse, inizialmente in sequenza e quindi contemporaneamente. È necessario definire entrambi gli approcci nel piano di test.
Test di query sequenziali
È facile eseguire test di query sequenziali in SSMS. È importante eseguire questi test usando un utente con una classe di risorse sufficientemente grande. Una classe di risorse è un limite di risorse predeterminato nel pool SQL dedicato che regola le risorse di calcolo e la concorrenza per l'esecuzione delle query. Per le query semplici, è consigliabile usare la classe di risorse staticrc20. Per le query più complesse, è consigliabile usare la classe di risorse staticrc40 predefinita.
Si noti che la prima query seguente usa un'etichetta di query per fornire un meccanismo per tenerne traccia. La seconda query usa la vista a gestione dinamica sys.dm_pdw_exec_requests per eseguire la ricerca in base all'etichetta.
/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
*
FROM
[dbo].[Date]
OPTION (LABEL = 'Test1');
/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
Total_elapsed_time AS [Elapsed_Time_ms],
[label]
FROM
sys.dm_pdw_exec_requests
WHERE
[label] = 'Test1';
Test di query simultanee
Dopo aver registrato le prestazioni delle query sequenziali, è quindi possibile eseguire più query contemporaneamente. In questo modo, è possibile simulare un carico di lavoro di Business Intelligence in esecuzione nel pool SQL dedicato. Il modo più semplice per eseguire questo test consiste nel scaricare uno strumento di test di stress. Lo strumento più diffuso è Apache JMeter, che è uno strumento open source di terze parti.
Lo strumento segnala le durate minime, massime e medie delle query per un determinato livello di concorrenza. Si supponga, ad esempio, di voler simulare un carico di lavoro di business intelligence che genera 100 query simultanee. È possibile configurare JMeter per eseguire queste 100 query simultanee in un ciclo e quindi esaminare l'esecuzione dello stato stabile. Può essere eseguito con la memorizzazione nella cache dei set di risultati attivata o disattivata per valutarne l'idoneità.
Assicurarsi di documentare i risultati. Ecco un esempio di alcuni risultati:
| Concorrenza | # Query eseguite | DWU | Durata minima (s) | Durata massima (s) | Durata media (s) |
|---|---|---|---|---|---|
| 100 | 1.000 | 5.000 | 3 | 10 | 5 |
| 50 | 5,000 | 5,000 | 3 | 6 | 4 |
Test su carichi di lavoro misti
Il test misto del carico di lavoro è un'estensione dei test di query simultanei. Aggiungendo un processo di caricamento dei dati nella combinazione di carichi di lavoro, il carico di lavoro ne simula meglio uno di produzione reale.
Ottimizzare i dati
A seconda del carico di lavoro di query in esecuzione in Azure Synapse, potrebbe essere necessario ottimizzare le distribuzioni e gli indici del data warehouse ed eseguire di nuovo i test. Per altre informazioni, vedere Procedure consigliate per pool SQL dedicati in Azure Synapse Analytics.
Gli errori più comuni riscontrati durante l'installazione sono:
- Le query di grandi dimensioni vengono eseguite con una classe di risorse troppo bassa.
- Le DWU del pool SQL dedicato sono troppo basse per il carico di lavoro.
- Le tabelle di grandi dimensioni richiedono la distribuzione hash.
Per migliorare le prestazioni delle query è possibile:
- Creare viste materializzate per accelerare le query che coinvolgono aggregazioni comuni.
- Replicare tabelle, in particolare quelle di piccole dimensioni.
- Distribuzione hash per tabelle dei fatti di grandi dimensioni unite o aggregate.
Test con valore aggiunto
Al termine del test delle prestazioni delle query, è consigliabile testare funzionalità specifiche per verificare che soddisfino i casi d'uso previsti. Queste funzionalità sono:
- Sicurezza a livello di riga
- Sicurezza a livello di colonna
- Maschera dati dinamica
- Scalabilità all'interno del cluster tramite isolamento del carico di lavoro
Infine, è necessario interpretare i risultati del modello di verifica.
Interpretare i risultati del modello di verifica
Dopo aver ottenuto i risultati dei test per il data warehouse, è importante interpretarli. Un approccio comune che è possibile adottare consiste nel confrontare le esecuzioni in termini di prezzo/prestazioni. In poche parole, il rapporto prezzo/prestazioni rimuove le differenze di prezzo per DWU o hardware del servizio e fornisce un singolo numero paragonabile per ogni test delle prestazioni.
Ecco un esempio:
| Test | Durata test | DWU | $/ora per DWU | Costo del test |
|---|---|---|---|---|
| Test 1 | 10 min | 1000 | $12/ora | $ 2 |
| Test 2 | 30 min | 500 | $6/ora | $ 3 |
Questo esempio rende più semplice constatare come test 1 in DWU1000 sia più conveniente a $ 2 per esecuzione di test rispetto a $ 3 per esecuzione di test.
Nota
È anche possibile usare questa metodologia per confrontare i risultati tra i fornitori in un modello di verifica.
In sintesi, dopo aver completato tutti i test del modello di verifica, si è pronti per valutare i risultati. Per iniziare, valutare se gli obiettivi del modello di verifica sono stati raggiunti e gli output desiderati raccolti. Prendere nota della posizione in cui sono necessari test aggiuntivi e dove sono state poste domande aggiuntive.