Cette page a été traduite par l'API Cloud Translation.

Migrer les tables gérées Hive vers Google Cloud

Ce document explique comment migrer vos tables gérées Hive vers Google Cloud.

Vous pouvez utiliser le connecteur de migration des tables gérées Hive dans le service de transfert de données BigQuery pour migrer facilement vos tables gérées par Hive Metastore, en acceptant les formats Hive et Iceberg des environnements sur site et cloud vers Google Cloud. Nous acceptons le stockage de fichiers sur HDFS ou Amazon S3.

Avec le connecteur de migration des tables gérées Hive, vous pouvez enregistrer vos tables gérées Hive avec Dataproc Metastore, BigLake Metastore ou BigLake Metastore Iceberg REST Catalog tout en utilisant Cloud Storage comme stockage de fichiers.

Le schéma suivant présente le processus de migration des tables à partir d'un cluster Hadoop.

Présentation de la migration de tables depuis un data lake Hive vers BigQuery.

Limites

Les transferts de tables gérées Hive sont soumis aux limitations suivantes :

Pour migrer des tables Apache Iceberg, vous devez les enregistrer dans le metastore BigLake afin d'autoriser l'accès en écriture pour les moteurs Open Source (tels qu'Apache Spark ou Flink) et l'accès en lecture pour BigQuery.
Pour migrer les tables gérées Hive, vous devez les enregistrer dans Dataproc Metastore afin d'autoriser l'accès en écriture pour les moteurs Open Source et l'accès en lecture pour BigQuery.
Vous devez utiliser l'outil de ligne de commande bq pour migrer les tables gérées Hive vers BigQuery.

Avant de commencer

Avant de planifier le transfert de tables gérées Hive, vous devez effectuer les opérations suivantes :

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 dans un bucket Cloud Storage, appelé DUMPER_BUCKET dans ce document.

Activer les API

Activez les API suivantes dans votre projetGoogle Cloud :

API Data Transfer
API Storage Transfer

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

Configurer les autorisations

Créez un compte de service et attribuez-lui le rôle Administrateur BigQuery (roles/bigquery.admin). Ce compte de service est utilisé pour créer la configuration du transfert.
Un agent de service (P4SA) est créé lorsque vous activez l'API Data Transfer. Attribuez-lui les rôles suivants :
- roles/metastore.metadataOwner
- roles/storagetransfer.admin
- roles/serviceusage.serviceUsageConsumer
- roles/storage.objectAdmin
  - Si vous migrez des métadonnées pour des tables BigLake Iceberg, vous devez également attribuer le rôle roles/bigquery.admin.
  - Si vous migrez des métadonnées vers le catalogue REST Iceberg de BigLake Metastore, vous devez également accorder le rôle roles/biglake.admin.

Attribuez le rôle roles/iam.serviceAccountTokenCreator à l'agent de service à l'aide de la commande suivante :

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

Configurer Storage Transfer Service pour les lacs de données HDFS

Obligatoire lorsque le fichier est stocké dans HDFS. Pour configurer l'agent de transfert de stockage requis pour un transfert de lac de données HDFS :

Configurez les autorisations pour exécuter l'agent de transfert de stockage sur votre cluster Hadoop.
Installez Docker sur les machines agents sur site.
Créez un pool d'agents service de transfert de stockage Service dans votre projet Google Cloud .
Installez des agents sur vos machines d'agents sur site.

Configurer les autorisations du service de transfert de stockage pour Amazon S3

Obligatoire lorsque le fichier est stocké dans Amazon S3. Les transferts depuis Amazon S3 sont des transferts sans agent qui nécessitent des autorisations spécifiques. Pour configurer le service de transfert de stockage pour un transfert Amazon S3, procédez comme suit :

Configurer les autorisations de transfert sans agent
Configurez les identifiants d'accès pour AWS Amazon S3.
- Notez l'ID de clé d'accès et la clé d'accès secrète après avoir configuré vos identifiants d'accès.
Ajoutez les plages d'adresses IP utilisées par les nœuds de calcul service de transfert de stockage à votre liste d'adresses IP autorisées si votre projet AWS utilise des restrictions d'adresses IP.

Planifier le transfert de tables gérées Hive

Sélectionnez l'une des options suivantes :

Console

Accédez à la page "Transferts de données" dans la console Google Cloud .

Accéder à la page Transferts de données
Cliquez sur Créer un transfert.
Dans la section Type de source, sélectionnez Tables gérées Hive dans la liste Source.
Pour Emplacement, sélectionnez un type d'emplacement, puis une région.
Dans la section Nom de la configuration de transfert, sous Nom à afficher, saisissez le nom du transfert de données.
Dans la section Options de programmation, procédez comme suit :
- Dans la liste Fréquence de répétition, sélectionnez une option pour spécifier la fréquence d'exécution de ce transfert de données. Pour spécifier une fréquence de répétition personnalisée, sélectionnez Personnalisée. Si vous sélectionnez À la demande, le transfert s'exécute lorsque vous le déclenchez manuellement.
- Le cas échéant, sélectionnez Commencer ou Commencer à l'heure définie, puis indiquez une date de début et une heure d'exécution.
Dans la section Data source details (Détails de la source de données), procédez comme suit :
1. Dans Modèles de nom de table, spécifiez les tables du lac de données HDFS à transférer en fournissant des noms de table ou des modèles correspondant aux tables de la base de données HDFS. Vous devez utiliser la syntaxe d'expression régulière Java pour spécifier les modèles de table. Exemple :
  - db1..* correspond à toutes les tables de db1.
  - db1.table1;db2.table2 correspond à table1 dans db1 et à table2 dans db2.
2. Pour Chemin GCS de vidage de la découverte BQMS, saisissez le chemin d'accès au bucket contenant le fichier hive-dumper-output.zip que vous avez généré lors de la création d'un fichier de métadonnées pour Apache Hive.
3. Sélectionnez le type de metastore dans la liste déroulante :
  - DATAPROC_METASTORE : sélectionnez cette option pour stocker vos métadonnées dans Dataproc Metastore. Vous devez fournir l'URL de Dataproc Metastore dans URL Dataproc Metastore.
  - BIGLAKE_METASTORE : sélectionnez cette option pour stocker vos métadonnées dans BigLake Metastore. Vous devez fournir un ensemble de données BigQuery dans Ensemble de données BigQuery.
  - BIGLAKE_REST_CATALOG : sélectionnez cette option pour stocker vos métadonnées dans le catalogue REST Iceberg BigLake Metastore.
4. Dans le champ Chemin GCS de destination, saisissez le chemin d'accès à un bucket Cloud Storage pour stocker vos données migrées.
5. Facultatif : Pour Compte de service, saisissez un compte de service à utiliser avec ce transfert de données. Le compte de service doit appartenir au même projetGoogle Cloud que celui dans lequel la configuration du transfert et l'ensemble de données de destination sont créés.
6. Facultatif : Vous pouvez activer l'option Utiliser la sortie de la traduction pour configurer un chemin d'accès Cloud Storage et une base de données uniques pour chaque table migrée. Pour ce faire, indiquez le chemin d'accès au dossier Cloud Storage contenant les résultats de la traduction dans le champ Chemin d'accès GCS de la sortie de traduction BQMS. Pour en savoir plus, consultez Configurer la sortie de la traduction.
  - Si vous spécifiez un chemin Cloud Storage pour la sortie de la traduction, le chemin Cloud Storage de destination et l'ensemble de données BigQuery seront extraits des fichiers de ce chemin.
7. Pour Type de stockage, sélectionnez l'une des options suivantes :
  - HDFS : sélectionnez cette option si votre stockage de fichiers est HDFS. Dans le champ Nom du pool d'agents STS, vous devez indiquer le nom du pool d'agents que vous avez créé lorsque vous avez configuré votre agent Storage Transfer.
  - S3 : sélectionnez cette option si votre stockage de fichiers est Amazon S3. Dans les champs ID de clé d'accès et Clé d'accès secrète, vous devez fournir l'ID de clé d'accès et la clé d'accès secrète que vous avez créés lorsque vous avez configuré vos identifiants d'accès.

bq

Pour planifier le transfert de tables Hive gérées, saisissez la commande bq mk et indiquez l'indicateur de création de transfert --transfer_config :

  bq mk --transfer_config
  --data_source=hadoop
  --display_name='TRANSFER_NAME'
  --service_account_name='SERVICE_ACCOUNT'
  --project_id='PROJECT_ID'
  --location='REGION'
  --params='{"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"
    }'

