Hive 관리 테이블을 Google Cloud로 마이그레이션
이 문서에서는 Hive 관리 테이블을 Google Cloud로 마이그레이션하는 방법을 보여줍니다.
BigQuery Data Transfer Service의 Hive 관리 테이블 마이그레이션 커넥터를 사용하여 온프레미스 및 클라우드 환경에서 Hive 및 Iceberg 형식을 모두 지원하는 Hive metastore에서 관리하는 테이블을 Google Cloud로 원활하게 마이그레이션할 수 있습니다. HDFS 또는 Amazon S3의 파일 스토리지가 지원됩니다.
Hive 관리 테이블 마이그레이션 커넥터를 사용하면 파일 스토리지로 Cloud Storage를 사용하는 동시에 Dataproc Metastore, BigLake metastore 또는 BigLake metastore Iceberg REST 카탈로그에 Hive 관리 테이블을 등록할 수 있습니다.
다음 다이어그램은 Hadoop 클러스터에서 테이블을 마이그레이션하는 프로세스를 간략하게 보여줍니다.
제한사항
Hive 관리형 테이블 전송에는 다음과 같은 제한사항이 적용됩니다.
- Apache Iceberg 테이블을 이전하려면 오픈소스 엔진 (예: Apache Spark 또는 Flink)의 쓰기 액세스를 허용하고 BigQuery의 읽기 액세스를 허용하도록 해당 테이블을 BigLake metastore에 등록해야 합니다.
- Hive 관리 테이블을 이전하려면 오픈소스 엔진의 쓰기 액세스를 허용하고 BigQuery의 읽기 액세스를 허용하도록 해당 테이블을 Dataproc Metastore에 등록해야 합니다.
- bq 명령줄 도구를 사용하여 Hive 관리 테이블을 BigQuery로 마이그레이션해야 합니다.
시작하기 전에
Hive 관리 테이블 전송을 예약하기 전에 다음을 수행해야 합니다.
Apache Hive용 메타데이터 파일 생성
dwh-migration-dumper 도구를 실행하여 Apache Hive의 메타데이터를 추출합니다. 이 도구는 이 문서에서 DUMPER_BUCKET이라는 Cloud Storage 버킷에 hive-dumper-output.zip이라는 파일을 생성합니다.
API 사용 설정
Google Cloud 프로젝트에서 다음 API를 사용 설정합니다.
- Data Transfer API
- Storage Transfer API
Data Transfer API를 사용 설정하면 서비스 에이전트가 생성됩니다.
권한 구성
- 서비스 계정을 만들고 BigQuery 관리자 역할(
roles/bigquery.admin)을 부여합니다. 이 서비스 계정은 전송 구성을 만드는 데 사용됩니다. Data Transfer API를 사용 설정하면 서비스 에이전트(P4SA)가 생성됩니다. 다음 역할을 부여합니다.
roles/metastore.metadataOwnerroles/storagetransfer.adminroles/serviceusage.serviceUsageConsumerroles/storage.objectAdmin- BigLake Iceberg 테이블의 메타데이터를 마이그레이션하는 경우
roles/bigquery.admin역할도 부여해야 합니다. - BigLake metastore Iceberg REST 카탈로그로 메타데이터를 마이그레이션하는 경우
roles/biglake.admin역할도 부여해야 합니다.
- BigLake Iceberg 테이블의 메타데이터를 마이그레이션하는 경우
다음 명령어를 사용하여 서비스 에이전트에
roles/iam.serviceAccountTokenCreator역할을 부여합니다.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
HDFS 데이터 레이크용 스토리지 전송 에이전트 구성
파일이 HDFS에 저장된 경우 필수입니다. HDFS 데이터 레이크 전송에 필요한 스토리지 전송 에이전트를 설정하려면 다음을 실행하세요.
- Hadoop 클러스터에서 스토리지 전송 에이전트를 실행하도록 권한을 구성합니다.
- 온프레미스 에이전트 머신에 Docker를 설치합니다.
- Google Cloud 프로젝트에서 Storage Transfer Service 에이전트 풀을 만듭니다.
- 온프레미스 에이전트 머신에 에이전트를 설치합니다.
Amazon S3에 대한 Storage Transfer Service 권한 구성
파일이 Amazon S3에 저장된 경우 필요합니다. Amazon S3에서 전송하는 경우 에이전트가 없는 전송이며 특정 권한이 필요합니다. Amazon S3 전송을 위해 Storage Transfer Service를 구성하려면 다음 단계를 따르세요.
- 에이전트 없는 전송 권한 구성
- AWS Amazon S3의 액세스 사용자 인증 정보 설정
- 액세스 사용자 인증 정보를 설정한 후 액세스 키 ID와 보안 비밀 액세스 키를 기록해 둡니다.
- AWS 프로젝트에서 IP 제한을 사용하는 경우 Storage Transfer Service 작업자가 사용하는 IP 범위를 추가합니다.
Hive 관리형 테이블 전송 예약
다음 옵션 중 하나를 선택합니다.
콘솔
Google Cloud 콘솔에서 데이터 전송 페이지로 이동합니다.
전송 만들기를 클릭합니다.
소스 유형 섹션의 소스 목록에서 Hive 관리 테이블을 선택합니다.
위치에서 위치 유형을 선택한 다음 리전을 선택합니다.
전송 구성 이름 섹션의 표시 이름에 데이터 전송 이름을 입력합니다.
일정 옵션 섹션에서 다음을 수행합니다.
- 반복 빈도 목록에서 이 데이터 전송 실행 빈도를 지정하는 옵션을 선택합니다. 커스텀 반복 빈도를 지정하려면 커스텀을 선택합니다. 주문형을 선택한 경우 수동으로 전송을 트리거하면 이 전송이 실행됩니다.
- 해당하는 경우 지금 시작 또는 설정 시간에 시작을 선택하고 시작 날짜와 실행 시간을 입력합니다.
데이터 소스 세부정보 섹션에서 다음을 수행합니다.
- 테이블 이름 패턴에 HDFS 데이터베이스의 테이블과 일치하는 테이블 이름이나 패턴을 입력하여 전송할 HDFS 데이터 레이크 테이블을 지정합니다. Java 정규 표현식 구문을 사용하여 테이블 패턴을 지정해야 합니다. 예를 들면 다음과 같습니다.
db1..*은 db1의 모든 테이블과 일치합니다.db1.table1;db2.table2은 db1의 table1과 db2의 table2를 찾습니다.
- BQMS 검색 덤프 gcs 경로에 Apache Hive용 메타데이터 파일을 만들 때 생성한
hive-dumper-output.zip파일이 포함된 버킷의 경로를 입력합니다. - 드롭다운 목록에서 메타스토어 유형을 선택합니다.
DATAPROC_METASTORE: Dataproc Metastore에 메타데이터를 저장하려면 이 옵션을 선택합니다. Dataproc metastore url에 Dataproc Metastore의 URL을 제공해야 합니다.BIGLAKE_METASTORE: BigLake Metastore에 메타데이터를 저장하려면 이 옵션을 선택하세요. BigQuery 데이터 세트에 BigQuery 데이터 세트를 제공해야 합니다.BIGLAKE_REST_CATALOG: BigLake metastore Iceberg REST 카탈로그에 메타데이터를 저장하려면 이 옵션을 선택합니다.
대상 gcs 경로에 마이그레이션된 데이터를 저장할 Cloud Storage 버킷의 경로를 입력합니다.
선택사항: 서비스 계정에 이 데이터 전송에 사용할 서비스 계정을 입력합니다. 서비스 계정은 전송 구성과 대상 데이터 세트가 생성된 동일한Google Cloud 프로젝트에 속해야 합니다.
선택사항: 변환 출력 사용을 사용 설정하여 마이그레이션되는 각 테이블에 대해 고유한 Cloud Storage 경로와 데이터베이스를 설정할 수 있습니다. 이렇게 하려면 BQMS 번역 출력 gcs 경로 필드에 번역 결과가 포함된 Cloud Storage 폴더의 경로를 제공합니다. 자세한 내용은 변환 출력 구성을 참고하세요.
- 번역 출력 Cloud Storage 경로를 지정하면 대상 Cloud Storage 경로와 BigQuery 데이터 세트가 해당 경로의 파일에서 가져옵니다.
스토리지 유형에서 다음 옵션 중 하나를 선택합니다.
HDFS: 파일 스토리지가HDFS인 경우 이 옵션을 선택합니다. STS 에이전트 풀 이름 필드에 Storage Transfer Agent를 구성할 때 만든 에이전트 풀의 이름을 제공해야 합니다.S3: 파일 스토리지가Amazon S3인 경우 이 옵션을 선택합니다. 액세스 키 ID 및 보안 비밀 액세스 키 필드에 액세스 사용자 인증 정보를 설정할 때 만든 액세스 키 ID와 보안 비밀 액세스 키를 입력해야 합니다.
- 테이블 이름 패턴에 HDFS 데이터베이스의 테이블과 일치하는 테이블 이름이나 패턴을 입력하여 전송할 HDFS 데이터 레이크 테이블을 지정합니다. Java 정규 표현식 구문을 사용하여 테이블 패턴을 지정해야 합니다. 예를 들면 다음과 같습니다.
bq
Hive 관리 테이블 전송을 예약하려면 bq mk 명령어를 입력하고 전송 생성 플래그 --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" }'
다음을 바꿉니다.
TRANSFER_NAME: 전송 구성의 표시 이름. 전송 이름은 나중에 수정해야 할 경우를 대비해 전송을 식별할 수 있는 값이면 됩니다.SERVICE_ACCOUNT: 전송을 인증하는 데 사용되는 서비스 계정 이름입니다. 전송을 만드는 데 사용한 것과 동일한project_id에서 서비스 계정을 소유해야 하며 이 계정에 모든 필수 권한이 있어야 합니다.PROJECT_ID: Google Cloud 프로젝트 ID입니다. 특정 프로젝트를 지정하는--project_id가 입력되지 않으면 기본 프로젝트가 사용됩니다.REGION: 이 전송 구성의 위치입니다.LIST_OF_TABLES: 전송할 항목 목록입니다. 계층적 이름 지정 사양(database.table)을 사용합니다. 이 필드는 테이블을 지정하기 위해 RE2 정규 표현식을 지원합니다. 예를 들면 다음과 같습니다.db1..*: 데이터베이스의 모든 테이블을 지정합니다.db1.table1;db2.table2: 테이블 목록입니다.
DUMPER_BUCKET:hive-dumper-output.zip파일이 포함된 Cloud Storage 버킷입니다.MIGRATION_BUCKET: 모든 기본 파일이 로드될 대상 GCS 경로입니다.METASTORE: 이전할 메타스토어의 유형입니다. 다음 값 중 하나로 설정합니다.DATAPROC_METASTORE: 메타데이터를 Dataproc Metastore로 전송합니다.BIGLAKE_METASTORE: 메타데이터를 BigLake metastore로 전송합니다.BIGLAKE_REST_CATALOG: 메타데이터를 BigLake metastore Iceberg REST 카탈로그로 전송합니다.
DATAPROC_METASTORE_URL: Dataproc Metastore의 URL입니다.metastore이DATAPROC_METASTORE인 경우에 필요합니다.BIGLAKE_METASTORE_DATASET: BigLake Metastore의 BigQuery 데이터 세트입니다.metastore이BIGLAKE_METASTORE인 경우에 필요합니다.TRANSLATION_OUTPUT_BUCKET: (선택사항) 변환 출력의 Cloud Storage 버킷을 지정합니다. 자세한 내용은 변환 출력 사용을 참조하세요.STORAGE_TYPE: 테이블의 기본 파일 스토리지를 지정합니다. 지원되는 유형은HDFS및S3입니다.AGENT_POOL_NAME: 에이전트 생성에 사용되는 에이전트 풀의 이름입니다.storage_type이HDFS인 경우에 필요합니다.AWS_ACCESS_KEY_ID: 액세스 사용자 인증 정보의 액세스 키 ID입니다.storage_type이S3인 경우에 필요합니다.AWS_SECRET_ACCESS_KEY: 액세스 사용자 인증 정보의 보안 액세스 키입니다.storage_type이S3인 경우에 필요합니다.
이 명령어를 실행하여 전송 구성을 만들고 Hive 관리 테이블 전송을 시작합니다. 전송은 기본적으로 24시간마다 실행되도록 예약되지만 전송 예약 옵션을 사용하여 구성할 수 있습니다.
전송이 완료되면 Hadoop 클러스터의 테이블이 MIGRATION_BUCKET으로 마이그레이션됩니다.
데이터 수집 옵션
다음 섹션에서는 Hive 관리형 테이블 전송을 구성하는 방법을 자세히 설명합니다.
증분 전송
반복 일정으로 전송 구성을 설정하면 후속 전송마다 소스 테이블에 적용된 최신 업데이트로 Google Cloud 의 테이블이 업데이트됩니다. 예를 들어 스키마가 변경되는 모든 삽입, 삭제 또는 업데이트 작업은 전송될 때마다 Google Cloud 에 반영됩니다.
전송 예약 옵션
기본적으로 전송은 24시간마다 실행되도록 예약됩니다. 전송 실행 빈도를 구성하려면 전송 구성에 --schedule 플래그를 추가하고 schedule 문법을 사용하여 전송 일정을 지정합니다.
Hive 관리 테이블 전송은 전송 실행 간에 최소 24시간이 필요합니다.
일회성 전송의 경우 전송 구성에 end_time 플래그를 추가하여 전송을 한 번만 실행할 수 있습니다.
변환 출력 구성
마이그레이션된 각 테이블에 대해 고유한 Cloud Storage 경로와 데이터베이스를 구성할 수 있습니다. 이렇게 하려면 다음 단계에 따라 전송 구성에서 사용할 수 있는 테이블 매핑 YAML 파일을 생성하세요.
DUMPER_BUCKET에 다음이 포함된 구성 YAML 파일(config.yaml접미사)을 만듭니다.type: object_rewriter relation: - match: relationRegex: ".*" external: location_expression: "'gs://MIGRATION_BUCKET/' + table.schema + '/' + table.name"
MIGRATION_BUCKET을 마이그레이션된 테이블 파일의 대상인 Cloud Storage 버킷 이름으로 바꿉니다.location_expression필드는 Common Expression Language(CEL) 표현식입니다.
DUMPER_BUCKET에서 다음을 포함하는 다른 구성 YAML 파일(config.yaml접미사)을 만듭니다.type: experimental_object_rewriter relation: - match: schema: SOURCE_DATABASE outputName: database: null schema: TARGET_DATABASE
- 선택한 metastore에 따라
SOURCE_DATABASE및TARGET_DATABASE를 소스 데이터베이스 이름과 Dataproc Metastore 데이터베이스 또는 BigQuery 데이터 세트 이름으로 바꿉니다. BigLake Metastore의 데이터베이스를 구성하는 경우 BigQuery 데이터 세트가 있는지 확인합니다.
이러한 구성 YAML에 대한 자세한 내용은 구성 YAML 파일을 만들기 위한 가이드라인을 참조하세요.
- 선택한 metastore에 따라
다음 명령어를 사용하여 YAML 파일을 매핑하는 테이블을 생성합니다.
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
다음을 바꿉니다.
TRANSLATION_OUTPUT_BUCKET: (선택사항) 변환 출력의 Cloud Storage 버킷을 지정합니다. 자세한 내용은 변환 출력 사용을 참조하세요.DUMPER_BUCKET:hive-dumper-output.zip및 구성 YAML 파일이 포함된 Cloud Storage 버킷의 기본 URI입니다.TOKEN: OAuth 토큰입니다. 명령줄에서gcloud auth print-access-token명령어를 사용하여 생성할 수 있습니다.PROJECT_ID: 변환을 처리할 프로젝트입니다.LOCATION: 작업이 처리되는 위치입니다. 예를 들면eu또는us입니다.
이 작업의 상태를 모니터링합니다. 완료되면
TRANSLATION_OUTPUT_BUCKET의 사전 정의된 경로 내에서 데이터베이스에 있는 각 테이블에 매핑 파일이 생성됩니다.
cron 명령어를 사용하여 덤퍼 실행 오케스트레이션
cron 작업을 사용하여 dwh-migration-dumper 도구를 실행하면 증분 전송을 자동화할 수 있습니다. 메타데이터 추출을 자동화하면 후속 증분 전송 실행에 사용할 수 있는 최신 Hadoop 덤프가 제공됩니다.
시작하기 전에
이 자동화 스크립트를 사용하기 전에 dumper 설치 기본 요건을 완료하세요. 스크립트를 실행하려면 dwh-migration-dumper 도구가 설치되어 있고 필요한 IAM 권한이 구성되어 있어야 합니다.
자동화 예약
다음 스크립트를 로컬 파일에 저장합니다. 이 스크립트는
cron데몬이 구성하고 실행하여 덤퍼 출력의 추출 및 업로드 프로세스를 자동화하도록 설계되었습니다.#!/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-pathThe base GCS path for output files. (Required)" echo " --local-base-dirThe 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.다음 명령어를 실행하여 스크립트를 실행 가능하게 만듭니다.
chmod +x PATH_TO_SCRIPT
crontab를 사용하여 스크립트를 예약하고 변수를 작업에 적합한 값으로 바꿉니다. 작업을 예약하는 항목을 추가합니다. 다음 예시에서는 매일 오전 2시 30분에 스크립트를 실행합니다.# 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
전송을 만들 때
table_metadata_path필드가GCS_PATH_TO_UPLOAD_DUMPER_OUTPUT에 구성한 Cloud Storage 경로와 동일하게 설정되어 있는지 확인합니다. dumper 출력 ZIP 파일이 포함된 경로입니다.
예약 고려사항
데이터가 오래되는 것을 방지하려면 예약된 전송이 시작되기 전에 메타데이터 덤프가 준비되어 있어야 합니다. 이에 따라 cron 작업 빈도를 구성합니다.
덤퍼 도구가 출력을 생성하는 데 걸리는 평균 시간을 확인하려면 스크립트를 수동으로 몇 번 실행해 보는 것이 좋습니다. 이 타이밍을 사용하여 DTS 전송 실행보다 안전하게 앞서고 최신 상태를 유지하는 cron 일정을 설정하세요.
Hive 관리형 테이블 전송 모니터링
Hive 관리 테이블 전송을 예약한 후 bq 명령줄 도구 명령어로 전송 작업을 모니터링할 수 있습니다. 전송 작업 모니터링에 관한 자세한 내용은 전송 보기를 참조하세요.
테이블 마이그레이션 상태 추적
dwh-dts-status 도구를 실행하여 전송 구성 또는 특정 데이터베이스 내에서 전송된 모든 테이블의 상태를 모니터링할 수도 있습니다. dwh-dts-status 도구를 사용하여 프로젝트의 모든 전송 구성을 나열할 수도 있습니다.
시작하기 전에
dwh-dts-status 도구를 사용하려면 다음을 수행하세요.
dwh-migration-toolsGitHub 저장소에서dwh-migration-tool패키지를 다운로드하여dwh-dts-status도구를 가져옵니다.다음 명령어를 사용하여 Google Cloud 에 대해 계정을 인증합니다.
gcloud auth application-default login자세한 내용은 애플리케이션 기본 사용자 인증 정보의 작동 방식을 참조하세요.
사용자에게
bigquery.admin및logging.viewer역할이 있는지 확인합니다. IAM 역할에 대한 자세한 내용은 액세스 제어 참조를 참고하세요.
프로젝트의 모든 전송 구성 나열
프로젝트의 모든 전송 구성을 나열하려면 다음 명령어를 사용합니다.
./dwh-dts-status --list-transfer-configs --project-id=[PROJECT_ID] --location=[LOCATION]
다음을 바꿉니다.
PROJECT_ID: 전송을 실행하는 Google Cloud 프로젝트 ID입니다.LOCATION: 전송 구성이 생성된 위치입니다.
이 명령어는 전송 구성 이름과 ID 목록이 포함된 테이블을 출력합니다.
구성의 모든 테이블 상태 보기
전송 구성에 포함된 모든 테이블의 상태를 보려면 다음 명령어를 사용합니다.
./dwh-dts-status --list-status-for-config --project-id=[PROJECT_ID] --config-id=[CONFIG_ID] --location=[LOCATION]
다음을 바꿉니다.
PROJECT_ID: 전송을 실행하는 Google Cloud 프로젝트 ID입니다.LOCATION: 전송 구성이 생성된 위치입니다.CONFIG_ID: 지정된 전송 구성의 ID입니다.
이 명령어는 지정된 전송 구성에 있는 테이블 목록과 전송 상태가 포함된 테이블을 출력합니다. 전송 상태는 PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED 중 하나일 수 있습니다.
데이터베이스의 모든 테이블 상태 보기
특정 데이터베이스에서 전송된 모든 테이블의 상태를 보려면 다음 명령어를 사용합니다.
./dwh-dts-status --list-status-for-database --project-id=[PROJECT_ID] --database=[DATABASE]
다음을 바꿉니다.
PROJECT_ID: 전송을 실행하는 Google Cloud 프로젝트 ID입니다.DATABASE: 지정된 데이터베이스의 이름입니다.
이 명령어는 지정된 데이터베이스의 테이블 목록과 전송 상태가 포함된 테이블을 출력합니다. 전송 상태는 PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED 중 하나일 수 있습니다.