Migração​: ​Pool de SQL dedicado do Azure Synapse Analytics

Aplica-se a:✅Warehouse no Microsoft Fabric

Este artigo detalha a estratégia, as considerações e os métodos de migração do armazenamento de dados nos pools de SQL dedicados do Azure Synapse Analytics para o Microsoft Fabric Warehouse.

Introdução à migração

Como a Microsoft introduziu o Microsoft Fabric, uma solução de análise de SaaS completa para empresas que oferece um conjunto abrangente de serviços, incluindo Data Factory, Engenharia de Dados, Data Warehousing, Ciência de Dados, Inteligência em Tempo Real e Power BI.

Este artigo se concentra nas opções de migração de esquema (DDL), migração de código de banco de dados (DML) e migração de dados. A Microsoft oferece várias opções e aqui discutimos cada opção em detalhes e fornecemos diretrizes sobre quais dessas opções você deve considerar para seu cenário. Este artigo usa o parâmetro de comparação do setor TPC-DS para ilustração e teste de desempenho. Seu resultado real pode variar dependendo de muitos fatores, incluindo tipo de dados, tipos de dados, largura de tabelas, latência da fonte de dados etc.

Preparar para a migração

Planeje cuidadosamente seu projeto de migração antes de começar e verifique se o esquema, o código e os dados são compatíveis com o Fabric Warehouse. Há algumas limitações que você precisa considerar. Quantifique o trabalho de refatoração dos itens incompatíveis, bem como todos os outros recursos necessários antes da entrega da migração.

Outra meta importante do planejamento é ajustar o design para que a sua solução aproveite ao máximo o alto desempenho de consulta que o Fabric Warehouse oferece. O design de data warehouses para larga escala apresenta padrões de design diferentes. Portanto, as abordagens tradicionais nem sempre são as melhores. Examine as diretrizes de desempenho do Fabric Warehouse, pois, embora alguns ajustes de design possam ser feitos após a migração, fazer alterações anteriores no processo economizará tempo e esforço. A migração de uma tecnologia/ambiente para outro é sempre um grande esforço.

O diagrama a seguir mostra o Ciclo de Vida de Migração listando os principais pilares que consistem nos pilares Analisar e Avaliar, Planejar e Projetar, Migrar, Monitorar e Controlar, Otimizar e Modernizar com as tarefas associadas em cada pilar para planejar e se preparar para a migração tranquila.

Runbook para migração

Considere as seguintes atividades como um runbook de planejamento para a migração de pools de SQL dedicados do Synapse para o Fabric Warehouse.

1. Analisar e Avaliar
   1. Identifique objetivos e motivações. Estabeleça resultados claros desejados.
   2. Descoberta, avaliação e linha de base da arquitetura existente.
   3. Identifique os principais stakeholders e patrocinadores.
   4. Defina o escopo do que deve ser migrado.
      1. Comece pequeno e simples, prepare-se para várias migrações pequenas.
      2. Monitore e documente todas as fases do processo.
      3. Compilar o inventário de dados e processos para migração.
      4. Definir alterações de modelo de dados (se houver).
      5. Configure o espaço de trabalho do Fabric.
   5. Qual o seu conjunto de habilidades/preferência?
      1. Automatize sempre que possível.
      2. Use ferramentas e recursos internos do Azure para reduzir o esforço de migração.
   6. Treine a equipe antecipadamente na nova plataforma.
      1. Identifique as necessidades de qualificação e os ativos de treinamento, incluindo o Microsoft Learn.
2. Planejar e Projetar
   1. Defina a arquitetura desejada.
   2. Selecione o método/ferramentas para a migração para realizar as seguintes tarefas:
      1. Extração de dados da origem.
      2. Conversão de esquema (DDL), incluindo metadados para tabelas e exibições
      3. Ingestão de dados, incluindo dados históricos.
         1. Refaça a engenharia do modelo de dados, se preciso (usando o novo desempenho e a escalabilidade da plataforma).
      4. Migração de código de banco de dados (DML).
         1. Migre ou refatore os processos de negócios e procedimentos armazenados.
   3. Inventário e extração dos recursos de segurança e permissões de objeto da origem.
   4. Projete e planeje substituir/modificar processos ETL/ELT existentes para carga incremental.
      1. Crie processos ETL/ELT paralelos para o novo ambiente.
   5. Prepare um plano de migração detalhado.
      1. Mapeie o estado atual para o novo estado desejado.