Remplacez les éléments suivants :

TRANSFER_NAME : nom à afficher de la configuration de transfert. Ce nom peut correspondre à toute valeur permettant d'identifier le transfert si vous devez le modifier ultérieurement.
SERVICE_ACCOUNT : nom du compte de service utilisé pour authentifier le transfert. Le compte de service doit appartenir au même project_id que celui utilisé pour créer le transfert et doit disposer de toutes les autorisations requises.
PROJECT_ID : ID de votre projet Google Cloud . Si vous ne fournissez pas de --project_id afin de spécifier un projet particulier, le projet par défaut est utilisé.
REGION : emplacement de cette configuration de transfert.
LIST_OF_TABLES : liste des entités à transférer. Utilisez une spécification de nommage hiérarchique : database.table. Ce champ accepte les expressions régulières RE2 pour spécifier les tables. Par exemple :
- db1..* : spécifie toutes les tables de la base de données.
- db1.table1;db2.table2 : liste des tables
DUMPER_BUCKET : bucket Cloud Storage contenant le fichier hive-dumper-output.zip.
MIGRATION_BUCKET : chemin d'accès GCS de destination dans lequel tous les fichiers sous-jacents seront chargés.
METASTORE : type de metastore vers lequel migrer. Définissez ce paramètre sur l'une des valeurs suivantes :
- DATAPROC_METASTORE : pour transférer des métadonnées vers Dataproc Metastore.
- BIGLAKE_METASTORE : pour transférer des métadonnées vers BigLake Metastore.
- BIGLAKE_REST_CATALOG : pour transférer les métadonnées vers le catalogue REST Iceberg BigLake Metastore.
DATAPROC_METASTORE_URL : URL de votre Dataproc Metastore. Obligatoire si la valeur de metastore est DATAPROC_METASTORE.
BIGLAKE_METASTORE_DATASET : ensemble de données BigQuery pour votre metastore BigLake. Obligatoire si la valeur de metastore est BIGLAKE_METASTORE.
TRANSLATION_OUTPUT_BUCKET : (facultatif) Spécifiez un bucket Cloud Storage pour les résultats de la traduction. Pour en savoir plus, consultez Utiliser le résultat de la traduction.
STORAGE_TYPE : spécifiez le stockage de fichiers sous-jacent pour vos tables. Les types acceptés sont HDFS et S3.
AGENT_POOL_NAME : nom du pool d'agents utilisé pour créer des agents. Obligatoire si la valeur de storage_type est HDFS.
AWS_ACCESS_KEY_ID : ID de la clé d'accès provenant des identifiants d'accès. Obligatoire si storage_type est défini sur S3.
AWS_SECRET_ACCESS_KEY : clé d'accès secrète provenant des identifiants d'accès. Obligatoire si storage_type est défini sur S3.

