Esegui il deployment dell'automazione del backup di BigQuery scalabile

Last reviewed 2024-09-17 UTC

Questo documento descrive come eseguire il deployment dell'automazione dei backup BigQuery scalabili.

Questo documento è rivolto ad architetti, ingegneri e responsabili della governance dei dati cloud che vogliono definire e automatizzare i criteri dei dati nelle loro organizzazioni. È utile avere esperienza con Terraform.

Architettura

Il seguente diagramma mostra l'architettura del backup automatico:

Cloud Scheduler attiva l'esecuzione. Il servizio di smistamento, che utilizza l'API BigQuery, elenca le tabelle in ambito. Tramite un messaggio Pub/Sub, il servizio di smistamento invia una richiesta per ogni tabella al servizio di configurazione. Il servizio di configurazione determina i criteri di backup per le tabelle, quindi invia una richiesta per ogni tabella al servizio Cloud Run pertinente. Il servizio Cloud Run invia quindi una richiesta all'API BigQuery e esegue le operazioni di backup. Pub/Sub attiva il servizio di tagging, che registra i risultati e aggiorna lo stato del backup nel livello dei metadati di Cloud Storage.

Per informazioni dettagliate sull'architettura, consulta Automatizzazione del backup di BigQuery scalabile.

Obiettivi

• Crea servizi Cloud Run.
• Configura le variabili Terraform.
• Esegui gli script Terraform e di deployment manuale.
• Esegui la soluzione.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

• BigQuery
• Pub/Sub
• Cloud Logging
• Cloud Run
• Cloud Storage
• Cloud Scheduler
• Firestore in Datastore mode (Datastore)

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Al termine delle attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per maggiori informazioni, consulta la sezione Eseguire la pulizia.

Prima di iniziare

Se stai eseguendo nuovamente il deployment della soluzione, puoi saltare questa sezione (ad esempio dopo nuovi commit).

In questa sezione crei risorse una tantum.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

2. Se vuoi creare un nuovo progetto Google Cloud da utilizzare come progetto host per il deployment, utilizza il comando gcloud projects create:

      gcloud projects create PROJECT_ID
   

   Sostituisci PROJECT_ID con l'ID del progetto che vuoi creare.

3. Installa Maven:

   1. Scarica Maven.

   2. In Cloud Shell, aggiungi Maven a PATH:

      export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
      

4. In Cloud Shell, clona il repository GitHub:

   git clone https://github.com/GoogleCloudPlatform/bq-backup-manager.git
   

5. Imposta ed esporta le seguenti variabili di ambiente:

   export PROJECT_ID=PROJECT_ID
   export TF_SA=bq-backup-mgr-terraform
   export COMPUTE_REGION=COMPUTE_REGION
   export DATA_REGION=DATA_REGION
   export BUCKET_NAME=${PROJECT_ID}-bq-backup-mgr
   export BUCKET=gs://${BUCKET_NAME}
   export DOCKER_REPO_NAME=docker-repo
   export CONFIG=bq-backup-manager
   export ACCOUNT=ACCOUNT_EMAIL
   
   gcloud config configurations create $CONFIG
   gcloud config set project $PROJECT_ID
   gcloud config set account $ACCOUNT
   gcloud config set compute/region $COMPUTE_REGION
   
   gcloud auth login
   gcloud auth application-default login
   

   Sostituisci quanto segue:

   • PROJECT_ID: l'ID del progetto host Google Cloud su cui vuoi eseguire il deployment della soluzione.
   • COMPUTE_REGION: la regione Google Cloud in cui vuoi eseguire il deployment di risorse di calcolo come Cloud Run e Identity and Access Management (IAM).
   • DATA_REGION: la regione Google Cloud in cui vuoi eseguire il deployment delle risorse di dati (come bucket e set di dati).
   • ACCOUNT_EMAIL: l'indirizzo email dell'account utente.

6. Abilita le API:

   ./scripts/enable_gcp_apis.sh
   

   Lo script abilita le seguenti API:

   • API Cloud Resource Manager
   • API IAM
   • API Data Catalog
   • API Artifact Registry
   • API BigQuery
   • API Pub/Sub
   • API Cloud Storage
   • API Cloud Run Admin
   • API Cloud Build
   • API Service Usage
   • API App Engine Admin
   • API Serverless VPC Access
   • API del cloud DNS

