Limitações nas bases de dados espelhadas do Microsoft Fabric em relação ao Snowflake

As limitações atuais nas bases de dados espelhadas Microsoft Fabric do Snowflake estão listadas nesta página. Esta página está sujeita a alterações.

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

• A tabela seguinte lista quais os métodos de autenticação suportados para espelhamento no Snowflake:

• A identidade do espaço de trabalho não é atualmente suportada para o espelhamento do Snowflake. Está disponível para fontes selecionadas, como o SharePoint.

• A conectividade Private Link entre um espaço de trabalho Fabric e o Snowflake ainda não está disponível. Use um gateway de dados de rede virtual ou gateway de dados local para conectividade privada entretanto.

• Tem de adicionar destinatários da partilha ao espaço de trabalho. Para partilhar um conjunto de dados ou relatório, primeiro adicione acesso ao espaço de trabalho com um papel de administrador, membro, leitor ou colaborador.

• Sensibilidade a maiúsculas e minúsculas: todos os identificadores do Snowflake — incluindo o nome do armazém, o nome da base de dados, o nome do esquema, os nomes das tabelas e os nomes das vistas — são sensíveis a maiúsculas e minúsculas ao configurar ligações de espelhamento e ao utilizar a API REST de espelhamento. A carcaça que introduzir no Fabric tem de corresponder exatamente ao que está configurado no Snowflake. A carcaça incompatível pode causar falhas de ligação ou tabelas que não aparecem para replicação, muitas vezes sem mensagem de erro descritiva. Por exemplo, se o seu armazém Snowflake se chama ANALYTICS_WH, deve inserir ANALYTICS_WH na ligação Fabric, não analytics_wh.

Tipos de objeto suportados

• A tabela seguinte lista quais os tipos de objetos Snowflake suportados para espelhamento:

Replicação e limitações de dados

• Se não houver atualizações em uma tabela de origem, o mecanismo replicador começará a recuar com uma duração exponencialmente crescente para essa tabela, até uma hora. O mesmo pode ocorrer se houver um erro transitório, impedindo a atualização de dados. O mecanismo replicador retomará automaticamente a sondagem regular depois que os dados atualizados forem detetados.
• A hierarquia do esquema de origem é replicada para o banco de dados espelhado. Para bancos de dados espelhados criados antes da habilitação desse recurso, o esquema de origem é nivelado e o nome do esquema é codificado no nome da tabela. Se quiser reorganizar tabelas com esquemas, recrie seu banco de dados espelhado. Saiba mais em Replicar hierarquia de esquema de origem.
• O espelhamento suporta a replicação de colunas contendo espaços ou caracteres especiais em nomes (como ,;{}()\n\t=). Para tabelas em replicação antes que esse recurso seja 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. Quaisquer tabelas acima do limite de 1000 atualmente não podem ser replicadas.
  • Se selecionar Espelhar todos os dados ao configurar o Espelhamento, as tabelas a espelhar serão determinadas tomando as primeiras 1.000 tabelas quando todas as tabelas forem ordenadas alfabeticamente com base no nome do esquema e depois no nome da tabela. O conjunto restante de tabelas no fundo da lista alfabética não será espelhado.
  • Se desmarcar Espelhar todos os dados e selecionar tabelas individualmente, não poderá selecionar mais de 1.000 tabelas.
• Colunas calculadas e tabelas calculadas: As bases de dados em espelho são só de leitura. Não podes criar colunas calculadas ou tabelas calculadas diretamente numa base de dados espelhada. Para adicionar colunas calculadas, cria um Lakehouse e utiliza atalhos para fazer referência aos dados espelhados e, em seguida, cria as colunas calculadas no Lakehouse utilizando blocos de notas ou SQL.

Limitações de desempenho

• Se estiveres a alterar a maioria dos dados numa tabela grande, é 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 necessitam de uma alteração de dados (inserir, atualizar ou eliminar) antes de as alterações de esquema serem replicadas para o Fabric.
• Considerações entre regiões: Se a sua instância Snowflake e a capacidade do Fabric estiverem em regiões cloud diferentes, poderá experienciar uma latência de replicação e cargas de saída de dados mais elevadas. Para um desempenho ótimo e evitar custos de saída entre regiões, implemente a sua capacidade Fabric na mesma região cloud da sua instância Snowflake. Se a implementação entre regiões for inevitável, considere as taxas adicionais de saída do Snowflake e/ou do Azure. Consulte a documentação de saída do Snowflake para mais detalhes.
• Ao espelhar dados do Snowflake para o OneLake de um cliente, o processo normalmente coloca os dados em estágio através de uma URL inline para melhorar o desempenho. Se o parâmetro ao nível da conta do Snowflake PREVENT_UNLOAD_TO_INLINE_URL estiver definido como verdadeiro, aplica-se o seguinte comportamento:

Resolução prevista: o suporte para integração de armazenamento está em desenvolvimento e disponibilizará um caminho alternativo de preparação que funciona mesmo quando PREVENT_UNLOAD_TO_INLINE_URL estiver definido como verdadeiro. Esta solução desbloqueia cenários de VNet e OPDG. Consulte esta página para atualizações sobre disponibilidade.

• Comportamento da reinicialização: Uma reinicialização é uma recarga integral dos dados de toda a tabela. Ao contrário da sincronização incremental (que só processa linhas alteradas), uma reseed relê e reescreve todos os dados da tabela. Os reseeds podem implicar custos de computação significativos no Snowflake, especialmente para tabelas grandes.
  • O que desencadeia uma nova propagação:

• Melhores práticas para evitar resemeaduras desnecessárias:
  • Agende alterações ao esquema fora dos períodos de espelhamento ativo. Se usar DBT ou outras ferramentas de gestão de esquemas, agende-as durante janelas de manutenção ou pause o espelhamento antes de executar alterações de esquema.
  • Evite alterações frequentes ao DDL. Consolide as alterações de esquema em menos lotes maiores, em vez de fazer alterações incrementais ao longo do dia.
  • Monitorize possíveis re-semeaduras inesperadas. Na página de Estado de Espelhamento, observe tabelas que mostrem repetidamente o comportamento de cópia inicial. Se uma tabela grande estiver a reiniciar a cada poucos minutos, verifique as alterações DDL a montante.
  • Esteja atento ao impacto nos custos. A reinicialização de uma tabela com 226 milhões de linhas (~26,5 GB) requer um tempo de processamento considerável. Multiplique este custo pela frequência das alterações de esquema para estimar o impacto de custo.

Limitações de segurança

• O Fabric não replica as políticas de Row-Level Security (RLS) e Column-Level Security (CLS) do Snowflake. Tem de reconfigurar manualmente políticas de segurança equivalentes no Fabric.
• Os destinatários de compartilhamento devem ser adicionados ao espaço de trabalho. Para partilhar um conjunto de dados ou relatório, primeiro adicione acesso ao espaço de trabalho com um papel de administrador, membro, leitor ou colaborador.

Considerações de custos e faturação

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

• Reutilizar um armazém existente. Em vez de criar um armazém dedicado para espelhamento, configure o espelhamento para usar o mesmo armazém que as suas aplicações já usam para atualizar as tabelas de origem. Esta abordagem evita ciclos desnecessários de reativação e suspensão automática do warehouse. Quando a sua aplicação atualiza uma tabela, o replicador de espelhamento capta alterações quase imediatamente enquanto o armazém ainda está ativo, eliminando a necessidade de ativar um armazém separado. Algumas organizações podem preferir um armazém dedicado para isolamento orçamental. Esta escolha é um compromisso entre poupança de custos e granularidade orçamental.
• Espelha apenas as mesas de que precisares. Espelhar uma base de dados inteira pode causar um consumo inesperadamente elevado do Snowflake e picos de capacidade do Fabric. Comece por selecionar apenas as tabelas necessárias para os seus cenários de análise. Podes adicionar tabelas mais tarde, conforme necessário.
• Monitorize possíveis re-semeaduras inesperadas. Um reseed (recarga total de dados) processa toda a tabela e incorre em custos de computação proporcionais ao tamanho da tabela. Alterações ao esquema — incluindo as desencadeadas por ferramentas como o DBT — podem causar reinicializações contínuas. Monitorize a página Estado de Espelhamento para identificar tabelas que apresentem comportamento repetido de cópia inicial e consulte a secção de Reinicialização para conhecer os fatores que a desencadeiam e as orientações de resolução de problemas.
• Tenha em atenção que o espelhamento é executado continuamente. O espelhamento atualmente não suporta janelas de agendamento ou replicação. O replicador sonda continuamente as alterações, o que gera o uso contínuo do cálculo Snowflake. Planeie os seus orçamentos para a Snowflake em conformidade.

Regiões suportadas

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

Conteúdo relacionado

• O que é espelhamento em malha?
• Flocos de neve espelhados
• Tutorial: Configurar bases de dados espelhadas Microsoft Fabric a partir do Snowflake