[HADOOP] 스파크 : 작업 간 지연 시간이 길다.

스파크 : 작업 간 지연 시간이 길다.

그래서 우리는 데이터를 추출하고 확장 데이터 변환 및 여러 다른 파일에 쓰기 작업을하는 스파크 작업을 실행하고 있습니다. 모든 것이 잘 돌아가고 있지만 리소스 집약적 인 작업 마무리와 다음 작업 시작 사이에 임의의 팽창성 지연이 있습니다.

아래 그림에서 우리는 17:22:02에 예정된 작업이 완료되기까지 15 분이 걸린다는 것을 알 수 있습니다. 이는 다음 작업이 17:37:02 경에 예정되어 있음을 의미합니다. 그러나 다음 작업은 22:05:59에 예정되어 있으며, 이는 작업 성공 후 +4 시간입니다.

다음 작업의 스파크 UI를 파헤쳐 보면 <1 초 스케줄러 지연이 표시됩니다. 그래서 나는이 4 시간의 긴 지연이 어디에서 오는 것인지 혼란 스럽습니다.

(Hadoop 2로 스파크 1.6.1)

업데이트 :

아래의 David의 대답은 Spark에서 IO 작업을 처리하는 방법이 예상치 못한 부분이라는 점을 확인할 수 있습니다. (파일 쓰기가 명령이나 다른 작업을 고려하여 작성하기 전에 기본적으로 커튼 뒤에 "수집"한다는 의미입니다.) 그러나 I / O 시간이 작업 실행 시간에 포함되지 않는다는 사실에 조금 불편합니다. 나는 모든 작업이 성공하더라도 쿼리가 실행 중이므로 스파크 UI의 "SQL"탭에서 확인할 수 있지만 전혀 잠글 수는 없습니다.

개선 할 수있는 방법이 더 많지만 다음 두 가지 방법으로는 충분하다고 생각합니다.

해결법

1. ==============================

   1.I / O 작업은 종종 마스터 노드에서 발생할 수있는 상당한 오버 헤드가 있습니다. 이 작업은 병렬 처리되지 않으므로 시간이 많이 걸릴 수 있습니다. 작업이 아니기 때문에 리소스 관리자 UI에는 나타나지 않습니다. 마스터 노드에 의해 수행되는 I / O 태스크의 몇 가지 예

   I / O 작업은 종종 마스터 노드에서 발생할 수있는 상당한 오버 헤드가 있습니다. 이 작업은 병렬 처리되지 않으므로 시간이 많이 걸릴 수 있습니다. 작업이 아니기 때문에 리소스 관리자 UI에는 나타나지 않습니다. 마스터 노드에 의해 수행되는 I / O 태스크의 몇 가지 예

   이러한 문제는 원사 설정을 조정하거나 코드를 다시 디자인하여 해결할 수 있습니다. 일부 소스 코드를 제공하면 문제를 정확히 지적 할 수 있습니다.

   I / O 오버 헤드 작성에 대한 토론

   I / O 오버 헤드 읽기에 대한 토론

2. ==============================

   2.문제:

   문제:

   EMR 5.5.1의 pyspark를 사용하여 s3에 마루 (parquet) 데이터를 작성할 때 비슷한 문제가 발생했습니다. 모든 작업자는 출력 폴더에 _temporary 버킷의 데이터 쓰기를 완료하고 Spark UI는 모든 작업이 완료되었음을 나타냅니다. 그러나 Hadoop Resource Manager UI는 애플리케이션의 리소스를 해제하지 않으므로 완전한 것으로 표시하지 않습니다. s3 버킷 검사에서 스파크 드라이버가 _temporary 디렉토리에서 매우 느린 출력 버킷으로 파일을 1 씩 이동했지만 모든 클러스터가 드라이버 노드를 제외하고 유휴 상태 인 것처럼 보였습니다.

   해결책:

   나를 위해 일한 솔루션은 구성 속성 인 spark.sql.parquet.fs.optimized.committer.optimization-enabled를 true로 설정하여 AWS (EmrOptimizedSparkSqlParquetOutputCommitter)로 커미터 클래스를 사용하는 것이 었습니다.

   e.f. :

   spark-submit ....... --conf spark.sql.parquet.fs.optimized.committer.optimization-enabled = true

   또는

   pyspark ....... --conf spark.sql.parquet.fs.optimized.committer.optimization-enabled = true

   이 속성은 EMR 5.19 이상에서 사용할 수 있습니다.

   결과:

   위의 솔루션을 사용하여 EMR 5.20.0에서 스파크 작업을 실행 한 후에는 _temporary 디렉토리가 생성되지 않고 모든 파일이 출력 버킷에 직접 작성되므로 작업이 매우 빨리 완료되었습니다.

   더 자세한 내용 : https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-s3-optimized-committer.html

from https://stackoverflow.com/questions/36524945/spark-long-delay-between-jobs by cc-by-sa and MIT license