7. Prepara il bucket dello stato di Terraform:

   gsutil mb -p $PROJECT_ID -l $COMPUTE_REGION -b on $BUCKET
   

8. Prepara l'account di servizio Terraform:

   ./scripts/prepare_terraform_service_account.sh
   

9. Per pubblicare le immagini utilizzate da questa soluzione, prepara un repository Docker:

   gcloud artifacts repositories create $DOCKER_REPO_NAME
     --repository-format=docker \
     --location=$COMPUTE_REGION \
     --description="Docker repository for backups"
   

Esegui il deployment dell'infrastruttura

Assicurati di aver completato la sezione Prima di iniziare almeno una volta.

In questa sezione, segui i passaggi per eseguire il deployment o il nuovo deployment del codice di base più recente nell'ambiente Google Cloud.

Attiva la configurazione gcloud CLI

• In Cloud Shell, attiva e autentica la configurazione gcloud CLI:

  gcloud config configurations activate $CONFIG
  
  gcloud auth login
  gcloud auth application-default login
  

Creare immagini dei servizi Cloud Run

• In Cloud Shell, crea ed esegui il deployment di immagini Docker da utilizzare dal servizio Cloud Run:

  export DISPATCHER_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-dispatcher-service:latest
  export CONFIGURATOR_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-configurator-service:latest
  export SNAPSHOTER_BQ_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-bq-service:latest
  export SNAPSHOTER_GCS_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-gcs-service:latest
  export TAGGER_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-tagger-service:latest
  
  ./scripts/deploy_services.sh
  

Configura le variabili Terraform

Questo deployment utilizza Terraform per le configurazioni e uno script di deployment.

1. In Cloud Shell, crea un nuovo file TFVARS di Terraform in cui puoi sostituire le variabili in questa sezione:

   export VARS=FILENAME
   .tfvars
   

   Sostituisci FILENAME con il nome del file delle variabili che hai creato (ad esempio my-variables). Puoi utilizzare il file example-variables come riferimento.

2. Nel file TFVARS, configura le variabili del progetto:

   project = "PROJECT_ID"
   compute_region = "COMPUTE_REGION"
   data_region = "DATA_REGION"
   

   Puoi utilizzare i valori predefiniti definiti nel variables.tf o modificarli.

3. Configura l'account di servizio Terraform che hai creato e preparato in precedenza in Prima di iniziare:

   terraform_service_account =
   "bq-backup-mgr-terraform@PROJECT_ID.iam.gserviceaccount.com"
   

   Assicurati di utilizzare l'indirizzo email completo dell'account che hai creato.

4. Configura i servizi Cloud Run in modo da utilizzare le immagini container che hai creato ed eseguito in precedenza:

   dispatcher_service_image     = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-dispatcher-service:latest"
   configurator_service_image   = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-configurator-service:latest"
   snapshoter_bq_service_image  = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-bq-service:latest"
   snapshoter_gcs_service_image = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-gcs-service:latest"
   tagger_service_image         = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-tagger-service:latest"
   

   Questo script indica a Terraform di utilizzare queste immagini pubblicate nei servizi Cloud Run, che Terraform crea in un secondo momento.

   Terraform collega un servizio Cloud Run solo a un'immagine esistente. Non genera le immagini dal codice di base, perché questa operazione è stata completata in un passaggio precedente.