Exécutez cette commande pour créer la configuration de transfert et démarrer le transfert des tables gérées Hive. Par défaut, les transferts sont planifiés pour s'exécuter toutes les 24 heures, mais vous pouvez les configurer à l'aide des options de planification des transferts.

Une fois le transfert terminé, vos tables du cluster Hadoop seront migrées vers MIGRATION_BUCKET.

Options d'ingestion de données

Les sections suivantes fournissent plus d'informations sur la façon de configurer vos transferts de tables gérées Hive.

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 Google Cloud avec les dernières modifications apportées au tableau source. Par exemple, toutes les opérations d'insertion, de suppression ou de mise à jour avec des modifications de schéma sont reflétées dans Google Cloud à chaque transfert.

Options de planification des transferts

Par défaut, les transferts sont planifiés toutes les 24 heures. Pour configurer la fréquence d'exécution des transferts, ajoutez l'option --schedule à la configuration du transfert et spécifiez une programmation de transfert à l'aide de la syntaxe schedule. Les transferts de tables gérées Hive doivent être espacés d'au moins 24 heures.

Pour les transferts ponctuels, vous pouvez ajouter l'indicateur end_time à la configuration du transfert pour qu'il ne s'exécute qu'une seule fois.

Configurer la sortie de la traduction

Vous pouvez configurer un chemin d'accès Cloud Storage et une base de données uniques pour chaque table migrée. Pour ce faire, suivez les étapes ci-dessous afin de générer un fichier YAML de mappage des tables que vous pourrez utiliser dans votre configuration de transfert.

