Soluciona problemas de acceso a los datos multinube

En este documento, se muestra cómo resolver problemas habituales cuando se usa la capacidad de acceso a los datos entre nubes del Lakehouse sin límites.

Los datos y los recursos están desactualizados o no se actualizan

Los catálogos federados de Lakehouse sincronizan los metadatos de una nube remota según un intervalo de actualización. La actualización de los metadatos en segundo plano de un catálogo puede tardar más cuanto más recursos haya (recursos compartidos, esquemas, espacios de nombres, tablas). Si la actualización anterior se extiende demasiado, se omitirá la actualización actual, pero la siguiente se reprogramará para el intervalo siguiente.

Si los datos consultados parecen inactivos, es posible que la actualización de metadatos en segundo plano del catálogo se esté ejecutando demasiado tiempo o esté fallando. Los recursos de nube remota también están sujetos al mismo comportamiento. Si borras un recurso en la nube remota, solo se borrará de Lakehouse en la próxima actualización correcta de metadatos en segundo plano.

Verifica el estado de actualización de metadatos en segundo plano en un catálogo federado en la página de la consola de Lakehouse Google Cloud o ejecutando gcloud CLI:

Ir a Lakehouse

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 conectividad o enrutamiento

Si tienes problemas de conectividad o enrutamiento cuando usas una interconexión privada, verifica lo siguiente:

  • Verifica la propagación de rutas: Consulta Cloud Router enGoogle Cloud para verificar que haya aprendido los prefijos de la VPC de AWS. Verifica tus tablas de rutas de AWS para confirmar que tengan rutas de regreso a tu VPC Google Cloud .
  • Verifica el estado del ILB: En la consola de Google Cloud , ve a Servicios de red > Balanceo de cargas. Verifica si los backends (NEG) de tu servicio de backend del ILB están en buen estado. Si no es así, verifica la conectividad de la red y las reglas del grupo de seguridad de AWS.
  • Prueba la conectividad desde Google Cloud: Inicia una instancia de VM de prueba en la misma VPC y subred deGoogle Cloud que el ILB o el extremo de Directorio de servicios y trata de conectarte a las direcciones IP de la ENI de AWS en el puerto 443 (por ejemplo, con curl o telnet).
  • Resolución del Directorio de servicios: Verifica que la cuenta de servicio del catálogo tenga permisos para resolver extremos del Directorio de servicios (roles/servicedirectory.viewer, roles/servicedirectory.pscAuthorizedService).
  • Grupos de seguridad y reglas de firewall: Verifica que las reglas de firewall Google Cloud y los grupos de seguridad de AWS permitan el tráfico en el puerto TCP 443entre los rangos de IP pertinentes.

La actualización del catálogo de Snowflake falla con el código 16 (sin autenticar)

Si la actualización de metadatos en segundo plano para un catálogo de Snowflake Horizon falla con el estado Code 16 (UNAUTHENTICATED), verifica lo siguiente:

  • Formato de carga útil secreta: Asegúrate de que el token secreto en Secret Manager contenga la estructura JSON requerida ({"client_secret": "<var>SNOWFLAKE_PAT_TOKEN</var>", "scope": "session:role:<var>SNOWFLAKE_ROLE</var>"}) en lugar de la cadena sin procesar del token de acceso personal (PAT).
  • Vencimiento y permisos del token: Asegúrate de que el PAT de Snowflake sea válido y de que el usuario y el rol asociados tengan privilegios suficientes para acceder al catálogo y las bases de datos de destino.
  • Política de red: Si se configura una política de red de Snowflake, asegúrate de que los rangos de direcciones IP de salida de Google desde goog.json estén en la lista de entidades permitidas.