5. Nella variabile schedulers, definisci almeno un programmatore. Lo scheduler elenca e controlla periodicamente le tabelle per verificare la presenza dei backup richiesti, in base alle relative pianificazioni cron dei backup a livello di tabella.

   {
   name    = "SCHEDULER_NAME"
   cron    = "SCHEDULER_CRON"
   payload = {
       is_force_run = FORCE_RUN
       is_dry_run   = DRY_RUN
   
       folders_include_list  = [FOLDERS_INCLUDED]
       projects_include_list = [PROJECTS_INCLUDED]
       projects_exclude_list = [PROJECTS_EXCLUDED]
       datasets_include_list =  [DATASETS_INCLUDED]
       datasets_exclude_list =  [DATASETS_EXCLUDED]
       tables_include_list   =  [TABLES_INCLUDED]
       tables_exclude_list   =  [TABLES_EXCLUDED]
       }
   }
   

   Sostituisci quanto segue:

   • SCHEDULER_NAME: il nome visualizzato di Cloud Scheduler.
   • SCHEDULER_CRON: la frequenza con cui lo scheduler controlla se è dovuto un backup per le tabelle nell'ambito, in base alle relative pianificazioni dei backup. Può essere qualsiasi stringa compatibile con unix-cron. Ad esempio, 0 * * * * è una frequenza oraria.
   • FORCE_RUN: un valore booleano. Imposta il valore su false se vuoi che lo scheduler utilizzi le pianificazioni cron delle tabelle. Se impostato su true, viene eseguito il backup di tutte le tabelle nell'ambito, indipendentemente dall'impostazione di cron.
   • DRY_RUN: un valore booleano. Se impostato su true, non vengono eseguite operazioni di backup effettive. Vengono generati solo i messaggi di log. Utilizza true quando vuoi testare e eseguire il debug della soluzione senza sostenere costi di backup.
   • FOLDERS_INCLUDED: un elenco di ID numerici per le cartelle contenenti i dati BigQuery (ad es. 1234, 456). Se impostato, la soluzione esegue il backup delle tabelle nelle cartelle specificate e ignora le impostazioni dei campi projects_include_list, datasets_include_list e tables_include_list.
   • PROJECTS_INCLUDED: un elenco di nomi di progetti (ad esempio "project1", "project2"). Se impostato, la soluzione esegue il backup delle tabelle nei progetti specificati e ignora le impostazioni dei campi datasets_include_list e tables_include_list. Questa impostazione viene ignorata se imposti il campo folders_include_list.
   • PROJECTS_EXCLUDED: un elenco di nomi di progetti o di espressioni regolari (ad esempio "project1", "regex:^test_"). Se impostato, la soluzione non esegue il backup delle tabelle nei progetti specificati. Puoi utilizzare questa impostazione in combinazione con il campo folders_include_list.
   • DATASETS_INCLUDED: un elenco di set di dati (ad esempio "project1.dataset1", "project1.dataset2"). Se impostato, la soluzione esegue il backup delle tabelle nei set di dati specificati e ignora l'impostazione del campo tables_include_list. Questa impostazione viene ignorata se imposti i campi folders_include_list o projects_include_list.
   • DATASETS_EXCLUDED: un elenco di set di dati o un'espressione regolare (ad esempio "project1.dataset1", "regex:.*\\_landing$"). Se impostato, la soluzione non esegue il backup delle tabelle nei set di dati specificati. Puoi utilizzare questa impostazione in combinazione con i campi folders_include_list o projects_include_list.
   • TABLES_INCLUDED: un elenco di tabelle (ad esempio, "project1.dataset1.table 1", "project1.dataset2.table2"). Se impostato, la soluzione esegue il backup delle tabelle specificate. Questa impostazione viene ignorata se imposti i campi folders_include_list, projects_include_list o datasets_include_list.
   • TABLES_EXCLUDED: un elenco di tabelle o un'espressione regolare (ad es. "project1.dataset1.table 1", "regex:.*\_test"). Se impostato, la soluzione non esegue i backup delle tabelle specificate. Puoi utilizzare questa impostazione in combinazione con i campi folders_include_list, projects_include_list o datasets_include_list.

   Tutti gli elenchi di esclusione accettano espressioni regolari nel formatoregex:REGULAR_EXPRESSION.

   Se il nome della voce completo (ad es. "project.dataset.table") corrisponde a una delle espressioni regolari fornite, viene escluso dall'ambito del backup.

   Di seguito sono riportati alcuni casi d'uso comuni:

   • Escludi tutti i nomi dei set di dati che terminano con _landing: datasets_exclude_list = ["regex:.*\\_landing$"]
   • Escludi tutte le tabelle che terminano con _test, _tst, _bkp o _copy: tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

Definire i criteri di riserva

