Metodologia di successo dell'implementazione di Synapse: valutare l'ambiente

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.

Il primo passaggio per l'implementazione di Azure Synapse Analytics consiste nell'eseguire una valutazione dell'ambiente. Una valutazione consente di raccogliere tutte le informazioni disponibili sull'ambiente esistente, sui requisiti ambientali, sui requisiti di progetto, sui vincoli, sulle tempistiche e sulle aree problematiche. Queste informazioni costituiscono la base delle valutazioni e delle attività di checkpoint successive. Ciò risulterà di vitale importanza quando si tratta di convalidare e confrontare con la soluzione di progetto durante le fasi di pianificazione, progettazione e sviluppo. È consigliabile dedicare tutto il tempo necessario alla raccolta delle informazioni e assicurarsi di coinvolgere tutti i gruppi pertinenti. I gruppi pertinenti possono includere stakeholder del progetto, utenti aziendali, progettisti di soluzioni ed esperti di dominio (SME) della soluzione e dell'ambiente esistenti.

La valutazione costituirà una linea guida per valutare la progettazione della soluzione e fornire raccomandazioni informate in merito alle tecnologie necessarie per implementare Azure Synapse.

Valutazione del carico di lavoro

La valutazione del carico di lavoro ha come oggetto l'ambiente, i ruoli del carico di lavoro analitico, ETL/ELT, la rete e la sicurezza, l'ambiente di Azure e l'utilizzo dei dati.

Ambiente

Per l'ambiente, valutare i punti seguenti.

• Descrivere il carico di lavoro analitico esistente:
  • Quali sono i carichi di lavoro (ad esempio data warehouse o Big Data)?
  • In che modo questo carico di lavoro aiuta l'azienda? Quali sono gli scenari dei casi d'uso?
  • Qual è il driver aziendale per questa piattaforma analitica e per la potenziale migrazione?
  • Raccogliere informazioni dettagliate sull'architettura, la progettazione e le scelte di implementazione esistenti.
  • Raccogliere informazioni dettagliate su tutti i componenti e i consumer dipendenti upstream e downstream esistenti.
• Si sta eseguendo la migrazione di un data warehouse esistente (ad esempio Microsoft SQL Server, piattaforma di strumenti analitici Microsoft (APS), Netezza, Snowflake o Teradata)?
• Si sta eseguendo la migrazione di una piattaforma Big Data (ad esempio Cloudera o Hortonworks)?
• Raccogliere i diagrammi dell'architettura e del flusso di dati per l'ambiente analitico corrente.
• Dove si trovano le origini dati per i carichi di lavoro analitici pianificati (Azure, altri provider di servizi cloud o origini locali)?
• Qual è la dimensione totale dei set di dati esistenti (cronologici e incrementali)? Qual è il tasso di crescita corrente dei set di dati? Qual è il tasso di crescita previsto dei set di dati per i prossimi 2-5 anni?
• Si dispone di un data lake esistente? Raccogliere il maggior numero di dettagli possibile sui tipi di file (ad esempio Parquet o CSV), le dimensioni dei file e la configurazione della sicurezza.
• Sono disponibili dati semistrutturati o non strutturati da elaborare e analizzare?
• Descrivere la natura dell'elaborazione dei dati (elaborazione batch o in tempo reale).
• È necessaria un'esplorazione interattiva dei dati a livello di dati relazionali, data lake o altre origini?
• È necessaria l'analisi e l'esplorazione dei dati in tempo reale a livello di origini dati operative?
• Quali sono le aree problematiche e le limitazioni dell'ambiente corrente?
• Quali strumenti di controllo del codice sorgente e DevOps si usano attualmente?
• È disponibile un caso d'uso per creare una soluzione analitica ibrida (cloud e locale), solo cloud o multi-cloud?
• Raccogliere informazioni sull'ambiente cloud esistente. Si tratta di un provider single-cloud o multi-cloud?
• Raccogliere piani sull'ambiente cloud futuro. Sarà un provider single-cloud o multi-cloud?
• Quali sono i requisiti per RPO/RTO/disponibilità elevata/contratto di servizio nell'ambiente esistente?
• Quali sono i requisiti per RPO/RTO/disponibilità elevata/contratto di servizio nell'ambiente pianificato?

Ruoli del carico di lavoro analitico

