部署可擴充的 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計費元件:

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

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

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

事前準備

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

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

  1. 在 Google Cloud 控制台中啟用 Cloud Shell。

    啟用 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
    • 無伺服器 VPC 存取 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 bucket,格式為 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 帳戶收取本次部署所用資源的費用,請刪除含有相關資源的專案,或者保留專案但刪除個別資源。

刪除專案

  1. 前往 Google Cloud 控制台的「Manage resources」(管理資源) 頁面。

    前往「Manage resources」(管理資源)

  2. 在專案清單中選取要刪除的專案,然後點選「Delete」(刪除)。
  3. 在對話方塊中輸入專案 ID,然後按一下 [Shut down] (關閉) 以刪除專案。

刪除新資源

除了刪除專案,您也可以刪除此程序中建立的資源。

  • 在 Cloud Shell 中刪除 Terraform 資源:

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

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

後續步驟

貢獻者

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

其他貢獻者: