部署可擴充的 BigQuery 備份自動化功能

Last reviewed 2024-09-17 UTC

本文說明如何部署可擴充的 BigQuery 自動備份功能。

本文適用於雲端架構師、工程師和資料控管人員，協助他們在機構中定義及自動執行資料政策。具備 Terraform 使用經驗會有所幫助。

架構

下圖顯示自動備份架構：

Cloud Scheduler 會觸發執行作業。調度員服務會使用 BigQuery API 列出範圍內的資料表。透過 Pub/Sub 訊息，分派器服務會為每個資料表向設定器服務提交一項要求。設定器服務會判斷資料表的備份政策，然後為每個資料表向相關的 Cloud Run 服務提交一項要求。接著，Cloud Run 服務會向 BigQuery API 提交要求，並執行備份作業。Pub/Sub 會觸發標記器服務，該服務會記錄結果，並更新 Cloud Storage 中繼資料層的備份狀態。

如要瞭解架構詳情，請參閱「可擴充的 BigQuery 自動備份機制」。

目標

• 建構 Cloud Run 服務。
• 設定 Terraform 變數。
• 執行 Terraform 和手動部署指令碼。
• 執行解決方案。

費用

在本文件中，您會使用 Google Cloud的下列計費元件：

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

如要根據預測用量估算費用，請使用 Pricing Calculator。

初次使用 Google Cloud 的使用者可能符合免費試用資格。

完成本文所述工作後，您可以刪除已建立的資源，避免繼續計費。詳情請參閱清除所用資源一節。

事前準備

如果重新部署解決方案 (例如在新的提交後)，可以略過這個部分。

在本節中，您將建立一次性資源。

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

   Activate Cloud Shell

2. 如要建立新的 Google Cloud 專案做為部署作業的主專案，請使用 gcloud projects create 指令：

      gcloud projects create PROJECT_ID
   

   將 PROJECT_ID 替換為要建立的專案 ID。

3. 安裝 Maven：

   1. 下載 Maven。

   2. 在 Cloud Shell 中，將 Maven 新增至 PATH：

      export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
      

4. 在 Cloud Shell 中，複製 GitHub 存放區。

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

5. 設定並匯出下列環境變數：

   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
   

   更改下列內容：

   • PROJECT_ID：您要部署解決方案的 Google Cloud 主機專案 ID。
   • COMPUTE_REGION：您要部署運算資源 (例如 Cloud Run 和 Identity and Access Management (IAM)) 的 Google Cloud 區域。
   • DATA_REGION：您要將資料資源 (例如 bucket 和資料集) 部署至的 Google Cloud 區域。
   • ACCOUNT_EMAIL：使用者帳戶電子郵件地址。

6. 啟用 API：

   ./scripts/enable_gcp_apis.sh
   

   這個指令碼會啟用下列 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
   • Cloud DNS API

7. 準備 Terraform 狀態 bucket：

   gcloud storage buckets create $BUCKET --project=$PROJECT_ID --location=$COMPUTE_REGION --uniform-bucket-level-access
   

8. 準備 Terraform 服務帳戶：

   ./scripts/prepare_terraform_service_account.sh
   

9. 如要發布這項解決方案使用的映像檔，請準備 Docker 存放區：

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

部署基礎架構

請確認你至少完成一次「開始前」步驟。

在本節中，請按照步驟將最新程式碼庫部署或重新部署至 Google Cloud 環境。

啟用 gcloud CLI 設定

• 在 Cloud Shell 中，啟用並驗證 gcloud CLI 設定：

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

建構 Cloud Run 服務映像檔

• 在 Cloud Shell 中，建構及部署 Docker 映像檔，供 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
  

設定 Terraform 變數

這項部署作業會使用 Terraform 進行設定，並使用部署指令碼。

1. 在 Cloud Shell 中建立新的 Terraform TFVARS 檔案，您可以在其中覆寫本節中的變數：

   export VARS=FILENAME
   .tfvars
   

   將 FILENAME 替換為您建立的變數檔案名稱 (例如 my-variables)。您可以將 example-variables 檔案做為參考。

