Migra las tablas administradas de Hive a Google Cloud

En este documento, se muestra cómo migrar tus tablas administradas de Hive a Google Cloud.

Puedes usar el conector de migración de tablas administradas de Hive en el Servicio de transferencia de datos de BigQuery para migrar sin problemas tus tablas administradas por el metastore de Hive, que admite los formatos de Hive y de Iceberg desde entornos locales y de la nube a Google Cloud. Admitimos el almacenamiento de archivos en HDFS o Amazon S3.

Con el conector de migración de tablas administradas de Hive, puedes registrar tus tablas administradas de Hive en Dataproc Metastore, BigLake Metastore o BigLake Metastore Iceberg REST Catalog mientras usas Cloud Storage como almacenamiento de archivos.

En el siguiente diagrama, se proporciona una descripción general del proceso de migración de tablas desde el clúster de Hadoop.

Descripción general de la migración de tablas del data lake de Hive a BigQuery.

Limitaciones

Las transferencias de tablas administradas de Hive están sujetas a las siguientes limitaciones:

  • Para migrar tablas de Apache Iceberg, debes registrarlas en el metastore de BigLake para permitir el acceso de escritura a los motores de código abierto (como Apache Spark o Flink) y el acceso de lectura a BigQuery.
  • Para migrar tablas administradas de Hive, debes registrarlas en Dataproc Metastore para permitir el acceso de escritura a los motores de código abierto y el acceso de lectura a BigQuery.
  • Debes usar la herramienta de línea de comandos de bq para migrar las tablas administradas de Hive a BigQuery.

Antes de comenzar

Antes de programar la transferencia de tablas administradas de Hive, debes realizar las siguientes acciones:

Genera un archivo de metadatos para Apache Hive

Ejecuta la herramienta dwh-migration-dumper para extraer metadatos de Apache Hive. La herramienta genera un archivo llamado hive-dumper-output.zip en un bucket de Cloud Storage, al que se hace referencia en este documento como DUMPER_BUCKET.

Habilita las APIs

Habilita las siguientes APIs en tu proyecto deGoogle Cloud :

  • API de Data Transfer
  • API de Storage Transfer

Cuando habilitas la API de Data Transfer, se crea un agente de servicio.

Configura permisos

  1. Crea una cuenta de servicio y otórgale el rol de administrador de BigQuery (roles/bigquery.admin). Esta cuenta de servicio se usa para crear la configuración de transferencia.
  2. Cuando se habilita la API de Data Transfer, se crea un agente de servicio (P4SA). Otorga los siguientes roles:

    • roles/metastore.metadataOwner
    • roles/storagetransfer.admin
    • roles/serviceusage.serviceUsageConsumer
    • roles/storage.objectAdmin
      • Si migras metadatos para tablas de BigLake Iceberg, también debes otorgar el rol roles/bigquery.admin.
      • Si migras metadatos al catálogo de Iceberg de REST de BigLake Metastore, también debes otorgar el rol roles/biglake.admin.
  3. Otorga al agente de servicio el rol roles/iam.serviceAccountTokenCreator con el siguiente comando:

    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

Configura Storage Transfer Agent para los data lakes de HDFS

Se requiere cuando el archivo se almacena en HDFS. Para configurar el agente de transferencia de almacenamiento necesario para una transferencia de data lake de HDFS, haz lo siguiente:

  1. Configura los permisos para ejecutar el agente de transferencia de almacenamiento en tu clúster de Hadoop.
  2. Instala Docker en las máquinas de agentes locales.
  3. Crea un grupo de agentes del Servicio de transferencia de almacenamiento en tu Google Cloud proyecto.
  4. Instala agentes en tus máquinas de agentes locales.

Configura los permisos del Servicio de transferencia de almacenamiento para Amazon S3

Se requiere cuando el archivo se almacena en Amazon S3. Las transferencias de Amazon S3 son transferencias sin agentes que requieren permisos específicos. Para configurar el Servicio de transferencia de almacenamiento para una transferencia de Amazon S3, haz lo siguiente:

  1. Configura permisos de transferencia sin agente.
  2. Configura las credenciales de acceso para AWS Amazon S3.
    • Toma nota del ID de clave de acceso y la clave de acceso secreta después de configurar tus credenciales de acceso.
  3. Agrega los rangos de IP que usan los trabajadores del Servicio de transferencia de almacenamiento a tu lista de IPs permitidas si tu proyecto de AWS usa restricciones de IP.

