Diese Seite wurde von der Cloud Translation API übersetzt.

Verwaltete Hive-Tabellen zu Google Cloudmigrieren

In diesem Dokument wird beschrieben, wie Sie verwaltete Hive-Tabellen zu Google Cloudmigrieren.

Mit dem Connector für die Migration von verwalteten Hive-Tabellen im BigQuery Data Transfer Service können Sie Ihre von Hive Metastore verwalteten Tabellen nahtlos migrieren. Dabei werden sowohl Hive- als auch Iceberg-Formate aus lokalen und Cloud-Umgebungen in Google Cloudunterstützt. Wir unterstützen die Dateispeicherung in HDFS oder Amazon S3.

Mit dem Connector für die Migration von verwalteten Hive-Tabellen können Sie Ihre verwalteten Hive-Tabellen in Dataproc Metastore, BigLake Metastore oder BigLake Metastore Iceberg REST Catalog registrieren, während Sie Cloud Storage als Dateispeicher verwenden.

Das folgende Diagramm bietet einen Überblick über die Tabellenmigration aus dem Hadoop-Cluster.

Übersicht über die Tabellenmigration vom Hive-Data Lake zu BigQuery.

Beschränkungen

Übertragungen von Hive-verwalteten Tabellen unterliegen den folgenden Einschränkungen:

Wenn Sie Apache Iceberg-Tabellen migrieren möchten, müssen Sie die Tabellen im BigLake-Metastore registrieren, um Schreibzugriff für Open-Source-Engines (z. B. Apache Spark oder Flink) und Lesezugriff für BigQuery zu ermöglichen.
Wenn Sie verwaltete Hive-Tabellen migrieren möchten, müssen Sie die Tabellen im Dataproc Metastore registrieren, um Schreibzugriff für Open-Source-Engines und Lesezugriff für BigQuery zu ermöglichen.
Sie müssen das bq-Befehlszeilentool verwenden, um verwaltete Hive-Tabellen zu BigQuery zu migrieren.

Hinweise

Bevor Sie die Übertragung von verwalteten Hive-Tabellen planen, müssen Sie Folgendes tun:

Metadatendatei für Apache Hive generieren

Führen Sie das dwh-migration-dumper-Tool aus, um Metadaten für Apache Hive zu extrahieren. Das Tool generiert eine Datei mit dem Namen hive-dumper-output.zip in einem Cloud Storage-Bucket, der in diesem Dokument als DUMPER_BUCKET bezeichnet wird.

APIs aktivieren

Aktivieren Sie die folgenden APIs in IhremGoogle Cloud -Projekt:

Data Transfer API
Storage Transfer API

Ein Dienst-Agent wird erstellt, wenn Sie die Data Transfer API aktivieren.

Berechtigungen konfigurieren

Erstellen Sie ein Dienstkonto und weisen Sie ihm die Rolle „BigQuery-Administrator“ (roles/bigquery.admin) zu. Dieses Dienstkonto wird zum Erstellen der Übertragungskonfiguration verwendet.
Beim Aktivieren der Data Transfer API wird ein Dienst-Agent (P4SA) erstellt. Weisen Sie ihm die folgenden Rollen zu:
- roles/metastore.metadataOwner
- roles/storagetransfer.admin
- roles/serviceusage.serviceUsageConsumer
- roles/storage.objectAdmin
  - Wenn Sie Metadaten für BigLake-Iceberg-Tabellen migrieren, müssen Sie auch die Rolle roles/bigquery.admin gewähren.
  - Wenn Sie Metadaten zum Iceberg REST Catalog von BigLake Metastore migrieren, müssen Sie auch die Rolle roles/biglake.admin zuweisen.

Weisen Sie dem Dienst-Agent mit dem folgenden Befehl die Rolle roles/iam.serviceAccountTokenCreator zu:

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

Storage Transfer Agent für HDFS-Data Lakes konfigurieren

Erforderlich, wenn die Datei in HDFS gespeichert ist. So richten Sie den für eine HDFS-Data-Lake-Übertragung erforderlichen Storage Transfer Agent ein:

Berechtigungen konfigurieren, damit der Storage Transfer Agent in Ihrem Hadoop-Cluster ausgeführt werden kann.
Installieren Sie Docker auf lokalen Agent-Computern.
Erstellen Sie einen Storage Transfer Service-Agent-Pool in Ihrem Google Cloud Projekt.
Installieren Sie Agents auf Ihren lokalen Agent-Computern.

Storage Transfer Service-Berechtigungen für Amazon S3 konfigurieren

Erforderlich, wenn die Datei in Amazon S3 gespeichert ist. Übertragungen von Amazon S3 sind agentenlose Übertragungen, für die bestimmte Berechtigungen erforderlich sind. So konfigurieren Sie den Storage Transfer Service für eine Amazon S3-Übertragung:

Berechtigungen für die agentenlose Übertragung konfigurieren
Zugangsdaten für AWS Amazon S3 einrichten
- Notieren Sie sich die Zugriffsschlüssel-ID und den geheimen Zugriffsschlüssel, nachdem Sie Ihre Zugriffsanmeldedaten eingerichtet haben.
Fügen Sie die von Storage Transfer Service-Workern verwendeten IP-Bereiche der Liste der zulässigen IP-Adressen hinzu, wenn in Ihrem AWS-Projekt IP-Einschränkungen verwendet werden.

Übertragung von verwalteten Hive-Tabellen planen

Wählen Sie eine der folgenden Optionen aus:

Console

Rufen Sie in der Google Cloud -Console die Seite „Datenübertragungen“ auf.

Zu „Datenübertragungen”
Klicken Sie auf Übertragung erstellen.
Wählen Sie im Abschnitt Quelltyp die Option Hive Managed Tables aus der Liste Quelle aus.
Wählen Sie unter Standort einen Standorttyp und dann eine Region aus.
Geben Sie im Abschnitt Konfigurationsname für Übertragung als Anzeigename einen Namen für die Datenübertragung ein.
Führen Sie im Abschnitt Zeitplanoptionen folgende Schritte aus:
- Wählen Sie in der Liste Wiederholungshäufigkeit aus, wie oft diese Datenübertragung ausgeführt werden soll. Wenn Sie eine benutzerdefinierte Wiederholungshäufigkeit angeben möchten, wählen Sie Benutzerdefiniert aus. Wenn Sie On demand auswählen, wird diese Datenübertragung ausgeführt, wenn Sie die Übertragung manuell auslösen.
- Wählen Sie gegebenenfalls Jetzt starten oder Zu festgelegter Zeit starten aus und geben Sie ein Startdatum und eine Laufzeit an.
Führen Sie im Abschnitt Details zur Datenquelle folgende Schritte aus:
1. Geben Sie bei Table name patterns (Tabellennamensmuster) HDFS-Data-Lake-Tabellen an, die übertragen werden sollen. Geben Sie dazu Tabellennamen oder Muster an, die mit Tabellen in der HDFS-Datenbank übereinstimmen. Sie müssen die Java-Syntax für reguläre Ausdrücke verwenden, um Tabellenmuster anzugeben. Beispiel:
  - db1..* führt zu Übereinstimmung mit allen Tabellen in db1.
  - db1.table1;db2.table2 entspricht „table1“ in „db1“ und „table2“ in „db2“.
2. Geben Sie für BQMS discovery dump gcs path den Pfad zum Bucket ein, der die hive-dumper-output.zip-Datei enthält, die Sie beim Erstellen einer Metadatendatei für Apache Hive generiert haben.
3. Wählen Sie den Metastore-Typ aus der Drop-down-Liste aus:
  - DATAPROC_METASTORE: Wählen Sie diese Option aus, um Ihre Metadaten in Dataproc Metastore zu speichern. Sie müssen die URL für den Dataproc Metastore in Dataproc Metastore-URL angeben.
  - BIGLAKE_METASTORE: Wählen Sie diese Option aus, um Ihre Metadaten im BigLake Metastore zu speichern. Sie müssen ein BigQuery-Dataset in BigQuery-Dataset angeben.
  - BIGLAKE_REST_CATALOG: Wählen Sie diese Option aus, um Ihre Metadaten im Iceberg REST-Katalog von BigLake Metastore zu speichern.
