Este documento mostra como resolver problemas comuns ao usar a capacidade de acesso aos dados entre nuvens do Lakehouse sem fronteiras.
Os dados e recursos estão desatualizados ou não estão sendo atualizados
Os catálogos federados do Lakehouse sincronizam metadados de uma nuvem remota com base em um intervalo de atualização. A atualização de metadados em segundo plano de um catálogo pode levar mais tempo quanto mais recursos houver (compartilhamentos, esquemas, namespaces, tabelas). Se a atualização anterior exceder o tempo limite, a atual será ignorada, mas a próxima será reagendada no intervalo seguinte.
Se os dados consultados parecerem desatualizados, a atualização de metadados em segundo plano do catálogo poderá estar excedendo o tempo limite ou falhando. Os recursos de nuvem remota também estão sujeitos ao mesmo comportamento. Se você excluir um recurso na nuvem remota, ele só será excluído do Lakehouse na próxima atualização de metadados em segundo plano.
Verifique o status da atualização de metadados em segundo plano em um catálogo federado na Lakehouse Google Cloud ou executando a CLI gcloud:
gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" gcloud alpha biglake delta-sharing catalogs describe FEDERATED_CATALOG_NAME \ --project="PROJECT_ID"
Problemas de conectividade ou roteamento
Se você encontrar problemas de conectividade ou roteamento ao usar uma interconexão privada, verifique o seguinte:
- Verificar a propagação de rotas: confira o Cloud Router em Google Cloud para verificar se ele aprendeu os prefixos da VPC da AWS. Verifique as tabelas de rotas da AWS para confirmar se elas têm rotas de volta para sua Google Cloud VPC.
- Verificar a integridade do ILB: No Google Cloud console, acesse Serviços de rede > Balanceamento de carga. Verifique se os back-ends (NEGs) do serviço de back-end do ILB estão íntegros. Se não estiverem, verifique a conectividade de rede e as regras do grupo de segurança da AWS.
- Testar a conectividade de Google Cloud: inicie uma instância de VM de teste na mesma
Google Cloud VPC e sub-rede que o endpoint do ILB ou do diretório de serviços
e tente se conectar aos endereços IP da ENI da AWS na porta
443(por exemplo, usandocurloutelnet). - Resolução do diretório de serviços:verifique se a conta de serviço do catálogo tem permissões para resolver endpoints do diretório de serviços (
roles/servicedirectory.viewer,roles/servicedirectory.pscAuthorizedService). - Grupos de segurança e regras de firewall: verifique se as Google Cloud regras de firewall
e os grupos de segurança da AWS permitem o tráfego na porta TCP
443entre os intervalos de IP relevantes.
A atualização do catálogo do Snowflake falha com o código 16 (não autenticado)
Se a atualização de metadados em segundo plano de um catálogo do Snowflake Horizon falhar com o status Code 16 (UNAUTHENTICATED), verifique o seguinte:
- Formatação do payload do secret:verifique se o token secreto no
Secret Manager contém a estrutura JSON necessária
(
{"client_secret": "<var>SNOWFLAKE_PAT_TOKEN</var>", "scope": "session:role:<var>SNOWFLAKE_ROLE</var>"}) em vez da string bruta do token de acesso pessoal (PAT). - Validade e permissões do token:verifique se o PAT do Snowflake é válido e se o usuário e o papel associados têm privilégios suficientes para acessar o catálogo e os bancos de dados de destino.
- Política de rede: Se uma política de rede do Snowflake estiver configurada, verifique se os intervalos de endereços IP de saída do Google de
goog.jsonestão na lista de permissões.