Opzioni per Big Data nella piattaforma Microsoft SQL Server

Si applica a: SQL Server 2019 (15.x) e versioni successive

Il 28 febbraio 2025, i cluster Big Data di SQL Server 2019 sono stati ritirati. Per altre informazioni, vedere il post di blog dell'annuncio.

Modifiche al supporto di PolyBase in SQL Server

Alcune funzionalità correlate alle query di scalabilità orizzontale sono legate al ritiro dei cluster Big Data di SQL Server 2019.

La funzionalità Gruppi con scalabilità orizzontale polyBase di Microsoft SQL Server è stata ritirata. La funzionalità del gruppo di scalabilità orizzontale è stata rimossa dal prodotto in SQL Server 2022 (16.x). Le versioni in-market di SQL Server 2019, SQL Server 2017 e SQL Server 2016 continuano a supportare la funzionalità fino alla fine della durata di tali prodotti. La virtualizzazione dei dati PolyBase continua a essere completamente supportata come funzionalità di aumento delle prestazioni in SQL Server.

Le fonti dati esterne Hadoop di Cloudera (CDP) e Hortonworks (HDP) verranno ritirati per tutte le versioni di SQL Server attualmente sul mercato e non sono incluse in SQL Server 2022. Il supporto per le origini dati esterne è limitato alle versioni del prodotto nel supporto principale del rispettivo fornitore. Si consiglia di usare la nuova integrazione dell'archiviazione oggetti disponibile in SQL Server 2022 (16.x).

In SQL Server 2022 (16.x) e versioni successive, gli utenti devono configurare le origini dati esterne per utilizzare nuovi connettori quando si collegano ad Azure Storage. La tabella seguente riepiloga la modifica:

Origine dati esterna	From	To
Blob Storage di Azure	`wasb[s]`	`abs`
ADLS Gen 2	`abfs[s]`	`adls`

Note

Archiviazione BLOB di Azure (abs) richiederà l'utilizzo della firma di accesso condiviso (SAS) per SECRET nella credenziale con ambito nel database. In SQL Server 2019 e versioni precedenti il connettore usava la wasb[s] chiave dell'account di archiviazione con credenziali con ambito database durante l'autenticazione nell'account di archiviazione di Azure.

Informazioni sull'architettura dei cluster Big Data per le opzioni di sostituzione e migrazione

Per creare la soluzione di sostituzione per un sistema di archiviazione ed elaborazione Big Data, è importante comprendere cosa offre i cluster Big Data di SQL Server 2019 e l'architettura può aiutare a fornire informazioni sulle scelte. L'architettura di un cluster Big Data è la seguente:

Questa architettura fornisce il seguente mapping delle funzionalità.

Component	Benefit
Kubernetes	Agente di orchestrazione open source per la distribuzione e la gestione di applicazioni basate su contenitori su larga scala. Fornisce un metodo dichiarativo per creare e controllare resilienza, ridondanza e portabilità per l'intero ambiente con scalabilità elastica.
Controllore del cluster Big Data	Fornisce la gestione e la sicurezza per il cluster. Contiene il servizio di controllo, l'archivio di configurazione e altri servizi a livello di cluster, ad esempio Kibana, Grafana e Ricerca elastica.
Compute Pool	Fornisce risorse di calcolo al cluster. Contiene nodi che eseguono SQL Server in pod Linux. I pod nel pool di calcolo sono suddivisi in istanze di calcolo SQL per attività di elaborazione specifiche. Questo componente fornisce anche la virtualizzazione dei dati usando PolyBase per eseguire query su origini dati esterne senza spostare o copiare i dati.
Data Pool	Fornisce la persistenza dei dati per il cluster. Il pool di dati è costituito da uno o più pod che eseguono SQL Server in Linux. Viene usato per inserire dati da query SQL o processi Spark.
Storage Pool	Il pool di archiviazione è costituito da pod del pool di archiviazione costituiti da SQL Server in Linux, Spark e HDFS. Tutti i nodi di archiviazione in un cluster Big Data sono membri di un cluster HDFS.
App Pool	Consente la distribuzione di applicazioni in un cluster Big Data fornendo interfacce per creare, gestire ed eseguire applicazioni.