4. Geben Sie unter Ziel-GCS-Pfad einen Pfad zu einem Cloud Storage-Bucket ein, in dem die migrierten Daten gespeichert werden sollen.
5. Optional: Geben Sie unter Dienstkonto ein Dienstkonto ein, das für diese Datenübertragung verwendet werden soll. Das Dienstkonto sollte zum selbenGoogle Cloud -Projekt gehören, in dem die Übertragungskonfiguration und das Ziel-Dataset erstellt werden.
6. Optional: Sie können Übersetzungsausgabe verwenden aktivieren, um für jede migrierte Tabelle einen eindeutigen Cloud Storage-Pfad und eine eindeutige Datenbank einzurichten. Geben Sie dazu im Feld BQMS translation output gcs path (BQMS-Übersetzungsausgabe-GCS-Pfad) den Pfad zum Cloud Storage-Ordner mit den Übersetzungsergebnissen an. Weitere Informationen finden Sie unter Übersetzungsausgabe konfigurieren.
  - Wenn Sie einen Cloud Storage-Pfad für die Übersetzungsausgabe angeben, werden der Cloud Storage-Zielpfad und das BigQuery-Dataset aus den Dateien in diesem Pfad abgerufen.
7. Wählen Sie für Speichertyp eine der folgenden Optionen aus:
  - HDFS: Wählen Sie diese Option aus, wenn Ihr Dateispeicher HDFS ist. Geben Sie im Feld STS-Agent-Pool-Name den Namen des Agent-Pools an, den Sie beim Konfigurieren Ihres Storage Transfer Agent erstellt haben.
  - S3: Wählen Sie diese Option aus, wenn Ihr Dateispeicher Amazon S3 ist. In den Feldern Zugriffsschlüssel-ID und Secret-Zugriffsschlüssel müssen Sie die Zugriffsschlüssel-ID und den Secret-Zugriffsschlüssel angeben, die Sie beim Einrichten Ihrer Zugangsdaten erstellt haben.

bq

Geben Sie den Befehl bq mk mit dem Flag --transfer_config für die Übertragungserstellung ein, um die Übertragung von verwalteten Hive-Tabellen zu planen:

  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"
    }'

Ersetzen Sie Folgendes:

TRANSFER_NAME: Der Anzeigename für die Übertragungskonfiguration. Der Übertragungsname kann ein beliebiger Wert sein, mit dem Sie die Übertragung identifizieren können, wenn Sie sie später ändern müssen.
SERVICE_ACCOUNT ist der Name des Dienstkontos, der zur Authentifizierung der Übertragung verwendet wird. Das Dienstkonto sollte zum selben project_id gehören, das für die Erstellung der Übertragung verwendet wurde, und sollte alle erforderlichen Berechtigungen haben.
PROJECT_ID: Projekt-ID in Google Cloud . Wenn --project_id nicht bereitgestellt wird, um ein bestimmtes Projekt anzugeben, wird das Standardprojekt verwendet.
REGION: Speicherort dieser Übertragungskonfiguration.
LIST_OF_TABLES: eine Liste der zu übertragenden Einheiten. Verwenden Sie eine hierarchische Namensspezifikation – database.table. In diesem Feld können Sie Tabellen mit regulären RE2-Ausdrücken angeben. Beispiel:
- db1..*: gibt alle Tabellen in der Datenbank an.
- db1.table1;db2.table2: eine Liste von Tabellen
DUMPER_BUCKET: Der Cloud Storage-Bucket, der die Datei hive-dumper-output.zip enthält.
MIGRATION_BUCKET: Der GCS-Zielpfad, in den alle zugrunde liegenden Dateien geladen werden.
METASTORE: Der Typ des Metastore, zu dem migriert werden soll. Legen Sie dafür einen der folgenden Werte fest:
- DATAPROC_METASTORE: Zum Übertragen von Metadaten in Dataproc Metastore.
- BIGLAKE_METASTORE: Zum Übertragen von Metadaten in BigLake Metastore.
- BIGLAKE_REST_CATALOG: Zum Übertragen von Metadaten in den BigLake Metastore Iceberg REST-Katalog.
DATAPROC_METASTORE_URL: Die URL Ihres Dataproc Metastore. Erforderlich, wenn metastore DATAPROC_METASTORE ist.
BIGLAKE_METASTORE_DATASET: Das BigQuery-Dataset für Ihren BigLake Metastore. Erforderlich, wenn metastore BIGLAKE_METASTORE ist.
TRANSLATION_OUTPUT_BUCKET: (Optional) Geben Sie einen Cloud Storage-Bucket für die Übersetzungsausgabe an. Weitere Informationen finden Sie unter Übersetzungsausgabe verwenden.
STORAGE_TYPE: Geben Sie den zugrunde liegenden Dateispeicher für Ihre Tabellen an. Unterstützte Typen sind HDFS und S3.
AGENT_POOL_NAME: Der Name des Agent-Pools, der zum Erstellen von Agents verwendet wird. Erforderlich, wenn storage_type HDFS ist.
AWS_ACCESS_KEY_ID: Die Zugriffsschlüssel-ID aus den Anmeldedaten für den Zugriff. Erforderlich, wenn storage_type S3 ist.
AWS_SECRET_ACCESS_KEY: Der Secret-Zugriffsschlüssel aus den Zugangsdaten. Erforderlich, wenn storage_type S3 ist.