2. 在 TFVARS 檔案中設定專案變數：

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

   您可以使用 variables.tf 檔案中定義的預設值，也可以變更這些值。

3. 設定您先前在「事前準備」中建立及準備的 Terraform 服務帳戶：

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

   請務必使用您建立帳戶時的完整電子郵件地址。

4. 設定 Cloud Run 服務，以便使用您先前建構及部署的容器映像檔：

   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"
   

   這個指令碼會指示 Terraform 在 Cloud Run 服務中使用這些已發布的映像檔，而 Terraform 會在稍後建立這些服務。

   Terraform 只會將 Cloud Run 服務連結至現有映像檔。這項作業不會從程式碼集建構映像檔，因為這項作業已在先前的步驟中完成。

5. 在 schedulers 變數中，定義至少一個排程器。排程器會根據資料表層級的備份 Cron 排程，定期列出並檢查資料表是否需要備份。

   {
   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]
       }
   }
   

   更改下列內容：

   • SCHEDULER_NAME：Cloud Scheduler 的顯示名稱。
   • SCHEDULER_CRON：排程器檢查範圍內資料表是否應備份的頻率，檢查依據是各資料表的備份排程。可以是任何與 Unix-Cron 相容的字串。例如 0 * * * * 是每小時的頻率。
   • FORCE_RUN：布林值。如要讓排程器使用表格的 Cron 排程，請將值設為 false。如果設為 true，系統會備份所有範圍內的資料表，無論其 cron 設定為何。
   • DRY_RUN：布林值。如果設為 true，系統不會執行實際的備份作業。系統只會產生記錄訊息。如要測試及偵錯解決方案，但不想支付備份費用，請使用 true。
   • FOLDERS_INCLUDED：含有 BigQuery 資料的資料夾數值 ID 清單 (例如 1234, 456)。設定後，解決方案會備份指定資料夾中的資料表，並忽略 projects_include_list、datasets_include_list 和 tables_include_list 欄位設定。
   • PROJECTS_INCLUDED：專案名稱清單 (例如 "project1", "project2")。設定後，解決方案會備份指定專案中的資料表，並忽略 datasets_include_list 和 tables_include_list 欄位設定。如果您設定 folders_include_list 欄位，系統會忽略這項設定。
   • PROJECTS_EXCLUDED：專案名稱或規則運算式清單 (例如 "project1", "regex:^test_")。設定後，解決方案不會備份指定專案中的資料表。您可以搭配 folders_include_list 欄位使用這項設定。
   • DATASETS_INCLUDED：資料集清單 (例如 "project1.dataset1", "project1.dataset2")。設定後，解決方案會備份指定資料集中的資料表，並忽略 tables_include_list 欄位設定。如果設定 folders_include_list 或 projects_include_list 欄位，系統會忽略這項設定。
   • DATASETS_EXCLUDED：資料集清單或規則運算式 (例如 "project1.dataset1", "regex:.*\\_landing$")。設定後，解決方案「不會」備份指定資料集中的資料表。這項設定可與 folders_include_list 或 projects_include_list 欄位搭配使用。
   • TABLES_INCLUDED：資料表清單 (例如 "project1.dataset1.table 1", "project1.dataset2.table2")。設定後，解決方案會備份指定資料表。如果您設定 folders_include_list、projects_include_list 或 datasets_include_list 欄位，系統會忽略這項設定。
   • TABLES_EXCLUDED：資料表清單或規則運算式 (例如 "project1.dataset1.table 1", "regex:.*\_test")。設定後，解決方案「不會」備份指定資料表。您可以搭配 folders_include_list、projects_include_list 或 datasets_include_list 欄位使用這項設定。

   所有排除清單都接受 regex:REGULAR_EXPRESSION 形式的規則運算式。

   如果完整合格的項目名稱 (例如 "project.dataset.table") 符合任何提供的規則運算式，就會從備份範圍中排除。

   以下是一些常見用途：

   • 排除所有以 _landing 結尾的資料集名稱：datasets_exclude_list = ["regex:.*\\_landing$"]
   • 排除所有結尾為 _test、_tst、_bkp 或 _copy 的表格： tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

定義備用政策