Per altre informazioni su queste funzioni, vedere Introduzione ai cluster Big Data di SQL Server.

Opzioni di sostituzione delle funzionalità per Big Data e SQL Server

La funzione dati operativi facilitata da SQL Server all'interno dei cluster Big Data può essere sostituita da SQL Server in locale in una configurazione ibrida o tramite la piattaforma Microsoft Azure. Microsoft Azure offre una scelta di database relazionali, NoSQL e in memoria completamente gestiti, con motori proprietari e open source, per soddisfare le esigenze degli sviluppatori di app moderne. La gestione dell'infrastruttura, inclusa scalabilità, disponibilità e sicurezza, è automatizzata, consente di risparmiare tempo e denaro e consente di concentrarsi sulla creazione di applicazioni mentre i database gestiti da Azure semplificano il processo visualizzando informazioni dettagliate sulle prestazioni tramite intelligence incorporata, scalabilità senza limiti e gestione delle minacce alla sicurezza. Per altre informazioni, vedere Database di Azure.

Il punto decisionale successivo è costituito dalle posizioni di calcolo e archiviazione dei dati per l'analisi. Le due opzioni di architettura sono le distribuzioni nel cloud e ibride. È possibile eseguire la migrazione della maggior parte dei carichi di lavoro analitici alla piattaforma Microsoft Azure. I dati "nati nel cloud" (originati nelle applicazioni basate sul cloud) sono candidati principali per queste tecnologie e i servizi di spostamento dei dati possono eseguire la migrazione dei dati locali su larga scala in modo sicuro e rapido. Per altre informazioni sulle opzioni di spostamento dei dati, vedere Soluzioni di trasferimento dei dati.

Microsoft Azure dispone di sistemi e certificazioni che consentono l'elaborazione sicura dei dati e dei dati in vari strumenti. Per altre informazioni su queste certificazioni, vedere il Centro protezione.

Note

La piattaforma Microsoft Azure offre un livello molto elevato di sicurezza, più certificazioni per vari settori e rispetta la sovranità dei dati per i requisiti governativi. Microsoft Azure ha anche una piattaforma cloud dedicata per i carichi di lavoro per enti pubblici. La sicurezza da sola non deve essere il punto decisionale principale per i sistemi locali. È consigliabile valutare attentamente il livello di sicurezza fornito da Microsoft Azure prima di decidere di conservare le soluzioni Big Data in locale.

Nell'opzione architettura nel cloud tutti i componenti si trovano in Microsoft Azure. La responsabilità è costituita dai dati e dal codice creati per l'archiviazione e l'elaborazione dei carichi di lavoro. Queste opzioni sono descritte in modo più dettagliato in questo articolo.

Questa opzione è ideale per un'ampia gamma di componenti per l'archiviazione e l'elaborazione dei dati e quando si vuole concentrarsi sui costrutti di dati ed elaborazione anziché sull'infrastruttura.

Nelle opzioni di architettura ibrida alcuni componenti vengono conservati in locale e altri vengono inseriti in un provider di servizi cloud. La connettività tra i due è progettata per un miglior posizionamento dell'elaborazione dei dati.

Questa opzione funziona al meglio quando si ha un notevole investimento in tecnologie e architetture locali, ma si desidera usare le offerte di Microsoft Azure o quando si dispone di destinazioni di elaborazione e applicazione che risiedono in locale o per un pubblico mondiale.

Per altre informazioni sulla creazione di architetture scalabili, vedere Creare un sistema scalabile per dati di grandi dimensioni.

In-cloud

Azure SQL con Synapse

