Partilhar via


Métodos de migração para pools SQL dedicados do Azure Synapse Analytics para o Fabric Data Warehouse

Aplica-se para:✅ Armazém no Microsoft Fabric

Este artigo detalha os métodos de migração de armazenamento de dados nos pools de SQL dedicados do Azure Synapse Analytics para o Warehouse do Microsoft Fabric.

Tip

Para obter mais informações sobre estratégia e planejamento de migração, consulte Planejamento de migração: pools SQL dedicados do Azure Synapse Analytics para o Fabric Data Warehouse.

Uma experiência automatizada para migração de pools SQL dedicados do Azure Synapse Analytics está disponível utilizando o Assistente de Migração do Fabric para Data Warehouse. O restante deste artigo contém mais etapas de migração manual.

Esta tabela resume informações para esquema de dados (DDL), código de banco de dados (DML) e métodos de migração de dados. Expandiremos ainda mais cada cenário mais adiante neste artigo, vinculado na coluna Opção .

Número da opção Opção O que faz Habilidade/Preferência Cenário
1 Data Factory Conversão do esquema (DDL)
Extração de dados
Ingestão de dados
ADF/Gasoduto Esquema integrado tudo-em-um simplificado (DDL) e migração de dados. Recomendado para tabelas de dimensões.
2 Data Factory com partição Conversão do esquema (DDL)
Extração de dados
Ingestão de dados
ADF/Gasoduto Usando opções de particionamento para aumentar o paralelismo de leitura/gravação, fornecendo dez vezes a taxa de transferência em comparação com a opção 1, recomendada para tabelas de fatos.
3 Data Factory com código otimizado Conversão do esquema (DDL) ADF/Gasoduto Converta e migre o esquema (DDL) primeiro, depois use o CETAS para extrair e o COPY/Data Factory para ingerir dados para um desempenho de ingestão geral ideal.
4 Procedimentos armazenados com código acelerado Conversão do esquema (DDL)
Extração de dados
Avaliação de código
T-SQL Utilizador SQL a usar uma IDE com um controlo mais detalhado sobre as tarefas em que deseja trabalhar. Utilize o COPY/Data Factory para ingerir dados.
5 Extensão SQL Database Project para Visual Studio Code Conversão do esquema (DDL)
Extração de dados
Avaliação de código
Projeto SQL Projeto de Banco de Dados SQL para implantação com a integração da opção 4. Utilize COPY ou o Data Factory para ingerir dados.
6 CRIAR TABELA EXTERNA COMO SELEÇÃO (CETAS) Extração de dados T-SQL Extração de dados de alto desempenho e custo-efetivo para o Azure Data Lake Storage (ADLS) Gen2. Utilize o COPY/Data Factory para ingerir dados.
7 Migrar usando dbt Conversão do esquema (DDL)
conversão de código de banco de dados (DML)
DBT Os usuários dbt existentes podem usar o adaptador dbt Fabric para converter suas DDL e DML. Em seguida, você deve migrar dados usando outras opções nesta tabela.

Escolha uma carga de trabalho para a migração inicial

Ao decidir por onde começar no pool SQL dedicado do Synapse para o projeto de migração do Fabric Warehouse, escolha uma área de carga de trabalho onde você possa:

  • Comprove a viabilidade da migração para o Fabric Warehouse oferecendo rapidamente os benefícios do novo ambiente. Comece pequeno e simples, prepare-se para várias pequenas migrações.
  • Permita que sua equipe técnica interna ganhe experiência relevante com os processos e ferramentas que eles usam quando migram para outras áreas.
  • Crie um modelo para migrações adicionais que seja específico para o ambiente Synapse de origem e as ferramentas e processos em vigor para ajudar.

Tip

Crie um inventário de objetos que precisam ser migrados e documente o processo de migração do início ao fim, para que ele possa ser repetido para outros pools SQL dedicados ou cargas de trabalho.

O volume de dados migrados em uma migração inicial deve ser grande o suficiente para demonstrar os recursos e benefícios do ambiente do Fabric Warehouse, mas não muito grande para demonstrar valor rapidamente. Um tamanho na faixa de 1-10 terabytes é típico.

Migração com o Fabric Data Factory

Nesta seção, discutimos as opções de utilização do Data Factory para utilizadores low-code/no-code que estejam familiarizados com o Azure Data Factory e o Synapse Pipeline. Esta opção de arrastar e soltar a interface do usuário fornece uma etapa simples para converter a DDL e migrar os dados.

