Risolvere i problemi di accesso ai dati cross-cloud

Quando accedi ai dati cross-cloud con Lakehouse, puoi diagnosticare e risolvere i problemi relativi all'aggiornamento dei metadati in background, al routing di Private Interconnect su Cross-Cloud Interconnect e alla risoluzione degli endpoint di Service Directory. La risoluzione di questi problemi aiuta a mantenere aggiornati i metadati delle tabelle federate e ripristina l'esecuzione di query cross-cloud private.

Dati e risorse non aggiornati o non in fase di aggiornamento

I cataloghi federati Lakehouse sincronizzano i metadati da un cloud remoto in base a un intervallo di aggiornamento. L'aggiornamento dei metadati in background di un catalogo federato può richiedere più tempo se il catalogo federato contiene molte risorse (condivisioni, schemi, spazi dei nomi e tabelle). Se un aggiornamento precedente supera il tempo previsto, l'aggiornamento corrente viene saltato e quello successivo viene eseguito all'intervallo pianificato successivo.

Se i dati sottoposti a query sembrano obsoleti, l'aggiornamento dei metadati in background del catalogo federato potrebbe essere in sovraccarico o non riuscire. Se elimini una risorsa nel cloud remoto, questa viene rimossa da Lakehouse al successivo aggiornamento dei metadati in background completato.

Controlla lo stato di aggiornamento dei metadati in background su un catalogo federato nella pagina Lakehouse della console Google Cloud o utilizzando Google Cloud CLI:

Vai a Lakehouse

gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID"

gcloud biglake delta-sharing catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID"

Risoluzione dei problemi di AWS Glue Data Catalog

Se l'aggiornamento dei metadati in background non riesce dopo aver configurato --metadata-service-directory-name su un catalogo federato AWS Glue nel catalogo di runtime Lakehouse, controlla quanto segue:

  • Verifica la mappatura degli endpoint del catalogo privato: verifica che il gruppo di endpoint di rete (NEG) di connettività ibrida o l'endpoint di Service Directory per l'aggiornamento dei metadati in background punti all'indirizzo IP privato dell'endpoint VPC dell'interfaccia AWS Glue (com.amazonaws.AWS_REGION.glue) sulla porta TCP 443, anziché all'endpoint VPC dell'interfaccia Amazon S3.
  • Verifica la policy di attendibilità e le autorizzazioni del ruolo IAM: verifica che la policy di attendibilità del ruolo IAM di Amazon Web Services (AWS) consenta al service account del catalogo federato (Google Cloud ) (biglake-service-account) di assumere il ruolo (sts:AssumeRoleWithWebIdentity) e che il ruolo disponga delle autorizzazioni per leggere i metadati del database e della tabella AWS Glue (glue:GetDatabase, glue:GetDatabases, glue:GetTable, glue:GetTables).
  • Controlla le regole del gruppo di sicurezza dell'endpoint VPC: verifica che il gruppo di sicurezza AWS collegato all'endpoint VPC dell'interfaccia AWS Glue consenta il traffico HTTPS in entrata sulla porta TCP 443 dagli intervalli CIDR della subnet del Virtual Private Cloud (VPC)Google Cloud e della subnet solo proxy.

Risoluzione dei problemi di Databricks Unity Catalog

Le tabelle sono vuote o non vengono rilevate durante l'aggiornamento dei metadati in background

Se l'aggiornamento dei metadati in background del catalogo federato indica il completamento (ad esempio Refresh successfully completed), ma le tabelle nel catalogo federato non vengono visualizzate o l'elenco delle tabelle restituisce 0 elementi, controlla quanto segue:

  • Privilegio EXTERNAL USE SCHEMA: verifica che all'entità servizio Databricks sia stato concesso il privilegio EXTERNAL USE SCHEMA sugli schemi o sul catalogo di destinazione in Databricks Unity Catalog. Senza questo privilegio, l'aggiornamento dei metadati in background e la distribuzione delle credenziali per le query non vanno a buon fine.
  • Impostazione di accesso ai dati esterni: verifica che l'accesso ai dati esterni sia abilitato nel metastore Databricks Unity Catalog.
  • Posizione esterna: verifica che il catalogo e le tabelle Databricks Unity utilizzino una posizione di archiviazione esterna (come Amazon S3, Microsoft Azure Data Lake Storage Gen2 o Cloud Storage) anziché lo spazio di archiviazione predefinito.

Il refresh dei metadati in background non riesce su Cross-Cloud Interconnect