Führen Sie diesen Befehl aus, um die Übertragungskonfiguration zu erstellen und die Übertragung der verwalteten Hive-Tabellen zu starten. Übertragungen werden standardmäßig alle 24 Stunden ausgeführt. Sie können sie aber mit Optionen für die Übertragungsplanung konfigurieren.

Nach Abschluss der Übertragung werden Ihre Tabellen im Hadoop-Cluster zu MIGRATION_BUCKET migriert.

Optionen für die Datenaufnahme

In den folgenden Abschnitten finden Sie weitere Informationen zur Konfiguration von Übertragungen für von Hive verwaltete Tabellen.

Inkrementelle Übertragungen

Wenn eine Übertragungskonfiguration mit einem wiederkehrenden Zeitplan eingerichtet wird, wird die Tabelle auf Google Cloud bei jeder nachfolgenden Übertragung mit den neuesten Änderungen an der Quelltabelle aktualisiert. Beispielsweise werden alle Einfüge-, Lösch- oder Aktualisierungsvorgänge mit Schemaänderungen bei jeder Übertragung in Google Cloud berücksichtigt.

Optionen für die Übertragungsplanung

Standardmäßig werden Übertragungen alle 24 Stunden ausgeführt. Wenn Sie konfigurieren möchten, wie oft Übertragungen ausgeführt werden, fügen Sie der Übertragungskonfiguration das Flag --schedule hinzu und geben Sie einen Übertragungszeitplan mit der schedule-Syntax an. Bei Übertragungen von Hive-verwalteten Tabellen müssen mindestens 24 Stunden zwischen den Übertragungsvorgängen liegen.

Bei einmaligen Übertragungen können Sie der Übertragungskonfiguration das Flag end_time hinzufügen, damit die Übertragung nur einmal ausgeführt wird.

Übersetzungsausgabe konfigurieren

Sie können für jede migrierte Tabelle einen eindeutigen Cloud Storage-Pfad und eine eindeutige Datenbank konfigurieren. Führen Sie dazu die folgenden Schritte aus, um eine YAML-Datei mit der Tabellenzuordnung zu generieren, die Sie in Ihrer Übertragungskonfiguration verwenden können.

Erstellen Sie im DUMPER_BUCKET eine YAML-Konfigurationsdatei (mit dem Suffix config.yaml), die Folgendes enthält:
```
    type: object_rewriter
    relation:
    - match:
        relationRegex: ".*"
      external:
        location_expression: "'gs://MIGRATION_BUCKET/' + table.schema + '/' + table.name"
```
- Ersetzen Sie MIGRATION_BUCKET durch den Namen des Cloud Storage-Bucket, der das Ziel für die migrierten Tabellendateien ist. Das Feld location_expression ist ein CEL-Ausdruck (Common Expression Language).
Erstellen Sie eine weitere YAML-Konfigurationsdatei (mit dem Suffix config.yaml) im DUMPER_BUCKET, die Folgendes enthält:
```
    type: experimental_object_rewriter
    relation:
      - match:
          schema: SOURCE_DATABASE
        outputName:
          database: null
          schema: TARGET_DATABASE
```
- Ersetzen Sie SOURCE_DATABASE und TARGET_DATABASE durch den Namen der Quelldatenbank und der Dataproc Metastore-Datenbank oder des BigQuery-Datasets, je nach ausgewähltem Metastore. Achten Sie darauf, dass das BigQuery-Dataset vorhanden ist, wenn Sie die Datenbank für den BigLake-Metastore konfigurieren.
Weitere Informationen zu dieser Konfigurations-YAML-Datei finden Sie unter Richtlinien zum Erstellen einer Konfigurations-YAML-Datei.