3. Migrar
   1. Execute a migração de esquema, dados e código.
      1. Extração de dados da origem.
      2. Conversão de esquema (DDL)
      3. Ingestão de dados
      4. Migração de código de banco de dados (DML).
   2. Se necessário, dimensione temporariamente os recursos dedicados do pool de SQL para ajudar na velocidade de migração.
   3. Aplique segurança e permissões.
   4. Migre processos ETL/ELT existentes para carga incremental.
      1. Migre ou refatore os processos de carga incremental de ETL/ELT.
      2. Teste e compare processos de carga de incremento paralelos.
   5. Adapte o plano de migração de detalhes conforme necessário.
4. Monitorar e Controlar
   1. Execute em paralelo, compare com seu ambiente de origem.
      1. Teste aplicativos, plataformas de business intelligence e ferramentas de consulta.
      2. Crie um parâmetro de comparação e otimize o desempenho da consulta.
      3. Monitore e gerencie custo, segurança e desempenho.
   2. Parâmetro de comparação de governança e avaliação.
5. Otimizar e Modernizar
   1. Quando a empresa estiver confortável, faça a transição de aplicativos e das principais plataformas de relatórios para o Fabric.
      1. Dimensione os recursos para cima/para baixo à medida que a carga de trabalho se desloca do Azure Synapse Analytics para o Microsoft Fabric.
      2. Crie um modelo repetível com base na experiência obtida para migrações futuras. Itere.
      3. Identificar oportunidades de otimização de custos, segurança, escalabilidade e excelência operacional
      4. Identifique oportunidades para modernizar seu patrimônio de dados com os recursos mais recentes do Fabric.

"Lift-and-shift" ou modernizar?

Em geral, há dois tipos de cenários de migração independentemente da finalidade e do escopo planejado: lift-and-shift sem alterações e uma abordagem em fases que incorpora alterações arquitetônicas e de código.

Lift-and-shift

Em uma migração de lift-and-shift, um modelo de dados existente é migrado com pequenas alterações para o novo Fabric Warehouse. Essa abordagem minimiza o risco e o tempo de migração, reduzindo o novo trabalho necessário para alcançar os benefícios da migração.

A migração lift-and-shift é uma boa opção para estes cenários:

• Você tem um ambiente existente com um pequeno número de data marts para migrar.
• Você tem um ambiente existente com dados que já estão em um esquema estrela ou floco de neve bem projetado.
• Você está sob pressão de custo e tempo para se mudar para o Fabric Warehouse.

Em resumo, essa abordagem funciona bem para cargas de trabalho otimizadas com o ambiente atual de pools de SQL dedicados do Synapse e, portanto, não requer grandes alterações no Fabric.

Modernizar em uma abordagem em fases com alterações arquitetônicas

Se um data warehouse herdado estiver em evolução há um longo período, talvez seja necessário refazer sua engenharia para manter os níveis de desempenho necessários.

Talvez você também queira reprojetar a arquitetura para aproveitar os novos mecanismos e recursos disponíveis no espaço de trabalho do Fabric.

Diferenças de design: pools de SQL dedicados do Synapse e Fabric Warehouse

Considere as seguintes diferenças de armazenamento de dados do Azure Synapse e do Microsoft Fabric, comparando pools de SQL dedicados com o Fabric Warehouse.

Considerações sobre tabela

Ao migrar tabelas entre ambientes diferentes, normalmente só é possível migrar fisicamente dados brutos e os metadados. Outros elementos de banco de dados do sistema de origem, como índices, geralmente não são migrados porque podem ser desnecessários ou implementados de forma diferente no novo ambiente.

As otimizações de desempenho no ambiente de origem, como índices, indicam onde você pode adicionar otimização de desempenho em um novo ambiente, mas agora o Fabric cuida disso automaticamente para você.

Considerações do T-SQL