每次執行時，解決方案都必須判斷每個範圍內資料表的備份政策。如要進一步瞭解政策類型，請參閱「備份政策」。本節說明如何定義備援政策。

後備政策是透過 default_policy 變數和一組不同層級 (資料夾、專案、資料集和表格) 的例外狀況或覆寫項目定義。這種做法可提供精細的彈性，不必為每個表格建立項目。

視您決定使用的備份方法 (BigQuery 快照、匯出至 Cloud Storage 或兩者皆是) 而定，還有其他政策欄位集。

1. 在 TFVARS 檔案中，針對 default_policy 變數，為預設政策設定下列常見欄位：

   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",
   
   

   更改下列內容：

   • BACKUP_CRON：Cron 運算式，用於設定資料表備份頻率 (例如，如要每 6 小時備份一次，請指定 0 0 */6 * * *)。這必須是與 Spring-Framework 相容的 Cron 運算式。
   • BACKUP_METHOD：方法，您可指定為 BigQuery Snapshot、GCS Snapshot (使用匯出至 Cloud Storage 的方法) 或 Both。您必須為每個所選備份方法提供必要欄位，如下所示。
   • OFFSET_DAYS：過去的天數，決定要從哪個時間點備份資料表。值可以是介於 0 到 7 之間的數字。
   • BACKUP_STORAGE_PROJECT：專案 ID，用於儲存所有快照和匯出作業。這與 bq_snapshot_storage_dataset 和 gcs_snapshot_storage_location 所在的專案相同。小型部署作業可以使用主專案，但大規模部署作業應使用個別專案。
   • BACKUP_OPERATIONS_PROJECT：選用設定，用於指定所有快照和匯出作業執行的專案 ID。這項專案適用快照和匯出工作的配額與限制。可以與 backup_storage_project 的值相同。如未設定，解決方案會使用來源資料表的專案。

2. 如果您將 BigQuery Snapshot 或 Both 指定為 backup_method，請在 default_policy 變數中，於通用欄位後方新增下列欄位：

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

   更改下列內容：

   • SNAPSHOT_EXPIRATION：保留每個快照的天數 (例如 15)。
   • DATASET_NAME：用於儲存快照的資料集名稱 (例如 backups)。資料集必須已存在於為 backup_storage_project 指定的專案中。

3. 如果您指定 GCS Snapshot (使用匯出至 Cloud Storage 方法) 或 Both 做為 backup_method，請將下列欄位新增至 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
   

   更改下列內容：

   • STORAGE_BUCKET：用於儲存匯出資料的 Cloud Storage 值區，格式為 gs://bucket/path/。例如：gs://bucket1/backups/。
   • FILE_FORMAT：將 BigQuery 資料表匯出至 Cloud Storage 時使用的檔案格式和壓縮方式。可用值為 CSV、CSV_GZIP、JSON、JSON_GZIP、AVRO、AVRO_DEFLATE、AVRO_SNAPPY、PARQUET、PARQUET_SNAPPY 和 PARQUET_GZIP。
   • AVRO_TYPE：布林值。如果設為 false，BigQuery 類型會匯出為字串。如果設為 true，類型會匯出為對應的 Avro 邏輯類型。如果 gcs_snapshot_format 是任何 Avro 類型格式，則這個欄位為必填。
   • CSV_DELIMITER：用於匯出 CSV 檔案的分隔符號，值可以是任何 ISO-8859-1 半形字元。您可以使用 \t 或 tab 指定分行符號。如果 gcs_snapshot_format 是任何 CSV 類型格式，則這個欄位為必填。
   • CSV_EXPORT_HEADER：布林值。如果設為 true，系統會將資料欄標頭匯出至 CSV 檔案。如果 gcs_snapshot_format 是任何 CSV 類型格式，則這個欄位為必填。

   如需詳細資料和 Avro 型別對應，請參閱下表：

   BigQuery 類型	Avro 邏輯類型
   TIMESTAMP	timestamp-micros (註解 Avro LONG)
   DATE	date (註解 Avro INT)
   TIME	timestamp-micro (註解 Avro LONG)
   DATETIME	STRING (自訂命名邏輯類型 datetime)