Per i ruoli del carico di lavoro analitico, valutare i punti seguenti.

• Descrivere i diversi ruoli (scienziato dei dati, ingegnere dei dati, analista dei dati e altri).
• Descrivere il requisito di controllo di accesso della piattaforma analitica per questi ruoli.
• Identificare il proprietario della piattaforma responsabile del provisioning delle risorse di calcolo e concedere l'accesso.
• Descrivere le modalità di collaborazione dei diversi ruoli dati.
• Sono presenti più team che collaborano sulla stessa piattaforma analitica? In caso di risposta affermativa, quali sono i requisiti di controllo di accesso e isolamento per ciascuno di questi team?
• Quali sono gli strumenti client usati dagli utenti finali per interagire con la piattaforma analitica?

ETL/ELT, trasformazione e orchestrazione

Per ETL/ELT, trasformazione e orchestrazione, valutare i punti seguenti.

• Quali strumenti si usano oggi per l'inserimento dati (ETL o ELT)?
• Dove sono disponibili questi strumenti nell'ambiente esistente (locale o nel cloud)?
• Quali sono i requisiti di caricamento e aggiornamento dei dati correnti (batch in tempo reale, micro batch, orario, giornaliero, settimanale o mensile)?
• Descrivere i requisiti di trasformazione per ogni livello (Big Data, data lake, data warehouse).
• Qual è l'approccio di programmazione corrente per trasformare i dati (con uso limitato di codice, senza uso di codice, programmazione come SQL, Python, Scala, C# o altro)?
• Qual è l'approccio di programmazione pianificato preferito per trasformare i dati (con uso limitato di codice, senza uso di codice, programmazione come SQL, Python, Scala, C# o altro)?
• Quali strumenti sono attualmente in uso per l'orchestrazione dei dati per automatizzare il processo basato sui dati?
• Dove si trovano le origini dati per la funzionalità ETL esistente (Azure, altri provider di servizi cloud o locali)?
• Quali sono gli strumenti esistenti per l'uso dei dati (creazione di report, strumenti BI, strumenti open source) che richiedono l'integrazione con la piattaforma analitica?
• Quali sono gli strumenti pianificati per l'uso dei dati (creazione di report, strumenti BI, strumenti open source) che richiederanno l'integrazione con la piattaforma analitica?

Rete e sicurezza

Per la rete e la sicurezza, valutare i punti seguenti.

• Quali requisiti normativi sono disponibili per i dati?
• Se i dati contengono informazioni relative a contenuti dei clienti, PCI (Payment Card Industry) o HIPAA (Health Insurance Portability and Accountability 1996), per questi dati è stato certificato Azure per il gruppo di sicurezza? In caso di risposta affermativa, per quali servizi di Azure?
• Descrivere i requisiti di autorizzazione e autenticazione dell'utente.
• Esistono problemi di sicurezza che potrebbero limitare l'accesso ai dati durante l'implementazione?
• Sono disponibili dati di test da usare durante lo sviluppo e i test?
• Descrivere i requisiti di sicurezza della rete dell'organizzazione nel calcolo analitico e nell'archiviazione (rete privata, rete pubblica o restrizioni del firewall).
• Descrivere i requisiti di sicurezza di rete per gli strumenti client per accedere al calcolo analitico e all'archiviazione (rete associata, endpoint privato o altro).
• Descrivere la configurazione di rete corrente tra l'ambiente locale e Azure (Azure ExpressRoute, da sito a sito o altro).

Usare gli elenchi di controllo seguenti dei possibili requisiti come guida per la valutazione.

• Protezione dei dati:
  • Crittografia dei dati in transito
  • Crittografia dei dati inattivi (chiavi predefinite o chiavi gestite dal cliente)
  • Individuazione e classificazione dei dati
• Controllo di accesso:
  • Sicurezza a livello di oggetto
  • Sicurezza a livello di riga
  • Sicurezza a livello di colonna
  • Maschera dati dinamica
• Autenticazione:
  • Account di accesso SQL
  • Microsoft Entra ID
  • Autenticazione a più fattori
• Sicurezza di rete:
  • Reti virtuali
  • Firewall
  • Azure ExpressRoute
• Protezione dalle minacce:
  • Rilevamento delle minacce
  • Controllo
  • Valutazione della vulnerabilità

