Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a: ✅ Magazzino in Microsoft Fabric
Questo articolo descrive metodi per migrare il data warehousing in Azure Synapse Analytics pool SQL dedicati a Microsoft Fabric Data Warehouse.
Suggerimento
Per altre informazioni sulla strategia e sulla pianificazione della migrazione, vedere Pianificazione della migrazione: Pool SQL dedicati di Azure Synapse Analytics nel Data Warehouse di Fabric.
Un'esperienza automatizzata per la migrazione da pool SQL dedicati di Azure Synapse Analytics è disponibile usando Fabric Migration Assistant per Data Warehouse. Il resto di questo articolo contiene altri passaggi di migrazione manuale.
Questa tabella riepiloga le informazioni per lo schema dei dati (DDL), il codice del database (DML) e i metodi di migrazione dei dati. Più avanti in questo articolo si espande ulteriormente ogni scenario, collegato nella colonna Opzione .
| Opzione Numero | Opzione | Funzione | Competenza/Preferenza | Sceneggiatura |
|---|---|---|---|---|
| 1 | Data Factory | Schema (DDL) conversione Estrazione dei dati Inserimento dati |
ADF/Pipeline | Tutto semplificato in uno schema (DDL) e migrazione dei dati. Consigliato per le tabelle delle dimensioni. |
| 2 | Fabbrica di dati con partizione | Schema (DDL) conversione Estrazione dei dati Inserimento dati |
ADF/Pipeline | Usando le opzioni di partizionamento per aumentare il parallelismo di lettura/scrittura, fornendo dieci volte la velocità effettiva rispetto all'opzione 1, consigliata per tabelle dei fatti. |
| 3 | Data Factory con codice accelerato | Schema (DDL) conversione | ADF/Pipeline | Convertire e migrare prima lo schema (DDL), quindi utilizzare CETAS per l'estrazione e COPY/Data Factory per l'ingestione dei dati per ottenere prestazioni complessive ottimali nell'inserimento. |
| 4 | Stored procedure che accelerano il codice | Schema (DDL) conversione Estrazione dei dati Valutazione del codice |
T-SQL | Utente SQL che usa l'IDE con un controllo più granulare su quali attività vogliono lavorare. Usare COPY/Data Factory per inserire i dati. |
| 5 | Estensione progetto di database SQL per Visual Studio Code | Schema (DDL) conversione Estrazione dei dati Valutazione del codice |
Progetto SQL | Progetto di database SQL per la distribuzione con l'integrazione dell'opzione 4. Usare COPY o Data Factory per inserire i dati. |
| 6 | CREA UNA TABELLA ESTERNA COME SELECT (CETAS) | Estrazione dei dati | T-SQL | Estrarre dati convenienti e ad alte prestazioni in Azure Data Lake Storage (ADLS) Gen2. Usare COPY/Data Factory per inserire i dati. |
| 7 | Eseguire la migrazione con dbt | Schema (DDL) conversione conversione del codice di database (DML) |
dbt | Gli utenti dbt esistenti possono usare l'adattatore dbt Fabric per convertire DDL e DML. È quindi necessario eseguire la migrazione dei dati usando altre opzioni in questa tabella. |
Scegliere un carico di lavoro per la migrazione iniziale
Quando decidi da dove iniziare con il pool SQL dedicato di Synapse per Fabric Data Warehouse progetto di migrazione, scegli un'area di carico di lavoro dove puoi:
- Dimostra la fattibilità della migrazione verso Fabric Data Warehouse offrendo rapidamente i benefici del nuovo ambiente. Inizia in modo semplice e semplice, e preparati a più piccole migrazioni.
- Concedere tempo al personale tecnico interno per acquisire esperienza pertinente con i processi e gli strumenti che usa per eseguire la migrazione ad altre aree.
- Creare un modello per altre migrazioni specifiche per l'ambiente Synapse di origine, e gli strumenti e i processi di aiuto già presenti.
Suggerimento
Creare un inventario degli oggetti di cui è necessario eseguire la migrazione e documentare il processo di migrazione dall'inizio alla fine, in modo che possa essere ripetuto per altri pool o carichi di lavoro SQL dedicati.
Il volume di dati migrati in una migrazione iniziale dovrebbe essere abbastanza grande da dimostrare le capacità e i benefici dell'ambiente Fabric Data Warehouse, ma non troppo grande per dimostrare rapidamente il valore. Una dimensione nell'intervallo da 1 a 10 terabyte è tipica.
Migrazione con Fabric Data Factory
In questa sezione vengono illustrate le opzioni che usano Data Factory per l'utente con poco codice o senza codice che ha familiarità con Azure Data Factory e Synapse Pipeline. Questa opzione di interfaccia utente di trascinamento fornisce un modo semplice per trasformare il DDL ed eseguire la migrazione dei dati.
Fabric Data Factory può eseguire le attività seguenti:
- Converti lo schema (DDL) in Fabric Data Warehouse sintassi.
- Crea lo schema (DDL) su Fabric Data Warehouse.
- Migra i dati su Fabric Data Warehouse.
Opzione 1. Migrazione di schemi/dati - Copia guidata e attività di copia ForEach
Questo metodo utilizza l'assistente Data Factory Copy per collegarsi al pool SQL dedicato di origine, convertire la sintassi DDL del pool SQL dedicato in Fabric e copiare i dati in Fabric Data Warehouse. È possibile selezionare una o più tabelle di destinazione (per il set di dati TPC-DS sono presenti 22 tabelle). Genera il ciclo ForEach per scorrere l'elenco di tabelle selezionate nell'interfaccia utente e generare 22 thread di attività di copia parallela.
- Le 22 query SELECT (una per ogni tabella selezionata) sono state generate ed eseguite nel pool SQL dedicato.
- Assicurarsi di disporre della classe DWU e della risorsa appropriata per consentire l'esecuzione delle query generate. Per questo caso, è necessario un minimo di DWU1000 con
staticrc10per consentire un massimo di 32 query per gestire 22 query inviate. - Data Factory copiando direttamente i dati dal pool SQL dedicato a Fabric Data Warehouse richiede uno staging. Il processo di ingestione è composto da due fasi.
- La prima fase consiste nell'estrarre i dati dal pool SQL dedicato in ADLS e viene definito staging.
- La seconda fase assimila i dati dello staging in Fabric Data Warehouse. La maggior parte dei tempi di inserimento dei dati è nella fase di preparazione. In sintesi, la fase di staging ha un impatto enorme sulle prestazioni di ingestione.
Uso consigliato
Utilizzare il Copy Wizard per generare un ForEach fornisce un'interfaccia utente semplice per convertire DDL e integrare le tabelle selezionate dal pool SQL dedicato in Fabric Data Warehouse un unico passaggio.
Tuttavia, non è ottimale per le prestazioni complessive. Il requisito di usare la messa in scena, la necessità di parallelizzare la lettura e la scrittura per il passaggio "Origine-Stage" sono i fattori principali che contribuiscono alla latenza delle prestazioni. È consigliabile usare questa opzione solo per le tabelle delle dimensioni.
Opzione 2. Migrazione DDL/Dati - Pipeline utilizzando l'opzione di partizionamento
Per migliorare la capacità di trasmissione per caricare tabelle dei fatti di dimensioni maggiori usando la pipeline di Fabric, è consigliabile usare l'attività di copia per ogni tabella dei fatti con l'opzione di partizione. Questo fornisce prestazioni ottimali con l'attività di copia.
È possibile usare il partizionamento fisico della tabella di origine, se disponibile. Se la tabella non dispone del partizionamento fisico, è necessario specificare la colonna della partizione e specificare valori min/max per usare il partizionamento dinamico. Nello screenshot seguente le opzioni Origine pipeline specificano un intervallo dinamico di partizioni in base alla ws_sold_date_sk colonna.
Anche se l'uso della partizione può aumentare la velocità effettiva con la fase di gestione temporanea, esistono alcune considerazioni per apportare le modifiche appropriate:
- A seconda dell'intervallo di partizioni, potrebbe potenzialmente usare tutti gli slot di concorrenza perché potrebbe generare più di 128 query nel pool SQL dedicato.
- È necessario scalare a un minimo di DWU6000 per consentire l'esecuzione di tutte le query.
- Ad esempio, per la tabella TPC-DS
web_salessono state inviate 163 query al pool SQL dedicato. Alla DWU6000, sono state eseguite 128 query mentre ne sono state messe in coda 35. - La partizione dinamica seleziona automaticamente la partizione di intervallo. In questo caso, un intervallo di 11 giorni per ogni query SELECT inviata al pool SQL dedicato. Per esempio:
WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080') ... WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')
Uso consigliato
Per le tabelle dei fatti, è consigliabile usare Data Factory con l'opzione di partizionamento per aumentare la velocità effettiva.
Tuttavia, l'aumento delle letture parallelizzate richiede che un pool SQL dedicato si scali a DWU più elevati per permettere l'esecuzione delle query di estrazione. Sfruttando la partizionazione, il tasso migliora di dieci volte rispetto a un'opzione senza partizione. Puoi aumentare la DWU per ottenere un throughput aggiuntivo tramite risorse di calcolo, ma il pool SQL dedicato ha un massimo di 128 query attive consentite.
Per altre informazioni sul mapping tra Synapse DWU e Infrastruttura, vedere Blog: Mapping dei pool SQL dedicati di Azure Synapse al calcolo di Fabric Data Warehouse.
Opzione 3. Migrazione DDL - Procedura guidata per ogni attività di copia
Le due opzioni precedenti sono opzioni di migrazione dei dati ideali per i database più piccoli. Tuttavia, se è necessaria una velocità effettiva più elevata, è consigliabile usare un'opzione alternativa:
- Estrarre i dati dal pool SQL dedicato ad ADLS, riducendo quindi il sovraccarico delle prestazioni del processo.
- Usa o Data Factory o il comando COPY per inserire i dati nel tuo warehouse.
Uso consigliato
È possibile continuare a usare Data Factory per convertire lo schema (DDL). Usando la Copia guidata è possibile selezionare la tabella specifica o Tutte le tabelle. Per impostazione predefinita, esegue la migrazione dello schema e dei dati in un unico passaggio, estraendo lo schema senza righe, usando la condizione false, TOP 0 nell'istruzione di query.
L'esempio di codice seguente illustra la migrazione dello schema (DDL) con Data Factory.
Esempio di codice: migrazione dello schema (DDL) con Data Factory
Puoi usare Fabric Pipelines per migrare facilmente i tuoi DDL (schemi) per oggetti tabelle da qualsiasi database SQL di Azure o pool SQL dedicato. Questa pipeline migra lo schema (DDL) per le tabelle di pool SQL dedicate al Fabric Data Warehouse.
Progettazione della pipeline: parametri
Questa pipeline accetta un parametro SchemaName, che consente di specificare gli schemi di cui eseguire la migrazione. Lo schema dbo è l'impostazione predefinita.
Nel campo Valore predefinito, immettere un elenco delimitato da virgole dello schema di tabella che indica gli schemi di cui eseguire la migrazione: 'dbo','tpch' per fornire due schemi, dbo e tpch.
Progettazione della pipeline: attività di ricerca
Creare un'attività di ricerca e impostare la Connessione per puntare al database di origine.
Nella scheda Impostazioni:
Impostare Tipo di archivio dati su Esterno.
Connessione è il tuo pool SQL dedicato di Azure Synapse. Il tipo di connessione è Azure Synapse Analytics.
"L'uso della query è impostato su Query."
Il campo Query deve essere costruito utilizzando un'espressione dinamica, permettendo di utilizzare il parametro
SchemaNamein una query che restituisce una lista di tabelle sorgente di destinazione. Selezionare Query e quindi Aggiungi contenuto dinamico.Questa espressione all'interno dell'attività LookUp genera un'istruzione SQL per eseguire query sulle viste di sistema per recuperare un elenco di schemi e tabelle. Fa riferimento al
SchemaNameparametro per permettere il filtraggio sugli schemi SQL. Il suo output è una matrice di tabelle e schema SQL che verranno usate come input nell'attività ForEach.Usare il codice seguente per restituire un elenco di tutte le tabelle utente con il nome dello schema.
@concat(' SELECT s.name AS SchemaName, t.name AS TableName FROM sys.tables AS t INNER JOIN sys.schemas AS s ON t.type = ''U'' AND s.schema_id = t.schema_id AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),') ')
Pipeline design: Ciclo ForEach
Per il ciclo ForEach, configurare le opzioni seguenti nella scheda Impostazioni:
- Disabilitare Sequenziale per consentire l'esecuzione simultanea di più iterazioni.
- Imposta Batch count su
50, limitando il numero massimo di iterazioni simultanee. - Il campo Items deve usare il contenuto dinamico per fare riferimento all'output dell'attività LookUp. Usare il frammento di codice seguente:
@activity('Get List of Source Objects').output.value
Progettazione della pipeline: attività di copia all'interno del ciclo ForEach
All'interno dell'attività ForEach, aggiungi un'attività di copia. Questo metodo utilizza il Dynamic Expression Language all'interno delle pipeline per costruire un SELECT TOP 0 * FROM <TABLE> modo per migrare solo lo schema senza dati in un warehouse.
Nella scheda Origine:
- Impostare Tipo di archivio dati su Esterno.
- Connessione è il tuo pool SQL dedicato di Azure Synapse. Il tipo di connessione è Azure Synapse Analytics.
- Impostare Usa query su Query.
- Nel campo Query, incollare la query di contenuto dinamico e utilizzare questa espressione che restituirà zero righe, solo lo schema della tabella:
@concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)
Nella scheda Destinazione:
- Impostare Tipo di archivio dati su Area di lavoro.
- Il tipo di data store di Workspace è Data Warehouse e il Data Warehouse è impostato come il warehouse.
- Lo schema e il nome della tabella di destinazione vengono definiti usando il contenuto dinamico.
- Schema si riferisce al campo dell'iterazione corrente,
SchemaNamecon il frammento:@item().SchemaName - La tabella fa riferimento a TableName con il frammento di codice:
@item().TableName
- Schema si riferisce al campo dell'iterazione corrente,
Progettazione della pipeline: Destinazione
Per la Destinazione, punta al tuo Magazzino e fai riferimento allo Schema sorgente e al Nome della tabella.
Dopo aver eseguito questa pipeline, vedrai il tuo Data Warehouse popolato con ogni tabella della tua origine con lo schema appropriato.
Migrazione tramite stored procedure nel pool SQL dedicato di Synapse
Questa opzione utilizza le stored procedure per eseguire la migrazione del Fabric.
È possibile ottenere gli esempi di codice in microsoft/fabric-migration in GitHub.com. Questo codice viene condiviso come open source, quindi è possibile contribuire a collaborare e aiutare la community.
Cosa possono fare le Stored Procedures di Migrazione:
- Converti lo schema (DDL) in Fabric Data Warehouse sintassi.
- Crea lo schema (DDL) su Fabric Data Warehouse.
- Estrarre dati dal pool SQL dedicato di Synapse ad ADLS.
- Segnalare la sintassi Fabric non supportata per i codici T-SQL (stored procedure, funzioni, viste).
Uso consigliato
Questa è un'ottima opzione per coloro che:
- Hanno familiarità con T-SQL.
- Vogliono usare un ambiente di sviluppo integrato, ad esempio SQL Server Management Studio (SSMS).
- Vogliono un controllo più granulare sulle attività su cui si vuole lavorare.
Puoi eseguire la procedura memorizzata specifica per la conversione dello schema (DDL), l'estrazione dati o la valutazione del codice T-SQL.
Per la migrazione dei dati, devi usare o COPY INTO Fabric Data Factory per inserire i dati nel tuo warehouse.
Eseguire la migrazione tramite progetti di database SQL
Microsoft Fabric Data Warehouse è supportato nell'estensione Progetti di database SQL disponibile all'interno di Visual Studio Code.
Questa estensione è disponibile in Visual Studio Code. Questa funzionalità abilita le funzionalità per il controllo del codice sorgente, il test del database e la convalida dello schema.
Per ulteriori informazioni sul controllo del sorgente, vedi panoramica dello sviluppo e del deployment.
Uso consigliato
Questa è un'ottima opzione per coloro che preferiscono usare database SQL Project per la distribuzione. Questa opzione ha integrato essenzialmente le stored procedure di migrazione di Fabric nel progetto database SQL per offrire un'esperienza di migrazione fluida.
Un progetto database SQL può:
- Converti lo schema (DDL) in Fabric Data Warehouse sintassi.
- Crea lo schema (DDL) su Fabric Data Warehouse.
- Estrarre dati dal pool SQL dedicato di Synapse ad ADLS.
- Segnala la sintassi non supportata per i codici T-SQL (procedure memorizzate, funzioni, viste).
Per la migrazione dei dati, userai quindi o COPY INTO Data Factory per inserire i dati nel tuo warehouse.
Il team cat di Microsoft Fabric ha fornito un set di script di PowerShell per gestire l'estrazione, la creazione e la distribuzione dello schema (DDL) e del codice del database (DML) tramite un progetto di database SQL. Per una procedura dettagliata sull'uso del progetto database SQL con gli script di PowerShell utili, vedere microsoft/fabric-migration su GitHub.com.
Per altre informazioni sui progetti di database SQL, vedere Introduzione all'estensione Progetti di database SQL e Compilare un progetto di database dalla riga di comando.
Migrazione dei dati con CETAS
Il comando T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) fornisce il metodo più conveniente e ottimale per estrarre i dati dai pool SQL dedicati di Synapse ad Azure Data Lake Storage (ADLS) Gen2.
Cosa può fare CETAS:
- Estrarre dati in ADLS.
- Questa opzione richiede agli utenti di creare lo schema (DDL) nel proprio warehouse prima di assumere i dati. Considerare le opzioni di questo articolo per migrare lo schema (DDL).
I vantaggi di questa opzione sono:
- Viene inviata solo una singola query per tabella nel pool SQL dedicato di Synapse di origine. Questo non userà tutti gli slot di concorrenza e quindi non bloccherà le operazioni ETL/queries di produzione dei clienti eseguite simultaneamente.
- Il ridimensionamento a DWU6000 non è necessario, perché per ogni tabella viene usato un solo slot di concorrenza, in modo che i clienti possano usare DWU inferiori.
- L'estrazione viene eseguita in parallelo in tutti i nodi di calcolo e questa è la chiave per il miglioramento delle prestazioni.
Uso consigliato
Usare CETAS per estrarre i dati su ADLS in formato Parquet. I file Parquet offrono il vantaggio di un'efficiente archiviazione dei dati con compressione a colonne che richiederà meno larghezza di banda per spostarsi attraverso la rete. Inoltre, poiché Fabric ha archiviato i dati nel formato Parquet Delta, l'inserimento dei dati sarà 2,5 volte più veloce rispetto al formato di file di testo, poiché non richiede alcuna conversione al formato Delta durante l'inserimento.
Per aumentare la velocità effettiva CETAS:
- Aggiungere operazioni CETAS parallele, aumentando l'uso di slot di concorrenza, ma consentendo una maggiore capacità di elaborazione.
- Ridimensionare la DWU nel pool SQL dedicato di Synapse.
Migrazione tramite dbt
In questa sezione viene descritta l'opzione dbt per i clienti che usano già dbt nell'ambiente del pool SQL dedicato di Synapse corrente.
Operazioni che dbt può eseguire:
- Converti lo schema (DDL) in Fabric Data Warehouse sintassi.
- Crea lo schema (DDL) su Fabric Data Warehouse.
- Convertire il codice del database (DML) nella sintassi di Fabric.
Il framework dbt genera DDL e DML (script SQL) in tempo reale con ogni esecuzione. Con i file di modello espressi nelle istruzioni SELECT, il DDL/DML può essere convertito immediatamente in qualsiasi piattaforma di destinazione modificando il profilo (stringa di connessione) e il tipo di adattatore.
Uso consigliato
Il framework dbt è un approccio code-first. È necessario eseguire la migrazione dei dati usando le opzioni elencate in questo documento, ad esempio CETAS o COPY/Data Factory.
L'adattatore DBT per Microsoft Fabric Data Warehouse consente ai progetti DBT esistenti che miravano a diverse piattaforme come pool SQL dedicati Synapse, Snowflake, Databricks, Google Big Query o Amazon Redshift di essere migrati in un warehouse con una semplice modifica di configurazione.
Per iniziare con un progetto dbt targeting Fabric Data Warehouse, vedi Tutorial: Configura dbt per Fabric Data Warehouse. Questo documento elenca anche un'opzione per spostarsi tra magazzini/piattaforme diversi.
Ingestione dei dati in Fabric Data Warehouse
Per l'ingestione in Fabric Data Warehouse, usa COPY INTO o Fabric Data Factory, a seconda delle tue preferenze. Entrambi i metodi sono le opzioni consigliate e migliori, poiché hanno una velocità effettiva delle prestazioni equivalente, dato il prerequisito che i file sono già estratti in Azure Data Lake Storage (ADLS) Gen2.
Diversi fattori da notare per poter progettare il processo per ottenere prestazioni massime:
- Con Fabric, non c'è alcuna contesa di risorse quando si caricano più tabelle da ADLS a Fabric Data Warehouse contemporaneamente. Di conseguenza, non si verifica alcuna riduzione delle prestazioni durante il caricamento di thread paralleli. La velocità massima di ingestione sarà limitata solo dalla potenza di calcolo della tua capacità Fabric.
- La gestione del carico di lavoro del fabric offre la separazione delle risorse allocate per il carico di lavoro e le interrogazioni. Non esiste alcuna contesa di risorse mentre le query e il caricamento dei dati vengono eseguiti contemporaneamente.
Contenuto correlato
- Assistente alla Migrazione di Fabric per Magazzino Dati
- Crea un magazzino in Microsoft Fabric
- Linee guida sulle prestazioni di Fabric Data Warehouse
- Sicurezza per il data warehouse in Microsoft Fabric
- Blog: Mapping dei pool SQL dedicati di Azure Synapse alla computazione di Fabric Data Warehouse
- Panoramica della migrazione di Microsoft Fabric