Créez un fichier YAML de configuration (suffixé par config.yaml) dans DUMPER_BUCKET contenant les éléments suivants :
```
    type: object_rewriter
    relation:
    - match:
        relationRegex: ".*"
      external:
        location_expression: "'gs://MIGRATION_BUCKET/' + table.schema + '/' + table.name"
```
- Remplacez MIGRATION_BUCKET par le nom du bucket Cloud Storage qui servira de destination pour vos fichiers de tables migrés. Le champ location_expression est une expression CEL (Common Expression Language).
Créez un autre fichier de configuration YAML (suffixé par config.yaml) dans DUMPER_BUCKET contenant les éléments suivants :
```
    type: experimental_object_rewriter
    relation:
      - match:
          schema: SOURCE_DATABASE
        outputName:
          database: null
          schema: TARGET_DATABASE
```
- Remplacez SOURCE_DATABASE et TARGET_DATABASE par le nom de la base de données source et de la base de données Dataproc Metastore ou de l'ensemble de données BigQuery, selon le metastore choisi. Assurez-vous que l'ensemble de données BigQuery existe si vous configurez la base de données pour le metastore BigLake.
Pour en savoir plus sur ces fichiers de configuration YAML, consultez Consignes pour créer un fichier de configuration YAML.

Générez des tables mappant le fichier YAML à l'aide de la commande suivante :

curl -d '{
  "tasks": {
      "string": {
        "type": "HiveQL2BigQuery_Translation",
        "translation_details": {
            "target_base_uri": "TRANSLATION_OUTPUT_BUCKET",
            "source_target_mapping": {
              "source_spec": {
                  "base_uri": "DUMPER_BUCKET"
              }
            },
            "target_types": ["metadata"]
        }
      }
  }
  }' \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/PROJECT_ID/locations/LOCATION/workflows

Remplacez les éléments suivants :

TRANSLATION_OUTPUT_BUCKET : (facultatif) spécifiez un bucket Cloud Storage pour les résultats de la traduction. Pour en savoir plus, consultez Utiliser le résultat de la traduction.
DUMPER_BUCKET : URI de base du bucket Cloud Storage contenant le fichier YAML de configuration et hive-dumper-output.zip.
TOKEN : jeton OAuth. Vous pouvez le générer dans la ligne de commande avec la commande gcloud auth print-access-token.
PROJECT_ID : projet pour le traitement de la traduction.
LOCATION : emplacement où le job est traité. Par exemple, eu ou us.

Surveillez l'état de ce job. Une fois l'opération terminée, un fichier de mappage est généré pour chaque table de la base de données dans un chemin prédéfini dans TRANSLATION_OUTPUT_BUCKET.

Orchestrer l'exécution du dumper à l'aide de la commande `cron`

Vous pouvez automatiser les transferts incrémentiels à l'aide d'un job cron pour exécuter l'outil dwh-migration-dumper. En automatisant l'extraction des métadonnées, vous vous assurez qu'un dump à jour de Hadoop est disponible pour les exécutions de transfert incrémentiel ultérieures.

Avant de commencer

Avant d'utiliser ce script d'automatisation, remplissez les conditions préalables à l'installation du dumper. Pour exécuter le script, vous devez avoir installé l'outil dwh-migration-dumper et configuré les autorisations IAM nécessaires.

Planifier l'automatisation

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 de la sortie du vidage :

#!/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"

# Function to display usage information
usage() {
  echo "Usage: $0 [options]"
  echo ""
  echo "Runs the dwh-migration-dumper tool and uploads its output to provided GCS path."
  echo ""
  echo "Options:"
  echo "  --dumper-executable   The full path to the dumper executable. (Required)"
  echo "  --gcs-base-path       The base GCS path for output files. (Required)"
  echo "  --local-base-dir      The local base directory for logs and temp files. (Required)"
  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
          ;;
      -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

# 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="hive-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 GCS."

  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 "GCS 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}"
)

log "Starting dumper tool execution..."
log "COMMAND: ${DUMPER_EXECUTABLE} ${dumper_command_args[*]}"

"${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 GCS
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 GCS successful."

# The script will now exit with code 0. The trap will call cleanup and log the script end.

Exécutez la commande suivante pour rendre le script exécutable :
```
chmod +x PATH_TO_SCRIPT
```

Planifiez le script à l'aide de crontab, en remplaçant les variables par les valeurs appropriées pour votre tâche. Ajoutez une entrée pour planifier le job. L'exemple suivant exécute le script tous les jours à 2h30 :

# 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

Lorsque vous créez le transfert, assurez-vous que le champ table_metadata_path est défini sur le même chemin d'accès Cloud Storage que celui que vous avez configuré pour GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT. Il s'agit du chemin d'accès contenant les fichiers ZIP de sortie du dumper.

Considérations relatives à la planification