È possibile sostituire la funzionalità dei cluster Big Data di SQL Server usando una o più opzioni di database SQL di Azure per i dati operativi e Microsoft Azure Synapse per i carichi di lavoro analitici.

Microsoft Azure Synapse è un servizio di analisi aziendale che accelera il tempo per ottenere informazioni dettagliate tra data warehouse e sistemi Big Data, usando costrutti di elaborazione e dati distribuiti. Azure Synapse riunisce tecnologie SQL usate nel data warehousing aziendale, tecnologie Spark usate per Big Data, Pipeline per l'integrazione dei dati e ETL/ELT e un'integrazione approfondita con altri servizi di Azure, ad esempio Power BI, Cosmos DB e Azure Machine Learning.

Usare Microsoft Azure Synapse come sostituzione per i cluster Big Data di SQL Server 2019 quando è necessario:

Usare sia i modelli di risorse serverless sia quelli dedicati. Per prestazioni e costi prevedibili, creare pool SQL dedicati per riservare la potenza di elaborazione per i dati archiviati in tabelle SQL.
Elaborare carichi di lavoro non pianificati o "burst", accedere a un endpoint SQL serverless sempre disponibile.
Usare le funzionalità di streaming predefinite per trasferire i dati dalle origini dati cloud alle tabelle SQL.
Integrare l'intelligenza artificiale con SQL usando i modelli di Machine Learning per assegnare punteggi ai dati usando la funzione T-SQL PREDICT.
Usare modelli di Machine Learning con algoritmi SparkML e integrazione di Azure Machine Learning per Apache Spark 2.4 supportato per Linux Foundation Delta Lake.
Usare un modello di risorse semplificato che consente di evitare di doversi preoccupare della gestione dei cluster.
Elaborare i dati che richiedono l'avvio rapido di Spark e la scalabilità automatica aggressiva.
Elaborare i dati using.NET per Spark, consentendo di riutilizzare le competenze di C# e il codice .NET esistente all'interno di un'applicazione Spark.
Lavorare con tabelle definite nei file del data lake, consumate senza soluzione di continuità da Spark o Hive.
Usare SQL con Spark per esplorare e analizzare direttamente i file Parquet, CSV, TSV e JSON archiviati in un data lake.
Abilitare il caricamento rapido e scalabile dei dati tra database SQL e Spark.
Inserire dati da più di 90 origini dati.
Abilitare l'ETL "Senza codice" con le attività flusso di dati.
Orchestrare notebook di lavoro, processi Spark, procedure memorizzate, script SQL e altro ancora.
Monitorare le risorse, l'utilizzo e gli utenti in SQL e Spark.
Usare il controllo degli accessi in base al ruolo per semplificare l'accesso alle risorse di analisi.
Scrivere codice SQL o Spark e integrarsi con processi CI/CD aziendali.

L'architettura di Microsoft Azure Synapse è la seguente:

Per altre informazioni su Microsoft Azure Synapse, vedere Che cos'è Azure Synapse Analytics?

Azure SQL più Azure Machine Learning

È possibile sostituire la funzionalità dei cluster Big Data di SQL Server usando una o più opzioni di database SQL di Azure per i dati operativi e Microsoft Azure Machine Learning per i carichi di lavoro predittivi.

Azure Machine Learning è un servizio basato sul cloud che può essere usato per qualsiasi tipo di Machine Learning, dal machine learning classico all'apprendimento avanzato, supervisionato e non supervisionato. Sia che si preferisca scrivere codice Python o R con l'SDK o usare opzioni senza codice/basso codice nello studio, è possibile compilare, eseguire il training e tenere traccia di modelli di Machine Learning e Deep Learning in un'area di lavoro di Azure Machine Learning. Con Azure Machine Learning, è possibile avviare il training sulla macchina locale e quindi scalare nel cloud. Il servizio interagisce anche con gli strumenti open source più diffusi di Deep Learning e apprendimento per rinforzo, ad esempio PyTorch, TensorFlow, scikit-learn e Ray RLlib.

