Compartilhar via


Considerações sobre o gateway de dados no local para destinos de dados no Dataflow Gen2

Este artigo tenta listar as limitações e considerações ao usar o Gateway de Dados com cenários de destinos de dados no Fluxo de Dados Gen2.

Tempos limite de avaliação

Os fluxos de dados que usam um Gateway e o recurso de destino de dados são limitados a um tempo de avaliação ou atualização de uma hora.

Saiba mais sobre essa limitação no artigo Solucionar problemas do gateway de dados local.

Problemas de rede com a porta 1433

Ao usar o Microsoft Fabric Dataflow Gen2 com um gateway de dados local, você pode encontrar problemas com o processo de atualização do fluxo de dados. O problema subjacente ocorre quando o gateway não consegue se conectar ao fluxo de dados staging Lakehouse para ler os dados antes de copiá-los para o destino de dados desejado. Esse problema pode ocorrer independentemente do tipo de destino de dados que está sendo usado.

Durante a atualização geral do fluxo de dados, a atualização das tabelas pode ser mostrada como "Êxito", mas a seção de atividades é exibida como "Falha". Os detalhes do erro da atividade WriteToDatabaseTableFrom_... indicam o seguinte erro:

Mashup Exception Error: Couldn't refresh the entity because of an issue with the mashup document MashupException.Error: Microsoft SQL: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - An attempt was made to access a socket in a way forbidden by its access permissions.) Details: DataSourceKind = Lakehouse;DataSourcePath = Lakehouse;Message = A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - An attempt was made to access a socket in a way forbidden by its access permissions.);ErrorCode = -2146232060;Number = 10013

Observação

Do ponto de vista arquitetônico, o mecanismo de fluxo de dados usa um ponto de extremidade HTTPS de saída (porta 443) para gravar dados em um Lakehouse. Porém, a leitura de dados do Lakehouse requer o uso do protocolo TDS (TCP pela porta 1433). Esse protocolo é usado para copiar os dados do lakehouse de preparo no destino dos dados. Isso explica por que a etapa Carregamento de Tabelas é bem-sucedida enquanto a atividade de destino de dados falha, mesmo quando ambos os lakehouses estão na mesma instância do OneLake.

Solução de problemas

Para solucionar o problema, siga estas etapas:

  1. Confirme se o fluxo de dados está configurado com um destino de dados.

    Captura de tela do editor do Power Query com o destino de dados do Lakehouse enfatizado.

  2. Verifique se a atualização do fluxo de dados falha, com a atualização de tabelas sendo exibida como "Êxito" e as atividades exibidas como "Falha".

    Captura de tela dos detalhes do fluxo de dados com tabelas que mostram as atividades bem-sucedidas e as que não foram bem-sucedidas.

  3. Examine os detalhes do erro da Atividade WriteToDatabaseTableFrom_..., que fornece informações sobre o erro encontrado.

    Captura de tela da atividade WriteToDatabaseTablefrom mostrando a mensagem de erro.

Solução: definir novas regras de firewall no servidor que executa o gateway

As regras de firewall no servidor de gateway e/ou nos servidores proxy do cliente precisam ser atualizadas para permitir o tráfego de saída do servidor de gateway para os pontos de extremidade abaixo. Se o firewall não der suporte a curingas, utilize os endereços IP de Intervalos de IP e marcas de Serviço do Azure. Observe que eles precisarão ser mantidos em sincronia todos os meses.

  • Protocolo: TCP
  • Pontos de extremidade: *.datawarehouse.pbidedicated.windows.net, *.datawarehouse.fabric.microsoft.com, *.dfs.fabric.microsoft.com
  • Porta: 1433

Observação

Em determinados cenários, especialmente quando a capacidade está localizada em uma região que não é a mais próxima do Gateway, pode ser necessário configurar o firewall para permitir o acesso a vários pontos de extremidade(*cloudapp.azure.com). Esse ajuste é necessário para acomodar redirecionamentos que podem ocorrer nessas condições. Se o tráfego destinado a *.cloudapp.azure.com não for interceptado pela regra, você pode, alternativamente, permitir os endereços IP para sua região de dados no firewall.

Se você quiser restringir o escopo do ponto de extremidade à instância real do OneLake em um espaço de trabalho (em vez do coringa *.datawarehouse.pbidedicated.windows.net), essa URL pode ser encontrada navegando até o espaço de trabalho Fabric, localizando DataflowsStagingLakehouse, e selecionando Exibir Detalhes. Em seguida, copie e cole a cadeia de conexão SQL.

Captura de tela do espaço de trabalho do Fabric com DataflowsStagingLakehouse, com as reticências selecionadas e a opção Exibir detalhes enfatizada.

Captura de tela das informações de detalhes do DataflowsStagingLakehouse, com a cadeia de conexão SQL enfatizada.

O nome completo do ponto de extremidade é semelhante ao exemplo a seguir:

x6eps4xrq2xudenlfv6naeo3i4-l27nd6wdk4oephe4gz4j7mdzka.datawarehouse.pbidedicated.windows.net

Solução alternativa: dividir o fluxo de dados em um fluxo de dados separado para ingerir e carregar

Se não for possível atualizar as regras do firewall, você pode dividir o fluxo de dados em dois fluxos de dados separados. O primeiro fluxo de dados é responsável por ingerir os dados no seu Lakehouse de preparo. O segundo fluxo de dados é responsável por carregar os dados do lakehouse de preparo para o destino dos dados. Essa solução alternativa não é ideal, pois exige o uso de dois fluxos de dados separados, mas pode ser utilizada como uma solução temporária até que as regras do firewall possam ser atualizadas.

Para implementar essa solução alternativa, siga estas etapas:

  1. Remova o destino dos dados do seu fluxo de dados atual que ingerem dados através do seu gateway.

    Captura de tela do editor do Power Query com o destino de dados do Lakehouse sendo removido.

  2. Crie um novo fluxo de dados que utilize o conector de fluxo de dados para conectar-se ao fluxo de dados de ingestão. Esse fluxo de dados é responsável pela ingestão de dados do preparo para o destino dos dados.

    Captura de tela do editor do Power Query com a opção Obter Dados selecionada e a opção Conector de Fluxo de Dados realçada.

    Captura de tela do diálogo Obter Dados com a opção Conector de fluxo de dados selecionada.

  3. Defina o destino de dados que será o destino de dados de sua escolha para esse novo fluxo de dados.

    Captura de tela do editor do Power Query com o destino de dados do Lakehouse sendo definido.

  4. Opcionalmente, você pode desabilitar o processo de preparo para esse novo fluxo de dados. Essa alteração evita que os dados sejam copiados novamente para o Lakehouse de preparo e, em vez disso, copia os dados diretamente do fluxo de dados ingerido para o destino dos dados.

    Captura de tela do editor do Power Query com a opção de preparo sendo desativada.