Migrer les tables Apache Hive Metastore versCloud de Confiance

Ce document explique comment migrer vos tables Iceberg et Hive gérées par Apache Hive Metastore versCloud de Confiance à l'aide du service de transfert de données BigQuery.

Le connecteur de migration Apache Hive Metastore du service de transfert de données BigQuery vous permet de migrer facilement vos tables Hive Metastore vers Cloud de Confiance à grande échelle. Ce connecteur est compatible avec les tables Hive et Iceberg provenant d'installations sur site et d'environnements cloud, y compris les configurations Cloudera. Le connecteur de migration Hive Metastore est compatible avec les fichiers stockés dans les sources de données suivantes :

• Système de fichiers distribué Hadoop (HDFS)
• Amazon Simple Storage Service (Amazon S3)
• Azure Blob Storage ou Azure Data Lake Storage Gen2

Avec le connecteur de migration Hive Metastore, vous pouvez utiliser Cloud Storage comme stockage de fichiers et enregistrer vos tables Hive Metastore avec l'un des metastores suivants :

• Catalogue d'environnement d'exécution Lakehouse : catalogue REST Iceberg

  Nous vous recommandons d'utiliser le catalogue Iceberg REST du runtime Lakehouse pour toutes vos données Iceberg.

  Le catalogue d'exécution Lakehouse Iceberg REST Catalog crée une interopérabilité entre vos moteurs de requête en offrant une source unique de vérité pour toutes vos données Iceberg. Vous pouvez utiliser BigQuery pour interroger les données, en plus d'Apache Spark et d'autres moteurs OSS. Le catalogue d'exécution Lakehouse Iceberg REST Catalog n'est compatible qu'avec les formats de table Iceberg.

• Dataproc Metastore

  Dataproc Metastore est compatible avec les formats de table Hive et Iceberg. Vous ne pouvez utiliser qu'Apache Spark et d'autres moteurs OSS pour lire et écrire des données dans Dataproc Metastore.

Ce connecteur est compatible avec les transferts complets et les transferts de métadonnées uniquement. Les transferts complets transfèrent à la fois vos données et vos métadonnées de vos tables sources vers votre metastore cible. Vous pouvez créer un transfert de métadonnées uniquement si vos données se trouvent déjà dans Cloud Storage et si vous souhaitez uniquement les enregistrer dans un métastore de destination.

Le diagramme suivant présente une vue d'ensemble du processus de migration.

Limites

Les transferts de tables Hive Metastore sont soumis aux limitations suivantes :

• Les transferts Hive Metastore doivent être planifiés à au moins 24 heures d'intervalle. Les exécutions à la demande peuvent toujours être déclenchées à n'importe quel intervalle.
• Pour migrer des tables Hive, vous devez utiliser Dataproc Metastore comme métastore de destination.
• Les noms de fichiers doivent respecter les exigences concernant les noms d'objets Cloud Storage.
• Cloud Storage limite la taille des objets individuels à 5 Tio. Le transfert des fichiers de plus de 5 Tio dans vos tables Hive Metastore échouera.
• Le service de transfert de stockage a des comportements spécifiques si des données sont modifiées au niveau de la source pendant un transfert. Nous vous déconseillons d'écrire dans les tables pendant leur migration. Pour obtenir la liste des autres limites du service de transfert de stockage, consultez les limitations connues.

Options d'ingestion de données

Les sections suivantes fournissent plus d'informations sur la façon de configurer vos transferts Hive Metastore.

Transferts incrémentiels

Lorsqu'une configuration de transfert est définie avec une programmation récurrente, chaque transfert ultérieur met à jour le tableau sur Cloud de Confiance by S3NS avec les dernières modifications apportées au tableau source. Par exemple, toutes les mises à jour de données, ainsi que toutes les opérations d'insertion, de suppression ou de mise à jour avec des modifications de schéma sont reflétées dans Cloud de Confiance by S3NS à chaque transfert.

Filtrer les partitions

