이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Apache Hive에서 스키마 및 데이터 마이그레이션

이 문서에서는 데이터, 보안 설정, 파이프라인을 Apache Hive에서 BigQuery로 마이그레이션하는 방법을 설명합니다.

또한 일괄 SQL 변환을 사용하여 SQL 스크립트를 일괄적으로 마이그레이션하거나 대화형 SQL 변환을 사용하여 임시 쿼리를 변환할 수 있습니다. 두 SQL 변환 서비스에서 Apache HiveQL이 완벽하게 지원됩니다.

마이그레이션 준비

다음 섹션에서는 Hive에서 BigQuery로 데이터 웨어하우스를 마이그레이션하는 데 도움이 되는 테이블 통계, 메타데이터, 보안 설정에 대한 정보를 수집하는 방법을 설명합니다.

소스 테이블 정보 수집

행 수, 열 수, 열 데이터 유형, 크기, 데이터 입력 형식, 위치와 같은 소스 Hive 테이블에 대한 정보를 수집합니다. 이 정보는 마이그레이션 프로세스와 데이터 마이그레이션을 검증하는 데 유용합니다. corp라는 데이터베이스에 employees라는 Hive 테이블이 있는 경우 다음 명령어를 사용하여 테이블 정보를 수집합니다.

# Find the number of rows in the table
hive> SELECT COUNT(*) FROM corp.employees;

# Output all the columns and their data types
hive> DESCRIBE corp.employees;

# Output the input format and location of the table
hive> SHOW CREATE TABLE corp.employees;
Output:
…
STORED AS INPUTFORMAT
  'org.apache.hadoop.hive.ql.io.avro.AvroContainerInputFormat'
OUTPUTFORMAT
  'org.apache.hadoop.hive.ql.io.avro.AvroContainerOutputFormat'
LOCATION
  'hdfs://demo_cluster/user/hive/warehouse/corp/employees'