A ogni esecuzione, la soluzione deve determinare il criterio di backup di ogni tabella in ambito. Per ulteriori informazioni sui tipi di criteri, consulta Criteri di backup. Questa sezione mostra come definire un criterio di riserva.

Un criterio di riserva è definito con una variabile default_policy e un insieme di eccezioni o sostituzioni a diversi livelli (cartella, progetto, set di dati e tabella). Questo approccio offre flessibilità granulare senza la necessità di una voce per ogni tabella.

Esistono insiemi aggiuntivi di campi di criteri, a seconda del metodo di backup che decidi di utilizzare: snapshot di BigQuery, esportazioni in Cloud Storage o entrambi.

1. Nel file TFVARS, per la variabile default_policy, imposta i seguenti campi comuni per il criterio predefinito:

   fallback_policy = {
     "default_policy" : {
       "backup_cron" : "BACKUP_CRON"
       "backup_method" : "BACKUP_METHOD",
       "backup_time_travel_offset_days" : "OFFSET_DAYS",
       "backup_storage_project" : "BACKUP_STORAGE_PROJECT",
       "backup_operation_project" : "BACKUP_OPERATIONS_PROJECT",
   
   

   Sostituisci quanto segue:

   • BACKUP_CRON: un'espressione cron per impostare la frequenza con cui viene eseguito il backup di una tabella (ad esempio, per i backup ogni 6 ore, specifica 0 0 */6 * * *). Deve essere un'espressione cron compatibile con Spring-Framework.
   • BACKUP_METHOD: il metodo, specificato come BigQuery Snapshot, GCS Snapshot (per utilizzare il metodo di esportazione in Cloud Storage) o Both. Devi fornire i campi obbligatori per ogni metodo di backup scelto, come mostrato di seguito.
   • OFFSET_DAYS: il numero di giorni nel passato che determina il punto in cui eseguire il backup delle tabelle. I valori possono essere un numero tra 0 e 7.
   • BACKUP_STORAGE_PROJECT: l'ID del progetto in cui sono archiviate tutte le operazioni di snapshot ed esportazione. Si tratta dello stesso progetto in cui si trovano bq_snapshot_storage_dataset e gcs_snapshot_storage_location. I piccoli implementazioni possono utilizzare il progetto host, ma le implementazioni su larga scala devono utilizzare un progetto separato.
   • BACKUP_OPERATIONS_PROJECT: un'impostazione facoltativa in cui specifichi l'ID del progetto in cui vengono eseguite tutte le operazioni di snapshot ed esportazione. A questo progetto si applicano quote e limiti per i job di istantanea ed esportazione. Può essere lo stesso valore di backup_storage_project. Se non è impostato, la soluzione utilizza il progetto della tabella di origine.

2. Se hai specificato BigQuery Snapshot o Both come backup_method, aggiungi i seguenti campi dopo i campi comuni, nella variabile default_policy:

     "bq_snapshot_expiration_days" : "SNAPSHOT_EXPIRATION",
     "bq_snapshot_storage_dataset" : "DATASET_NAME",
   

   Sostituisci quanto segue:

   • SNAPSHOT_EXPIRATION: il numero di giorni per conservare ogni istantanea (ad esempio 15).
   • DATASET_NAME: il nome del set di dati in cui archiviare gli snapshot (ad es. backups). Il set di dati deve già esistere nel progetto specificato per backup_storage_project.

3. Se hai specificato GCS Snapshot (per utilizzare il metodo di esportazione in Cloud Storage) o Both come backup_method, aggiungi i seguenti campi alla variabile default_policy:

     "gcs_snapshot_storage_location" : "STORAGE_BUCKET",
     "gcs_snapshot_format" : "FILE_FORMAT",
     "gcs_avro_use_logical_types" : AVRO_TYPE,
     "gcs_csv_delimiter" : "CSV_DELIMITER",
     "gcs_csv_export_header" : CSV_EXPORT_HEADER
   

   Sostituisci quanto segue:

   • STORAGE_BUCKET: il bucket Cloud Storage in cui memorizzare i dati esportati nel formato gs://bucket/path/. Ad esempio, gs://bucket1/backups/.
   • FILE_FORMAT: il formato e la compressione del file utilizzati per esportare una tabella BigQuery in Cloud Storage. I valori disponibili sono CSV, CSV_GZIP, JSON, JSON_GZIP, AVRO, AVRO_DEFLATE, AVRO_SNAPPY, PARQUET, PARQUET_SNAPPY e PARQUET_GZIP.
   • AVRO_TYPE: un valore booleano. Se impostato su false, i tipi BigQuery vengono esportati come stringhe. Se impostato su true, i tipi vengono esportati come corrispondente tipo logico Avro. Questo campo è obbligatorio quando gcs_snapshot_format è un formato di tipo Avro.
   • CSV_DELIMITER: il delimitatore utilizzato per i file CSV esportati. Il valore può essere qualsiasi carattere ISO-8859-1 a un byte. Puoi utilizzare \t o tab per specificare i delimitatori di tabulazione. Questo campo è obbligatorio quando gcs_snapshot_format è un formato di tipo CSV.
   • CSV_EXPORT_HEADER: un valore booleano. Se impostato su true, le intestazioni delle colonne vengono esportate nei file CSV. Questo campo è obbligatorio quando gcs_snapshot_format è un formato di tipo CSV.

   Per i dettagli e la mappatura dei tipi Avro, consulta la seguente tabella:

   Tipo BigQuery	Tipo logico Avro
   TIMESTAMP	timestamp-micros (annota Avro LONG)
   DATE	date (annota Avro INT)
   TIME	timestamp-micro (annota Avro LONG)
   DATETIME	STRING (tipo logico denominato personalizzato datetime)

4. Aggiungi variabili di override per cartelle, progetti, set di dati e tabelle specifici:

     },
     "folder_overrides" : {
      "FOLDER_NUMBER" : {
      },
     },
   
     "project_overrides" : {
      "PROJECT_NAME" : {
      }
     },
   
     "dataset_overrides" : {
      "PROJECT_NAME.DATASET_NAME" : {
      }
     },
   
     "table_overrides" : {
      "PROJECT_NAME.DATASET_NAME.TABLE_NAME" : {
      }
     }
   }
   

   Sostituisci quanto segue:

   • FOLDER_NUMBER: specifica la cartella per la quale vuoi impostare i campi di override.
   • PROJECT_NAME: specifica il progetto quando imposti i campi di override per un determinato progetto, set di dati o tabella.
   • DATASET_NAME: specifica il set di dati quando imposti i campi di override per un determinato set di dati o una determinata tabella.
   • TABLE_NAME: specifica la tabella per la quale vuoi impostare i campi di override.

   Per ogni voce di override, ad esempio un progetto specifico nella variabile project_overrides, aggiungi i campi comuni e quelli obbligatori per il metodo di backup specificato in precedenza in default_policy.

   Se non vuoi impostare sostituzioni per un determinato livello, imposta la variabile su una mappa vuota (ad es. project_overrides : {}).

   Nell'esempio seguente, i campi di override sono impostati per una tabella specifica che utilizza il metodo di snapshot di BigQuery:

     },
     "project_overrides" : {},
   
     "table_overrides" : {
      "example_project1.dataset1.table1" : {
       "backup_cron" : "0 0 */5 * * *", # every 5 hours each day
       "backup_method" : "BigQuery Snapshot",
       "backup_time_travel_offset_days" : "7",
       "backup_storage_project" : "project name",
       "backup_operation_project" : "project name",
       # bq settings
       "bq_snapshot_expiration_days" : "14",
       "bq_snapshot_storage_dataset" : "backups2"
       },
      }
   }
   