Vous pouvez transférer un sous-ensemble de partitions de vos tables Hive en fournissant un fichier JSON de filtre personnalisé stocké dans Cloud Storage. Lorsque vous planifiez le transfert, indiquez le chemin d'accès Cloud Storage complet à ce fichier JSON à l'aide du paramètre partition_filter_gcs_path.

Voici un exemple de structure de fichier JSON de filtre :

{
  "filters": [
    {
      "table": "db1.table1", "condition": "IN", "partition":
      ["partition1=value1/partition2=value2"]
    },
    {
      "table": "db1.table2", "condition": "LESS_THAN", "partition":
      ["partition1;value1"]
    },
    {
      "table": "db1.table3", "condition": "GREATER_THAN", "partition":
      ["partition1;value1"]
    },
    {
      "table": "db1.table4", "condition": "RANGE", "partition":
      ["partition1;value1;value2"]
    }
  ]
}

Conditions de filtrage

Le champ condition du fichier JSON accepte les valeurs suivantes, chacune avec un format spécifique pour le tableau partition :

• IN : spécifie les chemins d'accès exacts aux partitions à inclure. Le tableau partition contient des chaînes représentant la structure exacte des répertoires des partitions par rapport au chemin de base de la table (par exemple, ["partition_key1=value1/partition_key2=value2"]). Vous pouvez spécifier plusieurs chemins d'accès dans le tableau.
• LESS_THAN : inclut les partitions dont la valeur de la clé de partition principale est inférieure ou égale à la valeur spécifiée. Le tableau partition doit contenir une seule chaîne au format ["<partition_key>;<value>"].
• GREATER_THAN : inclut les partitions dont la valeur de clé de partition principale est supérieure ou égale à la valeur spécifiée. Le tableau partition doit contenir une seule chaîne au format ["<partition_key>;<value>"].
• RANGE : inclut les partitions dont la valeur de clé de partition principale se trouve dans la plage spécifiée (inclusive). Le tableau partition doit contenir une seule chaîne au format ["<partition_key>;<start_value>;<end_value>"].

Les conditions de filtre sont soumises aux règles et restrictions suivantes :

• Valeurs incluses : les conditions de filtrage pour GREATER_THAN, LESS_THAN et RANGE incluent les valeurs fournies. Par exemple, un filtre LESS_THAN avec une valeur de 2023 inclut les partitions jusqu'à 2023 (inclus).
• Suppression de partitions : si une partition de destination existante répond au filtre de partition et n'est plus présente dans la source, elle est supprimée du metastore de destination. Toutefois, les fichiers de données sous-jacents de cette partition ne sont pas supprimés du bucket Cloud Storage de destination.
• Restrictions concernant les tableaux individuels :
  • Il n'est pas possible d'appliquer plusieurs filtres au même tableau.
  • Vous ne pouvez pas combiner différents types de conditions (par exemple, GREATER_THAN et IN) dans le même tableau.
• Colonne de partition cible : les conditions de filtrage telles que GREATER_THAN, LESS_THAN et RANGE doivent cibler la colonne de partition principale.
• Limites de préfixes : la combinaison de filtres spécifiée ne doit pas générer plus de 1 000 préfixes par table. Par exemple, un filtre tel que year>2020 sur une table partitionnée par year/month/day doit générer moins de 1 000 préfixes year= uniques.

Avant de commencer

Avant de planifier le transfert Hive Metastore, suivez les étapes décrites dans cette section.

Activer les API

Activez les API suivantes dans votre projetCloud de Confiance  :

• API Data Transfer
• API Storage Transfer

Un agent de service est créé lorsque vous activez l'API Data Transfer.

Configurer les autorisations

Pour configurer les autorisations pour un transfert Hive Metastore, suivez les étapes décrites dans les sections suivantes.

1. L'utilisateur ou le compte de service qui crée le transfert doit disposer du rôle Administrateur BigQuery (roles/bigquery.admin). Si vous utilisez un compte de service, il ne sert qu'à créer le transfert.