O Fabric Data Factory pode executar as seguintes tarefas:

  • Converta o esquema (DDL) em sintaxe do Fabric Warehouse.
  • Criar o schema (DDL) no Fabric Warehouse.
  • Migre os dados para o Fabric Warehouse.

Opção 1. Migração de Esquema/Dados - Assistente de Cópia e Atividade de Cópia ForEach

Esse método usa o Assistente de Cópia do Data Factory para se conectar ao pool SQL dedicado de origem, converter a sintaxe DDL do pool SQL dedicado para Fabric e copiar dados para o Fabric Warehouse. Você pode selecionar uma ou mais tabelas de destino (para TPC-DS conjunto de dados há 22 tabelas). Gera o ForEach para percorrer a lista de tabelas selecionadas na interface do utilizador e lançar 22 threads de atividade de cópia em paralelo.

  • 22 consultas SELECT (uma para cada tabela selecionada) foram geradas e executadas no pool SQL dedicado.
  • Certifique-se de ter a DWU e a classe de recurso apropriadas para permitir que as consultas geradas sejam executadas. Para este caso, precisará de, no mínimo, DWU1000 com staticrc10 para permitir um máximo de 32 consultas, a fim de lidar com 22 consultas enviadas.
  • O Data Factory precisa de staging para copiar dados diretamente do pool SQL dedicado para o Fabric Warehouse. O processo de ingestão consistiu em duas fases.
    • A primeira fase consiste em extrair os dados do pool SQL dedicado para o ADLS e é chamada de preparação.
    • A segunda fase consiste em ingerir os dados do staging no Fabric Warehouse. A maior parte do tempo de ingestão de dados está na fase de preparação. Em resumo, a configuração tem um enorme impacto na eficiência da ingestão.

Usar o Assistente de Cópia para gerar um ForEach oferece uma interface de utilizador simples para converter DDL e importar as tabelas selecionadas do pool SQL dedicado no Fabric Warehouse num único passo.

No entanto, não é ideal no que diz respeito à taxa de transferência geral. A exigência de usar estágio intermediário e a necessidade de paralelizar a leitura e escrita na fase "Source to Stage" são os principais fatores para a latência de performance. Recomenda-se usar essa opção apenas para tabelas de dimensão.

Opção 2. DDL/Migração de dados - Pipeline usando a opção de partição

Para abordar a melhoria da largura de banda para carregar tabelas de factos maiores usando o pipeline do Fabric, é recomendável usar uma atividade de cópia para cada tabela de factos com a opção de partição. Isso proporciona o melhor desempenho com a atividade de Copiar.

Você tem a opção de usar o particionamento físico da tabela de origem, se disponível. Se a tabela não tiver particionamento físico, você deverá especificar a coluna de partição e fornecer valores min/max para usar o particionamento dinâmico. Na captura de tela a seguir, as opções de origem do pipeline estão especificando um intervalo dinâmico de partições com base na coluna ws_sold_date_sk.

Captura de tela de um pipeline, representando a opção para especificar a chave primária ou a data da coluna de partição dinâmica.

Embora o uso da partição possa aumentar a taxa de transferência com a fase de preparo, há considerações para fazer os ajustes apropriados:

  • Dependendo do seu intervalo de partições, ele pode potencialmente usar todos os slots de simultaneidade, pois pode gerar mais de 128 consultas no pool SQL dedicado.
  • É necessário dimensionar para um mínimo de DWU6000 para permitir que todas as consultas sejam executadas.
  • Por exemplo, para a tabela TPC-DS web_sales , 163 consultas foram enviadas ao pool SQL dedicado. Em DWU6000, 128 consultas foram executadas enquanto 35 consultas estavam na fila.
  • O particionamento dinâmico seleciona automaticamente a partição de intervalo. Nesse caso, um intervalo de 11 dias para cada consulta SELECT enviada ao pool SQL dedicado. Por exemplo:
    WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080')
    ...
    WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')
    

Para tabelas de fatos, recomendamos o uso do Data Factory com a opção de particionamento para aumentar a taxa de transferência.

No entanto, o aumento das leituras paralelizadas requer que o pool SQL dedicado seja dimensionado para DWU mais alto para permitir que as consultas de extração sejam executadas. Aproveitando o particionamento, a taxa é melhorada dez vezes em relação a uma opção sem partição. Você pode aumentar a DWU para obter uma taxa de transferência adicional por meio de recursos de computação, mas o pool SQL dedicado tem um máximo de 128 consultas ativas permitidas.

