Limitações nos bancos de dados espelhados do Snowflake no Microsoft Fabric

As limitações atuais nos bancos de dados espelhados do Snowflake no Microsoft Fabric estão listadas nesta página. Esta página está sujeita a alterações.

Limitações de conexão e autenticação

• A tabela a seguir lista quais métodos de autenticação têm suporte para espelhamento para Snowflake:

• Atualmente, não há suporte para a identidade do espaço de trabalho no espelhamento do Snowflake. Ele está disponível para fontes selecionadas, como SharePoint.

• A conectividade do Link Privado entre um workspace do Fabric e o Snowflake ainda não está disponível. Use um gateway de dados de rede virtual ou um gateway de dados local para conectividade privada nesse ínterim.

• Você deve adicionar destinatários de compartilhamento ao workspace. Para compartilhar um conjunto de dados ou relatório, primeiro adicione acesso ao espaço de trabalho com uma função de administrador, membro, leitor ou colaborador.

• Diferenciação de maiúsculas e minúsculas: todos os identificadores snowflake - incluindo nome do armazém, nome do banco de dados, nome do esquema, nomes de tabela e nomes de exibição - diferenciam maiúsculas de minúsculas ao configurar conexões de espelhamento e ao usar a API REST de espelhamento. A caixa inserida em Fabric deve corresponder exatamente ao que está configurado no Snowflake. Diferenças entre maiúsculas e minúsculas podem causar falhas de conexão ou fazer com que tabelas não apareçam para replicação, muitas vezes sem qualquer mensagem de erro descritiva. Por exemplo, se o seu warehouse do Snowflake se chama ANALYTICS_WH, você deve inserir ANALYTICS_WH na conexão do Fabric, não analytics_wh.

Tipos de objeto com suporte

• A tabela a seguir lista quais tipos de objeto Snowflake têm suporte para espelhamento:

Replicação e limitações de dados

• Se não houver atualizações em uma tabela de origem, o mecanismo do replicador começará a recuar com uma duração exponencialmente crescente para essa tabela, até uma hora. O mesmo poderá ocorrer se houver um erro transitório, impedindo a atualização de dados. O mecanismo do replicador retomará automaticamente a sondagem regular depois que os dados atualizados forem detectados.
• A hierarquia de esquema de origem é replicada para o banco de dados espelhado. Para bancos de dados espelhados criados antes desse recurso habilitado, o esquema de origem é nivelado e o nome do esquema é codificado no nome da tabela. Se você quiser reorganizar tabelas com esquemas, recrie o banco de dados espelhado. Saiba mais sobre Replicar a hierarquia do esquema de origem.
• O espelhamento dá suporte à replicação de colunas que contêm espaços ou caracteres especiais em nomes (como ,;{}()\n\t=). Para tabelas em replicação antes desse recurso habilitado, você precisa atualizar as configurações do banco de dados espelhado ou reiniciar o espelhamento para incluir essas colunas. Saiba mais sobre o Suporte ao mapeamento de colunas Delta.
• O número máximo de tabelas que podem ser espelhadas no Fabric é de 1.000 tabelas. Todas as tabelas acima do limite de 1000 atualmente não podem ser replicadas.
  • Se você selecionar Espelhar todos os dados ao configurar o Espelhamento, as tabelas a serem espelhadas serão determinadas usando as primeiras 1.000 tabelas quando todas as tabelas forem classificadas em ordem alfabética com base no nome do esquema e, em seguida, no nome da tabela. O conjunto restante de tabelas na parte inferior da lista alfabética não será espelhado.
  • Se você desmarcar Espelhar todos os dados e selecionar tabelas individuais, será impedido de selecionar mais de 1.000 tabelas.
• Colunas calculadas e tabelas calculadas: bancos de dados espelhados são somente para leitura. Você não pode criar colunas calculadas ou tabelas calculadas diretamente em um banco de dados espelhado. Para adicionar colunas calculadas, crie um Lakehouse e use atalhos para referenciar os dados espelhados; depois, crie suas colunas calculadas no Lakehouse usando notebooks ou SQL.

Limitações de desempenho

• Se você estiver alterando a maioria dos dados em uma tabela grande, será mais eficiente parar e reiniciar o Espelhamento. Inserir ou atualizar bilhões de registros pode levar muito tempo.
• Algumas alterações de esquema não são refletidas imediatamente. Algumas alterações de esquema precisam de uma alteração de dados (inserir, atualizar ou excluir) antes que as alterações de esquema sejam replicadas para Fabric.
• Considerações entre regiões: se a instância snowflake e a capacidade de Fabric estiverem em diferentes regiões de nuvem, você poderá experimentar maior latência de replicação e encargos de saída de dados. Para obter um desempenho ideal e evitar custos de saída entre regiões, implante sua capacidade de Fabric na mesma região de nuvem que a instância do Snowflake. Se a implantação entre regiões for inevitável, considere as taxas de saída adicionais de Snowflake e/ou Azure. Consulte a documentação de saída do Snowflake para obter detalhes.
• Ao espelhar dados do Snowflake para o OneLake de um cliente, o processo normalmente realiza estágios de dados por meio de uma URL embutida para melhorar o desempenho. Se o parâmetro no nível da conta do Snowflake PREVENT_UNLOAD_TO_INLINE_URL for definido como true, o seguinte comportamento se aplicará:

Resolução planejada: o suporte à integração de armazenamento está em desenvolvimento e fornecerá um caminho alternativo de staging que funciona quando PREVENT_UNLOAD_TO_INLINE_URL está definido como true. Essa solução desbloqueia cenários de VNet e OPDG. Verifique esta página se há atualizações sobre a disponibilidade.

• Comportamento da reinicialização: Uma reinicialização é uma recarga completa dos dados de uma tabela inteira. Ao contrário da sincronização incremental (que processa apenas linhas alteradas), uma relançada relança e grava novamente todos os dados na tabela. Reseeds podem gerar custos significativos de computação do Snowflake, especialmente em tabelas grandes.
  • O que aciona uma nova semeadura:

• Práticas recomendadas para evitar ressemeaduras desnecessárias:
  • Agendar alterações de esquema fora do espelhamento ativo. Se você usar o DBT ou outras ferramentas de gerenciamento de esquema, agende-as durante as janelas de manutenção ou pause o espelhamento antes de executar alterações de esquema.
  • Evite alterações frequentes de DDL. Consolide as alterações de esquema em menos lotes maiores em vez de fazer alterações incrementais ao longo do dia.
  • Monitore ressemeaduras inesperadas. Na página Status de Espelhamento, fique atento às tabelas que exibem repetidamente o comportamento de cópia inicial. Se uma tabela grande estiver refazendo a carga inicial a cada poucos minutos, verifique se há alterações de DDL a montante.
  • Esteja atento ao impacto nos custos. Uma reutilização de uma tabela de 226 milhões de linhas (aproximadamente 26,5 GB) leva um tempo significativo de computação. Multiplique esse custo pela frequência das alterações de esquema para estimar o impacto no custo.

Limitações de segurança

• O Fabric não replica as políticas de segurança em nível de linha (RLS) e segurança em nível de coluna (CLS) do Snowflake. Você deve reconfigurar manualmente políticas de segurança equivalentes no Fabric.
• Os destinatários de compartilhamento devem ser adicionados ao workspace. Para compartilhar um conjunto de dados ou relatório, primeiro adicione acesso ao espaço de trabalho com uma função de administrador, membro, leitor ou colaborador.

Considerações sobre custo e cobrança

Para minimizar os custos de computação do Snowflake decorrentes do espelhamento, considere as seguintes práticas recomendadas:

• Reutilizar um armazém existente. Em vez de criar um warehouse dedicado para espelhamento, configure o espelhamento para usar o mesmo warehouse que seus aplicativos já usam para atualizar as tabelas de origem. Essa abordagem evita ciclos desnecessários de ativação e suspensão automática do armazém. Quando o aplicativo atualiza uma tabela, o replicador de espelhamento pega as alterações quase imediatamente enquanto o warehouse ainda está ativo, eliminando a necessidade de ativar um warehouse separado. Algumas organizações podem preferir um armazém dedicado para isolamento de orçamento. Essa opção é uma compensação entre a economia de custos e a granularidade orçamentária.
• Espelhar somente as tabelas de que você precisa. O espelhamento de um banco de dados inteiro pode causar um consumo inesperado no Snowflake e picos de capacidade do Fabric. Comece selecionando apenas as tabelas necessárias para seus cenários de análise. Você pode adicionar tabelas mais tarde, conforme necessário.
• Monitore ressemeaduras inesperadas. Um reseed (recarregamento completo de dados) processa toda a tabela e incorre no custo de computação proporcional ao tamanho da tabela. As alterações de esquema - incluindo aquelas disparadas por ferramentas como o DBT - podem causar ressesamentos contínuas. Monitore a página Status de Espelhamento para tabelas que mostram o comportamento repetido de cópia inicial e examine a seção Resseeding para obter gatilhos e diretrizes de solução de problemas.
• Lembre-se de que o espelhamento é executado de forma contínua. Atualmente, o espelhamento não dá suporte a janelas de agendamento ou replicação. O replicador verifica continuamente se há alterações, o que gera uso contínuo de recursos computacionais do Snowflake. Planeje adequadamente seu orçamento do Snowflake.

Regiões com suporte

O espelhamento de banco de dados e o espelhamento aberto estão disponíveis em todas as regiões Microsoft Fabric. Para obter mais informações, confira Disponibilidade do Fabric por região.

Conteúdo relacionado

• O que é Espelhamento no Tecido?
• Espelhando Floco de Neve
• Tutorial: Configurar bancos de dados espelhados do Microsoft Fabric do Snowflake