Há várias diferenças de sintaxe de DML (linguagem de manipulação de dados) a serem observadas. Consulte Área de superfície do T-SQL no Microsoft Fabric. Considere, também, uma avaliação de código ao escolher métodos de migração para o código de banco de dados (DML).

Dependendo das diferenças de paridade no momento da migração, talvez seja necessário reescrever partes do código DML do T-SQL.

Diferenças de mapeamento de tipo de dados

Há várias diferenças de tipo de dados no Fabric Warehouse. Para obter mais informações, consulte Tipos de dados no Microsoft Fabric.

A tabela a seguir fornece o mapeamento de tipos de dados com suporte de pools de SQL dedicados do Synapse para o Fabric Warehouse.

* Datetime2 não armazena as informações extra de deslocamento de fuso horário armazenadas. Como, atualmente, não há suporte para o tipo de dados datetimeoffset no Fabric Warehouse, os dados de deslocamento de fuso horário precisariam ser extraídos em uma coluna separada.

Métodos de migração de esquema, código e dados

Examine e identifique quais dessas opções se encaixam no seu cenário, conjuntos de habilidades da equipe e as características dos seus dados. As opções escolhidas dependerão da sua experiência, preferência e dos benefícios de cada uma das ferramentas. Nosso objetivo é continuar a desenvolver ferramentas de migração que reduzam o atrito e a intervenção manual para tornar essa experiência de migração perfeita.

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.

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

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

• Comprove a viabilidade da migração para o Fabric Warehouse por meio da entrega rápida de benefícios do novo ambiente. Comece pequeno e simples, prepare-se para várias 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 para migrações adicionais específicas para o ambiente do Synapse de origem e as ferramentas e processos em vigor para ajudar.

O volume de dados migrados em uma migração inicial deve ser grande o suficiente para demonstrar os recursos e benefícios do ambiente Fabric Warehouse, porém sem excesso, para uma demonstração rápida do seu valor. Um tamanho entre 1 e 10 terabytes é típico.

Migração com o Data Factory do Fabric

Nesta seção, discutiremos as opções usando o Data Factory para a persona de baixo código/sem código que esteja familiarizada com o Azure Data Factory e o Pipeline do Synapse. 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:

• Converter o esquema (DDL) na sintaxe do Fabric Warehouse.
• Criar o esquema (DDL) no Fabric Warehouse.
• Migrar os dados para o Fabric Warehouse.

Opção 1. Migração de esquemas/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 de SQL dedicado de origem, converter a sintaxe DDL do pool de SQL dedicado no Fabric e copiar dados para o Fabric 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 loop pela lista de tabelas selecionadas na interface do usuário e gerar 22 threads paralelos da atividade 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 staticrc10 a fim de permitir que no máximo 32 consultas lidem com 22 consultas enviadas.
• A cópia direta do Data Factory de dados do pool de SQL dedicado para o Fabric Warehouse requer um processo de preparo. O processo de ingestão consistia 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 consiste em ingerir os dados de preparo no Fabric 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 Assistente de Cópia para gerar um ForEach fornece uma interface do usuário simples para converter DDL e ingerir as tabelas selecionadas do pool de SQL dedicado para o Fabric Warehouse em uma etapa.

No entanto, ele não é ideal com 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 de dados 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 de dados do Fabric, é recomendável usar a atividade Copy para cada tabela de fatos com a opção de partição. Isso fornece 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 de dados 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_sales do 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 de 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, as leituras paralelizadas aumentadas exigem que o pool de SQL dedicado seja dimensionado para um DWU mais alto para permitir que as consultas de extração sejam executadas. Aproveitando o particionamento, a taxa é melhorada 10x em vez de nenhuma opção de partição. Você pode aumentar o DWU para obter taxa de transferência adicional por meio de recursos de computação, mas o pool de SQL dedicado tem uma permissão de um máximo de 128 consultas ativas.

Opção 3. Migração de DDL – Assistente de cópia da atividade de cópia 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:

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

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 pipelines de dados do Fabric para migrar facilmente seu DDL (esquemas) para objetos de tabela de qualquer banco de dados SQL do Azure de origem ou pool de SQL dedicado. Esse pipeline de dados migra pelo esquema (DDL) para as tabelas do pool de SQL dedicado de origem para o Fabric Warehouse.