Per un esempio completo di criteri di riserva, consulta il file example-variables.

Configurare progetti di operazioni di backup aggiuntivi

• Se vuoi specificare progetti di backup aggiuntivi, ad esempio quelli definiti nelle configurazioni esterne (criterio di backup a livello di tabella) o nei progetti di origini tabella, configura la seguente variabile:

  additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
  

  Sostituisci ADDITIONAL_BACKUPS con un elenco separato da virgola di nomi di progetti (ad esempio "project1", "project2"). Se utilizzi solo il criterio di backup di riserva senza criteri esterni a livello di tabella, puoi impostare il valore su un elenco vuoto.

  Se non aggiungi questo campo, tutti i progetti specificati nel campo facoltativo backup_operation_project vengono inclusi automaticamente come progetti di backup.

Configura le autorizzazioni dell'account di servizio Terraform

Nei passaggi precedenti, hai configurato i progetti di backup in cui vengono eseguite le operazioni di backup. Terraform deve eseguire il deployment delle risorse in questi progetti di backup.

L'account di servizio utilizzato da Terraform deve disporre delle autorizzazioni richieste per questi progetti di backup specificati.

• In Cloud Shell, concedi le autorizzazioni dell'account di servizio per tutti i progetti in cui vengono eseguite le operazioni di backup:

  ./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
  

  Sostituisci quanto segue:

  • BACKUP_OPERATIONS_PROJECT: tutti i progetti definiti nei campi backup_operation_project in uno dei criteri di riserva e dei criteri a livello di tabella.
  • DATA_PROJECTS: se non è definito un campo backup_operation_project in un criterio di riserva o a livello di tabella, includi i progetti per le tabelle di origine.
  • ADDITIONAL_BACKUPS: tutti i progetti definiti nella variabile Terraform additional_backup_operation_projects.

