Metodologia di successo dell'implementazione di Synapse: valutare la progettazione del pool SQL serverless

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.

È consigliabile valutare la progettazione del pool SQL serverless per identificare i problemi e verificare che soddisfi le linee guida e i requisiti. La valutazione della progettazione prima dell'inizio dello sviluppo di soluzioni consente di evitare situazioni di blocco delle attività e modifiche di progettazione impreviste. Ciò consente inoltre di rispettare la sequenza temporale e il budget del progetto.

La separazione dell'architettura di archiviazione e calcolo per dati moderni, piattaforme analitiche e servizi è stata un modello di tendenza e di uso frequente. Offre risparmi sui costi e maggiore flessibilità, consentendo un ridimensionamento indipendente su richiesta dell'archiviazione e dell'ambiente di calcolo. Synapse SQL serverless estende questo modello aggiungendo la funzionalità per eseguire query direttamente sui dati del data lake. Non è necessario preoccuparsi della gestione del calcolo quando si usano tipi self-service di carichi di lavoro.

Analisi corrispondenza-scarto

Quando si prevede di implementare pool SQL serverless all'interno di Azure Synapse, è prima necessario assicurarsi che i pool serverless siano adatti ai carichi di lavoro. È consigliabile valutare l'ottimizzazione dei costi, l'eccellenza operativa, l'efficienza delle prestazioni, l'affidabilità e la sicurezza.

Eccellenza operativa

Per l'eccellenza operativa, valutare i punti seguenti.

• Ambiente di sviluppo della soluzione: questa metodologia prevede una valutazione dell'ambiente di sviluppo della soluzione. Identificare il modo in cui gli ambienti (sviluppo, test e produzione) sono progettati per supportare lo sviluppo di soluzioni. In genere, si tratta di ambienti di produzione e non di produzione (per lo sviluppo e il test). È consigliabile trovare le aree di lavoro Synapse in tutti gli ambienti. Nella maggior parte dei casi, sarà necessario separare gli utenti e i carichi di lavoro di produzione e sviluppo/test.
• Progettazione dell'area di lavoro Synapse: all'interno di questa metodologia è disponibile una valutazione della progettazione dell'area di lavoro Synapse. Identificare il modo in cui le aree di lavoro sono state progettate per la soluzione. Acquisire familiarità con la progettazione e sapere se la soluzione userà una singola area di lavoro o se più aree di lavoro fanno parte della soluzione. Sapere perché è stata scelta una o più aree di lavoro. Una progettazione multi-area di lavoro viene spesso scelta per applicare limiti di sicurezza rigorosi.
• Distribuzione: SQL serverless è disponibile su richiesta con ogni area di lavoro Synapse, quindi non richiede alcuna azione di distribuzione speciale. Controllare la prossimità del servizio a livello di area e quella dell'account Azure Data Lake Storage Gen2 (ADLS Gen2) a cui è connessa.
• Monitoraggio: controllare se il monitoraggio predefinito è sufficiente e se è necessario implementare servizi esterni per archiviare i dati cronologici dei log. I dati di log consentono di analizzare le modifiche apportate alle prestazioni e di definire azioni di avviso o attivate per circostanze specifiche.

Efficienza prestazionale

A differenza dei motori di database tradizionali, SQL serverless non si basa sul proprio livello di archiviazione ottimizzato. Per questo motivo, le prestazioni dipendono in larga misura dalla modalità di organizzazione dei dati in ADLS Gen2. Per migliorare l'efficienza delle prestazioni, valutare i punti seguenti.

• Inserimento dati: esaminare la modalità di archiviazione dei dati nel data lake. Le dimensioni dei file, il numero di file e la struttura di cartelle hanno tutti un impatto sulle prestazioni. Tenere presente che, mentre alcune dimensioni dei file potrebbero funzionare per SQL serverless, altre possono creare problemi per l'elaborazione efficiente o l'utilizzo da parte di altri motori o applicazioni. Sarà necessario valutare la progettazione dell'archiviazione dei dati e convalidarla rispetto a tutti i consumer di dati, inclusi SQL serverless e qualsiasi altro strumento di dati appartenente alla soluzione.
• Posizionamento dei dati: valutare se la progettazione dispone di modelli comuni unificati e definiti per il posizionamento dei dati. Assicurarsi che la diramazione della directory possa supportare i requisiti di sicurezza. Esistono alcuni modelli comuni che consentono di gestire l'organizzazione dei dati delle serie temporali. Indipendentemente dalla scelta, assicurarsi che sia valido anche con altri motori e carichi di lavoro. Verificare anche se può aiutare a partizionare l'individuazione automatica per le applicazioni Spark e le tabelle esterne.
• Formati dei dati: nella maggior parte dei casi, SQL serverless sarà caratterizzato da prestazioni ottimali e una migliore funzionalità di compatibilità usando un formato Parquet. Verificare i requisiti di prestazioni e compatibilità, perché se da un lato il formato Parquet migliora le prestazioni grazie a una migliore compressione e riduzione dell'I/O (mediante la lettura solo delle colonne necessarie per l'analisi), dall'altro questo formato richiede più risorse di calcolo. Inoltre, poiché alcuni sistemi di origine non supportano in modo nativo Parquet come formato di esportazione, potrebbero comportare più passaggi di trasformazione nelle pipeline e/o nelle dipendenze nell'architettura complessiva.
• Esplorazione: ogni settore è diverso. In molti casi, tuttavia, esistono modelli di accesso ai dati comuni rilevati nelle query con una maggiore frequenza di esecuzione. I modelli in genere comportano filtri e aggregazioni in base a date, categorie o aree geografiche. Identificare i criteri di filtro più comuni e correlarli alla quantità di dati letti/eliminati dalle query eseguite più frequentemente. Verificare se le informazioni sul data lake sono organizzate in modo conforme ai requisiti di esplorazione e alle aspettative. Per le query individuate in fase di progettazione e valutazione, vedere se è possibile eliminare le partizioni non necessarie nel parametro di percorso OPENROWSET o, se sono presenti tabelle esterne, se la creazione di più indici può risultare utile.