Usare Microsoft Azure Machine Learning come sostituzione per i cluster Big Data di SQL Server 2019 quando necessario:

Un ambiente web progettato per il Machine Learning: moduli drag-and-drop per creare i tuoi esperimenti e quindi distribuire pipeline in un ambiente low-code.
Notebook di Jupyter: usare i notebook di esempio o creare notebook personalizzati per usare gli esempi sdk per Python per l'apprendimento automatico.
Script R o notebook in cui si usa l'SDK per R per scrivere codice personalizzato o usare i moduli R nella finestra di progettazione.
L'acceleratore di soluzioni molti modelli si basa su Azure Machine Learning e consente di eseguire il training, il funzionamento e gestire centinaia o persino migliaia di modelli di Machine Learning.
Le estensioni di Machine Learning per Visual Studio Code (anteprima) offrono un ambiente di sviluppo completo per la creazione e la gestione dei progetti di Machine Learning.
Un'interfaccia di apprendimento automatico Command-Line (CLI), Azure Machine Learning include un'estensione CLI di Azure che fornisce comandi per la gestione delle risorse di Azure Machine Learning dalla riga di comando.
Integrazione con framework open source come PyTorch, TensorFlow e scikit-learn e molti altri ancora per il training, la distribuzione e la gestione del processo di Machine Learning end-to-end.
Apprendimento per rinforzo con Ray RLlib.
MLflow per tenere traccia delle metriche e distribuire modelli o Kubeflow per compilare pipeline di flusso di lavoro end-to-end.

L'architettura di una distribuzione di Microsoft Azure Machine Learning è la seguente:

Diagramma che mostra l'architettura di Azure Machine Learning di un'area di lavoro e i relativi componenti.

Per altre informazioni su Microsoft Azure Machine Learning, vedere Funzionamento di Azure Machine Learning.

SQL di Azure in Databricks

È possibile sostituire la funzionalità dei cluster Big Data di SQL Server usando una o più opzioni di database SQL di Azure per i dati operativi e Microsoft Azure Databricks per i carichi di lavoro analitici.

Azure Databricks è una piattaforma di analisi dei dati ottimizzata per la piattaforma di servizi cloud di Microsoft Azure. Azure Databricks offre due ambienti per lo sviluppo di applicazioni a elevato utilizzo di dati: Analisi SQL di Azure Databricks e Area di lavoro di Azure Databricks.

Analisi SQL di Azure Databricks offre una piattaforma facile da usare per gli analisti che vogliono eseguire query SQL nel data lake, creare più tipi di visualizzazione per esplorare i risultati delle query da prospettive diverse e creare e condividere dashboard.

L'area di lavoro di Azure Databricks offre un'area di lavoro interattiva che consente la collaborazione tra data engineer, data scientist e ingegneri di Machine Learning. Per una pipeline di Big Data, i dati (non elaborati o strutturati) vengono inseriti in Azure tramite Azure Data Factory in batch o trasmessi quasi in tempo reale usando Apache Kafka, Hub eventi o hub IoT. Questi dati vengono inseriti in un data lake per un'archiviazione persistente a lungo termine, in Archiviazione Azure Blob o Archiviazione Azure Data Lake. Come parte del flusso di lavoro di analisi, usare Azure Databricks per leggere i dati da più origini dati e trasformarli in informazioni dettagliate innovative usando Spark.

Usare Microsoft Azure Databricks come sostituzione per i cluster Big Data di SQL Server 2019 quando necessario:

Cluster completamente gestiti di Spark con Spark SQL e DataFrames.
Streaming per l'elaborazione e l'analisi dei dati in tempo reale per applicazioni analitiche e interattive, integrazione con HDFS, Flume e Kafka.
Accesso alla libreria MLlib, costituito da algoritmi di apprendimento comuni e utilità, tra cui classificazione, regressione, clustering, filtro collaborativo, riduzione della dimensionalità e primitive di ottimizzazione sottostanti.
Documentare il tuo stato di avanzamento nei notebook in R, Python, Scala o SQL.
Visualizzazione dei dati in pochi passaggi, usando strumenti familiari come Matplotlib, ggplot o d3.
Dashboard interattivi per creare report dinamici.
GraphX, per grafici e calcoli a grafo per un ampio ambito di casi d'uso, dall'analisi cognitiva all'esplorazione dei dati.
Creazione di cluster in pochi secondi, con cluster con scalabilità automatica dinamica, condividendoli tra i team.
Accesso a cluster a livello di codice tramite le API REST.
Accesso immediato alle funzionalità più recenti di Apache Spark con ogni versione.
UN'API Spark Core: include il supporto per R, SQL, Python, Scala e Java.
Un'area di lavoro interattiva per l'esplorazione e la visualizzazione.
Endpoint SQL completamente gestiti nel cloud.
Query SQL eseguite su endpoint SQL completamente gestiti ridimensionati in base alla latenza di query e al numero di utenti simultanei.
Integrazione con Microsoft Entra ID (in precedenza Azure Active Directory).
Accesso basato sui ruoli per autorizzazioni utente con granularità fine per notebook, cluster, processi e dati.
Enterprise-grade SLAs.
Dashboard per condividere informazioni dettagliate, combinando visualizzazioni e testo per condividere informazioni dettagliate estratte dalle query.
Gli avvisi consentono di monitorare e integrare e notificare quando un campo restituito da una query soddisfa una soglia. Usare gli avvisi per monitorare l'attività aziendale o integrarli con strumenti per avviare flussi di lavoro come l'onboarding dell'utente o i ticket di supporto.
Sicurezza aziendale, tra cui integrazione di Microsoft Entra ID, controlli basati sui ruoli e contratti di servizio che proteggono i dati e l'azienda.
Integrazione con i servizi di Azure e i database di Azure e archivi, tra cui Synapse Analytics, Cosmos DB, Data Lake Store e archiviazione BLOB.
Integrazione con Power BI e altri strumenti di business intelligence, ad esempio Tableau Software.

L'architettura di una distribuzione di Microsoft Azure Databricks è la seguente:

Diagramma: architettura di un'area di lavoro di Azure Databricks e dei relativi componenti e flussi di dati, dalle persone alle applicazioni.

Per altre informazioni su Microsoft Azure Databricks, vedere Che cos'è Databricks Data Science & Engineering?

Hybrid

Database con mirroring del tessuto

Come esperienza di replica dei dati, il mirroring del database in Fabric è una soluzione a basso costo e a bassa latenza per riunire i dati da vari sistemi in una singola piattaforma di analisi. È possibile replicare continuamente il patrimonio di dati esistente direttamente in OneLake di Fabric, inclusi i dati del database SQL di Azure, Snowflake e Cosmos DB.

Con i dati più aggiornati in un formato interrogabile in OneLake, è ora possibile usare tutti i diversi servizi in Fabric, ad esempio l'esecuzione di analisi con Spark, l'esecuzione di notebook, l'ingegneria dei dati, la visualizzazione tramite report di Power BI e altro ancora.

Il mirroring in Fabric offre un'esperienza semplice per accelerare il tempo di ottenimento di informazioni e decisioni, ed eliminare i silos di dati tra le soluzioni tecnologiche, senza sviluppare costosi processi ETL (Extract, Transform e Load) per spostare i dati.

Con Mirroring in Fabric, non è necessario assemblare diversi servizi da più fornitori. Invece, è possibile usufruire di un prodotto end-to-end altamente integrato e facile da usare, progettato per semplificare le esigenze di analisi e creato per l'apertura e la collaborazione tra soluzioni tecnologiche in grado di leggere il formato di tabella Delta Lake open source.

Per altre informazioni, vedere:

Utilizzare SQL Server 2022 con Azure Synapse Link per SQL