Design do pipeline: parâmetros

Esse pipeline de dados aceita um parâmetro SchemaName, que permite especificar 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.

• A conexão é o 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 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 a fim de recuperar uma lista de esquemas e tabelas. Faz referência ao parâmetro SchemaName a fim de permitir a 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 Copy dentro do loop ForEach

Dentro da atividade ForEach, adicione uma atividade Copy. Esse método usa a linguagem de expressão dinâmica em pipelines de Dados para criar um SELECT TOP 0 * FROM <TABLE> para migrar apenas o esquema sem dados para um Fabric Warehouse.

Na guia Origem:

• Defina o tipo de armazenamento de dados como externo.
• A conexão é o pool de SQL dedicado do Azure Synapse. O tipo de conexão é Azure Synapse Analytics.
• Defina Usar Consulta para 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 espaço de trabalho é Data Warehouse e o Data Warehouse é definido como Fabric Warehouse.
• O esquema e o nome da tabela de destino são definidos usando conteúdo dinâmico.
  • O esquema se refere ao campo da iteração atual, SchemaName, com o snippet: @item().SchemaName
  • A tabela está referenciando TableName com o snippet: @item().TableName

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 em sua origem, com o esquema 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:

1. Converter o esquema (DDL) na sintaxe do Fabric Warehouse.
2. Criar o esquema (DDL) no Fabric Warehouse.
3. Extrair dados do pool de SQL dedicado do Synapse para o ADLS.
4. 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ê precisará usar COPY INTO ou Data Factory para ingerir os dados no Fabric Warehouse.

Migração usando o projeto de banco de dados SQL

O Data Warehouse do Microsoft Fabric agora é suportado na extensão de projetos de banco de dados SQL disponível dentro do Azure Data Studio e do Visual Studio Code.

Essa extensão está disponível no Azure Data Studio e 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 obter mais informações sobre o controle do código-fonte para warehouses no Microsoft Fabric, incluindo pipelines de integração e implantação do Git, consulte Controle do código-fonte com warehouse.

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:

1. Converter o esquema (DDL) na sintaxe do Fabric Warehouse.
2. Criar o esquema (DDL) no Fabric Warehouse.
3. Extrair dados do pool de SQL dedicado do Synapse para o ADLS.
4. 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.

Adicionando à capacidade de suporte do Azure Data Studio ao Fabric, a equipe de atendimento ao cliente 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 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 de banco de dados SQL, consulte Introdução à extensão de projetos de banco de dados SQL e Compilar 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 de SQL dedicados do Synapse para o ADLS (Azure Data Lake Storage) Gen2.

O que o CETAS pode fazer:

• Extrair dados no 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 (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 fornecem a vantagem de um armazenamento de dados eficiente com compactação vertical que levará menos largura de banda para se mover 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 taxa de transferência do CETAS:

• Adicione operações CETAS paralelas, aumentando o uso de slots de simultaneidade, mas permitindo mais taxa de transferência.
• Dimensione 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:

1. Converter o esquema (DDL) na sintaxe do Fabric Warehouse.
2. Criar o esquema (DDL) no Fabric Warehouse.
3. 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 o Data Warehouse do Synapse do Microsoft Fabric permite que os projetos dbt existentes direcionados a diferentes plataformas, como pools de SQL dedicados do 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 Data Warehouse do Fabric. Este documento também lista uma opção para mover entre diferentes warehouses/plataformas.

Ingestão de dados no Fabric Warehouse

Para ingestão no Fabric 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 o Fabric, não há nenhuma contenção de recursos ao carregar várias tabelas do ADLS para o Warehouse do Fabric simultaneamente. Como resultado, não há degradação do 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

• Criar um Warehouse no Microsoft Fabric
• Diretrizes de desempenho do Data Warehouse do Synapse no Microsoft Fabric
• Segurança para armazenamento de dados no Microsoft Fabric.
• Blog: Mapeando pools de SQL dedicados do Azure Synapse à computação de data warehouse do Fabric