2. Un agent de service (P4SA) est créé lorsque vous activez l'API Data Transfer.

   Pour vous assurer que l'agent de service dispose des autorisations nécessaires pour exécuter un transfert Hive Metastore, demandez à votre administrateur d'accorder à l'agent de service les rôles IAM suivants sur le projet :

   • Administrateur de transfert de stockage (roles/storagetransfer.admin)
   • Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer)
   • Administrateur de l'espace de stockage (roles/storage.admin)
   • Pour migrer les métadonnées vers le catalogue Iceberg REST du runtime Lakehouse : Administrateur BigLake (roles/biglake.admin)
   • Pour migrer des métadonnées vers Dataproc Metastore : Propriétaire de données Dataproc Metastore (roles/metastore.metadataOwner)

   Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

   Votre administrateur peut également attribuer à l'agent de service les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

3. Si vous utilisez un compte de service, accordez à l'agent de service le rôle roles/iam.serviceAccountTokenCreator à l'aide de la commande suivante :

   gcloud iam service-accounts add-iam-policy-binding
   SERVICE_ACCOUNT --member
   serviceAccount:service-PROJECT_NUMBER@gcp-sa-bigquerydatatransfer.s3ns-system.iam.gserviceaccount.com --role
   roles/iam.serviceAccountTokenCreator

4. Attribuez les rôles suivants à l'agent de service du service de transfert de stockage (project-PROJECT_NUMBER@storage-transfer-service.s3ns-system.iam.gserviceaccount.com) dans le projet :

   • roles/storage.admin
   • Si vous effectuez la migration depuis un système sur site/HDFS, vous devez également accorder le rôle roles/storagetransfer.serviceAgent.

   Vous pouvez également configurer des autorisations plus précises. Pour en savoir plus, consultez le guide suivant :

   • Autorisations HDFS
   • Autorisations Amazon S3 et Microsoft Azure

Générer un fichier de métadonnées pour Apache Hive

Exécutez l'outil dwh-migration-dumper pour extraire les métadonnées pour Apache Hive. L'outil génère un fichier nommé hive-dumper-output.zip qui peut être importé dans un bucket Cloud Storage. Dans ce document, ce bucket Cloud Storage est appelé DUMPER_BUCKET.

Vous pouvez également programmer des importations périodiques à l'aide d'un script. Pour en savoir plus, consultez Automatiser l'exécution de l'outil de vidage avec un job cron.

Configurer le service de transfert de stockage

Sélectionnez l'une des options suivantes :

Planifier un transfert Hive Metastore

Sélectionnez l'une des options suivantes :

  bq mk --transfer_config
  --data_source=hadoop display_name='TRANSFER_NAME'
  --service_account_name='SERVICE_ACCOUNT'
  --project_id='PROJECT_ID' location='REGION'
  --params='{
    "transfer_strategy":"TRANSFER_STRATEGY",
    "table_name_patterns":"LIST_OF_TABLES",
    "table_metadata_path":"gs://DUMPER_BUCKET/hive-dumper-output.zip",
    "target_gcs_file_path":"gs://MIGRATION_BUCKET",
    "metastore":"METASTORE",
    "destination_dataproc_metastore":"DATAPROC_METASTORE_URL",
    "destination_bigquery_dataset":"BIGLAKE_METASTORE_DATASET",
    "translation_output_gcs_path":"gs://TRANSLATION_OUTPUT_BUCKET/metadata/config/default_database/",
    "storage_type":"STORAGE_TYPE",
    "agent_pool_name":"AGENT_POOL_NAME",
    "aws_access_key_id":"AWS_ACCESS_KEY_ID",
    "aws_secret_access_key":"AWS_SECRET_ACCESS_KEY",
    "azure_sas_token":"AZURE_SAS_TOKEN",
    "partition_filter_gcs_path":"FILTER_GCS_PATH"
    }'

