Eseguire la migrazione dei metadati dai cataloghi di dati esterni alle tabelle del catalogo REST di Lakehouse per Apache Iceberg

Anteprima

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Nota: per ricevere assistenza o fornire feedback su questa funzionalità, contatta [e-mail].

Questo documento spiega come eseguire la migrazione dei metadati dai cataloghi di dati esterni alle tabelle del catalogo REST di Lakehouse per Apache Iceberg. BigQuery Migration Service supporta la migrazione dei metadati dai seguenti metastore esterni:

• Metastore Apache Hive
• Cataloghi REST Apache Iceberg

Limitazioni

**Avviso:** la modifica dei dati nelle tabelle di origine e di destinazione dopo una migrazione può comportare la perdita di dati.

• Le migrazioni dei metadati dai cataloghi di dati esterni alle tabelle del catalogo REST di Lakehouse per Apache Iceberg sono una sincronizzazione una tantum. Questa funzionalità non supporta sincronizzazioni continue o periodiche, quindi le scritture eseguite dopo la migrazione non sono visibili finché non esegui di nuovo la migrazione.
• Gli spazi dei nomi nidificati non sono supportati.
• Il catalogo REST Iceberg supporta solo i file di dati Parquet.
• Lakehouse non supporta le tabelle Apache Iceberg V3.
• Le migrazioni dei metadati dai cataloghi di dati esterni alle tabelle del catalogo REST di Lakehouse per Apache Iceberg supportano solo le migrazioni di un massimo di 10.000 tabelle. Se il tuo carico di lavoro richiede l'elaborazione di più di 10.000 tabelle, ti consigliamo di suddividerlo in più migrazioni.
• Le migrazioni dei metadati dai cataloghi di dati esterni alle tabelle del catalogo REST di Lakehouse per Apache Iceberg non supportano l'utilizzo di policy dell'organizzazione per applicare la condivisione con limitazioni di dominio.

Prima di iniziare

Prima di poter eseguire la migrazione dei metadati dai cataloghi di dati esterni, devi completare i passaggi nelle sezioni seguenti.

Abilitare le API

Abilita le API BigLake, BigQuery Data Transfer, BigQuery Migration, Secret Manager e Storage Transfer.

Ruoli richiesti per abilitare le API

Per abilitare le API, devi disporre del ruolo IAM Amministratore Service Usage (roles/serviceusage.serviceUsageAdmin), che contiene l'autorizzazione serviceusage.services.enable. Scopri come concedere i ruoli.

Abilitare le API

Quando abiliti l'API Data Transfer, viene creato un service agent.

Configurare le autorizzazioni

1. All'utente o al account di servizio che crea il trasferimento deve essere concesso il ruolo Amministratore BigQuery (roles/bigquery.admin). Se utilizzi un account di servizio, questo viene utilizzato solo per creare il trasferimento.

2. Quando abiliti l'API Data Transfer, viene creato un service agent (P4SA).

   Per assicurarti che il service agent disponga delle autorizzazioni necessarie per eseguire un trasferimento del metastore Hive, chiedi all'amministratore di concedere al service agent i seguenti ruoli IAM sul progetto:

   Importante: devi concedere questi ruoli al service agent, non al tuo account utente. Se non concedi i ruoli all'entità principale corretta, potrebbero verificarsi errori di autorizzazione.
   • Amministratore Storage Transfer (roles/storagetransfer.admin)
   • Service Usage Consumer (roles/serviceusage.serviceUsageConsumer)
   • Amministratore spazio di archiviazione (roles/storage.admin)
   • Per eseguire la migrazione dei metadati al catalogo runtime Lakehouse (catalogo REST Iceberg o catalogo Hive): Amministratore BigLake (roles/biglake.admin)
   • Per eseguire la migrazione dei metadati a Dataproc Metastore: Proprietario dei metadati di Dataproc Metastore (roles/metastore.metadataOwner)

   Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

   L'amministratore potrebbe anche essere in grado di concedere al service agent le autorizzazioni richieste tramite ruoli personalizzati o altri ruoli predefiniti.

3. Se utilizzi un account di servizio, concedi al service agent il ruolo roles/iam.serviceAccountTokenCreator con il seguente comando:

   gcloud iam service-accounts add-iam-policy-binding
   SERVICE_ACCOUNT --member
   serviceAccount:[e-mail] --role
   roles/iam.serviceAccountTokenCreator

4. Concedi al service agent di Storage Transfer Service ([e-mail]) i seguenti ruoli nel progetto:

   • roles/storage.admin
   • Se esegui la migrazione da un ambiente on-premise/HDFS, devi concedere anche il ruolo roles/storagetransfer.serviceAgent.

   Puoi anche configurare autorizzazioni più granulari. Per ulteriori informazioni, consulta la seguente guida:

   • Autorizzazioni HDFS
   • Autorizzazioni Amazon S3 e Microsoft Azure

Ruoli e autorizzazioni utente richiesti

Per assicurarti che il service agent disponga delle autorizzazioni necessarie per creare, modificare ed eseguire una migrazione delle tabelle del catalogo REST di Lakehouse per Apache Iceberg, chiedi all'amministratore di concedere al service agent i seguenti ruoli IAM sull'utente:

Importante: devi concedere questi ruoli al service agent, non al tuo account utente. Se non concedi i ruoli all'entità principale corretta, potrebbero verificarsi errori di autorizzazione.

• Utente Service Account (roles/iam.serviceAccountUser)
• Editor di gestione della migrazione (roles/bigquerymigration.migrationEditor)

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

L'amministratore potrebbe anche essere in grado di concedere al service agent le autorizzazioni richieste tramite ruoli personalizzati o altri ruoli predefiniti.

Ruoli e autorizzazioni del account di servizio richiesti

Per assicurarti che il account di servizio fornito dal cliente disponga delle autorizzazioni necessarie per creare, modificare ed eseguire una migrazione delle tabelle del catalogo REST di Lakehouse per Apache Iceberg, chiedi all'amministratore di concedere al account di servizio fornito dal cliente i seguenti ruoli IAM:

Importante: devi concedere questi ruoli al account di servizio fornito dal cliente, non al tuo account utente. Se non concedi i ruoli all'entità principale corretta, potrebbero verificarsi errori di autorizzazione.

• Accesso al collegamento di rete: Amministratore rete Compute (roles/compute.networkAdmin) sul account di servizio
• Accesso a BigQuery Data Transfer Service: Amministratore BigQuery (roles/bigquery.admin) sul account di servizio
• Accesso alle risorse di Lakehouse: Editor BigLake (roles/biglake.editor) sul account di servizio
• Accesso ai secret: Funzione di accesso ai secret di Secret Manager (roles/secretmanager.secretAccessor) sul secret fornito dal cliente

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

L'amministratore potrebbe anche essere in grado di concedere al account di servizio fornito dal cliente le autorizzazioni richieste tramite ruoli personalizzati o altri ruoli predefiniti.

Devi anche concedere al service agent il ruolo roles/iam.serviceAccountTokenCreator con il seguente comando:

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT --member user:[e-mail] --role roles/iam.serviceAccountTokenCreator --project PROJECT_ID

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT --member [e-mail] --role roles/iam.serviceAccountTokenCreator --project PROJECT_ID

Sostituisci quanto segue:

• SERVICE_ACCOUNT: l'ID del account di servizio
• PROJECT_ID: l'ID del progetto

Configurare il secret

Se esegui la migrazione a un catalogo REST Apache Iceberg, devi creare un secret per autorizzare la migrazione. Il secret deve essere formattato nel seguente modo:

{
  "client_id": "CLIENT_ID",
  "client_secret": "CLIENT_SECRET<",
  "polaris_realm": "POLARIS_REALM"
  "scope": "SCOPE"
}

Sostituisci quanto segue:

• CLIENT_ID: l'ID client OAuth 2.0
• CLIENT_SECRET: il client secret OAuth 2.0
• POLARIS_REALM: il realm per il catalogo Polaris. Questo campo è obbligatorio solo per Apache Polaris. Ad esempio, FINANCE.
• SCOPE: (facoltativo) l'ambito OAuth 2.0. Il valore predefinito è PRINCIPAL_ROLE:ALL.

Creare un catalogo Lakehouse

Crea un catalogo Lakehouse. I metadati di cui è stata eseguita la migrazione vengono archiviati nel bucket Cloud Storage che hai specificato quando hai creato il catalogo.

Eseguire la migrazione dei metadati

Per avviare una migrazione dei metadati alle tabelle del catalogo REST di Lakehouse Iceberg:

1. Nella Google Cloud console, vai alla pagina Migrazione > Servizi.

   Vai ai servizi di migrazione

2. In Registra o migra la lakehouse aperta, fai clic su Crea migrazione.

3. In Configurazione della migrazione:

   1. In Tipo di catalogo, seleziona un catalogo esterno.

   2. In Regione, seleziona una regione. La regione selezionata determina dove viene eseguita l'orchestrazione della migrazione e il trasferimento dei dati. Determina anche dove il servizio di migrazione utilizza o crea risorse, come collegamenti di rete o secret.

      Sono supportati solo i secret regionali. La regione del secret deve corrispondere alla regione in questo campo.

   3. In Nome visualizzato della migrazione, inserisci un nome per questa migrazione.

4. In Configurazione del sistema di origine:

   1. In URL, inserisci l'URL dell'endpoint di base che funge da punto di ingresso per il metastore Apache Iceberg o Apache Hive.
   2. In Service account, seleziona un account di servizio dall'elenco. Se non specificato, questa migrazione viene eseguita utilizzando le credenziali utente.
   3. (Facoltativo) In Collegamento di rete, seleziona un collegamento di rete.

5. Fai clic su Continua.

Al termine della migrazione dei metadati, i metadati dei cataloghi esterni vengono archiviati nel bucket Cloud Storage che hai specificato quando hai creato il catalogo Lakehouse.

Prezzi

Il trasferimento dei metadati alle tabelle del catalogo REST di Lakehouse Iceberg non comporta costi. Una volta trasferiti i metadati, vengono applicati i prezzi di Lakehouse.