Programa la transferencia de tablas administradas de Hive

Selecciona una de las siguientes opciones:

Console

  1. Ve a la página Transferencia de datos en la Google Cloud consola.

    Ir a Transferencias de datos

  2. Haz clic en Crear transferencia.

  3. En la sección Tipo de fuente, selecciona Tablas administradas de Hive en la lista Fuente.

  4. En Ubicación, selecciona un tipo de ubicación y, luego, una región.

  5. En la sección Nombre de configuración de la transferencia, en Nombre visible, ingresa el nombre de la transferencia de datos.

  6. En la sección Opciones de programación, haz lo siguiente:

    • En la lista Frecuencia de repetición, selecciona una opción para especificar la frecuencia con la que se ejecuta esta transferencia de datos. Para especificar una frecuencia de repetición personalizada, selecciona Personalizado. Si seleccionas Según demanda, esta transferencia se ejecuta cuando activas la transferencia de forma manual.
    • Si corresponde, selecciona Comenzar ahora o Comenzar a una hora determinada y proporciona una fecha de inicio y una hora de ejecución.
  7. En la sección Detalles de la fuente de datos, haz lo siguiente:

    1. En Patrones de nombres de tablas, especifica las tablas del data lake de HDFS que se transferirán. Para ello, proporciona nombres de tablas o patrones que coincidan con las tablas de la base de datos de HDFS. Debes usar la sintaxis de expresiones regulares de Java para especificar patrones de tablas. Por ejemplo:
      • db1..* coincide con todas las tablas de db1.
      • db1.table1;db2.table2 coincide con table1 en db1 y table2 en db2.
    2. En BQMS discovery dump gcs path, ingresa la ruta de acceso al bucket que contiene el archivo hive-dumper-output.zip que generaste cuando creaste un archivo de metadatos para Apache Hive.
    3. Elige el tipo de metastore en la lista desplegable:
      • DATAPROC_METASTORE: Selecciona esta opción para almacenar tus metadatos en Dataproc Metastore. Debes proporcionar la URL de Dataproc Metastore en URL de Dataproc Metastore.
      • BIGLAKE_METASTORE: Selecciona esta opción para almacenar tus metadatos en BigLake Metastore. Debes proporcionar un conjunto de datos de BigQuery en Conjunto de datos de BigQuery.
      • BIGLAKE_REST_CATALOG: Selecciona esta opción para almacenar tus metadatos en el catálogo de REST de Iceberg de BigLake Metastore.
    4. En Ruta de acceso de GCS de destino, ingresa una ruta de acceso a un bucket de Cloud Storage para almacenar los datos migrados.

    5. Opcional: En Cuenta de servicio, ingresa una cuenta de servicio para usar con esta transferencia de datos. La cuenta de servicio debe pertenecer al mismo proyecto deGoogle Cloud en el que se crean la configuración de transferencia y el conjunto de datos de destino.

    6. Opcional: Puedes habilitar Usar el resultado de la traducción para configurar una ruta de acceso y una base de datos únicas de Cloud Storage para cada tabla que se migre. Para ello, proporciona la ruta de acceso a la carpeta de Cloud Storage que contiene los resultados de la traducción en el campo Ruta de acceso de GCS de salida de la traducción de BQMS. Para obtener más información, consulta Cómo configurar el resultado de la traducción.

      • Si especificas una ruta de Cloud Storage de salida de la traducción, la ruta de Cloud Storage de destino y el conjunto de datos de BigQuery se obtendrán de los archivos de esa ruta.
    7. En Tipo de almacenamiento, selecciona una de las siguientes opciones:

      • HDFS: Selecciona esta opción si tu almacenamiento de archivos es HDFS. En el campo Nombre del grupo de agentes de STS, debes proporcionar el nombre del grupo de agentes que creaste cuando configuraste tu agente de transferencia de Storage.
      • S3: Selecciona esta opción si tu almacenamiento de archivos es Amazon S3. En los campos ID de clave de acceso y Clave de acceso secreta, debes proporcionar el ID de clave de acceso y la clave de acceso secreta que creaste cuando configuraste tus credenciales de acceso.