Per altre informazioni, vedere il White paper sulla sicurezza di Azure Synapse Analytics.

Ambiente di Azure

Per l'ambiente Azure, valutare i punti seguenti.

• È attualmente in uso il portale di Azure? Viene usato per i carichi di lavoro di produzione?
• Se si usa Azure, quali servizi si usano? Quali aree si usano?
• Si usa Azure ExpressRoute? Qual è la larghezza di banda?
• Si dispone dell'approvazione del budget per effettuare il provisioning dei servizi di Azure necessari?
• Come si esegue attualmente il provisioning e la gestione delle risorse (Azure Resource Manager (ARM) o Terraform?
• Il team principale ha familiarità con Synapse Analytics? Sono necessari eventi di training?

Consumo di dati

Per l'utilizzo dei dati, valutare i punti seguenti.

• Descrivere come e quali strumenti vengono attualmente usati per eseguire attività quali inserimento, esplorazione, preparazione e visualizzazione dei dati.
• Identificare gli strumenti che si prevede di usare per eseguire attività quali inserimento, esplorazione, preparazione e visualizzazione dei dati.
• Quali applicazioni sono pianificate per interagire con la piattaforma analitica (Microsoft Power BI, Microsoft Excel, Microsoft SQL Server Reporting Services, Tableau o altri)?
• Identificare tutti i consumer di dati.
• Identificare i requisiti di esportazione e condivisione dei dati.

Valutazione dei servizi di Azure Synapse

La valutazione dei servizi di Azure Synapse ha come oggetto i servizi all'interno di Azure Synapse. Azure Synapse include i componenti seguenti per il calcolo e lo spostamento dati:

• Synapse SQL: sistema di query distribuito per Transact-SQL (T-SQL) che consente scenari di data warehousing e virtualizzazione dei dati. Estende anche T-SQL per gestire scenari di streaming e Machine Learning (ML). Synapse SQL offre modelli di risorse serverless e dedicate.
• Pool SQL serverless: sistema di elaborazione dati distribuito, progettato per dati e funzioni di calcolo su vasta scala. Non esiste un'infrastruttura da configurare o cluster da gestire. Questo servizio è adatto per carichi di lavoro non pianificati o burst. Gli scenari consigliati includono un'esplorazione rapida dei dati sui file direttamente nel data lake, nel data warehouse logico e nella trasformazione dei dati non elaborati.
• Pool SQL dedicato: rappresenta una raccolta di risorse di analisi di cui viene effettuato il provisioning durante l'uso di Synapse SQL. Le dimensioni di un pool SQL dedicato (in precedenza SQL Data Warehouse) sono determinate da unità Data Warehouse (DWU). Questo servizio è adatto per un data warehouse con carichi di lavoro continui prevedibili e con prestazioni elevate sui dati archiviati nelle tabelle SQL. 
• Pool di Apache Spark si integra pienamente e facilmente con Apache Spark, il motore di Big Data open source più diffuso usato per la preparazione dei dati, l'ingegneria dei dati, i processi ETL e Machine Learning.
• Pipeline di integrazione dei dati: Azure Synapse contiene lo stesso motore di integrazione dei dati ed esperienze di Azure Data Factory (ADF). Consentono di creare pipeline ETL avanzate su larga scala senza uscire da Azure Synapse.

Per determinare il tipo di pool SQL migliore (dedicato o serverless), valutare i punti seguenti.

• Si vuole creare un data warehouse relazionale tradizionale riservando potenza di elaborazione per i dati archiviati nelle tabelle SQL?
• I casi d'uso richiedono prestazioni prevedibili?
• Si vuole creare un data warehouse logico su un data lake?
• Si vuole eseguire query sui dati direttamente da un data lake?
• Si vogliono esplorare i dati da un data lake?

La tabella seguente confronta i due tipi di pool di Synapse SQL.

Confronto	Pool SQL dedicato	Pool SQL serverless
Proposte di valore	Funzionalità completamente gestite di un data warehouse. Prestazioni prevedibili ed elevate per carichi di lavoro continui. Ottimizzato per i dati gestiti (caricati).	Facile da iniziare a usare per esplorare i dati del data lake. Migliore costo totale di proprietà (TCO) per carichi di lavoro ad hoc e intermittenti. Ottimizzato per l'esecuzione di query sui dati in un data lake.
Carichi di lavoro	Ideale per carichi di lavoro continui. Il caricamento incrementa le prestazioni e ne aumenta la complessità. La ricarica per DWU (se ridimensionata) sarà vantaggiosa.	Ideale per carichi di lavoro ad hoc o intermittenti. Non è necessario caricare i dati, quindi è più facile da avviare ed eseguire. L'addebito per utilizzo sarà vantaggioso per i costi.
Prestazioni delle query	Offre concorrenza elevata e bassa latenza. Supporta opzioni avanzate di memorizzazione nella cache, incluse le viste materializzate. È possibile scendere a compromessi con la gestione dei carichi di lavoro (WLM).	Non adatto per la creazione di dashboard di query. Non sono previsti i tempi di risposta in millisecondi. Funziona solo su dati esterni.

Valutazione del pool SQL dedicato

Per la valutazione del pool SQL dedicato, valutare i punti seguenti relativi alla piattaforma.

• Qual è la piattaforma data warehouse corrente (Microsoft SQL Server, Netezza, Teradata, Greenplum o altro)?
• Per un carico di lavoro di migrazione, determinare la marca e il modello dell'appliance per ogni ambiente. Includere i dettagli relativi a CPU, GPU e memoria.
• Per la migrazione di un'appliance, quando è stato acquistato l'hardware? L'appliance è stata completamente deprecata? In caso contrario, quando terminerà l'ammortamento? Qual è la spesa in conto capitale residua?
• Esistono diagrammi hardware e architettura di rete?
• Dove si trovano le origini dati per il data warehouse pianificato (Azure, altri provider di servizi cloud o locali)?
• Quali sono le piattaforme di hosting dei dati delle origini dati per il data warehouse (Microsoft SQL Server, database di Azure SQL, DB2, Oracle, Archiviazione BLOB di Azure, AWS, Hadoop o altro)?
• Le origini dati sono data warehouse? Se sì, quali?
• Identificare tutti gli scenari ETL, ELT e di caricamento dei dati (finestre batch, streaming, near real-time). Identificare i contratti di servizio esistenti per ogni scenario e documentare i contratti di servizio previsti nel nuovo ambiente.
• Quali sono le dimensioni correnti del data warehouse?
• Qual è il tasso di crescita obiettivo del set di dati per il pool SQL dedicato?
• Descrivere gli ambienti attualmente in uso (sviluppo, test o produzione).
• Quali strumenti sono attualmente disponibili per lo spostamento dei dati (ADF, Microsoft SQL Server Integration Services (SSIS), Robocopy, Informatica, SFTP o altri)?
• Si prevede di caricare dati in tempo reale o in modalità near real-time?

Valutare i punti di database seguenti.

• Qual è il numero di oggetti in ogni data warehouse (schemi, tabelle, viste, stored procedure, funzioni)?
• È uno schema star, uno schema snowflake o un altro tipo di progettazione?
• Quali sono le tabelle più grandi in termini di dimensioni e numero di record?
• Quali sono le tabelle più ampie in termini di numero di colonne?
• Esiste già un modello di dati progettato per il data warehouse? È una progettazione basata su schema star, Kimball, o Inmon?
• Vengono usate le dimensioni a modifica lenta (SCD)? In caso affermativo, quali tipi?
• Verrà implementato un livello semantico usando data mart relazionali o Analysis Services (tabulare o multidimensionale) o un altro prodotto?
• Quali sono i requisiti di archiviazione relativamente a disponibilità elevata/RPO/RTO/dati?
• Quali sono i requisiti di replica dell'area?

Valutare le caratteristiche del carico di lavoro seguenti.

• Qual è il numero stimato di utenti o processi simultanei che accedono al data warehouse durante le ore di punta?
• Qual è il numero stimato di utenti o processi simultanei che accedono al data warehouse durante le ore non di punta?
• C'è un intervallo di tempo in cui non ci saranno utenti o processi?
• Quali sono le aspettative delle prestazioni di esecuzione delle query interattive?
• Quali sono le aspettative per le prestazioni di caricamento dei dati per i caricamenti o gli aggiornamenti giornalieri/settimanali/mensili?
• Quali sono le aspettative di esecuzione delle query per la creazione di report e le query analitiche?
• Quanto saranno complesse le query eseguite più di frequente?
• Quale percentuale delle dimensioni totali del set di dati si riferisce al set di dati attivo?
• Quale percentuale approssimativa del carico di lavoro è prevista per il caricamento o l'aggiornamento, l'elaborazione batch o la creazione di report, le query interattive e l'elaborazione analitica?
• Identificare i modelli e le piattaforme che usano i dati:
  • Strumenti e metodi di creazione di report correnti e pianificati.
  • Quali strumenti analitici o applicazioni accederanno al data warehouse?
  • Numero di query simultanee?
  • Numero medio di query attive in qualsiasi momento?
  • Qual è la natura dell'accesso ai dati (interattivo, ad hoc, esportazione o altro)?
  • Ruoli dati e descrizione completa dei requisiti dei dati.
  • Numero massimo di connessioni simultanee.
• Modello di contratto di servizio per le prestazioni delle query in base a:
  • Utenti del dashboard.
  • Creazione di batch di report.
  • Utenti ML.
  • Processo ETL.
• Quali sono i requisiti di sicurezza per l'ambiente esistente e per il nuovo ambiente (sicurezza a livello di riga, sicurezza a livello di colonna, controllo di accesso, crittografia e altro)?
• Sono previsti requisiti per integrare il punteggio del modello di Machine Learning con T-SQL?

Valutazione del pool SQL serverless

Il pool SQL serverless di Synapse supporta tre casi d'uso principali.

• Individuazione ed esplorazione di base: è possibile ragionare rapidamente sui dati in vari formati (Parquet, CSV, JSON) nel data lake, in modo da pianificare come estrarne informazioni dettagliate.
• Data warehouse logico: è possibile ottenere un'astrazione relazionale su dati non elaborati o disparati senza spostarli e trasformarli, per averne una visualizzazione sempre aggiornata.
• Trasformazione dei dati: un modo semplice, scalabile e a elevate prestazioni per trasformare i dati nel data lake tramite T-SQL, in modo che possano essere inseriti in strumenti di business intelligence e di altro tipo o caricati in un archivio dati relazionale (database di Synapse SQL, Database di Azure SQL e così via).

I diversi ruoli dati possono trarre vantaggio dal pool SQL serverless:

• Gli ingegneri dei dati possono esplorare il data lake, trasformare e preparare i dati usando questo servizio, nonché semplificare le pipeline di trasformazione dei dati.
• Gli scienziati dei dati possono ragionare rapidamente sul contenuto e sulla struttura dei dati nel data lake, grazie a funzionalità come OPENROWSET e l'inferenza automatica dello schema.
• Gli analisti dei dati possono esplorare i dati e le tabelle esterne Spark creati dagli scienziati dei dati o dagli ingegneri dei dati usando un linguaggio T-SQL familiare o i loro strumenti preferiti, che possono connettersi a SQL su richiesta.
• I professionisti di business intelligence possono creare rapidamente report di Power BI sui dati del data lake e sulle tabelle Spark.

Nota

Il linguaggio T-SQL viene usato sia nel pool SQL dedicato che nel pool SQL serverless, ma esistono alcune differenze nel set di funzionalità supportate. Per altre informazioni sulle funzionalità T-SQL supportate in Synapse SQL (dedicato e serverless), vedere Funzionalità Transact-SQL supportate in Azure Synapse SQL.

Per la valutazione del pool SQL serverless, valutare i punti seguenti.

• Esistono casi d'uso per individuare ed esplorare i dati da un data lake usando query relazionali (T-SQL)?
• Esistono casi d'uso per creare un data warehouse logico su un data lake?
• Identificare se esistono casi d'uso per trasformare i dati nel data lake senza prima spostare i dati dal data lake.
• I dati sono già presenti in Azure Data Lake Storage (ADLS) o in Archiviazione BLOB di Azure?
• Se i dati sono già presenti in ADLS, si dispone di una buona strategia di partizione nel data lake?
• Sono presenti dati operativi in Azure Cosmos DB? Esistono casi d'uso per l'analisi in tempo reale in Azure Cosmos DB senza influire sulle transazioni?
• Identificare i tipi di file nel data lake.
• Identificare il contratto di servizio per le prestazioni delle query. Il caso d'uso richiede prestazioni e costi prevedibili?
• Sono presenti carichi di lavoro analitici SQL non pianificati o burst?
• Identificare il modello e le piattaforme che utilizzano i dati:
  • Strumenti e metodi di creazione di report correnti e pianificati.
  • Quali strumenti analitici o applicazioni accederanno al pool SQL serverless?
  • Numero medio di query attive in qualsiasi momento.
  • Qual è la natura dell'accesso ai dati (interattivo, ad hoc, esportazione o altro)?
  • Ruoli dati e descrizione completa dei requisiti dei dati.
  • Numero massimo di connessioni simultanee.
  • Complessità delle query?
• Quali sono i requisiti di sicurezza (controllo di accesso, crittografia e altro)?
• Qual è la funzionalità T-SQL necessaria (stored procedure o funzioni)?
• Identificare il numero di query che verranno inviate al pool SQL serverless e le dimensioni del set di risultati di ogni query.

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.

Valutazione del pool di Spark

I pool di Spark in Azure Synapse supportano gli scenari principali seguenti.

• Ingegneria dei dati/Preparazione dei dati: Apache Spark include molte funzionalità del linguaggio per supportare la preparazione e l'elaborazione di grandi volumi di dati. La preparazione e l'elaborazione possono rendere i dati più utili e consentire l'uso da parte di altri servizi di Azure Synapse. Queste funzionalità sono abilitate tramite più linguaggi (C#, Scala, PySpark, Spark SQL) e librerie fornite per l'elaborazione e la connettività.
• Apprendimento automatico: Apache Spark include MLlib, una libreria ML basata su Spark che è possibile usare da un pool di Spark. I pool di Spark includono anche Anaconda, ovvero una distribuzione Python che comprende vari pacchetti per l'analisi scientifica dei dati, incluso ML. Inoltre, Apache Spark in Synapse fornisce librerie preinstallate per Microsoft Machine Learning, che è un framework ML con tolleranza di errore, elastico e RESTful. Aggiungendo il supporto incorporato per notebook, si otterrà un ambiente avanzato per la creazione di applicazioni ML.

Nota

Per altre informazioni, vedere Apache Spark in Azure Synapse Analytics.

Inoltre, Azure Synapse è compatibile con Linux Foundation Delta Lake. Delta Lake è un livello di archiviazione open source che consente di usare transazioni ACID (Atomicity, Consistency, Isolation And Durability, ovvero atomicità, coerenza, isolamento e durabilità) in Apache Spark e nei carichi di lavoro di Big Data. Per altre informazioni, vedere Che cos'è Delta Lake.

Per la valutazione del pool di Spark, valutare i punti seguenti.

• Identificare i carichi di lavoro che richiedono l'ingegneria dei dati o la preparazione dei dati.
• Definire chiaramente i tipi di trasformazioni.
• Identificare se sono presenti dati non strutturati da elaborare.
• Quando si esegue la migrazione da un carico di lavoro Spark/Hadoop esistente:
  • Qual è la piattaforma Big Data esistente (Cloudera, Hortonworks, servizi cloud o altro)?
  • Se si tratta di una migrazione da un ambiente locale, l'hardware è deprecato o le licenze sono scadute? In caso di risposta negativa, quando si verificherà l'ammortamento o la scadenza?
  • Che cos'è il tipo di cluster esistente?
  • Quali sono le librerie e le versioni di Spark richieste?
  • Si tratta di una migrazione Hadoop a Spark?
  • Quali sono i linguaggi di programmazione correnti o preferiti?
  • Qual è il tipo di carico di lavoro (Big Data, ML o altro)?
  • Quali sono gli strumenti client e le piattaforme di creazione di report esistenti e pianificati?
  • Quali sono i requisiti di sicurezza?
  • Ci sono aree problematiche e limitazioni correnti?
• Si prevede di usare o si sta attualmente usando Delta Lake?
• Come vengono attualmente gestiti i pacchetti?
• Identificare i tipi di cluster di calcolo necessari.
• Identificare se è necessaria la personalizzazione del cluster.

Suggerimento

Se non si ha familiarità con i pool di Spark, è consigliabile usare il percorso di apprendimento Eseguire l'ingegneria dei dati con i pool di Apache Spark di Azure Synapse.

Passaggi successivi

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