Generieren Sie Tabellen, die die YAML-Datei zuordnen, mit dem folgenden Befehl:

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

Ersetzen Sie Folgendes:

TRANSLATION_OUTPUT_BUCKET: (Optional) Geben Sie einen Cloud Storage-Bucket für die Übersetzungsausgabe an. Weitere Informationen finden Sie unter Übersetzungsausgabe verwenden.
DUMPER_BUCKET: Der Basis-URI für den Cloud Storage-Bucket, der die hive-dumper-output.zip- und die YAML-Konfigurationsdatei enthält.
TOKEN: Das OAuth-Token. Sie können diese in der Befehlszeile mit dem Befehl gcloud auth print-access-token generieren.
PROJECT_ID: das Projekt, in dem die Übersetzung verarbeitet werden soll.
LOCATION: der Ort, an dem der Job verarbeitet wird. Beispiel: euoder us

Status dieses Jobs überwachen Nach Abschluss wird für jede Tabelle in der Datenbank eine Zuordnungsdatei in einem vordefinierten Pfad in TRANSLATION_OUTPUT_BUCKET generiert.

Ausführung des Dumpers mit dem Befehl `cron` orchestrieren

Sie können inkrementelle Übertragungen automatisieren, indem Sie einen cron-Job zum Ausführen des dwh-migration-dumper-Tools verwenden. Durch die Automatisierung der Metadatenextraktion stellen Sie sicher, dass ein aktueller Dump aus Hadoop für nachfolgende inkrementelle Übertragungen verfügbar ist.

Hinweise

Bevor Sie dieses Automatisierungsskript verwenden, müssen Sie die Voraussetzungen für die Installation des Dumpers erfüllen. Damit Sie das Skript ausführen können, muss das Tool „dwh-migration-dumper“ installiert und die erforderlichen IAM-Berechtigungen konfiguriert sein.

Automatisierung planen

Speichern Sie das folgende Skript in einer lokalen Datei. Dieses Skript ist so konzipiert, dass es von einem cron-Daemon konfiguriert und ausgeführt wird, um den Extraktions- und Uploadprozess der Dumper-Ausgabe zu automatisieren:

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

Führen Sie den folgenden Befehl aus, um das Skript ausführbar zu machen:
```
chmod +x PATH_TO_SCRIPT
```

Planen Sie das Script mit crontab und ersetzen Sie die Variablen durch die entsprechenden Werte für Ihren Job. Fügen Sie einen Eintrag hinzu, um den Job zu planen. Im folgenden Beispiel wird das Skript jeden Tag um 2:30 Uhr ausgeführt:

# 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

Achten Sie beim Erstellen der Übertragung darauf, dass das Feld table_metadata_path auf denselben Cloud Storage-Pfad festgelegt ist, den Sie für GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT konfiguriert haben. Dies ist der Pfad, der die ZIP-Dateien der Dumper-Ausgabe enthält.

Überlegungen zur Planung

Damit die Daten nicht veraltet sind, muss der Metadaten-Dump vor Beginn der geplanten Übertragung bereit sein. Konfigurieren Sie die Häufigkeit des cron-Jobs entsprechend.

Wir empfehlen, das Skript einige Male manuell auszuführen, um die durchschnittliche Zeit zu ermitteln, die das Dumper-Tool zum Generieren der Ausgabe benötigt. Legen Sie mit diesem Timing einen cron-Zeitplan fest, der sicher vor dem DTS-Übertragungslauf liegt und für aktuelle Daten sorgt.

Übertragungen von verwalteten Hive-Tabellen überwachen

Nachdem Sie die Übertragung von Hive-verwalteten Tabellen geplant haben, können Sie den Übertragungsjob mit Befehlen des bq-Befehlszeilentools überwachen. Informationen zum Überwachen Ihrer Übertragungsjobs finden Sie unter Übertragungen ansehen.