bq

Para programar la transferencia de tablas administradas de Hive, ingresa el comando bq mk y proporciona la marca de creación de transferencias --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"
    }'

Reemplaza lo siguiente:

  • TRANSFER_NAME es el nombre visible de la configuración de transferencia. El nombre de la transferencia puede ser cualquier valor que te permita identificarla si es necesario hacerle modificaciones más tarde.
  • SERVICE_ACCOUNT: Es el nombre de la cuenta de servicio que se usa para autenticar tu transferencia. La cuenta de servicio debe ser propiedad del mismo project_id que se usa para crear la transferencia y debe tener todos los permisos necesarios.
  • PROJECT_ID: El ID de tu proyecto Google Cloud . Si no se proporciona --project_id para especificar un proyecto en particular, se usa el proyecto predeterminado.
  • REGION: Es la ubicación de esta configuración de transferencia.
  • LIST_OF_TABLES: Es una lista de entidades que se transferirán. Usa una especificación de nombres jerárquica: database.table. Este campo admite expresiones regulares de RE2 para especificar tablas. Por ejemplo:
    • db1..*: Especifica todas las tablas de la base de datos.
    • db1.table1;db2.table2: Una lista de tablas
  • DUMPER_BUCKET: Es el bucket de Cloud Storage que contiene el archivo hive-dumper-output.zip.
  • MIGRATION_BUCKET: Es la ruta de acceso de GCS de destino en la que se cargarán todos los archivos subyacentes.
  • METASTORE: Es el tipo de metastore al que se migrará. Establece este parámetro en uno de los siguientes valores:
    • DATAPROC_METASTORE: Para transferir metadatos a Dataproc Metastore.
    • BIGLAKE_METASTORE: Para transferir metadatos a BigLake Metastore.
    • BIGLAKE_REST_CATALOG: Para transferir metadatos al catálogo de Iceberg de BigLake Metastore REST.
  • DATAPROC_METASTORE_URL: Es la URL de tu Dataproc Metastore. Obligatorio si metastore es DATAPROC_METASTORE.
  • BIGLAKE_METASTORE_DATASET: Es el conjunto de datos de BigQuery para tu metastore de BigLake. Obligatorio si metastore es BIGLAKE_METASTORE.
  • TRANSLATION_OUTPUT_BUCKET: (Opcional) Especifica un bucket de Cloud Storage para el resultado de la traducción. Para obtener más información, consulta Cómo usar el resultado de la traducción.
  • STORAGE_TYPE: Especifica el almacenamiento de archivos subyacente para tus tablas. Los tipos admitidos son HDFS y S3.
  • AGENT_POOL_NAME: Es el nombre del grupo de agentes que se usa para crear agentes. Obligatorio si storage_type es HDFS.
  • AWS_ACCESS_KEY_ID: Es el ID de la clave de acceso de las credenciales de acceso. Obligatorio si storage_type es S3.
  • AWS_SECRET_ACCESS_KEY: Es la clave de acceso secreta de las credenciales de acceso. Obligatorio si storage_type es S3.

Ejecuta este comando para crear la configuración de transferencia y comenzar la transferencia de las tablas administradas de Hive. De forma predeterminada, las transferencias se programan para ejecutarse cada 24 horas, pero se pueden configurar con opciones de programación de transferencias.

Cuando se complete la transferencia, tus tablas del clúster de Hadoop se migrarán a MIGRATION_BUCKET.

Opciones de transferencia de datos

En las siguientes secciones, se proporciona más información sobre cómo puedes configurar tus transferencias de tablas administradas de Hive.

Transferencias incrementales

Cuando se configura una transferencia con un programa recurrente, cada transferencia posterior actualiza la tabla en Google Cloud con las actualizaciones más recientes realizadas en la tabla de origen. Por ejemplo, todas las operaciones de inserción, eliminación o actualización con cambios de esquema se reflejan en Google Cloud con cada transferencia.