Se l'aggiornamento dei metadati in background non riesce quando --metadata-service-directory-name è configurato per Databricks Unity Catalog nel catalogo di runtime Lakehouse, verifica quanto segue:

  • Workspace private endpoint target: verifica che l'endpoint Service Directory dei metadati o il backend del bilanciatore del carico di rete proxy regionale interno abbia come target l'indirizzo IP privato dell'endpoint dell'interfaccia AWS PrivateLink del tuo workspace Databricks o l'endpoint privato di Azure sulla porta TCP 443, anziché l'endpoint dello spazio di archiviazione remoto, e che --unity-instance-name corrisponda al nome host del tuo workspace.
  • Impostazioni di accesso privato di Workspace: se il tuo workspace Databricks applica impostazioni di accesso privato o elenchi per gli accessi IP, verifica che le richieste che arrivano tramite l'endpoint privato dalla tua rete VPC Google Cloudsiano consentite.

L'aggiornamento dei metadati in background non va a buon fine o restituisce l'errore 401 Unauthorized

Se lo stato dell'aggiornamento dei metadati in background segnala un errore (ad esempio 401 Unauthorized) o non riesce a rilevare gli schemi, verifica quanto segue:

  • Policy di federazione del service principal: nella console dell'account Databricks (Impostazioni account > Sicurezza > Configurazione del provider di identità > Policy di federazione), verifica che la policy di federazione del service principal sia configurata come segue:
    • URL emittente: https://accounts.google.com
    • Oggetto: l'ID univoco numerico del account di servizio biglake-service-account del catalogo federato (non il suo indirizzo email).
    • Pubblico: https://accounts.cloud.databricks.com
  • Autorizzazioni di Secret Manager: se utilizzi l'autenticazione basata su secret, verifica che il secret esista nella località regionale specificata e che a biglake-service-account sia stato concesso il ruolo Secret Manager Secret Accessor (roles/secretmanager.secretAccessor).
  • Autorizzazioni del service principal: assicurati che il service principal di Databricks disponga dell'accesso in lettura allo spazio di lavoro di destinazione e a Databricks Unity Catalog.

La query interattiva non riesce con l'errore 401 Unauthorized o di convalida del token

Quando la federazione delle identità utente è abilitata, le query interattive generano dinamicamente un token di identità dell'utente finale e lo convalidano in base a una policy di federazione a livello di account in Databricks. Se le query non vanno a buon fine con errori di convalida dei token o 401 Unauthorized, mentre l'aggiornamento dei metadati in background è integro, controlla quanto segue:

  • Policy di federazione a livello di account configurata: assicurati che nella console dell'account Databricks in Impostazioni account > Sicurezza > Configurazione del provider di identità > Policy di federazione sia creata una policy di federazione a livello di account (diversa dalla policy del service principal).
  • Corrispondenza del pubblico sensibile alle maiuscole: Databricks convalida l'attestazione aud (pubblico) in modo rigorosamente sensibile alle maiuscole. Verifica che il campo Pubblico nella policy di federazione a livello di account Databricks corrisponda esattamente alle maiuscole e minuscole della rivendicazione audience con ambito metastore (databricks-METASTORE_ID) recuperata dal catalogo federato. Qualsiasi discrepanza tra maiuscole e minuscole (ad esempio nel prefisso databricks- o nell'UUID del metastore) causa il rifiuto della query da parte della convalida del token Databricks con 401 Unauthorized.
  • URL emittente: verifica che l'URL emittente corrisponda esattamente alla rivendicazione issuer-url del catalogo federato: https://www.gstatic.com/biglake/federation/organizations/ORGANIZATION_ID.
  • Disponibilità del pubblico del metastore: l'attestazione audience con ambito metastore viene compilata solo dopo il completamento del primo ciclo di aggiornamento dei metadati in background (in genere entro 5 minuti). Se configuri la policy con un valore segnaposto o prima del completamento del primo ciclo di aggiornamento, le query non vanno a buon fine. Esegui gcloud biglake iceberg catalogs describe per verificare che l'attestazione audience nel catalogo federato sia stata compilata prima di configurare la policy.

Risoluzione dei problemi di Snowflake Horizon Catalog