Affidabilità

Per l'affidabilità, valutare i punti seguenti.

• Disponibilità: convalidare tutti i requisiti di disponibilità individuati durante la fase di valutazione. Anche se non sono presenti contratti di servizio specifici per SQL serverless, è previsto un timeout di 30 minuti per l'esecuzione delle query. Facendo riferimento alla valutazione, identificare le query con i tempi di esecuzione più lunghi e convalidarle in base alla progettazione SQL serverless. Un timeout di 30 minuti potrebbe interrompere le aspettative per il carico di lavoro e apparire come un problema di servizio.
• Coerenza: SQL serverless è progettato principalmente per i carichi di lavoro di lettura. Verificare quindi se tutte le verifiche di coerenza sono state eseguite durante il processo di provisioning e formazione dei dati del data lake. Mantenersi informati sulle nuove funzionalità, ad esempio il livello di archiviazione open source Delta Lake, che fornisce il supporto per i requisiti ACID (atomicità, coerenza, isolamento e durabilità) per le transazioni. Questa funzionalità consente di implementare architetture Lambda o Kappa efficaci per supportare i casi d'uso sia in streaming che in batch. Assicurarsi di valutare la progettazione per individuare opportunità di applicazione di nuove funzionalità, ma non a scapito della sequenza temporale o dei costi del progetto.
• Backup: esaminare i requisiti di ripristino di emergenza identificati durante la valutazione. Convalidarli in base alla progettazione SQL serverless per il ripristino. SQL serverless non dispone di un proprio livello di archiviazione e richiederebbe la gestione di snapshot e copie di backup dei dati. L'archivio dati a cui si accede da SQL serverless è esterno (ADLS Gen2). Esaminare la progettazione del ripristino nel progetto per questi set di dati.

Sicurezza

L'organizzazione dei dati è importante per la creazione di basi flessibili per la sicurezza. Nella maggior parte dei casi, processi e utenti diversi richiedono autorizzazioni e accessi diversi ad aree secondarie specifiche del data lake o del data warehouse logico.

Per la sicurezza, valutare i punti seguenti.

• Archiviazione dei dati: usando le informazioni raccolte durante la fase di valutazione, identificare se le aree tipiche (non elaborate, temporanee e curate) del data lake devono essere inserite nello stesso account di archiviazione anziché in account di archiviazione indipendenti. Quest'ultimo potrebbe essere caratterizzato da una maggiore flessibilità in termini di ruoli e autorizzazioni. Può anche aggiungere più capacità di operazioni di input/output al secondo (IOPS) che potrebbero essere necessarie se l'architettura deve supportare carichi di lavoro di lettura/scrittura simultanei, ad esempio scenari IoT o in tempo reale. Verificare se è necessario separare ulteriormente le aree dati in modalità sandbox e master in account di archiviazione distinti. La maggior parte degli utenti non dovrà aggiornare o eliminare i dati, quindi non necessita di autorizzazioni di scrittura per il data lake, ad eccezione delle aree in modalità sandbox e privata.
• Dalle informazioni di valutazione identificare se i requisiti si basano su funzionalità di sicurezza come Always Encrypted, Dynamic data masking o Sicurezza a livello di riga. Convalidare la disponibilità di queste funzionalità in scenari specifici, ad esempio quando vengono usate con la funzione OPENROWSET. Prevedere potenziali soluzioni alternative necessarie.
• In base alle informazioni di valutazione identificare i metodi di autenticazione migliori. Si considerino le entità servizio Microsoft Entra, la firma di accesso condiviso (SAS) e il modo in cui è possibile usare e integrare il pass-through di autenticazione nello strumento di esplorazione scelto dal cliente. Valutare la progettazione e verificare che il metodo di autenticazione migliore sia incluso nella progettazione.

Altre considerazioni

Esaminare la progettazione e verificare se sono state applicate procedure consigliate e raccomandazioni. Prestare particolare attenzione all'ottimizzazione e alle regole di confronto dei filtri per garantire che il pushdown del predicato funzioni correttamente.

Passaggi successivi

Nell'articolo successivo della serie Successo di Azure Synapse in base alla progettazione, vedere come valutare la progettazione del pool di Spark per individuare eventuali problemi e verificare che sia conforme alle linee guida e ai requisiti.