Opciones de programación de transferencias

De forma predeterminada, las transferencias se programan para ejecutarse cada 24 horas. Para configurar la frecuencia con la que se ejecutan las transferencias, agrega la marca --schedule a la configuración de la transferencia y especifica un programa de transferencia con la sintaxis schedule. Las transferencias de tablas administradas por Hive deben tener un mínimo de 24 horas entre ejecuciones.

En el caso de las transferencias únicas, puedes agregar la marca end_time a la configuración de transferencia para que esta se ejecute solo una vez.

Configura el resultado de la traducción

Puedes configurar una ruta de acceso y una base de datos de Cloud Storage únicas para cada tabla migrada. Para ello, sigue estos pasos para generar un archivo YAML de asignación de tablas que puedas usar en la configuración de tu transferencia.

  1. Crea un archivo YAML de configuración (con el sufijo config.yaml) en DUMPER_BUCKET que contenga lo siguiente:

        type: object_rewriter
        relation:
        - match:
            relationRegex: ".*"
          external:
            location_expression: "'gs://MIGRATION_BUCKET/' + table.schema + '/' + table.name"
    • Reemplaza MIGRATION_BUCKET por el nombre del bucket de Cloud Storage que es el destino de los archivos de la tabla migrada. El campo location_expression es una expresión del lenguaje de expresiones comunes (CEL).
  2. Crea otro archivo YAML de configuración (con el sufijo config.yaml) en DUMPER_BUCKET que contenga lo siguiente:

        type: experimental_object_rewriter
        relation:
          - match:
              schema: SOURCE_DATABASE
            outputName:
              database: null
              schema: TARGET_DATABASE
    • Reemplaza SOURCE_DATABASE y TARGET_DATABASE por el nombre de la base de datos de origen y la base de datos de Dataproc Metastore o el conjunto de datos de BigQuery, según el metastore elegido. Asegúrate de que exista el conjunto de datos de BigQuery si configuras la base de datos para BigLake Metastore.

    Para obtener más información sobre estos archivos YAML de configuración, consulta Lineamientos para crear un archivo YAML de configuración.

  3. Genera el archivo YAML de asignación de tablas con el siguiente comando:

    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

    Reemplaza lo siguiente:

    • TRANSLATION_OUTPUT_BUCKET: (Opcional) Especifica un bucket de Cloud Storage para el resultado de la traducción. Para obtener más información, consulta Cómo usar el resultado de la traducción.
    • DUMPER_BUCKET: Es el URI base del bucket de Cloud Storage que contiene el archivo YAML de hive-dumper-output.zip y de configuración.
    • TOKEN: Es el token de OAuth. Puedes generar este archivo en la línea de comandos con el comando gcloud auth print-access-token.
    • PROJECT_ID: Es el proyecto que procesará la traducción.
    • LOCATION: Es la ubicación en la que se procesa el trabajo. Por ejemplo, eu o us.
  4. Supervisa el estado de este trabajo. Cuando se completa, se genera un archivo de asignación para cada tabla de la base de datos dentro de una ruta predefinida en TRANSLATION_OUTPUT_BUCKET.

Orquesta la ejecución del volcado con el comando cron

Puedes automatizar las transferencias incrementales con un trabajo de cron para ejecutar la herramienta dwh-migration-dumper. Al automatizar la extracción de metadatos, te aseguras de que haya disponible un volcado actualizado de Hadoop para las ejecuciones de transferencia incremental posteriores.

Antes de comenzar

Antes de usar esta secuencia de comandos de automatización, completa los requisitos previos de instalación del volcado. Para ejecutar la secuencia de comandos, debes tener instalada la herramienta dwh-migration-dumper y configurados los permisos de IAM necesarios.