Esegui gli script di deployment

1. In Cloud Shell, esegui lo script di deployment di Terraform:

   cd terraform
   
   terraform init \
       -backend-config="bucket=${BUCKET_NAME}" \
       -backend-config="prefix=terraform-state" \
       -backend-config="impersonate_service_account=$TF_SA@$PROJECT_ID.iam.gserviceaccount.com"
   
   terraform plan -var-file=$VARS
   
   terraform apply -var-file=$VARS
   

2. Aggiungi i criteri di durata (TTL) per Firestore:

   
   gcloud firestore fields ttls update expires_at \
       --collection-group=project_folder_cache \
       --enable-ttl \
       --async \
       --project=$PROJECT_ID
   

   La soluzione utilizza Datastore come cache in alcune situazioni. Per risparmiare sui costi e migliorare le prestazioni di ricerca, il criterio TTL consente a Firestore di eliminare automaticamente le voci scadute.

Configurare l'accesso a origini e destinazioni

1. In Cloud Shell, imposta le seguenti variabili per gli account di servizio utilizzati dalla soluzione:

   export SA_DISPATCHER_EMAIL=dispatcher@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_CONFIGURATOR_EMAIL=configurator@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_SNAPSHOTER_BQ_EMAIL=snapshoter-bq@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_SNAPSHOTER_GCS_EMAIL=snapshoter-gcs@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_TAGGER_EMAIL=tagger@${PROJECT_ID}.iam.gserviceaccount.com
   

   Se hai modificato i nomi predefiniti in Terraform, aggiorna le email dell'account di servizio.

2. Se hai impostato il campo folders_include_list e vuoi impostare l'ambito della scansione BigQuery in modo da includere determinate cartelle, concedi le autorizzazioni richieste a livello di cartella:

   ./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
   

3. Per consentire all'applicazione di eseguire le attività necessarie in progetti diversi, concedi le autorizzazioni richieste a ciascuno di questi progetti:

   ./scripts/prepare_data_projects.sh DATA_PROJECTS
   ./scripts/prepare_backup_storage_projects.sh BACKUP_STORAGE_PROJECT
   ./scripts/prepare_backup_operation_projects.sh BACKUP_OPERATIONS_PROJECT
   

   Sostituisci quanto segue:

   • DATA_PROJECTS: i progetti di dati (o progetti di origine) che contengono le tabelle di origine di cui vuoi eseguire il backup (ad esempio project1 project2). Includi i seguenti progetti:

     • I progetti specificati negli elenchi di inclusione nella variabile Terraform schedulers.
     • Se vuoi eseguire il backup delle tabelle nel progetto host, includi il progetto host.

   • BACKUP_STORAGE_PROJECT: i progetti di archiviazione dei backup (o progetti di destinazione) in cui la soluzione archivia i backup (ad esempio,project1 project2). Devi includere i progetti specificati nei seguenti campi:

     • I campi backup_storage_project in tutti i criteri di riserva.
     • I campi backup_storage_project in tutti i criteri a livello di tabella.

     Includi i progetti di archiviazione di backup utilizzati in più campi o come progetto di origine e di destinazione

   • BACKUP_OPERATIONS_PROJECT: i progetti di operazioni sui dati in cui la soluzione esegue le operazioni di backup (ad esempio project1 project2). Devi includere i progetti specificati nei seguenti campi:

     • I campi backup_operation_project in tutti i criteri di riserva.
     • Tutti gli elenchi di inclusione nell'ambito della scansione BigQuery (se non imposti il campo backup_operation_project).
     • I campi backup_operation_project in tutti i criteri a livello di tabella.

     Includi i progetti di operazioni di backup utilizzati in più campi o che vengono utilizzati sia come progetto di origine sia come progetto di destinazione.