Status der Tabellenmigration verfolgen

Sie können auch das Tool dwh-dts-status ausführen, um den Status aller übertragenen Tabellen in einer Übertragungskonfiguration oder einer bestimmten Datenbank zu überwachen. Sie können auch das Tool dwh-dts-status verwenden, um alle Übertragungskonfigurationen in einem Projekt aufzulisten.

Hinweise

Bevor Sie das Tool dwh-dts-status verwenden können, müssen Sie Folgendes tun:

Laden Sie das dwh-dts-status-Tool herunter, indem Sie das dwh-migration-tool-Paket aus dem dwh-migration-tools-GitHub-Repository herunterladen.
Authentifizieren Sie Ihr Konto für Google Cloud mit dem folgenden Befehl:
```
gcloud auth application-default login
```
Weitere Informationen finden Sie unter Funktionsweise von Standardanmeldedaten für Anwendungen.
Prüfen Sie, ob der Nutzer die Rolle bigquery.admin und logging.viewer hat. Weitere Informationen zu IAM-Rollen finden Sie unter Referenz zur Zugriffssteuerung.

Alle Übertragungskonfigurationen in einem Projekt auflisten

Verwenden Sie den folgenden Befehl, um alle Übertragungskonfigurationen in einem Projekt aufzulisten:

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

Ersetzen Sie Folgendes:

PROJECT_ID : die Google Cloud Projekt-ID, unter der die Übertragungen ausgeführt werden.
LOCATION : Der Ort, an dem die Übertragungskonfiguration erstellt wurde.

Mit diesem Befehl wird eine Tabelle mit einer Liste von Namen und IDs von Übertragungskonfigurationen ausgegeben.

Status aller Tabellen in einer Konfiguration ansehen

Mit dem folgenden Befehl können Sie den Status aller Tabellen in einer Übertragungskonfiguration aufrufen:

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

Ersetzen Sie Folgendes:

PROJECT_ID: die Google Cloud Projekt-ID, unter der die Übertragungen ausgeführt werden.
LOCATION: Der Ort, an dem die Übertragungskonfiguration erstellt wurde.
CONFIG_ID: Die ID der angegebenen Übertragungskonfiguration.

Mit diesem Befehl wird eine Tabelle mit einer Liste der Tabellen und ihrem Übertragungsstatus in der angegebenen Übertragungskonfiguration ausgegeben. Der Übertragungsstatus kann einer der folgenden Werte sein: PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED.

Status aller Tabellen in einer Datenbank ansehen

Mit dem folgenden Befehl können Sie den Status aller Tabellen aufrufen, die aus einer bestimmten Datenbank übertragen wurden:

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

Ersetzen Sie Folgendes:

PROJECT_ID: die Google Cloud Projekt-ID, unter der die Übertragungen ausgeführt werden.
DATABASE:Der Name der angegebenen Datenbank.

Mit diesem Befehl wird eine Tabelle mit einer Liste von Tabellen und deren Übertragungsstatus in der angegebenen Datenbank ausgegeben. Der Übertragungsstatus kann einer der folgenden Werte sein: PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED.

Verwaltete Hive-Tabellen zu Google Cloudmigrieren

Beschränkungen

Hinweise

Metadatendatei für Apache Hive generieren

APIs aktivieren

Berechtigungen konfigurieren

Storage Transfer Agent für HDFS-Data Lakes konfigurieren

Storage Transfer Service-Berechtigungen für Amazon S3 konfigurieren

Übertragung von verwalteten Hive-Tabellen planen

Console

bq

Optionen für die Datenaufnahme

Inkrementelle Übertragungen

Optionen für die Übertragungsplanung

Übersetzungsausgabe konfigurieren

Ausführung des Dumpers mit dem Befehl cron orchestrieren

Hinweise

Automatisierung planen

Überlegungen zur Planung

Übertragungen von verwalteten Hive-Tabellen überwachen

Status der Tabellenmigration verfolgen

Hinweise

Alle Übertragungskonfigurationen in einem Projekt auflisten

Status aller Tabellen in einer Konfiguration ansehen

Status aller Tabellen in einer Datenbank ansehen

Ausführung des Dumpers mit dem Befehl `cron` orchestrieren