Automatiser l'exécution de l'outil de vidage avec un job cron

Vous pouvez automatiser les transferts incrémentiels à l'aide d'une tâche cron pour exécuter l'outil dwh-migration-dumper. Automatiser l'extraction des métadonnées pour s'assurer qu'une sauvegarde à jour de la source de données est disponible pour les exécutions de transfert incrémentiel ultérieures.

Avant de commencer

Avant d'utiliser ce script d'automatisation, vous devez effectuer les opérations suivantes :

1. Remplissez toutes les conditions préalables pour l'outil de vidage.

2. Installez la Google Cloud CLI. Le script utilise l'outil de ligne de commande gsutil pour importer la sortie du dumper dans Cloud Storage.

3. Pour vous authentifier auprès de Cloud de Confiance afin d'autorisergsutilà importer des fichiers dans Cloud Storage, exécutez la commande suivante :

   gcloud auth application-default login

Planifier l'automatisation

1. Enregistrez le script suivant dans un fichier local. Ce script est conçu pour être configuré et exécuté par un daemon cron afin d'automatiser le processus d'extraction et d'importation des résultats du dumper.

   #!/bin/bash
   
   # Exit immediately if a command exits with a non-zero status.
   set -e
   # Treat unset variables as an error when substituting.
   set -u
   # Pipelines return the exit status of the last command to exit with a non-zero status.
   set -o pipefail
   
   # These values are used if not overridden by command-line options.
   DUMPER_EXECUTABLE="DUMPER_PATH/dwh-migration-dumper"
   GCS_BASE_PATH="gs://PATH_TO_DUMPER_OUTPUT"
   LOCAL_BASE_DIR="LOCAL_BASE_DIRECTORY_PATH"
   
   # Optional arguments for cloud environments
   DUMPER_HOST=""
   DUMPER_PORT=""
   HIVE_KERBEROS_URL=""
   HIVEQL_RPC_PROTECTION=""
   KERBEROS_AUTHENTICATION="false"
   
   # Function to display usage information
   usage() {
     echo "Usage: $0 [options]"
     echo ""
     echo "Runs the dwh-migration-dumper tool and uploads its output to provided Cloud Storage path."
     echo ""
     echo "Required Options:"
     echo "  --dumper-executable   The full path to the dumper executable."
     echo "  --gcs-base-path       The base Cloud Storage folder to upload dumper output files to. The script generates timestamped ZIP files in this folder."
     echo "  --local-base-dir      The local base directory for logs and temp files."
     echo ""
     echo "Optional Hive connection options:"
     echo "  --host              The hostname for the dumper connection."
     echo "  --port              The port number for the dumper connection."
     echo ""
     echo "To use Kerberos authentication, include the following options."
     echo "If --kerberos-authentication is specified, then --host, --port,"
     echo "--hive-kerberos-url and --hiveql-rpc-protection are all required:"
     echo ""
     echo "  --kerberos-authentication   Enable Kerberos authentication."
     echo "  --hive-kerberos-url    The Hive Kerberos URL."
     echo "  --hiveql-rpc-protection "
     echo "                            The hiveql-rpc-protection level, equal to the value of"
     echo "                            'hadoop.rpc.protection' in '/etc/hadoop/conf/core-site.xml',"
     echo "                            with one of the following values:"
     echo "                            - authentication"
     echo "                            - integrity"
     echo "                            - privacy"
     echo ""
     echo "Other Options:"
     echo "  -h, --help                  Display this help message and exit."
     exit 1
   }
   
   # This loop processes command-line options and overrides the default configuration.
   while [[ "$#" -gt 0 ]]; do
     case $1 in
         --dumper-executable)
             DUMPER_EXECUTABLE="$2"
             shift # past argument
             shift # past value
             ;;
         --gcs-base-path)
             GCS_BASE_PATH="$2"
             shift
             shift
             ;;
         --local-base-dir)
             LOCAL_BASE_DIR="$2"
             shift
             shift
             ;;
         --host)
             DUMPER_HOST="$2"
             shift
             shift
             ;;
         --port)
             DUMPER_PORT="$2"
             shift
             shift
             ;;
         --hive-kerberos-url)
             HIVE_KERBEROS_URL="$2"
             shift
             shift
             ;;
         --hiveql-rpc-protection)
             HIVEQL_RPC_PROTECTION="$2"
             shift
             shift
             ;;
         --kerberos-authentication)
             KERBEROS_AUTHENTICATION="true"
             shift
             ;;
         -h|--help)
             usage
             ;;
         *)
             echo "Unknown option: $1"
             usage
             ;;
     esac
   done
   
   # This runs AFTER parsing arguments to ensure no placeholder values are left.
   if [[ "$DUMPER_EXECUTABLE" == "DUMPER_PATH"* || "$GCS_BASE_PATH" == "gs://PATH_TO_DUMPER_OUTPUT" || "$LOCAL_BASE_DIR" == "LOCAL_BASE_DIRECTORY_PATH" ]]; then
     echo "ERROR: One or more configuration variables have not been set. Please provide them as command-line arguments or edit the script." >&2
     echo "Run with --help for more information." >&2
     exit 1
   fi
   
   # If Kerberos authentication is enabled, check for required fields.
   if [[ "$KERBEROS_AUTHENTICATION" == "true" ]]; then
     if [[ -z "$DUMPER_HOST" || -z "$DUMPER_PORT" || -z "$HIVE_KERBEROS_URL" || -z "$HIVEQL_RPC_PROTECTION" ]]; then
         echo "ERROR: If --kerberos-authentication is enabled, --host, --port, --hive-kerberos-url and --hiveql-rpc-protection must be provided." >&2
         echo "Run with --help for more information." >&2
         exit 1
     fi
   fi
   
   # Remove trailing slashes from GCS_BASE_PATH, if any.
   GCS_BASE_PATH=$(echo "${GCS_BASE_PATH}" | sed 's:/*$::')
   
   # Create unique timestamp and directories for this run
   EPOCH=$(date +%s)
   LOCAL_LOG_DIR="${LOCAL_BASE_DIR}/logs"
   mkdir -p "${LOCAL_LOG_DIR}" # Ensures the base and logs directories exist
   
   # Define the unique log and zip file path for this run
   LOG_FILE="${LOCAL_LOG_DIR}/dumper_execution_${EPOCH}.log"
   ZIP_FILE_NAME="dts-cron-dumper-output_${EPOCH}.zip"
   LOCAL_ZIP_PATH="${LOCAL_BASE_DIR}/${ZIP_FILE_NAME}"
   
   echo "Script execution started. All subsequent output will be logged to: ${LOG_FILE}"
   
   # --- Helper Functions ---
   
   log() { echo "$(date '+%Y-%m-%d %H:%M:%S') - $@" >> "${LOG_FILE}"; }
   
   cleanup() {
     local path_to_remove="$1"
     log "Cleaning up local file/directory: ${path_to_remove}..."
     rm -rf "${path_to_remove}"
   }
   
   # This function is called when the script exits to ensure cleanup and logging happen reliably.
   handle_exit() {
     local exit_code=$?
     # Only run the failure logic if the script is exiting with an error
     if [[ ${exit_code} -ne 0 ]]; then
         log "ERROR: Script is exiting with a failure code (${exit_code})."
         local gcs_log_path_on_failure="${GCS_BASE_PATH}/logs/$(basename "${LOG_FILE}")"
         log "Uploading log file to ${gcs_log_path_on_failure} for debugging..."
         # Attempt to upload the log file on failure, but don't let this command cause the script to exit.
         gsutil cp "${LOG_FILE}" "${gcs_log_path_on_failure}" > /dev/null 2>&1 || log "WARNING: Failed to upload log file to Cloud Storage."
   
     else
         # SUCCESS PATH
         log "Script finished successfully. Now cleaning up local zip file...."
         # Clean up the local zip file ONLY on success
         cleanup "${LOCAL_ZIP_PATH}"
     fi
   
     log "*****Script End*****"
     exit ${exit_code}
   }
   
   # Trap the EXIT signal to run the handle_exit function, ensuring cleanup always happens.
   trap handle_exit EXIT
   
   # Validates the dumper log file based on a strict set of rules.
   validate_dumper_output() {
     local log_file_to_check="$1"
   
     # Check for the specific success message from the dumper tool.
     if grep -q "Dumper execution: SUCCEEDED" "${log_file_to_check}"; then
         log "Validation Successful: Found 'Dumper execution: SUCCEEDED' message."
         return 0 # Success
     else
         log "ERROR: Validation failed. The 'Dumper execution: SUCCEEDED' message was not found."
         return 1 # Failure
     fi
   }
   
   # --- Main Script Logic ---
   
   log "*****Script Start*****"
   log "Dumper Executable: ${DUMPER_EXECUTABLE}"
   log "Cloud Storage Base Path: ${GCS_BASE_PATH}"
   log "Local Base Directory: ${LOCAL_BASE_DIR}"
   
   # Use an array to build the command safely
   dumper_command_args=(
     "--connector" "hiveql"
     "--output" "${LOCAL_ZIP_PATH}"
   )
   
   # Add optional arguments if they are provided
   if [[ -n "${DUMPER_HOST}" ]]; then
   dumper_command_args+=("--host" "${DUMPER_HOST}")
   log "Using Host: ${DUMPER_HOST}"
   fi
   if [[ -n "${DUMPER_PORT}" ]]; then
   dumper_command_args+=("--port" "${DUMPER_PORT}")
   log "Using Port: ${DUMPER_PORT}"
   fi
   if [[ -n "${HIVE_KERBEROS_URL}" ]]; then
   dumper_command_args+=("--hive-kerberos-url" "${HIVE_KERBEROS_URL}")
   log "Using Hive Kerberos URL: ${HIVE_KERBEROS_URL}"
   fi
   if [[ -n "${HIVEQL_RPC_PROTECTION}" ]]; then
   dumper_command_args+=("-Dhiveql.rpc.protection=${HIVEQL_RPC_PROTECTION}")
   log "Using HiveQL RPC Protection: ${HIVEQL_RPC_PROTECTION}"
   fi
   
   log "Starting dumper tool execution..."
   log "COMMAND: JAVA_OPTS=\"-Djavax.security.auth.useSubjectCredsOnly=false\" ${DUMPER_EXECUTABLE} ${dumper_command_args[*]}"
   
   JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false" "${DUMPER_EXECUTABLE}" "${dumper_command_args[@]}" >> "${LOG_FILE}" 2>&1
   
   log "Dumper process finished."
   
   # Validate the output from the dumper execution for success or failure.
   validate_dumper_output "${LOG_FILE}"
   
   # Upload the ZIP file to Cloud Storage
   gcs_zip_path="${GCS_BASE_PATH}/${ZIP_FILE_NAME}"
   log "Uploading ${LOCAL_ZIP_PATH} to ${gcs_zip_path}..."
   
   if [ ! -f "${LOCAL_ZIP_PATH}" ]; then
     log "ERROR: Expected ZIP file ${LOCAL_ZIP_PATH} not found after dumper execution."
     # The script will exit here with an error code, and the trap will run.
     exit 1
   fi
   
   gsutil cp "${LOCAL_ZIP_PATH}" "${gcs_zip_path}" >> "${LOG_FILE}" 2>&1
   log "Upload to Cloud Storage successful."
   
   # The script will now exit with code 0. The trap will call cleanup and log the script end.