4. 為特定資料夾、專案、資料集和資料表新增覆寫變數：

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

   更改下列內容：

   • FOLDER_NUMBER：指定要設定覆寫欄位的資料夾。
   • PROJECT_NAME：為特定專案、資料集或資料表設定覆寫欄位時，請指定專案。
   • DATASET_NAME：為特定資料集或資料表設定覆寫欄位時，請指定資料集。
   • TABLE_NAME：指定要設定覆寫欄位的資料表。

   針對每個覆寫項目 (例如 project_overrides 變數中的特定專案)，請新增通用欄位，以及您先前在 default_policy 中指定的備份方法所需欄位。

   如要為特定層級設定覆寫，請將該變數設為空白對應 (例如 project_overrides : {})。

   在下列範例中，系統會為使用 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"
       },
      }
   }
   

如需備援政策的完整範例，請參閱 example-variables 檔案。

設定其他備份作業專案

• 如要指定其他備份專案，例如外部設定 (資料表層級備份政策) 或資料表來源專案中定義的專案，請設定下列變數：

  additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
  

  將 ADDITIONAL_BACKUPS 替換為以半形逗號分隔的專案名稱清單 (例如 "project1", "project2")。如果您只使用備援備份政策，且沒有資料表層級的外部政策，可以將值設為空白清單。

  如未新增這個欄位，系統會自動將選用 backup_operation_project 欄位中指定的任何專案納入備份專案。

設定 Terraform 服務帳戶權限

在先前的步驟中，您已設定備份專案，備份作業會在其中執行。Terraform 需要將資源部署至這些備份專案。

Terraform 使用的服務帳戶必須具備這些指定備份專案的必要權限。

• 在 Cloud Shell 中，授予服務帳戶所有備份作業執行所在專案的權限：

  ./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
  

  更改下列內容：

  • BACKUP_OPERATIONS_PROJECT：任何在備援政策和表格層級政策的 backup_operation_project 欄位中定義的專案。
  • DATA_PROJECTS：如果沒有在備援或資料表層級政策中定義 backup_operation_project 欄位，請納入這些來源資料表的專案。
  • ADDITIONAL_BACKUPS：在 additional_backup_operation_projects Terraform 變數中定義的任何專案。

執行部署指令碼

1. 在 Cloud Shell 中，執行 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. 為 Firestore 新增存留時間 (TTL) 政策：

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

   在某些情況下，解決方案會使用 Datastore 做為快取。為節省費用並提升查詢效能，TTL 政策可讓 Firestore 自動刪除過期的項目。

設定來源和目的地的存取權

1. 在 Cloud Shell 中，為解決方案使用的服務帳戶設定下列變數：

   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
   

   如果您已在 Terraform 中變更預設名稱，請更新服務帳戶電子郵件。

2. 如果您已設定 folders_include_list 欄位，並想設定 BigQuery 掃描範圍，納入特定資料夾，請在資料夾層級授予必要權限：

   ./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
   

3. 如要讓應用程式在不同專案中執行必要工作，請在每個專案中授予必要權限：

   ./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
   

   更改下列內容：

   • DATA_PROJECTS：包含要備份來源資料表的資料專案 (或來源專案)，例如 project1 project2。請加入下列專案：

     • Terraform 變數 schedulers 包含清單中指定的專案。
     • 如要備份主專案中的資料表，請納入主專案。

   • BACKUP_STORAGE_PROJECT：備份儲存空間專案 (或目的地專案)，解決方案會將備份內容儲存在這些專案中 (例如 project1 project2)。您需要納入下列欄位中指定的專案：

     • 所有備用政策中的 backup_storage_project 欄位。
     • 所有資料表層級政策中的 backup_storage_project 欄位。

     包括用於多個欄位或同時做為來源和目的地專案的備份儲存空間專案

   • BACKUP_OPERATIONS_PROJECT：資料作業專案，解決方案會在其中執行備份作業 (例如 project1 project2)。您需要納入下列欄位中指定的專案：

     • 所有備用政策中的 backup_operation_project 欄位。
     • BigQuery 掃描範圍內的所有納入清單 (如果您未設定 backup_operation_project 欄位)。
     • 所有資料表層級政策中的 backup_operation_project 欄位。

     包括用於多個欄位，或同時做為來源和目的地專案的備份作業專案。