Para obter mais informações sobre o mapeamento Synapse DWU para Fabric, consulte Blog: Mapeando pools SQL dedicados do Azure Synapse para a computação do data warehouse Fabric.

Opção 3. Migração DDL - Assistente de cópia para cada atividade de cópia

As duas opções anteriores são ótimas opções de migração de dados para bancos de dados menores . Mas se você precisar de uma taxa de transferência mais alta, recomendamos uma opção alternativa:

  1. Extraia os dados do pool SQL dedicado para o ADLS, reduzindo assim a sobrecarga de desempenho no processamento.
  2. Use o comando Data Factory ou COPY para ingerir os dados no Fabric Warehouse.

Você pode continuar a usar o Data Factory para converter seu esquema (DDL). Usando o Assistente de Cópia, você pode selecionar a tabela específica ou Todas as tabelas. Por design, isso migra o esquema e os dados em uma etapa, extraindo o esquema sem linhas, usando a condição false, TOP 0 na instrução query.

O exemplo de código a seguir aborda a migração de esquema (DDL) com o Data Factory.

Exemplo de código: migração de esquema (DDL) com o Data Factory

Você pode usar Pipelines do Azure Data Factory para migrar facilmente seus DDL (esquemas) para os objetos de tabela de qualquer Banco de Dados SQL do Azure de origem ou pool SQL dedicado. Esse pipeline migra pelo esquema (DDL) das tabelas de pool SQL dedicadas de origem para o Fabric Warehouse.

Captura de ecrã do Fabric Data Factory mostrando um objeto Lookup que leva a um For Each Object. Dentro do For Each Object, há atividades para migrar DDL.

Projeto de tubulação: parâmetros

Este pipeline aceita um parâmetro SchemaName, que permite especificar quais esquemas devem ser migrados. O dbo esquema é o padrão.

No campo Valor padrão, insira uma lista delimitada por vírgulas do esquema de tabela indicando quais esquemas migrar: 'dbo','tpch' para fornecer dois esquemas dbo e tpch.

Screenshot da Data Factory mostrando o separador Parâmetros de um Pipeline. No campo Nome, 'SchemaName'. No campo de valor padrão, 'dbo', 'tpch', indicando que estes dois esquemas devem ser migrados.

Design do pipeline: atividade de consulta

Crie uma Atividade de Pesquisa e defina a Conexão para apontar para o banco de dados de origem.

Na guia Configurações:

  • Defina Tipo de armazenamento de dados como Externo.

  • Conexão é o pool SQL dedicado do Azure Synapse. O tipo de conexão é o Azure Synapse Analytics.

  • A opção Usar consulta está definida como Consulta.

  • O campo Consulta precisa ser criado usando uma expressão dinâmica, permitindo que o parâmetro SchemaName seja usado em uma consulta que retorna uma lista de tabelas de origem de destino. Selecione Consulta e, em seguida, selecione Adicionar conteúdo dinâmico.

    Essa expressão dentro da Atividade de Pesquisa gera uma instrução SQL para consultar as exibições do sistema para recuperar uma lista de esquemas e tabelas. Faz referência ao parâmetro SchemaName para permitir a filtragem em esquemas SQL. A saída disso é uma matriz de esquema SQL e tabelas que serão usadas como entrada na atividade ForEach.

    Use o código a seguir para retornar uma lista de todas as tabelas de usuário com seu nome de esquema.

    @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'),')
    ')
    

Captura de ecrã na Data Factory a mostrar o separador Definições de um pipeline. O botão 'Consulta' é selecionado e o código é colado no campo 'Consulta'.

Design de pipeline: "ForEach Loop"

Para o ForEach Loop, configure as seguintes opções na guia Configurações :

  • Desative Sequencial para permitir que várias iterações sejam executadas simultaneamente.
  • Defina Contagem de lotes como 50, limitando o número máximo de iterações simultâneas.
  • O campo Itens precisa usar conteúdo dinâmico para fazer referência à saída da Atividade de Pesquisa. Use o seguinte trecho de código: @activity('Get List of Source Objects').output.value

Captura de ecrã mostrando a guia de configurações da Atividade de Loop ForEach.

Design do pipeline: atividade de cópia dentro do ciclo ForEach

