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. L'esperienza con Terraform è utile.

Architettura

Il seguente diagramma mostra l'architettura del backup automatico:

Cloud Scheduler attiva l'esecuzione. Il servizio di committenza, utilizzando l'API BigQuery, elenca le tabelle nell'ambito. Tramite un messaggio Pub/Sub, il servizio di supervisore 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 tagger, che registra i risultati e aggiorna lo stato del backup nel livello dei metadati di Cloud Storage.

Per maggiori dettagli sull'architettura, vedi Automazione del backup BigQuery scalabile.

Obiettivi

• Creare servizi Cloud Run.
• Configura le variabili Terraform.
• Eseguire 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 Pulizia.

Prima di iniziare

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

In questa sezione, creerai 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 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 (ad esempio bucket e set di dati).
   • ACCOUNT_EMAIL: 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 redeployment del codice di base più recente nell'ambiente Google Cloud.

Attiva la configurazione dell'interfaccia a riga di comando gcloud

• In Cloud Shell, attiva e autentica la configurazione dell'interfaccia a riga di comando gcloud:

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

Crea immagini dei servizi Cloud Run

• In Cloud Shell, crea ed esegui il deployment di immagini Docker che possono essere utilizzate il 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 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 modifica i valori.

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 crea le immagini dal codebase perché questa operazione è stata completata in un passaggio precedente.

5. Nella variabile schedulers, definisci almeno uno scheduler. Scheduler elenca e controlla periodicamente le tabelle per verificare la presenza dei backup richiesti, in base ai le 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 esegue i controlli se è previsto un backup per le tabelle nell'ambito, in base alle singole 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, tutti viene eseguito il backup delle tabelle nell'ambito, indipendentemente dalle impostazioni cron.
   • DRY_RUN: un valore booleano. Se impostato su true, non vengono eseguite operazioni di backup effettive. Vengono generati solo 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 progetto o un'espressione regolare (ad es. "project1", "regex:^test_"). Se impostata, la soluzione non ed eseguire backup delle tabelle nei progetti specificati. Puoi utilizzare questo 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 es. "project1.dataset1", "regex:.*\\_landing$"). Se impostato, il parametro soluzione non esegue backup delle tabelle nei set di dati specificati. Tu puoi utilizzare questa impostazione in combinazione con folders_include_list o projects_include_list campi.
   • 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 configuri folders_include_list, projects_include_list o datasets_include_list campi.
   • TABLES_EXCLUDED: un elenco di tabelle o un'espressione regolare (ad un esempio, "project1.dataset1.table 1", "regex:.*\_test"). Se impostata, la soluzione non esegue backup delle tabelle specificate. Puoi usare questa impostazione in combinazione con folders_include_list, projects_include_list o datasets_include_list campi.

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

   Se il nome completo della voce (ad esempio "project.dataset.table") corrisponde a una qualsiasi delle espressioni regolari fornite, è esclusa dal backup l'ambito di attività.

   Di seguito sono riportati alcuni casi d'uso comuni:

   • Escludi tutti i nomi di 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)"]

Definisci i criteri di fallback

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

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

Esistono insiemi aggiuntivi di campi dei 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 la 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 BigQuery Snapshot, GCS Snapshot (per utilizzare nel metodo Cloud Storage) o Both. Devi fornire campi obbligatori per ciascun 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 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 deployment di piccole dimensioni possono utilizzare il progetto host, mentre quelli su larga scala deve usare un progetto separato.
   • BACKUP_OPERATIONS_PROJECT: un'impostazione facoltativa, in cui e specificare 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 viene configurato, la soluzione utilizza il metodo progetto.

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 acquisizione 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, il valore 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 è di qualsiasi formato 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 dettagli e mappatura dei tipi Avro, consulta la tabella seguente:

   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 che vuoi impostare 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 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, impostalo a una mappa vuota (ad esempio, project_overrides : {}).

   Nell'esempio seguente, i campi di override sono impostati per una tabella specifica che utilizza il metodo snapshot 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 altri progetti di backup, come definito nelle configurazioni esterne (criterio di backup a livello di tabella) o nella tabella progetti di origine, configura la seguente variabile:

  additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
  

  Sostituisci ADDITIONAL_BACKUPS con un elenco separato da virgole 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 imposta il valore su un elenco vuoto.

  Se non aggiungi questo campo, tutti i progetti specificati nel campo facoltativobackup_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 dell'esecuzione delle operazioni. Terraform deve eseguire il deployment delle risorse nei 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 è presente alcun campo backup_operation_project definiti in un criterio di riserva o a livello di tabella, includi i progetti 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 alcuni in situazioni diverse. 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 il 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 quelli di origine) che contenere 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 la 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 fallback.
     • I campi backup_storage_project in tutti i criteri a livello di tabella.

     Includi progetti di archiviazione di backup utilizzati in più campi o che vengono utilizzati sia come progetto di origine che 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 fallback.
     • Tutti gli elenchi di inclusione che rientrano nell'ambito di BigQuery scansione (se non imposti il campo backup_operation_project).
     • I campi backup_operation_project in tutti i criteri a livello di tabella.

     Includi progetti delle operazioni di backup utilizzati in più campi oppure utilizzati sia come progetto di origine che di destinazione.

4. Per le tabelle che utilizzano il controllo dell'accesso a livello di colonna, identifica tutte le tassonomie dei tag delle norme 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 in la tassonomia dei tag di criteri
   • TAXONOMY_LOCATION: la posizione specificata nella tassonomia dei tag di criteri
   • TAXONOMY_ID: l'ID tassonomia del criterio tassonomia dei tag

5. Ripeti il passaggio precedente per ciascuna 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 risiede 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.

Monitora e segnala

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 fatali (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.

• Ottieni tutte le esecuzioni su 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 di 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 vengono rimosse.

Passaggi successivi

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

Collaboratori

Autore: Karim Wadie | Strategic Cloud Engineer

Altri collaboratori:

• Chris DeForeest | Site Reliability Engineer
• Eyal Ben Ivri | Cloud Solutions Architect
• Giulio Verdi | Consulente per gli sviluppatori
• Giulia Ekanayake | Responsabile tecnico
• Muhammad Zain | Tecnico cloud strategico