2. Pour rendre le script exécutable, exécutez la commande suivante :

   chmod +x PATH_TO_SCRIPT

3. Planifiez le script à l'aide de crontab, en remplaçant les variables par les valeurs appropriées pour votre job. Ajoutez une entrée pour planifier le job. Les exemples suivants exécutent le script tous les jours à 2h30 :

   Si vous exécutez sur un hôte qui a un accès direct au metastore Hive et qui ne nécessite pas d'authentification Kerberos, exécutez la commande suivante :

   # Run the Hive dumper daily at 2:30 AM for incremental BigQuery transfer.
   30 2 * * * PATH_TO_SCRIPT \
     --dumper-executable PATH_TO_DUMPER_EXECUTABLE \
     --gcs-base-path GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT \
     --local-base-dir LOCAL_PATH_TO_SAVE_INTERMEDIARY_FILES

   Si votre instance Hive Metastore nécessite une authentification Kerberos, exécutez la commande suivante :

   # Run the Hive dumper daily at 2:30 AM for incremental BigQuery transfer with Kerberos authentication.
   30 2 * * * PATH_TO_SCRIPT \
     --dumper-executable PATH_TO_DUMPER_EXECUTABLE \
     --gcs-base-path GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT \
     --local-base-dir LOCAL_PATH_TO_SAVE_INTERMEDIARY_FILES \
     --kerberos-authentication \
     --host HIVE_HOST \
     --port HIVE_PORT \
     --hive-kerberos-url HIVE_KERBEROS_URL \
     --hiveql-rpc-protection HIVEQL_RPC_PROTECTION

