Questo documento mostra come risolvere i problemi comuni durante l'utilizzo della funzionalità di accesso ai dati cross-cloud di Lakehouse senza confini.
Dati e risorse non aggiornati
I cataloghi federati Lakehouse sincronizzano i metadati da un cloud remoto in base a un intervallo di aggiornamento. L'aggiornamento dei metadati di sfondo di un catalogo potrebbe richiedere più tempo quanto più risorse sono presenti (condivisioni, schemi, spazi dei nomi, tabelle). Se l'aggiornamento precedente viene superato, l'aggiornamento corrente verrà saltato, ma il successivo verrà riprogrammato all'intervallo successivo.
Se i dati interrogati sembrano obsoleti, l'aggiornamento dei metadati in background del catalogo potrebbe essere in corso o non riuscire. Anche le risorse cloud remote sono soggette allo stesso comportamento. Se elimini una risorsa nel cloud remoto, questa verrà eliminata da Lakehouse solo al successivo aggiornamento riuscito dei metadati in background.
Controlla lo stato dell'aggiornamento dei metadati in background in un catalogo federato nella pagina della console Lakehouse Google Cloud o eseguendo gcloud CLI:
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"
Problemi di connettività o routing
Se riscontri problemi di connettività o routing quando utilizzi un interconnessione privata, verifica quanto segue:
- Verifica la propagazione delle route:controlla il router Cloud in Google Cloud per verificare che abbia appreso i prefissi VPC AWS. Controlla le tabelle di routing AWS per verificare che contengano route di ritorno al tuo VPC Google Cloud .
- Controlla l'integrità del bilanciamento del carico interno:nella console Google Cloud , vai a Servizi di rete > Bilanciamento del carico. Controlla se i backend (NEG) per il servizio di backend ILB sono integri. In caso contrario, verifica la connettività di rete e le regole del gruppo di sicurezza AWS.
- Testa la connettività da Google Cloud: avvia un'istanza VM di test nello stesso
Google Cloud VPC e nella stessa subnet dell'endpoint ILB o Service Directory
e prova a connetterti agli indirizzi IP ENI AWS sulla porta
443(ad esempio utilizzandocurlotelnet). - Risoluzione di Service Directory:verifica che l'account di servizio del catalogo disponga delle autorizzazioni per risolvere gli endpoint Service Directory (
roles/servicedirectory.viewer,roles/servicedirectory.pscAuthorizedService). - Gruppi di sicurezza e regole firewall:verifica che le Google Cloud regole
firewall e i gruppi di sicurezza AWS consentano il traffico sulla porta TCP
443tra gli intervalli IP pertinenti.
L'aggiornamento del catalogo Snowflake non riesce con il codice 16 (non autenticato)
Se l'aggiornamento dei metadati in background per un catalogo Snowflake Horizon non va a buon fine con
lo stato Code 16 (UNAUTHENTICATED), verifica quanto segue:
- Formattazione del payload del secret:assicurati che il token secret in Secret Manager contenga la struttura JSON richiesta (
{"client_secret": "<var>SNOWFLAKE_PAT_TOKEN</var>", "scope": "session:role:<var>SNOWFLAKE_ROLE</var>"}) anziché la stringa PAT (Personal Access Token) non elaborata. - Scadenza e autorizzazioni del token:assicurati che il PAT Snowflake sia valido e che l'utente e il ruolo associati dispongano di privilegi sufficienti per accedere al catalogo e ai database di destinazione.
- Policy di rete:se è configurata una policy di rete Snowflake, assicurati che
gli intervalli di indirizzi IP in uscita di Google da
goog.jsonsiano inclusi nella lista consentita.