TBLPROPERTIES (
…

# Get the total size of the table data in bytes
shell> hdfs dfs -du -s TABLE_LOCATION

소스 테이블 형식 변환

Hive에서 지원하는 일부 형식은 BigQuery에서 직접 수집할 수 없습니다.

Hive에서 지원하는 데이터 형식은 다음과 같습니다.

텍스트 파일
RC 파일
시퀀스 파일
Avro 파일
ORC 파일
Parquet 파일

BigQuery는 Cloud Storage에서 다음 파일 형식의 데이터 로드를 지원합니다.

CSV
JSON(줄바꿈으로 구분)
Avro
ORC
Parquet

BigQuery는 스키마 파일 없이 Avro, ORC, Parquet 형식의 데이터 파일을 직접 로드할 수 있습니다. CSV 또는 JSON(줄바꿈으로 구분됨) 형식으로 지정되지 않은 텍스트 파일의 경우, 데이터를 Avro 형식으로 Hive 테이블에 복사하거나 테이블 스키마를 BigQuery JSON 스키마로 변환하여 수집 시 제공할 수 있습니다.

Hive 액세스 제어 설정 수집

Hive와 BigQuery의 액세스 제어 메커니즘은 서로 다릅니다. 역할, 그룹, 구성원, 부여된 권한 등 모든 Hive 액세스 제어 설정을 수집합니다. BigQuery에서 보안 모델을 데이터 세트 수준별로 매핑하고 세분화된 ACL을 구현합니다. 예를 들어 Hive 사용자를 Google 계정에 매핑하고 HDFS 그룹을 Google 그룹에 매핑할 수 있습니다. 데이터 세트 수준에서 액세스를 설정할 수 있습니다. 다음 명령어를 사용하여 Hive에서 액세스 제어 설정을 수집합니다.

# List all the users
> hdfs dfs -ls /user/ | cut -d/ -f3

# Show all the groups that a specific user belongs to
> hdfs groups user_name

# List all the roles
hive> SHOW ROLES;

# Show all the roles assigned to a specific group
hive> SHOW ROLE GRANT GROUP group_name

# Show all the grants for a specific role
hive> SHOW GRANT ROLE role_name;

# Show all the grants for a specific role on a specific object
hive> SHOW GRANT ROLE role_name on object_type object_name;

Hive에서 필요한 권한이 있는 경우 테이블 뒤의 HDFS 파일에 직접 액세스할 수 있습니다. 표준 BigQuery 테이블에서 데이터가 테이블에 로드된 후 데이터는 BigQuery 스토리지에 저장됩니다. BigQuery Storage Read API를 사용하여 데이터를 읽을 수 있지만 모든 IAM, 행, 열 수준 보안이 계속 적용됩니다. BigQuery 외부 테이블을 사용하여 Cloud Storage의 데이터를 쿼리하는 경우 Cloud Storage에 대한 액세스도 IAM에 의해 제어됩니다.

커넥터를 사용하여 Apache Spark, Trino 또는 Apache Hive로 데이터를 쿼리할 수 있도록 BigLake 테이블을 만들 수 있습니다. BigQuery Storage API는 Cloud Storage 또는 BigQuery의 모든 BigLake 테이블에 대해 행 및 열 수준 거버넌스 정책을 적용합니다.

데이터 이전

온프레미스 또는 다른 클라우드 기반 소스 클러스터의 Hive 데이터를 BigQuery로 마이그레이션하는 작업은 다음 두 단계로 이루어집니다.

소스 클러스터에서 Cloud Storage로 데이터 복사
Cloud Storage에서 BigQuery로 데이터 로드

다음 섹션에서는 Hive 데이터 마이그레이션, 마이그레이션된 데이터 검증, 지속적으로 수집되는 데이터의 마이그레이션 처리에 대해 다룹니다. 예시는 비ACID 테이블용으로 작성됩니다.

파티션 열 데이터

Hive에서 파티션을 나눈 테이블의 데이터는 디렉터리 구조에 저장됩니다. 테이블의 각 파티션은 파티션 열의 특정 값과 연결되어 있습니다. 데이터 파일 자체에는 파티션 열의 데이터가 없습니다. SHOW PARTITIONS 명령어를 사용하여 파티션을 나눈 테이블의 다른 파티션을 나열합니다.

아래의 예시는 소스 Hive 테이블이 joining_date 및 department 열에서 파티션이 나뉘는 것을 보여줍니다. 이 표의 데이터 파일에는 이 두 열과 관련된 데이터가 없습니다.

hive> SHOW PARTITIONS corp.employees_partitioned
joining_date="2018-10-01"/department="HR"
joining_date="2018-10-01"/department="Analyst"
joining_date="2018-11-01"/department="HR"

이러한 열을 복사하는 한 가지 방법은 BigQuery에 로드하기 전에 파티션을 나눈 테이블을 파티션을 나누지 않은 테이블로 변환하는 것입니다.

파티션을 나눈 테이블과 유사한 스키마를 사용하여 파티션을 나누지 않은 테이블을 만듭니다.
파티션을 나눈 소스 테이블에서 파티션을 나누지 않은 테이블에 데이터를 로드합니다.
파티션을 나누지 않은 테이블 아래의 이러한 데이터 파일을 Cloud Storage에 복사합니다.
bq load 명령어를 사용하여 데이터를 BigQuery에 로드하고 TIMESTAMP 또는 DATE 유형 파티션 열의 이름(있는 경우)을 time_partitioning_field 인수로 제공합니다.

Cloud Storage에 데이터 복사

데이터 마이그레이션의 첫 번째 단계는 데이터를 Cloud Storage에 복사하는 것입니다. Hadoop DistCp를 사용하여 온프레미스 또는 기타 클라우드 클러스터에서 Cloud Storage로 데이터를 복사합니다. BigQuery에 데이터를 저장하려는 데이터 세트와 동일한 리전 또는 멀티 리전에 데이터를 버킷에 저장합니다. 예를 들어 기존 BigQuery 데이터 세트를 도쿄 리전의 대상으로 사용하려면 데이터를 보관할 도쿄의 Cloud Storage 리전 버킷을 선택해야 합니다.

Cloud Storage 버킷 위치를 선택한 후 다음 명령어를 사용하면 employees Hive 테이블 위치에 있는 모든 데이터 파일을 나열할 수 있습니다.

> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0

위의 모든 파일을 Cloud Storage에 복사합니다.

> hadoop distcp
hdfs://demo_cluster/user/hive/warehouse/corp/employees
gs://hive_data/corp/employees

데이터 스토리지 가격 책정에 따라 Cloud Storage에 데이터를 저장하는 데 요금이 청구됩니다.

쿼리 작업용으로 생성된 중간 파일을 보관하는 스테이징 디렉터리가 있을 수 있습니다. bq load 명령어를 실행하기 전에 이러한 디렉터리를 삭제해야 합니다.

데이터 로드

BigQuery는 Cloud Storage에서 다양한 형식의 데이터 일괄 로드를 지원합니다. 로드 작업을 만들기 전에 데이터를 로드할 BigQuery 데이터 세트가 있는지 확인합니다.

다음 명령어는 Hive에서 비ACID 테이블에 복사된 데이터를 보여줍니다.

> gcloud storage ls gs://hive_data/corp/employees/
gs://hive-migration/corp/employees/
gs://hive-migration/corp/employees/000000_0
gs://hive-migration/corp/employees/000001_0
gs://hive-migration/corp/employees/000002_0

BigQuery에 Hive 데이터를 로드하려면 bq load 명령어를 사용합니다. URL에서 와일드 카드 문자 *를 사용하여 공통 객체 프리픽스를 공유하는 여러 파일에서 데이터를 로드할 수 있습니다. 예를 들어 다음 명령어를 사용하여 gs://hive_data/corp/employees/ 프리픽스를 공유하는 모든 파일을 로드합니다.

bq load --source_format=AVRO corp.employees gs://hive_data/corp/employees/*

작업을 완료하는 데 시간이 오래 걸릴 수 있으므로 --sync 플래그를 False로 설정하여 비동기식으로 실행할 수 있습니다. bq load 명령어를 실행하면 생성된 로드 작업의 작업 ID가 출력되므로 이 명령어를 사용하여 작업 상태를 폴링할 수 있습니다. 이 데이터에는 작업 유형, 작업 상태, 작업을 실행한 사용자와 같은 세부정보가 포함됩니다.

해당 작업 ID를 사용하여 각 로드 작업 상태를 폴링하고 오류가 발생하여 실패한 작업이 있는지 확인합니다. 실패한 경우 BigQuery는 데이터를 테이블에 로드하는 동안 '전체 또는 없음' 방식을 사용합니다. 오류를 해결하고 다른 로드 작업을 안전하게 다시 만들 수 있습니다. 자세한 내용은 오류 문제 해결을 참조하세요.

테이블 및 프로젝트별로 로드 작업 할당량이 충분한지 확인합니다. 할당량을 초과하면 로드 작업이 quotaExceeded 오류와 함께 실패합니다.

Cloud Storage에서 BigQuery로 데이터를 로드하는 로드 작업에 대한 요금은 청구되지 않습니다. 데이터가 BigQuery에 로드되면 BigQuery의 스토리지 가격 책정이 적용됩니다. 로드 작업이 성공적으로 완료되면 중복 데이터 저장 비용이 발생하지 않도록 Cloud Storage에서 나머지 파일을 삭제할 수 있습니다.

검증

데이터를 성공적으로 로드한 후 Hive의 행 수 및 BigQuery 테이블을 비교하여 마이그레이션된 데이터를 검증할 수 있습니다. 테이블 정보에서 행 수, 열 수, 파티션 나누기 필드, 클러스터링 필드와 같은 BigQuery 테이블에 대한 세부정보를 확인합니다. 추가 검증을 위해 데이터 검증 도구를 사용해 보세요.

지속적 수집

데이터를 Hive 테이블로 지속적으로 수집하는 경우 초기 마이그레이션을 수행한 후 증분 데이터 변경사항만 BigQuery로 마이그레이션합니다. 새 데이터를 찾고 로드하기 위해 반복적으로 실행되는 스크립트를 만드는 것이 일반적입니다. 이를 위해서는 여러 방법이 있으며 다음 섹션에서는 가능한 한 가지 방법을 설명합니다.

다음 섹션에서는 추적 테이블이라고 하는 Cloud SQL 데이터베이스 테이블에서 마이그레이션 진행 상황을 추적할 수 있습니다. 마이그레이션의 최초 실행 중 추적 테이블에 진행 상황을 저장합니다. 후속 마이그레이션 실행 시 추적 테이블 정보를 사용하여 추가 데이터가 수집되어 BigQuery로 마이그레이션할 수 있는지 감지하세요.

INT64, TIMESTAMP, DATE 유형 식별자 열을 선택하여 증분 데이터를 구분합니다. 이를 증분 열이라고 합니다.

다음 테이블은 증분 열에 TIMESTAMP 유형을 사용하는 파티션 나누기가 없는 테이블의 예시입니다.

+-----------------------------+-----------+-----------+-----------+-----------+
| timestamp_identifier        | column_2  | column_3  | column_4  | column_5  |
+-----------------------------+-----------+-----------+-----------+-----------+
| 2018-10-10 21\:56\:41       |           |           |           |           |
| 2018-10-11 03\:13\:25       |           |           |           |           |
| 2018-10-11 08\:25\:32       |           |           |           |           |
| 2018-10-12 05\:02\:16       |           |           |           |           |
| 2018-10-12 15\:21\:45       |           |           |           |           |
+-----------------------------+-----------+-----------+-----------+-----------+

다음 테이블은 DATE 유형 열 partition_column에서 파티션을 나눈 테이블의 예시입니다. 각 파티션에 정수 유형의 증분 열 int_identifier가 있습니다.

+---------------------+---------------------+----------+----------+-----------+
| partition_column    | int_identifier      | column_3 | column_4 | column_5  |
+---------------------+---------------------+----------+----------+-----------+
| 2018-10-01          | 1                   |          |          |           |
| 2018-10-01          | 2                   |          |          |           |
| ...                 | ...                 |          |          |           |
| 2018-10-01          | 1000                |          |          |           |
| 2018-11-01          | 1                   |          |          |           |
| 2018-11-01          | 2                   |          |          |           |
| ...                 | ...                 |          |          |           |
| 2018-11-01          | 2000                |          |          |           |
+---------------------+---------------------+----------+----------+-----------+

다음 섹션에서는 파티션을 나누는지 여부와 증분 열이 있는지 여부에 따라 Hive 데이터를 마이그레이션하는 방법을 설명합니다.

증분 열이 없는 파티션을 나누지 않은 테이블

Hive에 파일 압축이 없다고 가정하면 Hive는 새 데이터를 수집할 때 새 데이터 파일을 생성합니다. 처음 실행할 때 추적 테이블에 파일 목록을 저장하고 이 파일을 Cloud Storage에 복사하고 BigQuery에 로드하여 Hive 테이블의 초기 마이그레이션을 완료합니다.

> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees
Found 3 items
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0

초기 마이그레이션 후에는 일부 데이터가 Hive에서 수집됩니다. 이 증분 데이터는 BigQuery로 마이그레이션하기만 하면 됩니다. 후속 마이그레이션 실행에서 데이터 파일을 다시 나열하고 추적 테이블의 정보와 비교하여 마이그레이션되지 않은 새 데이터 파일을 감지합니다.

> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees
Found 5 items
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000003_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000004_0

이 예시에서는 테이블 위치에 두 개의 새 파일이 있습니다. 이러한 새 데이터 파일을 Cloud Storage에 복사하고 기존 BigQuery 테이블에 로드하여 데이터를 마이그레이션합니다.

증분 열이 있는 파티션을 나누지 않은 테이블

이 경우 증분 열의 최댓값을 사용하여 새 데이터가 추가되었는지 확인할 수 있습니다. 초기 마이그레이션을 수행하는 동안 Hive 테이블을 쿼리하여 증분 열의 최댓값을 가져오고 추적 테이블에 저장합니다.

hive> SELECT MAX(timestamp_identifier) FROM corp.employees;
2018-12-31 22:15:04

후속 마이그레이션 실행에서 동일한 쿼리를 다시 반복하여 증분 열의 현재 최댓값을 가져오고 추적 테이블의 이전 최댓값과 비교하여 증분 데이터가 있는지 확인합니다.

hive> SELECT MAX(timestamp_identifier) FROM corp.employees;
2019-01-04 07:21:16

현재 최댓값이 이전 최댓값보다 큰 경우 증분 데이터가 예시와 같이 Hive 테이블에 수집되었음을 나타냅니다. 증분 데이터를 마이그레이션하려면 스테이징 테이블을 만들고 여기에 증분 데이터만 로드합니다.

hive> CREATE TABLE stage_employees LIKE corp.employees;
hive> INSERT INTO TABLE stage_employees SELECT * FROM corp.employees WHERE timestamp_identifier>"2018-12-31 22:15:04" and timestamp_identifier<="2019-01-04 07:21:16"

HDFS 데이터 파일을 나열하고, Cloud Storage에 복사하고, 기존 BigQuery 테이블에 로드하여 스테이징 테이블을 마이그레이션합니다.

증분 열이 없는 파티션을 나눈 테이블

파티션을 나눈 테이블에 데이터를 수집하면 새 파티션이 생기거나 기존 파티션에 증분 데이터를 추가하거나 둘 다 수행할 수 있습니다. 이 시나리오에서는 이러한 업데이트된 파티션을 식별할 수 있지만 구분할 증분 열이 없으므로 이러한 기존 파티션에 추가된 데이터를 쉽게 식별할 수 없습니다. 또 다른 옵션은 HDFS 스냅샷을 만들고 유지하는 것입니다. 하지만 스냅샷으로 인해 Hive가 성능 문제를 일으킬 수 있으므로 일반적으로 사용 중지됩니다.

테이블을 처음 마이그레이션하는 동안 SHOW PARTITIONS 명령어를 실행하고 서로 다른 파티션에 대한 정보를 추적 테이블에 저장합니다.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01

위 출력은 employees 테이블에 파티션이 2개 있음을 보여줍니다. 이 정보를 저장할 수 있는 방법을 보여주기 위해 추적 테이블의 간소화된 버전이 아래에 제공됩니다.

partition_information	file_path	gcs_copy_status	gcs_file_path	bq_job_id	...
partition_column =2018-10-01
partition_column =2018-11-01

후속 마이그레이션 실행에서 SHOW PARTITIONS 명령어를 다시 실행하여 모든 파티션을 나열하고 이러한 파티션을 추적 테이블의 파티션 정보와 비교하여 아직 마이그레이션되지 않은 새 파티션이 있는지 확인합니다.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01
partition_column=2018-12-01
partition_column=2019-01-01

예시와 같이 새 파티션이 식별되면 스테이징 테이블을 만들고 소스 테이블에서 새 파티션만 로드합니다. 파일을 Cloud Storage에 복사하고 기존 BigQuery 테이블에 로드하여 스테이징 테이블을 마이그레이션합니다.

증분 열이 있는 파티션을 나눈 테이블

이 시나리오에서는 Hive 테이블의 파티션이 나뉘고 증분 열이 모든 파티션에 표시됩니다. 지속적으로 수집되는 데이터는 이 열 값을 기준으로 증분합니다. 여기에서 이전 섹션에 설명된 대로 새 파티션을 마이그레이션할 수 있으며 기존 파티션으로 수집된 증분 데이터를 마이그레이션할 수도 있습니다.

테이블을 처음 마이그레이션할 때는 각 파티션에 증분 열의 최솟값과 최댓값을 추적 테이블의 테이블 파티션에 대한 정보와 함께 저장합니다.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01

hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-10-01";
1 1000

hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-11-01";
1 2000

위 출력은 테이블 직원이 두 개의 파티션이 있고 각 파티션에 증분 열의 최솟값과 최댓값이 있음을 보여줍니다. 이 정보를 저장할 수 있는 방법을 보여주기 위해 추적 테이블의 간소화된 버전이 아래에 제공됩니다.

partition_information	inc_col_min	inc_col_max	file_path	gcs_copy_status	...
partition_column =2018-10-01	1	1000
partition_column =2018-11-01	1	2000

후속 실행에서는 동일한 쿼리를 실행하여 각 파티션의 현재 최댓값을 가져오고 추적 테이블의 이전 최댓값과 비교합니다.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01
partition_column=2018-12-01
partition_column=2019-01-01

hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-10-01";

이 예시에서는 두 개의 새 파티션이 식별되었으며 일부 증분 데이터는 기존 파티션 partition_column=2018-10-01에 수집되었습니다. 증분 데이터가 있으면 스테이징 테이블을 만들고, 증분 데이터만 스테이징 테이블에 로드하고, 데이터를 Cloud Storage에 복사하고, 데이터를 기존 BigQuery 테이블에 로드합니다.

보안 설정

BigQuery는 IAM을 사용하여 리소스에 대한 액세스를 관리합니다. BigQuery 사전 정의된 역할은 특정 서비스에 대한 세분화된 액세스 권한을 제공하며, 일반적인 사용 사례와 액세스 제어 패턴을 지원합니다. 커스텀 역할을 사용하면 권한 집합을 맞춤설정하여 보다 세분화된 액세스 권한을 제공할 수 있습니다.

테이블 및 데이터 세트에 대한 액세스 제어는 사용자, 그룹, 서비스 계정이 테이블, 뷰, 데이터 세트에서 수행할 수 있는 작업을 지정합니다. 승인된 뷰를 사용하면 기본 소스 데이터에 대한 액세스 권한을 부여하지 않고도 특정 사용자 및 그룹과 쿼리 결과를 공유할 수 있습니다. 행 수준 보안과 열 수준 보안을 사용하면 테이블 내의 행이나 열에 액세스할 수 있는 사용자를 제한할 수 있습니다. 데이터 마스킹을 사용하면 사용자 그룹의 열 데이터를 선택적으로 가리지 않으면서 열에 대한 액세스는 계속 허용합니다.

액세스 제어를 적용할 때 다음 사용자 및 그룹에 액세스 권한을 부여할 수 있습니다.

이메일별 사용자: 개별 Google 계정에 데이터 세트에 대한 액세스 권한을 부여합니다.
이메일별 그룹: Google 그룹의 모든 구성원에게 데이터 세트 액세스 권한을 부여합니다.
도메인: Google 도메인의 모든 사용자와 그룹에 데이터 세트 액세스 권한을 부여합니다.
모든 인증된 사용자: 모든 Google 계정 소유자에게 데이터 세트 액세스 권한을 부여합니다(데이터 세트를 공개로 설정).
프로젝트 소유자: 모든 프로젝트 소유자에게 데이터 세트 액세스 권한을 부여합니다.
프로젝트 뷰어: 모든 프로젝트 뷰어에게 데이터 세트 액세스 권한을 부여합니다.
프로젝트 편집자: 모든 프로젝트 편집자에게 데이터 세트 액세스 권한을 부여합니다.
승인된 뷰: 뷰에 데이터 세트 액세스 권한을 부여합니다.

데이터 파이프라인 변경사항

다음 섹션에서는 Hive에서 BigQuery로 마이그레이션할 때 데이터 파이프라인을 변경하는 방법을 설명합니다.

Sqoop

기존 파이프라인이 Sqoop를 사용하여 HDFS 또는 Hive로 데이터를 가져오는 경우 데이터를 Cloud Storage로 가져오도록 작업을 수정합니다.

HDFS로 데이터를 가져오는 경우 다음 중 하나를 선택합니다.

Hadoop DistCp를 사용하여 Sqoop 출력 파일을 Cloud Storage에 복사합니다.
Cloud Storage 커넥터를 사용하여 Cloud Storage에 파일을 직접 출력합니다. Cloud Storage 커넥터는 Cloud Storage의 데이터에서 직접 Apache Hadoop 또는 Apache Spark 작업을 실행할 수 있는 오픈소스 Java 라이브러리입니다. 자세한 내용은 Cloud Storage 커넥터 설치를 참조하세요.

Sqoop가 Google Cloud에서 실행되는 Hive로 데이터를 가져오도록 하려면 Hive 테이블을 직접 가리키고 Cloud Storage를 HDFS 대신 Hive 웨어하우스로 사용합니다. 이렇게 하려면 hive.metastore.warehouse.dir 속성을 Cloud Storage 버킷으로 설정합니다.

Dataproc을 사용하여 BigQuery로 데이터를 가져오는 Sqoop 작업을 제출하면 Hadoop 클러스터를 관리하지 않고도 Sqoop 작업을 실행할 수 있습니다.

Spark SQL 및 HiveQL

일괄 SQL 변환기 또는 대화형 SQL 변환기는 Spark SQL 또는 HiveQL을 GoogleSQL로 자동 변환할 수 있습니다.

Spark SQL 또는 HiveQL을 BigQuery로 마이그레이션하지 않으려면 Dataproc 또는 Apache Spark가 포함된 BigQuery 커넥터를 사용하면 됩니다.

Hive ETL

Hive에 기존 ETL 작업이 있으면 다음 방법으로 수정하여 Hive에서 마이그레이션할 수 있습니다.

일괄 SQL 변환기를 사용하여 Hive ETL 작업을 BigQuery 작업으로 변환합니다.
Apache BigQuery를 사용하여 BigQuery 커넥터를 사용하여 BigQuery에서 읽고 씁니다. Dataproc을 사용하면 임시 클러스터를 통해 비용 효율적인 방식으로 Spark 작업을 실행할 수 있습니다.
Apache Beam SDK를 사용하여 파이프라인을 다시 작성하고 Dataflow에서 실행합니다.
파이프라인을 다시 작성하려면 Apache Beam SQL을 사용합니다.

ETL 파이프라인을 관리하려면 Cloud Composer(Apache Airflow)와 Dataproc 워크플로 템플릿을 사용합니다. Cloud Composer는 Oozie 워크플로를 Cloud Composer 워크플로로 변환하는 도구를 제공합니다.

Dataflow

Hive ETL 파이프라인을 완전 관리형 클라우드 서비스로 이전하려면 Apache Beam SDK를 사용하여 데이터 파이프라인을 작성하고 Dataflow에서 실행하는 것이 좋습니다.

Dataflow는 데이터 처리 파이프라인을 실행하기 위한 관리형 서비스입니다. 이는 오픈소스 프레임워크 Apache Beam을 사용하여 작성된 프로그램을 실행합니다. Apache Beam은 배치 및 스트리밍 파이프라인을 모두 개발할 수 있는 통합 프로그래밍 모델입니다.

데이터 파이프라인이 표준 데이터 이동인 경우 Dataflow 템플릿을 사용하여 코드를 작성하지 않고 Dataflow 파이프라인을 빠르게 만들 수 있습니다. 이 Google 제공 템플릿을 참조하면 Cloud Storage에서 텍스트 파일을 읽고, 변환을 적용하고, 결과를 BigQuery 테이블에 쓸 수 있습니다.

데이터 처리를 더 단순화하려면 SQL과 유사한 문을 사용하여 데이터를 처리할 수 있는 Beam SQL을 사용해 볼 수도 있습니다.