L'aggiornamento dei metadati in background 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 del secret in Secret Manager contenga la struttura JSON richiesta ({"client_secret": "SNOWFLAKE_PAT_TOKEN", "scope": "session:role:SNOWFLAKE_ROLE"}) anziché la stringa del token di accesso programmatico (PAT) non elaborata.
  • Scadenza e autorizzazioni dei token: verifica che il PAT di Snowflake sia valido e che l'utente e il ruolo associati dispongano dei privilegi per leggere il catalogo e i database di destinazione.
  • Identificatore dell'account PrivateLink o Private Link: se hai configurato --metadata-service-directory-name per sincronizzare i metadati su Cross-Cloud Interconnect utilizzando AWS PrivateLink o Azure Private Link, verifica che --snowflake-account-identifier specifichi l'identificatore dell'account Snowflake .privatelink (ad esempio myorg-myaccount.privatelink) anziché l'identificatore dell'account pubblico.
  • Policy di rete: se l'aggiornamento dei metadati in background si connette tramite internet pubblico ed è attiva una policy di rete Snowflake, verifica che gli intervalli di indirizzi IP in uscita di Google di goog.json siano inclusi nell'elenco degli IP consentiti della policy di rete.

Il refresh dei metadati in background non riesce su Cross-Cloud Interconnect

Se l'aggiornamento dei metadati in background non va a buon fine quando --metadata-service-directory-name è configurato per Snowflake Horizon Catalog nel catalogo di runtime Lakehouse, verifica quanto segue:

  • Target dell'endpoint privato Snowflake: verifica che l'endpoint Service Directory dei metadati o il backend del bilanciatore del carico di rete proxy regionale interno punti all'indirizzo IP privato dell'endpoint dell'interfaccia AWS PrivateLink di Snowflake o dell'endpoint privato di Azure sulla porta TCP 443, anziché all'endpoint di archiviazione di oggetti remoto.
  • Identificatore dell'account privato: verifica che --snowflake-account-identifier utilizzi l'identificatore del tuo account .privatelink (ad esempio, myorg-myaccount.privatelink).

Problemi di connettività o routing

Se si verificano errori di trasporto delle query o di aggiornamento dei metadati in background durante il routing del traffico su Cross-Cloud Interconnect, verifica quanto segue:

  • Verifica la propagazione delle route: controlla il router Cloud inGoogle Cloud per verificare che abbia appreso i prefissi del VPC AWS o della rete virtuale (VNet) di Azure. Controlla le tabelle di route AWS o Azure per verificare che abbiano route di ritorno alla tua rete VPC Google Cloud. Se utilizzi un bilanciatore del carico di rete proxy regionale interno, verifica che il router Cloud annunci l'intervallo CIDR della subnet solo proxy tramite annunci di route BGP personalizzati.
  • Controlla lo stato del bilanciatore del carico interno: nella console Google Cloud , vai a Servizi di rete > Bilanciamento del carico e verifica che i backend del gruppo di endpoint di rete (NEG) di connettività ibrida per i servizi di backend di trasporto e metadati siano integri. Se un backend non è integro, controlla la connettività di interconnessione privata e le regole di sicurezza remote.
  • Testa la connettività da Google Cloud: crea un'istanza VM di test nella stessa rete VPC e subnet Google Cloud dell'endpoint del bilanciatore del carico interno o di Service Directory e testa la connettività agli indirizzi IP dell'interfaccia di rete elastica (ENI) AWS o dell'interfaccia di rete (NIC) dell'endpoint privato Azure sulla porta TCP 443 (ad esempio, utilizzando curl o nc).
  • Verifica la configurazione e le autorizzazioni di Service Directory: verifica che i servizi Service Directory configurati in --service-directory-name (per il trasporto delle query) e --metadata-service-directory-name (per l'aggiornamento dei metadati in background) si trovino nella stessa regione Google Cloud del tuo catalogo federato. Se un aggiornamento dei metadati in background per un catalogo federato non riesce con un errore Permission 'servicedirectory.services.resolve' denied, verifica che l'ID univoco del account di servizio del catalogo federato (campo biglake-service-account) disponga dei ruoli roles/servicedirectory.viewer e roles/servicedirectory.pscAuthorizedService in ogni progetto che ospita un servizio Service Directory.
  • Controlla i gruppi di sicurezza e le regole firewall: verifica che le regole firewallGoogle Cloud , i gruppi di sicurezza AWS e i gruppi di sicurezza di rete (NSG) di Azure consentano il traffico TCP sulla porta 443 tra gli intervalli CIDR VPC Google Cloud (incluso qualsiasi intervallo CIDR della subnet solo proxy) e i tuoi endpoint privati remoti.