SQL Server 2022 (16.x) contiene una nuova funzionalità che consente la connettività tra le tabelle di SQL Server e la piattaforma Microsoft Azure Synapse, collegamento ad Azure Synapse per SQL. Collegamento ad Azure Synapse per SQL Server 2022 (16.x) fornisce feed di modifiche automatici che acquisiscono le modifiche all'interno di SQL Server e le caricano in Azure Synapse Analytics. Fornisce un'analisi quasi in tempo reale e l'elaborazione transazionale e analitica ibrida con un impatto minimo sui sistemi operativi. Una volta che i dati si trovano in Synapse, è possibile combinarlo con molte origini dati diverse indipendentemente dalle dimensioni, dalla scalabilità o dal formato e dall'esecuzione di analisi avanzate in tutti i dati usando la scelta di Azure Machine Learning, Spark o Power BI. Poiché i feed di modifiche automatizzati esecedono solo il push di ciò che è nuovo o diverso, il trasferimento dei dati avviene molto più velocemente e ora consente informazioni dettagliate quasi in tempo reale, con un impatto minimo sulle prestazioni del database di origine in SQL Server 2022 (16.x).

Per i carichi di lavoro analitici operativi e anche per gran parte dei carichi di lavoro analitici, SQL Server può gestire dimensioni elevate del database. Per altre informazioni sulle specifiche di capacità massima per SQL Server, vedere Limiti di capacità di calcolo per edizione di SQL Server. L'uso di più istanze di SQL Server in computer separati con richieste T-SQL partizionate consente un ambiente con scalabilità orizzontale per le applicazioni.

L'uso di PolyBase consente all'istanza di SQL Server di eseguire query sui dati con T-SQL direttamente da SQL Server, Oracle, Teradata, MongoDB e Cosmos DB senza installare separatamente il software di connessione client. È anche possibile usare il connettore ODBC generico in un'istanza basata su Microsoft Windows per connettersi a provider aggiuntivi usando driver ODBC di terze parti. PolyBase consente alle query T-SQL di unire i dati da origini esterne a tabelle relazionali in un'istanza di SQL Server. Ciò consente ai dati di rimanere nella posizione e nel formato originali. È possibile virtualizzare i dati esterni tramite l'istanza di SQL Server, in modo che sia possibile eseguire query sul posto come qualsiasi altra tabella in SQL Server. SQL Server 2022 (16.x) consente anche query ad hoc e backup/ripristino su Object-Store (usando le opzioni di archiviazione hardware o software S3-API).

Due architetture di riferimento generali sono l'uso di SQL Server in un server autonomo per query di dati strutturate e un'installazione separata di un sistema non relazionale con scalabilità orizzontale (ad esempio Apache Hadoop o Apache Spark) per il collegamento locale a Synapse e l'altra opzione consiste nell'usare un set di contenitori in un cluster Kubernetes con tutti i componenti per la soluzione.

Microsoft SQL Server in Windows, Apache Spark e archiviazione oggetti in locale

È possibile installare SQL Server in Windows o Linux e aumentare le prestazioni dell'architettura hardware usando la funzionalità di query di archiviazione oggetti di SQL Server 2022 (16.x) e polyBase per abilitare le query su tutti i dati nel sistema.

L'installazione e la configurazione di una piattaforma con scalabilità orizzontale, ad esempio Apache Hadoop o Apache Spark, consente di eseguire query su dati non relazionali su larga scala. L'uso di un set centrale di sistemi Object-Storage che supportano l'S3-API consente sia a SQL Server 2022 (16.x) che a Spark di accedere allo stesso set di dati in tutti i sistemi.

Il connettore Microsoft Apache Spark per SQL Server e AZURE SQL offre anche la possibilità di eseguire query sui dati direttamente da SQL Server usando processi Spark. Per altre informazioni sul connettore Apache Spark per SQL Server e Azure SQL, vedere Connettore Apache Spark: SQL Server & Azure SQL.