4. Per le tabelle che utilizzano il controllo dell'accesso a livello di colonna, identifica tutte le tassonomie dei tag di criteri utilizzate dalle tabelle (se presenti) e concedi agli account di servizio della soluzione l'accesso ai dati delle tabelle:

   TAXONOMY="projects/TAXONOMY_PROJECT/locations/TAXONOMY_LOCATION/taxonomies/TAXONOMY_ID"
   
   gcloud data-catalog taxonomies add-iam-policy-binding \
   $TAXONOMY \
   --member="serviceAccount:${SA_SNAPSHOTER_BQ_EMAIL}" \
   --role='roles/datacatalog.categoryFineGrainedReader'
   
   gcloud data-catalog taxonomies add-iam-policy-binding \
   $TAXONOMY \
   --member="serviceAccount:${SA_SNAPSHOTER_GCS_EMAIL}" \
   --role='roles/datacatalog.categoryFineGrainedReader'
   

   Sostituisci quanto segue:

   • TAXONOMY_PROJECT: l'ID progetto nella la tassonomia dei tag di criteri
   • TAXONOMY_LOCATION: la posizione specificata nella tassonomia dei tag di criteri
   • TAXONOMY_ID: l'ID della tassonomia dei tag criterio

5. Ripeti il passaggio precedente per ogni tassonomia dei tag di criteri.

Esegui la soluzione

Dopo aver eseguito il deployment della soluzione, utilizza le sezioni seguenti per eseguirla e gestirla.

Impostare i criteri di backup a livello di tabella

• In Cloud Shell, crea un criterio a livello di tabella con i campi obbligatori, quindi archivialo nel bucket Cloud Storage per i criteri:

  # Use the default backup policies bucket unless overwritten in the .tfvars
  export POLICIES_BUCKET=${PROJECT_ID}-bq-backup-manager-policies
  
  # set target table info
  export TABLE_PROJECT='TABLE_PROJECT'
  export TABLE_DATASET='TABLE_DATASET'
  export TABLE='TABLE_NAME'
  
  # Config Source must be 'MANUAL' when assigned this way
  export BACKUP_POLICY="{
  'config_source' : 'MANUAL',
  'backup_cron' : 'BACKUP_CRON',
  'backup_method' : 'BACKUP_METHOD',
  'backup_time_travel_offset_days' : 'OFFSET_DAYS',
  'backup_storage_project' : 'BACKUP_STORAGE_PROJECT',
  'backup_operation_project' : 'BACKUP_OPERATION_PROJECT',
  'gcs_snapshot_storage_location' : 'STORAGE_BUCKET',
  'gcs_snapshot_format' : 'FILE_FORMAT',
  'gcs_avro_use_logical_types' : 'AVRO_TYPE',
  'bq_snapshot_storage_dataset' : 'DATASET_NAME',
  'bq_snapshot_expiration_days' : 'SNAPSHOT_EXPIRATION'
  }"
  
  # File name MUST BE backup_policy.json
  echo $BACKUP_POLICY >> backup_policy.json
  
  gsutil cp backup_policy.json gs://${POLICIES_BUCKET}/policy/project=${TABLE_PROJECT}/dataset=${TABLE_DATASET}/table=${TABLE}/backup_policy.json
  

  Sostituisci quanto segue:

  • TABLE_PROJECT: il progetto in cui si trova la tabella
  • TABLE_DATASET: il set di dati della tabella
  • TABLE_NAME: il nome della tabella

Attivare le operazioni di backup