4. 如果資料表使用資料欄層級存取權控管，請找出資料表使用的所有政策標記分類 (如有)，並授予解決方案的服務帳戶資料表資料存取權：

   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'
   

   更改下列內容：

   • TAXONOMY_PROJECT：政策標記分類中的專案 ID
   • TAXONOMY_LOCATION：政策標記分類中指定的位置
   • TAXONOMY_ID：政策標記分類的分類 ID

5. 針對每個政策標記分類重複上一個步驟。

執行解決方案

部署解決方案後，請參閱下列章節，瞭解如何執行及管理解決方案。

設定表格層級備份政策

• 在 Cloud Shell 中，建立含有必要欄位的資料表層級政策，然後將政策儲存在政策的 Cloud Storage bucket 中：

  # 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
  
  gcloud storage cp backup_policy.json gs://${POLICIES_BUCKET}/policy/project=${TABLE_PROJECT}/dataset=${TABLE_DATASET}/table=${TABLE}/backup_policy.json
  

  更改下列內容：

  • TABLE_PROJECT：資料表所在的專案
  • TABLE_DATASET：資料表所屬的資料集
  • TABLE_NAME：資料表名稱

觸發備份作業

您先前設定的 Cloud Scheduler 工作會根據其 cron 運算式自動執行。

您也可以在 Google Cloud 控制台中手動執行工作。詳情請參閱執行工作。

監控及回報

選取主機專案 (PROJECT_ID) 後，您可以在 BigQuery Studio 中執行下列查詢，取得報表和資訊。

• 取得每次執行的進度統計資料 (包括進行中的執行)：

  SELECT * FROM `bq_backup_manager.v_run_summary_counts`
  

• 取得單一執行作業的所有嚴重錯誤 (無法重試的錯誤)：

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

  將 RUN_ID 替換為執行作業的 ID。

• 取得資料表上的所有執行作業及其執行資訊：

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

  您也可以指定 grouped 版本：

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

• 如要進行偵錯，您可以取得每次服務調用的詳細要求和回應資訊：

  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"
  

• 取得手動新增或由系統根據備援指派的備份政策：

  SELECT * FROM `bq_backup_manager.ext_backup_policies`
  

限制

如要進一步瞭解 backup_operation_project 欄位中指定各專案的限制和配額，請參閱「限制」。

清除所用資源

如要避免系統向您的 Google Cloud 帳戶收取本次部署所用資源的費用，請刪除含有相關資源的專案，或者保留專案但刪除個別資源。

刪除專案

注意：刪除專案會造成以下結果：

• 專案中的所有內容都會遭到刪除。 如果您使用現有專案來進行本文中的工作，刪除專案將一併刪除其中已完成的所有工作。
• 自訂的專案 ID 會消失。當您之前建立這個專案時，可能建立了想要在日後使用的自訂專案 ID。如要保留使用該專案 ID 的網址 (例如 appspot.com 網址)，請刪除在該專案中選取的資源，而不是刪除整個專案。

如果打算探索多種架構、教學課程或快速入門導覽課程，重複使用專案有助於避免超出專案配額限制。

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

刪除新資源

您不必刪除專案，而是可以刪除在此程序期間建立的資源。

• 在 Cloud Shell 中刪除 Terraform 資源：

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

  這項指令會刪除幾乎所有資源。確認要刪除的所有資源都已移除。

後續步驟

• 進一步瞭解 BigQuery：
  • BigQuery 資料表快照
  • 將 BigQuery 資料表匯出至 Cloud Storage
• 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。

貢獻者

作者：Karim Wadie | 策略雲端工程師

其他貢獻者：

• Chris DeForeest | 網站可靠性工程師
• Eyal Ben Ivri | 雲端解決方案架構師
• Jason Davenport | 開發人員服務代表
• Jaliya Ekanayake | 工程經理
• Muhammad Zain | 策略雲端工程師