Pour éviter que les données ne soient obsolètes, le dump de métadonnées doit être prêt avant le début du transfert planifié. Configurez la fréquence du job cron en conséquence.

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 ce timing pour définir un calendrier cron qui précède de manière sécurisée l'exécution du transfert DTS et garantit la fraîcheur des données.

Surveiller les transferts de tables gérées Hive

Une fois que vous avez planifié le transfert de tables gérées Hive, vous pouvez surveiller le job de transfert à l'aide des commandes de l'outil de ligne de commande bq. Pour en savoir plus sur la surveillance de vos tâches de transfert, consultez Afficher vos transferts.

Suivre l'état de la migration des tables

Vous pouvez également exécuter l'outil dwh-dts-status pour surveiller l'état de toutes les tables transférées dans une configuration de transfert ou une base de données spécifique. Vous pouvez également utiliser l'outil dwh-dts-status pour lister toutes les configurations de transfert d'un projet.

Avant de commencer

Avant de pouvoir utiliser l'outil dwh-dts-status, procédez comme suit :

Obtenez l'outil dwh-dts-status en téléchargeant le package dwh-migration-tool à partir du dépôt GitHub dwh-migration-tools.
Authentifiez votre compte auprès de Google Cloud à l'aide de la commande suivante :
```
gcloud auth application-default login
```
Pour en savoir plus, consultez Fonctionnement des identifiants par défaut de l'application.
Vérifiez que l'utilisateur dispose des rôles bigquery.admin et logging.viewer. Pour en savoir plus sur les rôles IAM, consultez la documentation de référence sur le contrôle des accès.

Répertorier toutes les configurations de transfert d'un projet

Pour répertorier toutes les configurations de transfert d'un projet, exécutez la commande suivante :

  ./dwh-dts-status --list-transfer-configs --project-id=[PROJECT_ID] --location=[LOCATION]

Remplacez les éléments suivants :

PROJECT_ID : ID du projet Google Cloud qui exécute les transferts.
LOCATION : emplacement où la configuration de transfert a été créée.

Cette commande génère une table contenant une liste des noms et des ID des configurations de transfert.

Afficher l'état de toutes les tables d'une configuration

Pour afficher l'état de toutes les tables incluses dans une configuration de transfert, utilisez la commande suivante :

  ./dwh-dts-status --list-status-for-config --project-id=[PROJECT_ID] --config-id=[CONFIG_ID] --location=[LOCATION]

Remplacez les éléments suivants :

PROJECT_ID : ID du projet Google Cloud qui exécute les transferts.
LOCATION : emplacement où la configuration de transfert a été créée.
CONFIG_ID : ID de la configuration de transfert spécifiée.

Cette commande génère un tableau listant les tables et leur état de transfert dans la configuration de transfert spécifiée. L'état du transfert peut être l'une des valeurs suivantes : PENDING, RUNNING, SUCCEEDED, FAILED ou CANCELLED.

Afficher l'état de toutes les tables d'une base de données

Pour afficher l'état de toutes les tables transférées à partir d'une base de données spécifique, utilisez la commande suivante :

  ./dwh-dts-status --list-status-for-database --project-id=[PROJECT_ID] --database=[DATABASE]

Remplacez les éléments suivants :

PROJECT_ID : ID du projet Google Cloud qui exécute les transferts.
DATABASE : nom de la base de données spécifiée.

Cette commande génère un tableau listant les tables et leur état de transfert dans la base de données spécifiée. L'état du transfert peut être l'une des valeurs suivantes : PENDING, RUNNING, SUCCEEDED, FAILED ou CANCELLED.

Migrer les tables gérées Hive vers Google Cloud

Limites

Avant de commencer

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

Activer les API

Configurer les autorisations

Configurer Storage Transfer Service pour les lacs de données HDFS

Configurer les autorisations du service de transfert de stockage pour Amazon S3

Planifier le transfert de tables gérées Hive

Console

bq

Options d'ingestion de données

Transferts incrémentiels

Options de planification des transferts

Configurer la sortie de la traduction

Orchestrer l'exécution du dumper à l'aide de la commande cron

Avant de commencer

Planifier l'automatisation

Considérations relatives à la planification

Surveiller les transferts de tables gérées Hive

Suivre l'état de la migration des tables

Avant de commencer

Répertorier toutes les configurations de transfert d'un projet

Afficher l'état de toutes les tables d'une configuration

Afficher l'état de toutes les tables d'une base de données

Orchestrer l'exécution du dumper à l'aide de la commande `cron`