Points à prendre en compte pour la planification

Pour éviter que les données ne deviennent obsolètes, exécutez l'outil de vidage avant le transfert de données planifié.

Nous vous recommandons d'exécuter manuellement le script plusieurs fois pour déterminer le temps moyen nécessaire à l'outil de vidage pour générer son résultat. Utilisez cette planification pour définir un calendrier de tâches cron qui précède l'exécution de votre transfert afin de garantir la fraîcheur des données.

Surveiller et afficher l'état des transferts

Vous pouvez surveiller les transferts au niveau des ressources pour les tables individuelles afin de suivre la progression, d'afficher des informations détaillées sur les erreurs et d'interroger l'état des ressources spécifiques en cours de migration.

Pour afficher la progression et l'état de vos ressources, sélectionnez l'une des options suivantes :

  GET https://bigquerydatatransfer.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/transferConfigs/CONFIG_ID/transferResources
  Example Response (abridged) (JSON):
  {
    "transferResources": [
      {
        "name": "projects/.../transferResources/table1",
        "latestStatusDetail": {
          "state": "RESOURCE_TRANSFER_SUCCEEDED",
          "completedPercentage": 100.0
        },
        "updateTime": "2026-02-03T22:42:06Z"
      }
    ]
  }
  

  curl -X GET 

  "https://bigquerydatatransfer.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/transferConfigs/CONFIG_ID/transferResources" 

  -H "Authorization: Bearer $(gcloud auth print-access-token)" 

  -H "Accept: application/json"
  

  GET https://bigquerydatatransfer.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/transferConfigs/CONFIG_ID/transferResources/RESOURCE_ID
  

  curl -X GET 

  "https://bigquerydatatransfer.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/transferConfigs/CONFIG_ID/transferResources/RESOURCE_ID" 

  -H "Authorization: Bearer $(gcloud auth print-access-token)" 

  -H "Accept: application/json"
  

Quotas et limites de simultanéité

Pour chaque exécution du service de transfert de données BigQuery, le connecteur Hive Metastore exécute une tâche service de transfert de stockage par table.

Une fois le quota atteint, le transfert attend qu'un quota supplémentaire soit disponible. Les tâches du service de transfert de stockage sont créées dans le projet client et sont soumises aux quotas et limites du service de transfert de stockage.

Tarifs

L'utilisation du connecteur Apache Hive Metastore pour transférer vos données est sans frais. Une fois les données transférées, leur stockage dans votre destination vous est facturé. Pour en savoir plus, consultez les ressources suivantes :

• BigLake
• Tarifs de Dataproc Metastore
• Tarifs de Cloud Storage