내용으로 건너뛰기

Amazon RDS에서 Amazon S3로 대규모 데이터세트를 마이그레이션할 때 노드 손실로 인해 AWS Glue 작업이 실패하는 이유는 무엇입니까?

3분 분량
0

AWS Glue를 사용하여 Amazon Relational Database Service(Amazon RDS) 또는 온프레미스 JDBC 데이터베이스에서 Amazon Simple Storage Service(Amazon S3)로 대규모 데이터세트를 마이그레이션하고 있습니다. ETL 작업이 오랫동안 실행된 후 노드가 손실되어 실패합니다.

간략한 설명

AWS Glue는 단일 연결을 사용하여 전체 데이터세트를 읽습니다. 대규모 JDBC 테이블을 마이그레이션하는 경우 ETL 작업이 AWS Glue 측에서 진행 없이 오랫동안 실행될 수 있습니다. 그러면 디스크 공간 문제(노드 손실)로 인해 작업이 결국 실패할 수 있습니다. 이 문제를 해결하려면 JDBC 테이블을 병렬로 읽으십시오. 노드가 손실되어 작업이 여전히 실패하는 경우 SQL 표현식을 푸시다운 조건자로 사용하십시오.

해결 방법

JDBC 데이터세트의 노드 손실 오류를 해결하려면 다음 방법 중 하나 이상을 사용하십시오.

JDBC 테이블을 병렬로 읽기

테이블에 INT 또는 BIGINT와 같은 숫자 열이 없는 경우 hashfield 옵션을 사용하여 데이터를 분할합니다. hashfield를 JDBC 테이블의 열 이름으로 설정합니다. 최상의 결과를 얻으려면 값이 균등하게 분포된 열을 선택하십시오.

테이블에 숫자 열이 있는 경우 테이블에서 또는 DynamicFrame을 생성하는 동안 hashpartitionshashexpression 옵션을 설정하십시오. 자세한 내용은 JDBC 테이블에서 병렬로 읽기를 참조하십시오.

다음은 JDBC 연결을 사용하여 DynamicFrame을 생성할 때 hashpartitionshashexpression을 설정하는 방법의 예입니다. connection_option에서 JDBC URL, 사용자 이름, 암호, 테이블 이름 및 열 이름을 바꿉니다.

connection_option= {"url": "jdbc:mysql://mysql-instance1.123456789012.us-east-1.rds.amazonaws.com:3306/database", "user": "your_user_name", "password": "your_password","dbtable": "your_table","hashexpression":"column_name","hashpartitions":"10"}
datasource0 = glueContext.create_dynamic_frame.from_options('mysql',connection_options=connection_option,transformation_ctx = "datasource0")

참고: JDBC URL, your_user_name, your_password, your_tablecolumn_name을 사용자 정보로 바꾸십시오.

다음은 AWS Glue Data Catalog에서 DynamicFrame을 생성할 때 hashpartitionshashexpression을 설정하는 방법의 예입니다.

datasource0 = glueContext.create_dynamic_frame.from_catalog(database = "your_database", table_name = "your_table",additional_options={"hashexpression":"column_name","hashpartitions":"10"}, transformation_ctx = "datasource0")

참고: hashpartitions에 더 큰 값을 설정하면 테이블 성능이 저하될 수 있습니다. 이는 각 작업이 전체 테이블을 읽은 다음, 실행기에 행 집합을 반환하기 때문입니다.

SQL 표현식을 푸시다운 조건자로 사용

참고: 다음 SQL 표현식은 Oracle 데이터베이스의 푸시다운 조건자로 작동하지 않습니다. 이 표현식은 AWS Glue가 기본적으로 지원하는 다른 모든 데이터베이스의 푸시다운 조건자로 작동합니다. 이러한 데이터베이스에는 Amazon Aurora, MariaDB, Microsoft SQL Server, MySQL 및 PostgreSQL이 포함됩니다.

테이블에 수십억 개의 레코드와 테비바이트(TiB) 데이터가 포함된 경우 작업을 완료하는 데 시간이 오래 걸리거나 노드가 손실되어 실패할 수 있습니다. 이러한 지연이나 실패는 hashpartitionshashexpression을 설정한 후에도 발생할 수 있습니다. 이러한 문제를 해결하려면 다음과 유사한 SQL 표현식을 hashexpression 옵션과 함께 사용하십시오.

column_name > 1000 AND column_name < 2000 AND column_name

SQL 표현식은 푸시다운 조건자 역할을 합니다. 이 표현식은 작업에서 모든 데이터를 한 번에 읽는 대신 작업 실행당 하나의 행 집합을 읽도록 강제 적용합니다. 전체 명령문은 다음과 비슷합니다.

datasource0 = glueContext.create_dynamic_frame.from_catalog(database = "sampledb", table_name = "test_table",additional_options={"hashexpression":"column_name > 1000 AND column_name < 2000 AND column_name","hashpartitions":"10"}, transformation_ctx = "datasource0")

참고: 이 구성으로 초기 작업 실행에 대한 작업 북마크를 비활성화하십시오. 작업 북마크를 사용하여 작업을 실행하면 AWS Glue가 열의 최댓값을 기록합니다. 작업을 다시 실행하면 AWS Glue는 이전 북마크 값보다 큰 값이 있는 행만 처리합니다. 필요에 따라 마지막 작업 실행 중에 작업 북마크를 활성화하십시오.

관련 정보

AWS Glue 작업이 ‘Exit status: -100. Diagnostics: Container released on a *lost* node’ 오류와 함께 실패하는 이유는 무엇입니까?

데이터에 연결

AWS 공식업데이트됨 7달 전
댓글 없음