AWS Glue ETL 작업이 ‘Container killed by YARN for exceeding memory limits’ 오류로 인해 실패하는 이유는 무엇입니까?

3분 분량
0

AWS Glue 추출, 전환, 적재(ETL) 작업이 ‘Container killed by YARN for exceeding memory limits’ 오류로 인해 실패합니다.

간략한 설명

이 오류의 가장 일반적인 원인은 다음과 같습니다.

  • 메모리 집약적 작업(예: 대규모 테이블 조인 또는 특정 열 값의 분포가 치우친 데이터 집합 처리, 기반 Spark 클러스터의 메모리 임계값 초과)
  • 실행기에 할당된 메모리 이상을 소비하는 데이터의 Fat 파티션
  • 분할이 불가능해 대용량 인메모리 파티션을 만드는 대용량 파일

해결 방법

이 오류를 해결하려면 다음 솔루션 옵션 중 하나 이상을 사용합니다.

  • 작업자 유형을 G.1x에서 메모리 구성이 더 높은 G.2x로 업그레이드합니다. 작업자 유형의 사양에 대한 자세한 내용은 Spark 작업에 대한 작업 속성 정의에서 작업자 유형 섹션을 참조하세요.
  • AWS Glue 2.0에서 3.0으로 마이그레이션하는 방법에 대한 자세한 내용은 AWS Glue 2.0에서 AWS Glue 3.0으로 마이그레이션을 참조하세요.
  • 다음 표에서 작업자 유형 사양에 대한 자세한 내용을 검토할 수도 있습니다.
AWS Glue 버전 1.0 및 2.0
표준spark.executor.memory: 5g spark.driver.memory: 5g spark.executor.cores: 4
G.1xspark.executor.memory: 10g spark.driver.memory: 10g spark.executor.cores: 8
G.2xspark.executor.memory: 20g spark.driver.memory: 20g spark.executor.cores: 16
AWS Glue 버전 3.0
표준spark.executor.memory: 5g spark.driver.memory: 5g spark.executor.cores: 4
G.1xspark.executor.memory: 10g spark.driver.memory: 10g spark.executor.cores: 4
G.2xspark.executor.memory: 20g spark.driver.memory: 20g spark.executor.cores: 8
  • 작업자 유형을 업그레이드한 후에도 오류가 지속되면 작업의 실행기 수를 늘리세요. 각 실행기에는 특정 수의 코어가 포함됩니다. 이 숫자는 실행기에서 처리할 수 있는 파티션 수를 결정합니다. 데이터 처리 장치(DPU)에 대한 Spark 구성은 작업자 유형에 따라 정의됩니다.
  • 조인과 같은 셔플 작업 전에 실행기를 균등하게 사용할 수 있도록 데이터가 올바르게 병렬화되었는지 확인해야 합니다. 모든 실행기에 걸쳐 데이터를 다시 분할할 수 있습니다. ETL 작업에서 AWS Glue DynamicFrame 및 Spark DataFrame에 대한 다음 명령을 각각 포함하면 됩니다.
dynamicFrame.repartition(totalNumberOfExecutorCores)

dataframe.repartition(totalNumberOfExecutorCores)
  • 작업 북마크를 사용하면 새로 작성된 파일만 AWS Glue 작업에서 처리할 수 있습니다. 이렇게 하면 AWS Glue 작업에서 처리되는 파일의 개수가 줄어들고 메모리 문제가 줄어듭니다. 북마크는 이전 실행에서 처리된 파일에 대한 메타데이터를 저장합니다. 후속 실행에서 작업은 타임스탬프를 비교한 다음 이러한 파일을 다시 처리할지 여부를 결정합니다. 자세한 내용은 작업 북마크를 사용하여 처리된 데이터 추적을 참조하세요.
  • JDBC 테이블에 연결할 때 Spark는 기본적으로 하나의 동시 연결만 엽니다. 드라이버는 단일 Spark 실행기에서 한 번에 전체 테이블을 다운로드하려고 시도합니다. 이 작업은 더 오래 걸리고 실행기에서 메모리 부족 오류가 발생할 수도 있습니다. 대신 JDBC 테이블의 특정 속성을 설정하여 DynamicFrame을 통해 병렬로 데이터를 읽도록 AWS Glue에 지시할 수 있습니다. 자세한 내용은 JDBC 테이블을 병렬로 읽기를 참조하세요. 또는 Spark DataFrame을 통해 JDBC에서 병렬 읽기를 수행할 수 있습니다. 자세한 내용은 JDBC에서 Spark DataFrame 병렬 읽기를 참조하고 partitionColumn, lowerBound, upperBoundnumPartitions와 같은 속성을 검토하세요.
  • ETL 작업에서, 특히 Python/Scala 코드를 Spark의 함수 및 메서드와 결합하는 경우 사용자 정의 함수를 사용하지 마세요. 예를 들어 if/else 문 또는 for 루프 내에서 빈 DataFrame을 확인하는 데 Spark의 **df.count()**를 사용하지 마세요. 대신, df.schema() 또는 **df.rdd.isEmpty()**와 같이 더 우수한 함수를 사용하세요.
  • 개발 엔드포인트에서 AWS Glue 작업을 테스트하고 그에 따라 ETL 코드를 최적화합니다.
  • 위의 솔루션 옵션이 모두 효과가 없는 경우 입력 데이터를 청크 또는 파티션으로 분할합니다. 그런 다음 하나의 큰 작업을 실행하는 대신 여러 AWS Glue ETL 작업을 실행합니다. 자세한 내용은 제한된 실행으로 워크로드 파티셔닝을 참조하세요.

관련 정보

OOM 예외 및 작업 이상 디버깅

Apache Spark 작업을 확장하고 AWS Glue를 사용하여 데이터를 파티셔닝하는 모범 사례

AWS Glue에서 메모리 관리 최적화

AWS 공식
AWS 공식업데이트됨 2년 전