È anche possibile usare il sistema di orchestrazione dei contenitori Kubernetes per la distribuzione. Ciò consente un'architettura dichiarativa che può essere eseguita in locale o in qualsiasi cloud che supporta Kubernetes o la piattaforma Red Hat OpenShift. Per altre informazioni sulla distribuzione di SQL Server in un ambiente Kubernetes, vedere Distribuire un cluster di contenitori di SQL Server in Azure o vedere Distribuzione di SQL Server 2019 in Kubernetes.

Usare SQL Server e Hadoop/Spark in locale come sostituzione per i cluster Big Data di SQL Server 2019 quando è necessario:

Mantenere l'intera soluzione in locale
Usare hardware dedicato per tutte le parti della soluzione
Accedere ai dati relazionali e non relazionali dalla stessa architettura, in entrambe le direzioni
Condividere un singolo set di dati non relazionali tra SQL Server e il sistema non relazionale con scalabilità orizzontale

Eseguire la migrazione

Dopo aver selezionato un percorso (In-Cloud o Ibrido) per la migrazione, è necessario valutare i vettori di tempo di inattività e costo per determinare se si esegue un nuovo sistema e si spostano i dati dal sistema precedente alla nuova migrazione in tempo reale (migrazione side-by-side) o un backup e ripristino oppure un nuovo avvio del sistema da origini dati esistenti (migrazione sul posto).

La decisione successiva consiste nel riscrivere le funzionalità correnti nel sistema usando la nuova scelta dell'architettura o spostare la maggior parte del codice possibile nel nuovo sistema. Anche se la scelta precedente può richiedere più tempo, consente di usare i nuovi metodi, concetti e vantaggi offerti dalla nuova architettura. In tal caso, le mappe di accesso ai dati e funzionalità sono le principali attività di pianificazione su cui concentrarsi.

Se si prevede di eseguire la migrazione del sistema corrente con il minor numero possibile di modifiche al codice, la compatibilità del linguaggio è l'obiettivo principale per la pianificazione.

Code migration

Il passaggio successivo consiste nel controllare il codice usato dal sistema corrente e le modifiche necessarie per l'esecuzione nel nuovo ambiente.

Esistono due vettori principali per la migrazione del codice da considerare:

Origini e destinazioni
Functionality migration

Origini e destinazioni

La prima attività di migrazione del codice consiste nell'identificare i metodi di connessione, le stringhe o le API dell'origine dati usati dal codice per accedere ai dati importati, al relativo percorso e alla destinazione finale. Documentare queste fonti e creare una mappa delle posizioni della nuova architettura.

Se la soluzione corrente usa un sistema pipeline per spostare i dati nel sistema, eseguire il mapping delle nuove sorgenti, passaggi e destinazioni dell'architettura nei componenti della pipeline.
Se la nuova soluzione sostituisce anche l'architettura della pipeline , considera il sistema come una nuova installazione a scopo di pianificazione, anche se stai riutilizzando l'hardware o la piattaforma cloud come sostituzione.

Functionality migration

Il lavoro più complesso necessario in una migrazione consiste nel fare riferimento, aggiornare o creare la documentazione delle funzionalità del sistema corrente. Se si pianifica un aggiornamento sul posto e si tenta di ridurre la quantità di riscrittura del codice il più possibile, questo passaggio richiede più tempo.

Tuttavia, una migrazione da una tecnologia precedente è spesso un momento ottimale per aggiornarsi sui progressi più recenti della tecnologia e sfruttare i costrutti forniti. Spesso è possibile ottenere maggiore sicurezza, prestazioni, scelte di funzionalità e persino ottimizzazioni dei costi tramite una riscrittura del sistema corrente.

