Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a: ✅ Armazém no Microsoft Fabric
Este artigo descreve métodos para migrar data warehousing em Azure Synapse Analytics pools SQL dedicados para Microsoft Fabric Data Warehouse.
Dica
Para obter mais informações sobre estratégia e planejamento de migração, consulte Planejamento de migração: pools de SQL dedicados do Azure Synapse Analytics para o Data Warehouse do Fabric.
Uma experiência automatizada para migração de pools de SQL dedicados do Azure Synapse Analytics está disponível usando 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 as informações de 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 posteriormente neste artigo, vinculado na coluna Opção.
| Número da opção | Opção | O que faz | Habilidade/preferência | Cenário |
|---|---|---|---|---|
| 1 | Fábrica de dados | Conversão de esquema (DDL) Extração de dados Ingestão de dados |
ADF/Pipeline | Esquema integrado simplificado (DDL) e migração de dados. Recomendado para tabelas de dimensões. |
| 2 | Data Factory com partição | Conversão de esquema (DDL) Extração de dados Ingestão de dados |
ADF/Pipeline | Usar opções de particionamento para aumentar o paralelismo de leitura/gravação fornecendo taxa de transferência de dez vezes versus a opção 1, recomendada para tabelas de fatos. |
| 3 | Data Factory com código acelerado | Conversão de esquema (DDL) | ADF/Pipeline | Converta e migre primeiro o esquema (DDL). Em seguida, utilize CETAS para extrair e COPY/Data Factory para ingerir dados, garantindo um desempenho geral ideal na ingestão. |
| 4 | Código acelerado de procedimentos armazenados | Conversão de esquema (DDL) Extração de dados Avaliação de códigos |
T-SQL | Usuário do SQL usando o IDE com controle mais granular sobre em quais tarefas deseja trabalhar. Utilize COPY/Data Factory para consumir dados. |
| 5 | Extensão do Projeto do Banco de Dados SQL para Visual Studio Code | Conversão de esquema (DDL) Extração de dados Avaliação de códigos |
Projeto SQL | Projeto de banco de dados SQL para implantação com a integração da opção 4. Use COPY ou Data Factory para ingerir dados. |
| 6 | CRIAR UMA TABELA EXTERNA COMO SELEÇÃO (CETAS) | Extração de dados | T-SQL | Extração de dados econômica e de alto desempenho no ADLS (Azure Data Lake Storage) Gen2. Utilize COPY/Data Factory para consumir dados. |
| 7 | Migrar usando dbt | Conversão de esquema (DDL) conversão de código de banco de dados (DML) |
dbt | Os usuários de dbt existentes podem usar o adaptador do dbt Fabric para converter seu DDL e DML. Em seguida, você deve migrar dados usando outras opções nesta tabela. |
Escolha a carga de trabalho para a migração inicial
Ao decidir por onde começar no pool dedicado SQL do Synapse para Fabric Data Warehouse projeto de migração, escolha uma área de carga de trabalho onde você possa:
- Comprove a viabilidade da migração para Fabric Data Warehouse entregando rapidamente os benefícios do novo ambiente. Comece pequeno e simples, e prepare-se para múltiplas migrações pequenas.
- Dê um tempo para que sua equipe técnica interna ganhe experiência relevante com os processos e as ferramentas que eles usarão ao migrar para outras áreas.
- Crie um modelo específico para o ambiente do Synapse de origem para futuras migrações, bem como as ferramentas e processos em vigor para auxiliar.
Dica
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 de SQL dedicados ou cargas de trabalho.
O volume de dados migrados em uma migração inicial deve ser grande o suficiente para demonstrar as capacidades e benefícios do ambiente Fabric Data Warehouse, mas não grande demais para demonstrar valor rapidamente. Um tamanho entre 1 e 10 terabytes é típico.
Migração com o Data Factory do Fabric
Nesta seção, discutimos as opções usando o Data Factory para perfis de baixo código/sem código que estejam familiarizados com o Azure Data Factory e o Synapse Pipeline. Essa opção de arrastar e soltar da interface do usuário fornece uma etapa simples para converter o DDL e migrar os dados.
O Data Factory Fabric pode executar as seguintes tarefas:
- Converta o esquema (DDL) para Fabric Data Warehouse sintaxe.
- Crie o esquema (DDL) em Fabric Data Warehouse.
- Migre os dados para Fabric Data Warehouse.
Opção 1. Migração de esquemas/dados – Assistente de Copy e atividade de cópia ForEach
Esse método usa o assistente Data Factory Copy para conectar ao pool SQL dedicado de origem, converter a sintaxe DDL do pool dedicado para Fabric e copiar dados para Fabric Data Warehouse. Você pode selecionar uma ou mais tabelas de destino (para o conjunto de dados TPC-DS há 22 tabelas). Ele gera o ForEach para fazer o loop pela lista de tabelas selecionadas na interface do usuário e gerar 22 threads paralelos da atividade de Copy.
- 22 consultas SELECT (uma para cada tabela selecionada) foram geradas e executadas no pool de SQL dedicado.
- Verifique se você tem o DWU e a classe de recurso apropriados para permitir que as consultas geradas sejam executadas. Para esse caso, você precisa de um mínimo de DWU1000 com
staticrc10a fim de permitir que no máximo 32 consultas lidem com 22 consultas enviadas. - Copiar diretamente dados do pool SQL dedicado para Fabric Data Warehouse requer staging. O processo de ingestão consiste em duas fases.
- A primeira fase consiste em extrair os dados do pool de SQL dedicado para o ADLS e é chamada de processo de preparo.
- A segunda fase absorve os dados do staging para Fabric Data Warehouse. A maior parte do tempo de ingestão de dados está na fase de preparo. Em resumo, o processo de preparo tem um enorme impacto no desempenho da ingestão.
Uso recomendado
Usar o Copy Wizard para gerar um ForEach fornece uma interface simples para converter DDL e ingerir as tabelas selecionadas do pool SQL dedicado para Fabric Data Warehouse em uma única etapa.
No entanto, isso não é o ideal para a taxa de transferência geral. O requisito para usar o processo de preparo, a necessidade de paralelizar a leitura e gravação para a etapa "Origem para preparo" são os principais fatores para a latência de desempenho. É recomendável usar essa opção somente para tabelas de dimensão.
Opção 2. Migração de DDL/Dados – Pipeline usando a opção de partição
Para lidar com a melhoria da taxa de transferência para carregar tabelas de fatos maiores usando o pipeline do Fabric, é recomendável usar a Atividade de Cópia para cada tabela de fatos com a opção de partição. Isso proporciona o melhor desempenho com a atividade Copy.
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 mínimos/máximos 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.
Embora o uso da partição possa aumentar a taxa de transferência com a fase do processo de preparo, há considerações para fazer os ajustes apropriados:
- Dependendo do intervalo de partições, ele pode potencialmente usar todos os slots de simultaneidade, pois pode gerar mais de 128 consultas no pool de SQL dedicado.
- É necessário dimensionar para um mínimo de DWU6000 a fim de permitir que todas as consultas sejam executadas.
- Por exemplo, para a tabela
web_salesdo TPC-DS, 163 consultas foram enviadas para o pool de SQL dedicado. Em DWU6000, 128 consultas foram executadas, enquanto 35 consultas foram enfileiradas. - A partição dinâmica seleciona automaticamente a partição por intervalo. Nesse caso, um intervalo de 11 dias para cada consulta SELECT enviada ao pool de 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')
Uso recomendado
Para tabelas de fatos, recomendamos usar o Data Factory com a opção de particionamento para aumentar a taxa de transferência.
No entanto, o aumento das leituras paralelizadas exige que um pool SQL dedicado escale para um DWU mais alto para permitir a execução das consultas de extração. Ao aproveitar o particionamento, a taxa melhora dez vezes em relação a uma opção sem partição. Você pode aumentar o DWU para obter throughput adicional através de recursos de computação, mas o pool dedicado de SQL permite no máximo 128 consultas ativas.
Para obter mais informações sobre o mapeamento do Synapse DWU to Fabric, consulte Blog: Mapeando pools de SQL dedicados do Azure Synapse para a computação do Fabric Data Warehouse.
Opção 3. Migração de DDL – Assistente de Copy da Atividade de Copy ForEach
As duas opções anteriores são ótimas opções de migração de dados para bancos de dados menores. Porém, se você precisar de uma taxa de transferência mais alta, recomendamos uma opção alternativa:
- Extraia os dados do pool de SQL dedicado para o ADLS, mitigando, portanto, a sobrecarga de desempenho do preparo.
- Use o Data Factory ou o comando COPY para ingerir os dados no seu depósito.
Uso recomendado
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. Intencionalmente, isso migra o esquema e os dados em uma etapa, extraindo o esquema sem nenhuma linha, usando a condição false TOP 0 na instrução de consulta.
O código de exemplo 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 o Fabric Pipelines para migrar facilmente seus DDL (esquemas) para objetos de tabela de qualquer fonte Banco de Dados SQL do Azure ou pool SQL dedicado. Esse pipeline migra o esquema (DDL) para as tabelas de pool SQL dedicadas de origem para Fabric Data Warehouse.
Projeto da tubulação: parâmetros
Esse pipeline aceita um parâmetro SchemaName, que permite que você especifique quais esquemas migrar. O esquema dbo é 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.
Design do pipeline: atividade de pesquisa
Crie uma atividade de pesquisa e defina a conexão para apontar para o banco de dados de origem.
Na guia Configurações:
Defina o tipo de armazenamento de dados como externo.
Connection é seu pool de SQL dedicado do Azure Synapse. O tipo de conexão é Azure Synapse Analytics.
Usar consulta é definido como Consulta.
O campo Consulta precisa ser construído usando uma expressão dinâmica, permitindo que o parâmetro
SchemaNameseja usado em uma consulta que retorna uma lista de tabelas de origem alvo. 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 a fim de recuperar uma lista de esquemas e tabelas. Ele faz referência ao
SchemaNameparâmetro para permitir filtragem em esquemas SQL. A saída disso é uma matriz de tabelas e esquema SQL que serão usados 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'),') ')
Design do pipeline: loop ForEach
Para o loop ForEach, configure as seguintes opções na guia Configurações:
- Desabilite 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 snippet de código:
@activity('Get List of Source Objects').output.value
Design do pipeline: atividade de Copy no loop ForEach
Dentro da atividade ForEach, adicione uma atividade Copy. Esse método utiliza a Linguagem de Expressões Dinâmicas dentro dos pipelines para construir um SELECT TOP 0 * FROM <TABLE> e migrar apenas o esquema sem dados para um warehouse.
Na guia Origem:
- Defina o tipo de armazenamento de dados como externo.
- Connection é seu pool de SQL dedicado do Azure Synapse. O tipo de conexão é Azure Synapse Analytics.
- Defina Usar Consulta como Consulta.
- No campo Consulta, cole na consulta de conteúdo dinâmico e use essa expressão que retornará zero linhas, somente o esquema de tabela:
@concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)
Na guia Destino:
- Defina o tipo de armazenamento de dados como espaço de trabalho.
- O tipo de armazenamento de dados do Workspace é Data Warehouse e o Data Warehouse é definido como o warehouse.
- O esquema e o nome da tabela de destino são definidos usando conteúdo dinâmico.
- Schema refere-se ao campo da iteração atual,
SchemaNamecom o trecho:@item().SchemaName - A tabela está referenciando TableName com o snippet:
@item().TableName
- Schema refere-se ao campo da iteração atual,
Design do pipeline: coletor
Para coletor, aponte para o Warehouse e faça referência ao nome de tabela e esquema de origem.
Depois de executar esse pipeline, você verá seu Data Warehouse preenchido com cada tabela da sua fonte, com o esquema de dados adequado.
Migração usando procedimentos armazenados no pool de SQL dedicado do Synapse
Essa opção usa procedimentos armazenados para executar a migração do Fabric.
Você pode obter os exemplos de código em microsoft/fabric-migration em GitHub.com. Esse código é compartilhado como software livre. Portanto, fique à vontade para contribuir para colaborar e ajudar a comunidade.
O que os procedimentos armazenados de migração podem fazer:
- Converta o esquema (DDL) para Fabric Data Warehouse sintaxe.
- Crie o esquema (DDL) em Fabric Data Warehouse.
- Extrair dados do pool de SQL dedicado do Synapse para o ADLS.
- Sinalizar sintaxe do Fabric sem suporte para códigos T-SQL (funções, exibições, procedimentos armazenados).
Uso recomendado
Essa é uma ótima opção para quem:
- Está familiarizado com o T-SQL.
- Deseja usar um ambiente de desenvolvimento integrado, como o SSMS (SQL Server Management Studio).
- Deseja um controle mais granular sobre em quais tarefas deseja 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 ou COPY INTO o Fabric Data Factory para ingerir os dados no seu depósito.
Migração usando o projeto de banco de dados SQL
Há suporte para o Microsoft Fabric Data Warehouse na extensão projetos do Banco de Dados SQL disponível dentro do Visual Studio Code.
Essa extensão está disponível no Visual Studio Code. Esse recurso permite recursos para controle do código-fonte, testes de bancos de dados e validação de esquema.
Para mais informações sobre controle de versão, veja Visão Geral de Desenvolvimento e Implantação.
Uso recomendado
Essa é uma ótima opção para quem prefere usar o projeto de banco de dados SQL para sua implantação. Essa opção essencialmente integrou os procedimentos armazenados de migração do Fabric ao 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) para Fabric Data Warehouse sintaxe.
- Crie o esquema (DDL) em Fabric Data Warehouse.
- Extrair dados do pool de 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ê então usará ou COPY INTO o Data Factory para ingerir os dados no seu depósito.
A equipe do Microsoft Fabric CAT forneceu um conjunto de scripts do PowerShell para lidar com a extração, criação e implantação de DDL (esquema) 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 de banco de dados SQL com nossos scripts úteis do PowerShell, consulte microsoft/fabric-migration em 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 crie um projeto de banco de dados a partir da linha de comando.
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 de SQL dedicados do Synapse para o ADLS (Azure Data Lake Storage) Gen2.
O que o CETAS pode fazer:
- Extrair dados para o ADLS.
- Essa opção exige que os usuários criem o esquema (DDL) no seu depósito antes de ingerir os dados. Considere as opções neste artigo para migrar o esquema (DDL).
As vantagens dessa opção são:
- Somente uma única consulta por tabela é enviada no pool de SQL dedicado do Synapse de origem. Isso não usará todos os slots de simultaneidade e, portanto, não bloqueará ETL/consultas simultâneas de produção do cliente.
- O dimensionamento para DWU6000 não é necessário, pois apenas um único slot de simultaneidade é usado para cada tabela, para que os clientes possam usar DWUs inferiores.
- O extrato é executado em paralelo em todos os nós de computação e essa é a chave para a melhoria do desempenho.
Uso recomendado
Use o CETAS para extrair os dados para o ADLS como arquivos Parquet. Os arquivos Parquet oferecem a vantagem de um armazenamento de dados eficiente com compactação em colunas, o que requererá menos largura de banda para transferência pela rede. Além disso, como o Fabric armazenou os dados como formato Delta Parquet, a ingestão de dados será 2,5x mais rápida em comparação com o formato de arquivo de texto, já que não há conversão para a sobrecarga do formato Delta durante a ingestão.
Para aumentar a capacidade de processamento do CETAS:
- Adicione operações CETAS paralelas, aumentando o uso de slots de simultaneidade, mas permitindo mais taxa de transferência.
- Escale o DWU no pool de SQL dedicado do Synapse.
Migração via dbt
Nesta seção, discutiremos a opção dbt para clientes que já estejam usando o dbt em seu ambiente de pool de SQL dedicado do Synapse atual.
O que o dbt pode fazer:
- Converta o esquema (DDL) para Fabric Data Warehouse sintaxe.
- Crie o esquema (DDL) em Fabric Data Warehouse.
- Converter código de banco de dados (DML) na sintaxe do Fabric.
A estrutura dbt gera DDL e DML (scripts SQL) em tempo real com 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.
Uso recomendado
A estrutura dbt é uma abordagem code-first. Os dados devem ser migrados usando as opções listadas neste documento, como CETAS ou COPY/Data Factory.
O adaptador dbt para Microsoft Fabric Data Warehouse permite que projetos DBT existentes que estavam direcionados a diferentes plataformas, como pools SQL dedicados Synapse, Snowflake, Databricks, Google Big Query ou Amazon Redshift, sejam migrados para um warehouse com uma simples mudança de configuração.
Para começar com um projeto de dbt Fabric Data Warehouse direcionado, veja o Tutorial: Configurar dbt para Fabric Data Warehouse. Este documento também lista uma opção para mover entre diferentes warehouses/plataformas.
Ingestão de dados em Fabric Data Warehouse
Para ingestão no Fabric Data Warehouse, use COPY INTO ou Fabric Data Factory, dependendo da 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 prerrequisito de que os arquivos já estão extraídos para o Azure Data Lake Storage (ADLS) Gen2.
Vários fatores a serem observados para que você possa projetar seu processo para o desempenho máximo:
- Com Fabric, não há contenção de recursos ao carregar várias tabelas do ADLS para Fabric Data Warehouse simultaneamente. Como resultado, não há degradação de desempenho ao carregar threads paralelos. A taxa de transferência máxima de ingestão será limitada apenas pelo poder de computação da capacidade do Fabric.
- O gerenciamento de carga de trabalho do Fabric fornece a 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.
Conteúdo relacionado
- Assistente de Migração do Fabric para Data Warehouse
- Criar um Armazém no Microsoft Fabric
- Diretrizes de desempenho do Data Warehouse do Fabric
- Segurança para armazenamento de dados no Microsoft Fabric.
- Blog: Mapeando pools de SQL dedicados do Azure Synapse para a computação do Fabric Data Warehouse
- Visão geral da migração do Microsoft Fabric