Cómo programar la automatización

  1. Guarda la siguiente secuencia de comandos en un archivo local. Esta secuencia de comandos está diseñada para que un daemon cron la configure y ejecute para automatizar el proceso de extracción y carga del resultado del volcado:

    #!/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.
  2. Ejecuta el siguiente comando para hacer que la secuencia de comandos sea ejecutable:

    chmod +x PATH_TO_SCRIPT
  3. Programa la secuencia de comandos con crontab y reemplaza las variables por los valores adecuados para tu trabajo. Agrega una entrada para programar el trabajo. En el siguiente ejemplo, se ejecuta la secuencia de comandos todos los días a las 2:30 a.m.:

    # 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
  4. Cuando crees la transferencia, asegúrate de que el campo table_metadata_path esté configurado con la misma ruta de Cloud Storage que configuraste para GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT. Es la ruta de acceso que contiene los archivos ZIP de salida del volcado.

Consideraciones de programación

Para evitar que los datos estén desactualizados, la volcado de metadatos debe estar listo antes de que comience la transferencia programada. Configura la frecuencia del trabajo cron según corresponda.

Te recomendamos que ejecutes algunas pruebas del script de forma manual para determinar el tiempo promedio que tarda la herramienta de volcado en generar su resultado. Usa este tiempo para establecer un programa de cron que preceda de forma segura la ejecución de la transferencia de DTS y garantice la actualización.

Supervisa las transferencias de tablas administradas de Hive

Después de programar la transferencia de tablas administradas de Hive, puedes supervisar el trabajo de transferencia con los comandos de la herramienta de línea de comandos de bq. Para obtener información sobre cómo supervisar tus trabajos de transferencia, consulta Cómo ver tus transferencias.

Realiza un seguimiento del estado de la migración de la tabla

También puedes ejecutar la herramienta dwh-dts-status para supervisar el estado de todas las tablas transferidas dentro de una configuración de transferencia o una base de datos en particular. También puedes usar la herramienta dwh-dts-status para enumerar todas las opciones de configuración de transferencia en un proyecto.

Antes de comenzar

Antes de usar la herramienta de dwh-dts-status, haz lo siguiente:

  1. Para obtener la herramienta dwh-dts-status, descarga el paquete dwh-migration-tool desde el repositorio de GitHub de dwh-migration-tools.

  2. Autentica tu cuenta en Google Cloud con el siguiente comando:

    gcloud auth application-default login
    

    Para obtener más información, consulta Cómo funcionan las credenciales predeterminadas de la aplicación.

  3. Verifica que el usuario tenga los roles bigquery.admin y logging.viewer. Para obtener más información sobre los roles de IAM, consulta la Referencia de control de acceso.

Enumera todas las configuraciones de transferencia en un proyecto

Para enumerar todas las opciones de configuración de transferencia en un proyecto, usa el siguiente comando:

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

Reemplaza lo siguiente:

  • PROJECT_ID : Es el ID del proyecto de Google Cloud que ejecuta las transferencias.
  • LOCATION : Es la ubicación en la que se creó la configuración de transferencia.

Este comando genera una tabla con una lista de los nombres y los IDs de las configuraciones de transferencia.

Consulta los estados de todas las tablas de una configuración

Para ver el estado de todas las tablas incluidas en una configuración de transferencia, usa el siguiente comando:

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

Reemplaza lo siguiente:

  • PROJECT_ID: Es el ID del proyecto Google Cloud que ejecuta las transferencias.
  • LOCATION: Es la ubicación en la que se creó la configuración de transferencia.
  • CONFIG_ID: Es el ID de la configuración de transferencia especificada.

Este comando genera una tabla con una lista de las tablas y su estado de transferencia en la configuración de transferencia especificada. El estado de la transferencia puede ser uno de los siguientes valores: PENDING, RUNNING, SUCCEEDED, FAILED o CANCELLED.

Consulta los estados de todas las tablas de una base de datos

Para ver el estado de todas las tablas transferidas desde una base de datos específica, usa el siguiente comando:

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

Reemplaza lo siguiente:

  • PROJECT_ID: Es el ID del proyecto Google Cloud que ejecuta las transferencias.
  • DATABASE:Es el nombre de la base de datos especificada.

Este comando genera una tabla con una lista de las tablas y su estado de transferencia en la base de datos especificada. El estado de la transferencia puede ser uno de los siguientes valores: PENDING, RUNNING, SUCCEEDED, FAILED o CANCELLED.