Dentro da Atividade ForEach, adicione uma Atividade de cópia. Esse método usa a Dynamic Expression Language dentro de pipelines para criar um SELECT TOP 0 * FROM <TABLE> para migrar somente o esquema sem dados para um Fabric Warehouse.

Na guia Origem:

  • Defina Tipo de armazenamento de dados como Externo.
  • Conexão é o pool SQL dedicado do Azure Synapse. O tipo de conexão é o Azure Synapse Analytics.
  • Defina Utilizar Consulta como Consulta.
  • No campo Consulta, cole na consulta de conteúdo dinâmico e use esta expressão que retornará zero linhas, somente o esquema da tabela:@concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

Captura de ecrã do Data Factory mostrando o separador Origem da atividade de cópia dentro do Loop ForEach.

Na guia Destino:

  • Defina Tipo de armazenamento de dados como Espaço de trabalho.
  • O tipo de armazenamento de dados do Espaço de Trabalho é Data Warehouse e o Data Warehouse é definido como Fabric Warehouse.
  • O esquema da tabela de destino e o nome da tabela são definidos usando conteúdo dinâmico.
    • Schema refere-se ao campo da iteração atual, SchemaName com o trecho: @item().SchemaName
    • A tabela está a referenciar TableName com o fragmento: @item().TableName

Captura de ecrã do Data Factory mostrando o separador Destino da Atividade de Cópia dentro de cada Ciclo ForEach.

Projeto de tubulação: Pia

Para Sink, aponte para o seu armazém e utilize como referência o esquema de origem e o nome da tabela.

Depois de executar este pipeline, verá o seu Data Warehouse preenchido com cada tabela na sua fonte de dados, com o esquema adequado.

Migração usando procedimentos armazenados no pool SQL dedicado Synapse

Essa opção usa procedimentos armazenados para executar a migração de malha.

Você pode obter os exemplos de código em microsoft/fabric-migration no GitHub.com. Este código é compartilhado como código aberto, então sinta-se à vontade para contribuir para colaborar e ajudar a comunidade.

O que os procedimentos de migração armazenados podem fazer:

  • Converta o esquema (DDL) em sintaxe do Fabric Warehouse.
  • Criar o schema (DDL) no Fabric Warehouse.
  • Extraia dados do pool SQL dedicado do Synapse para o ADLS.
  • Sinalizar sintaxe de malha sem suporte para códigos T-SQL (procedimentos armazenados, funções, exibições).

Esta é uma ótima opção para quem:

  • Estão familiarizados com T-SQL.
  • Deseja usar um ambiente de desenvolvimento integrado, como o SQL Server Management Studio (SSMS).
  • Querem um controle mais granular sobre quais tarefas eles querem trabalhar.

Você pode executar o procedimento armazenado específico para a conversão de esquema (DDL), extração de dados ou avaliação de código T-SQL.

Para a migração de dados, você precisa usar COPY INTO ou Data Factory para ingerir os dados no Fabric Warehouse.

Migrar usando projetos de banco de dados SQL

O Microsoft Fabric Data Warehouse é suportado na extensão SQL Database Projects disponível dentro do Visual Studio Code.

Esta extensão está disponível dentro do Visual Studio Code. Esse recurso permite recursos para controle do código-fonte, teste de banco de dados e validação de esquema.

Para obter mais informações sobre o controlo de versões para armazéns no Microsoft Fabric, incluindo integração com o Git e pipelines de implantação, consulte Controlo de versões com Armazém de Dados.

Essa é uma ótima opção para aqueles que preferem usar o SQL Database Project para sua implantação. Essa opção essencialmente integrou os procedimentos armazenados de migração de malha no projeto de banco de dados SQL para fornecer uma experiência de migração perfeita.

Um projeto de banco de dados SQL pode:

  • Converta o esquema (DDL) em sintaxe do Fabric Warehouse.
  • Criar o schema (DDL) no Fabric Warehouse.
  • Extraia dados do pool SQL dedicado do Synapse para o ADLS.
  • Sinalizar sintaxe sem suporte para códigos T-SQL (procedimentos armazenados, funções, exibições).

Para a migração de dados, você usará COPY INTO ou Data Factory para ingerir os dados no Fabric Warehouse.

A equipe CAT do Microsoft Fabric forneceu um conjunto de scripts do PowerShell para lidar com a extração, criação e implantação de esquema (DDL) e código de banco de dados (DML) por meio de um projeto de banco de dados SQL. Para obter um passo a passo sobre como usar o projeto do Banco de dados SQL com nossos scripts úteis do PowerShell, consulte microsoft/fabric-migration on GitHub.com.

