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

Il primo passaggio per l'implementazione di Azure Synapse Analytics consiste nell'eseguire una valutazione dell'ambiente. Una valutazione offre la possibilità di raccogliere tutte le informazioni disponibili sull'ambiente esistente, sui requisiti ambientali, sui requisiti di progetto, sui vincoli, sulle tempistiche e sui punti di dolore. Queste informazioni costituiscono la base delle valutazioni e delle attività di checkpoint successive. Sarà inestimabile quando si dovrà convalidare e confrontare la soluzione di progetto rispetto a come è stata pianificata, progettata e sviluppata. Ti consigliamo di dedicare una buona quantità di tempo per raccogliere tutte le informazioni e assicurati di avere discussioni necessarie con i gruppi pertinenti. I gruppi pertinenti possono includere stakeholder del progetto, utenti aziendali, progettisti di soluzioni ed esperti di materia (PMI) della soluzione e dell'ambiente esistenti.

La valutazione diventerà una guida per valutare la progettazione della soluzione e fornire raccomandazioni tecnologiche informate per implementare Azure Synapse.

Valutazione del carico di lavoro

La valutazione del carico di lavoro riguarda 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 dipendenti esistenti e i consumatori dipendenti upstream e downstream.
• Si sta eseguendo la migrazione di un data warehouse esistente (ad esempio Microsoft SQL Server, Microsoft Analytics Platform System (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 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 previsto di crescita 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 di 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 da dati relazionali, data lake o altre origini?
• Hai bisogno dell'analisi e dell'esplorazione dei dati in tempo reale dalle fonti di dati operative?
• Quali sono i punti di dolore e le limitazioni nell'ambiente corrente?
• Quali strumenti di controllo del codice sorgente e DevOps si usano oggi?
• Si ha 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 di un provider multi-cloud?
• Raccogliere piani per il futuro ambiente cloud. Si tratta di un provider di servizi cloud singolo o multi-cloud?
• Quali sono i requisiti RPO/RTO/HA/SLA nell'ambiente esistente?
• Quali sono i requisiti RPO/RTO/HA/SLA nell'ambiente pianificato?

Ruoli delle attività analitiche

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

• Descrivere i diversi ruoli (data scientist, data engineer, data analyst 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 come collaborano attualmente ruoli dati diversi.
• Sono presenti più team che collaborano sulla stessa piattaforma analitica? In tal caso, quali sono i requisiti di controllo di accesso e isolamento per ognuno 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 esistono 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, oraria, giornaliera, 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 (no-code, low-code, programmazione come SQL, Python, Scala, C# o altro)?
• Qual è l'approccio di programmazione pianificato preferito per trasformare i dati (no-code, low-code, 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 l'ETL esistente (Azure, altri provider di servizi cloud o locali)?
• Quali sono gli strumenti esistenti per l'utilizzo dei dati (creazione di report, strumenti bi, strumenti open source) che richiedono l'integrazione con la piattaforma analitica?
• Quali sono gli strumenti di utilizzo dei dati pianificati (creazione di report, strumenti di business intelligence, 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 tuoi dati contengono contenuti dei clienti, dati PCI (industria delle carte di pagamento) o dati della Legge sulla portabilità e responsabilità dell'assicurazione sanitaria del 1996 (HIPAA), il tuo gruppo di sicurezza ha certificato Azure per questi dati? In tal caso, 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 con peering, 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 per guidare la valutazione.

• Protezione dei dati:
  • Crittografia durante il transito
  • Crittografia dei dati a riposo (chiavi predefinite o chiavi gestite dal cliente)
  • Individuazione e classificazione dei dati
• Controllo di accesso:
  • Protezione a livello di oggetto
  • Sicurezza a livello di riga
  • Sicurezza a livello di colonna
  • Mascheratura dinamica dei dati
• Authentication:
  • Account di accesso SQL
  • Microsoft Entra ID
  • Multi-Factor Authentication (MFA)
• Sicurezza di rete:
  • Reti virtuali
  • Firewall
  • Azure ExpressRoute
• Protezione dalle minacce:
  • Rilevamento delle minacce
  • Auditing
  • 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 si usa 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? È necessaria una formazione?

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 consumatori di dati.
• Identificare i requisiti di esportazione dei dati e condivisione dei dati.

Valutazione dei servizi di Azure Synapse

La valutazione dei servizi di Azure Synapse riguarda i servizi in Azure Synapse. Azure Synapse include i componenti seguenti per il calcolo e lo spostamento dei dati:

• Synapse SQL: Un 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 dedicati .
• Serverless SQL pool: Un sistema di elaborazione dati distribuito, progettato per l'elaborazione di dati e funzioni di calcolo su ampia scala. Non esiste un'infrastruttura da configurare o cluster da gestire. Questo servizio è adatto per carichi di lavoro non pianificati o improvvisi. 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 analitiche di cui viene effettuato il provisioning quando si usa 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 ad alte prestazioni sui dati archiviati nelle tabelle SQL. 
• Pool di Apache Spark: Integra profondamente e senza problemi Apache Spark, che è il motore big data open source più diffuso usato per la preparazione dei dati, la progettazione dei dati, ETL e ML.
• 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?
• Vuoi creare un data warehouse logico su un data lake?
• Vuoi eseguire query sui dati direttamente da un data lake?
• Vuoi esplorare i dati di un data lake?

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

Valutazione del pool SQL dedicato

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

• Qual è la piattaforma data warehouse corrente (Microsoft SQL Server, Netezza, Teradata, Greenplum o altro)?
• Per un carico di lavoro di migrazione, identificare la marca e il modello del dispositivo per ogni ambiente. Includere i dettagli delle CPU, delle GPU e della memoria.
• Per una migrazione dell'appliance, quando è stato acquistato l'hardware? Il dispositivo è stato completamente ammortizzato? In caso contrario, quando terminerà l'ammortamento? E quanto rimane la spesa in conto capitale?
• 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 SQL di Azure, DB2, Oracle, Archiviazione BLOB di Azure, AWS, Hadoop o altro)?
• Ci sono delle origini dati che sono dei data warehouse? In tal caso, quali?
• Identificare tutti gli scenari ETL, ELT e di caricamento dei dati (finestre batch, streaming, quasi in tempo reale). 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?
• Quale tasso di crescita del set di dati è destinato al 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 quasi in tempo reale?

Valutare i punti di database seguenti.

• Qual è il numero di oggetti in ogni data warehouse (schemi, tabelle, viste, stored procedure, funzioni)?
• È un modello a stella, un modello a fiocco di neve o un altro tipo di design?
• 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? È un design di schema Kimball, Inmon o star?
• Le dimensioni a variazione lenta (SCD) sono in uso? In tal caso, quali tipi?
• Si implementerà un livello semantico usando data mart relazionali o Analysis Services (tabulare o multidimensionale) oppure un altro prodotto?
• Quali sono i requisiti di alta disponibilità, RPO, RTO e archiviazione dei 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 di minore attività?
• Esiste un periodo di tempo in cui non ci saranno utenti o attività?
• Quali sono le aspettative delle prestazioni di esecuzione delle query per le query interattive?
• Quali sono le aspettative sulle 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 è il set di dati attivo?
• Circa quale percentuale del carico di lavoro è prevista per il caricamento o l'aggiornamento, l'elaborazione batch o la creazione di report, 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 ogni momento?
  • Qual è la natura dell'accesso ai dati (interattivo, ad hoc, esportazione o altro)?
  • Ruoli relativi ai dati e descrizione completa dei loro requisiti di dati.
  • Numero massimo di connessioni simultanee.
• Modello SLA per le prestazioni delle query secondo:
  • Utenti del dashboard.
  • Creazione di report batch.
  • Utenti di 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 altri)?
• Sono previsti requisiti per integrare il punteggio del modello di Machine Learning con T-SQL?

Valutazione serverless del pool SQL

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

• Individuazione ed esplorazione di base: Analisi rapida dei dati in vari formati (Parquet, CSV, JSON) nel data lake, in modo da poter pianificare come estrarre approfondimenti.
• Data warehouse logico: Fornire un'astrazione relazionale su dati grezzi o eterogenei senza spostare o trasformare i dati, consentendo una vista sempre aggiornata dei dati.
• Trasformazione dei dati: Modo semplice, scalabile ed efficiente per trasformare i dati nel lake usando T-SQL, in modo che possa essere inserito in BI e in altri strumenti o caricato in un archivio dati relazionale (database SQL di Synapse, database SQL di Azure o altri).

Diversi ruoli relativi ai dati possono beneficiare del pool SQL serverless:

• I data engineer possono esplorare il data lake, trasformare e preparare i dati usando questo servizio e semplificare le pipeline di trasformazione dei dati.
• I data scientist possono ragionare rapidamente sul contenuto e sulla struttura dei dati nel data lake, grazie a funzionalità come OPENROWSET e inferenza automatica dello schema.
• Gli analisti deidati possono esplorare i dati e le tabelle esterne Spark create da data scientist o data engineer usando istruzioni T-SQL familiari o i relativi strumenti di query preferiti.
• I professionisti di Business Intelligence possono creare rapidamente report di Power BI sui dati nel data lake e nelle tabelle Spark.

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 l'accordo sul livello di servizio per le prestazioni delle query. Il caso d'uso richiede prestazioni e costi prevedibili?
• Hai carichi di lavoro analitici SQL non pianificati o improvvisi?
• 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 relativi ai dati e descrizione completa dei loro requisiti di dati.
  • Numero massimo di connessioni simultanee.
  • Complessità delle query?
• Quali sono i requisiti di sicurezza (controllo di accesso, crittografia e altri)?
• 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.

Valutazione del pool di Spark

I pool di Spark in Azure Synapse abilitano 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. È abilitato tramite più linguaggi (C#, Scala, PySpark, Spark SQL) e usando librerie fornite per l'elaborazione e la connettività.
• Machine Learning: Apache Spark include MLlib, una libreria di Machine Learning 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 a tolleranza di errore, elastico e RESTful. In combinazione con il supporto predefinito per i notebook, è disponibile un ambiente avanzato per la creazione di applicazioni ml.

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

• Identificare i carichi di lavoro che richiedono la progettazione 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 locale, l'hardware è deprecato o le licenze sono scadute? In caso contrario, quando si verificherà l'ammortamento o la scadenza?
  • Che cos'è il tipo di cluster esistente?
  • Quali sono le librerie necessarie e le versioni di Spark?
  • 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 esistenti e pianificati e le piattaforme di creazione di report?
  • Quali sono i requisiti di sicurezza?
  • Ci sono punti di dolore e limitazioni correnti?
• Si prevede di usare o si sta attualmente usando Delta Lake?
• Come si gestiscono i pacchetti oggi?
• Identificare i tipi di cluster di calcolo necessari.
• Identificare se è necessaria la personalizzazione del cluster.

Passaggi successivi

Nell'articolo successivo della serie Azure Synapse progettazione del successo, scoprire come esaminare la progettazione dell'area di lavoro Synapse e verificare che soddisfi le linee guida nonché i requisiti.