I job Cloud Scheduler che hai configurato in precedenza vengono eseguiti automaticamente in base alla relativa espressione cron.

Puoi anche eseguire manualmente i job nella console Google Cloud. Per ulteriori informazioni, consulta Eseguire il job.

Monitoraggio e report

Dopo aver selezionato il progetto host (PROJECT_ID), puoi eseguire le seguenti query in BigQuery Studio per ottenere report e informazioni.

• Visualizza le statistiche di avanzamento di ogni esecuzione (incluse quelle in corso):

  SELECT * FROM `bq_backup_manager.v_run_summary_counts`
  

• Visualizza tutti gli errori irreversibili (non ripetibili) per una singola esecuzione:

  SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
  WHERE run_id = 'RUN_ID'
  

  Sostituisci RUN_ID con l'ID dell'esecuzione.

• Visualizza tutte le esecuzioni di una tabella e le relative informazioni di esecuzione:

  SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
  WHERE tablespec = 'project.dataset.table'
  

  Puoi anche specificare una versione grouped:

  SELECT * FROM `bq_backup_manager.v_audit_log_by_table_grouped`, UNNEST(runs) r
  WHERE r.run_has_retryable_error = FALSE
  

• Per il debug, puoi ottenere informazioni dettagliate su richieste e risposte per ogni chiamata di servizio:

  SELECT
  jsonPayload.unified_target_table AS tablespec,
  jsonPayload.unified_run_id AS run_id,
  jsonPayload.unified_tracking_id AS tracking_id,
  CAST(jsonPayload.unified_is_successful AS BOOL) AS configurator_is_successful,
  jsonPayload.unified_error AS configurator_error,
  CAST(jsonPayload.unified_is_retryable_error AS BOOL) AS configurator_is_retryable_error,
  CAST(JSON_VALUE(jsonPayload.unified_input_json, '$.isForceRun') AS BOOL) AS is_force_run,
  CAST(JSON_VALUE(jsonPayload.unified_output_json, '$.isBackupTime') AS BOOL) AS is_backup_time,
  JSON_VALUE(jsonPayload.unified_output_json, '$.backupPolicy.method') AS backup_method,
  CAST(JSON_VALUE(jsonPayload.unified_input_json, '$.isDryRun') AS BOOL) AS is_dry_run,
  jsonPayload.unified_input_json AS request_json,
  jsonPayload.unified_output_json AS response_json
  FROM `bq_backup_manager.run_googleapis_com_stdout`
  WHERE jsonPayload.global_app_log = 'UNIFIED_LOG'
  -- 1= dispatcher, 2= configurator, 3=bq snapshoter, -3=gcs snapshoter and 4=tagger
  AND jsonPayload.unified_component = "2"
  

• Visualizza i criteri di backup aggiunti manualmente o assegnati dal sistema in base ai valori di riserva:

  SELECT * FROM `bq_backup_manager.ext_backup_policies`
  

Limitazioni

Per ulteriori informazioni su limiti e quote per ogni progetto specificato nei campi backup_operation_project, consulta Limiti.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo deployment, elimina i progetti che contengono le risorse oppure mantieni i progetti ed elimina le singole risorse.

Elimina i progetti

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini elimini anche tutto il lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, il riuso dei progetti può aiutarti a non superare i limiti di quota.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Elimina le nuove risorse

In alternativa all'eliminazione dei progetti, puoi eliminare le risorse create durante questa procedura.

• In Cloud Shell, elimina le risorse Terraform:

  terraform destroy -var-file="${VARS}"
  

  Il comando elimina quasi tutte le risorse. Verifica che tutte le risorse che vuoi eliminare siano state rimosse.

Passaggi successivi

• Scopri di più su BigQuery:
  • Istantanee delle tabelle BigQuery
  • Esportazioni delle tabelle BigQuery in Cloud Storage
• Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.

Collaboratori

Autore: Karim Wadie | Strategic Cloud Engineer

Altri collaboratori:

• Chris DeForeest | Site Reliability Engineer
• Eyal Ben Ivri | Cloud Solutions Architect
• Jason Davenport | Developer Advocate
• Jaliya Ekanayake | Engineering Manager
• Muhammad Zain | Strategic Cloud Engineer