Para obter mais informações sobre projetos do Banco de dados SQL, consulte Introdução à extensão Projetos do Banco de dados SQL e Criar e publicar um projeto.

Migração de dados com o CETAS

O comando T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) fornece o método mais econômico e ideal para extrair dados de pools SQL dedicados Synapse para o Azure Data Lake Storage (ADLS) Gen2.

O que o CETAS pode fazer:

  • Extraia dados para ADLS.
    • Essa opção exige que os usuários criem o esquema (DDL) no Fabric Warehouse antes de ingerir os dados. Considere as opções neste artigo para migrar o esquema de base de dados (DDL).

As vantagens desta opção são:

  • Apenas uma única consulta por tabela é enviada em relação ao pool SQL dedicado Synapse de origem. Isso não usará todos os slots de concorrência e, portanto, não bloqueará a execução simultânea de ETL/consultas por clientes.
  • O dimensionamento para DWU6000 não é necessário, pois um só slot de simultaneidade é usado para cada tabela, o que significa que os clientes podem usar DWUs mais baixas.
  • A extração é executada em paralelo em todos os nós de computação, e esta é a chave para a melhoria do desempenho.

Utilize o CETAS para extrair dados para o ADLS como ficheiros Parquet. Os arquivos Parquet oferecem a vantagem de um armazenamento de dados eficiente com compactação colunar que requer menos largura de banda para ser transferido através da rede. Além disso, como o Fabric armazenou os dados no formato de parquet Delta, a ingestão de dados será 2,5 vezes mais rápida em comparação ao formato de ficheiro de texto, já que não há a sobrecarga de conversão para o formato Delta durante a ingestão.

Para aumentar o rendimento do CETAS:

  • Adicione operações CETAS paralelas, aumentando o uso de slots de simultaneidade, mas permitindo mais taxa de transferência.
  • Escalar o DWU no pool SQL dedicado do Synapse.

Migração via dbt

Nesta seção, discutimos a opção dbt para os clientes que já estão usando dbt em seu ambiente atual de pool SQL dedicado Synapse.

O que o dbt pode fazer:

  • Converta o esquema (DDL) em sintaxe do Fabric Warehouse.
  • Criar o schema (DDL) no Fabric Warehouse.
  • Converta o código do banco de dados (DML) em sintaxe de malha.

O framework dbt gera DDL e DML (scripts SQL) em tempo real a cada execução. Com arquivos de modelo expressos em instruções SELECT, o DDL/DML pode ser traduzido instantaneamente para qualquer plataforma de destino, alterando o perfil (cadeia de conexão) e o tipo de adaptador.

A estrutura dbt é uma abordagem de prioridade ao código. Os dados devem ser migrados usando as opções listadas neste documento, como CETAS ou COPY/Data Factory.

O adaptador dbt para o Microsoft Fabric Data Warehouse permite que os projetos dbt existentes destinados a diferentes plataformas, como pools SQL dedicados Synapse, Snowflake, Databricks, Google Big Query ou Amazon Redshift, sejam migrados para um Fabric Warehouse com uma simples alteração de configuração.

Para começar a usar um projeto dbt direcionado ao Fabric Warehouse, consulte Tutorial: Configurar o dbt para o Fabric Data Warehouse. Este documento também lista uma opção para mover entre diferentes armazéns / plataformas.

Ingestão de dados no Fabric Warehouse

Para realizar a ingestão no Fabric Warehouse, use COPY INTO ou o Fabric Data Factory, conforme sua preferência. Ambos os métodos são as opções recomendadas e de melhor desempenho, pois têm taxa de transferência de desempenho equivalente, dado o pré-requisito de que os arquivos já sejam extraídos para o Azure Data Lake Storage (ADLS) Gen2.

Vários fatores a serem observados para que você possa projetar seu processo para obter o máximo desempenho:

  • Com o Fabric, não há qualquer contenção de recursos ao carregar várias tabelas do ADLS para o Fabric Warehouse simultaneamente. Como resultado, não há degradação de desempenho ao carregar threads paralelos. A capacidade máxima de ingestão será limitada apenas pelo poder de computação da sua capacidade Fabric.
  • A gestão de carga de trabalho têxtil fornece separação de recursos alocados para carga e consulta. Não há contenção de recursos enquanto consultas e carregamento de dados são executados ao mesmo tempo.