In entrambi i casi, si hanno due fattori principali coinvolti nella migrazione: il codice e le lingue supportate dal nuovo sistema e le scelte relative allo spostamento dei dati. In genere, è necessario essere in grado di modificare le stringhe di connessione dal cluster Big Data corrente all'istanza di SQL Server e all'ambiente Spark. Le informazioni di connessione dati e il passaggio del codice devono essere ridotti al minimo.

Se si prevede una riscrittura delle funzionalità correnti, eseguire il mapping delle nuove librerie, pacchetti e DLL all'architettura scelta per la migrazione. È disponibile un elenco di ognuna delle librerie, dei linguaggi e delle funzioni offerte da ogni soluzione nei riferimenti alla documentazione illustrati nelle sezioni precedenti. Mappare qualsiasi linguaggio sospetto o non supportato e pianificare la sostituzione nell'architettura scelta.

Opzioni di migrazione dei dati

Esistono due approcci comuni per lo spostamento dei dati in un sistema analitico su larga scala. Il primo consiste nel creare un processo di "cutover" in cui il sistema originale continua a elaborare i dati, e dove i dati vengono aggregati in un set più piccolo di fonte dati di report aggregata. Il nuovo sistema inizia quindi con i dati aggiornati e viene usato dalla data di migrazione successiva.

In alcuni casi, tutti i dati devono passare dal sistema legacy al nuovo sistema. In questo caso, è possibile montare gli archivi file originali dai cluster Big Data di SQL Server se il nuovo sistema lo supporta e quindi copiare i dati in modo frammentario nel nuovo sistema oppure creare uno spostamento fisico.

La migrazione dei dati correnti da cluster Big Data di SQL Server 2019 a un altro sistema dipende da due fattori: la posizione dei dati correnti e la destinazione in locale o nel cloud.

Migrazione dei dati locali

Per le migrazioni locali a locali, è possibile eseguire la migrazione dei dati di SQL Server con una strategia di backup e ripristino oppure configurare la replica per spostare alcuni o tutti i dati relazionali. SQL Server Integration Services può essere usato anche per copiare dati da SQL Server a un'altra posizione. Per altre informazioni sullo spostamento dei dati con SSIS, vedere SQL Server Integration Services.

Per i dati HDFS nell'ambiente del cluster Big Data di SQL Server corrente, l'approccio standard consiste nel montare i dati in un cluster Spark autonomo e usare il processo di archiviazione oggetti per spostare i dati in modo che un'istanza di SQL Server 2022 (16.x) possa accedervi o lasciarli as-is e continuare a elaborarli con processi Spark.

Migrazione dei dati nel cloud

Per i dati che si trovano nell'archiviazione cloud o in locale, è possibile usare Azure Data Factory, che include più di 90 connettori per una pipeline completa di trasferimento, con pianificazione, monitoraggio, avvisi e altri servizi. Per altre informazioni su Azure Data Factory, vedere Che cos'è Azure Data Factory?

Se si vogliono spostare grandi quantità di dati in modo sicuro e rapido dall'ambiente dati locale a Microsoft Azure, è possibile usare il servizio Importazione/Esportazione di Azure. Il servizio Importazione/Esportazione di Azure viene usato per importare in modo sicuro grandi quantità di dati nell'archiviazione BLOB di Azure e in File di Azure tramite la spedizione di unità disco a un data center di Azure. È anche possibile usare questo servizio per trasferire i dati dall'archivio BLOB di Azure a unità disco per la spedizione al sito locale. È possibile importare dati da uno o più dischi nell'Archivio Blob di Azure o in File di Azure. Per grandi quantità di dati, l'uso di questo servizio può essere il percorso più veloce.

Per trasferire i dati usando unità disco fornite da Microsoft, è possibile usare Azure Data Box Disk per importare dati in Azure. Per altre informazioni, vedere Che cos'è il servizio Importazione/Esportazione di Azure?

Per altre informazioni su queste scelte e sulle decisioni che li accompagnano, vedere Uso di Azure Data Lake Storage Gen1 per i requisiti di Big Data.

Last updated on 2024-03-08

Condividi tramite