다음을 통해 공유

I/O가 거의 없는 느린 Spark 단계

  • 아티클

I/O가 많지 않은 느린 단계가 있는 경우 다음으로 인해 발생할 수 있습니다.

  • 작은 파일을 많이 읽습니다.
  • 작은 파일을 많이 작성
  • 느린 UDF
  • 카티시안 조인
  • 쪼개진 조인

SQL DAG를 사용하여 거의 모든 문제를 식별할 수 있습니다.

SQL DAG 열기

SQL DAG를 열려면 작업 페이지 맨 위로 스크롤하여 연결된 SQL 쿼리를 클릭합니다.

SQL ID

이제 DAG가 표시됩니다. 그렇지 않은 경우 조금 스크롤하면 다음이 표시됩니다.

SLQ DAG

계속 진행하기 전에 DAG 및 시간이 소요되는 위치를 숙지합니다. DAG의 일부 노드에는 유용한 시간 정보가 있고 다른 노드는 그렇지 않습니다. 예를 들어 이 블록은 2.1분이 걸렸으며 스테이지 ID도 제공합니다.

느린 단계 노드

이 노드를 열려면 1.4분이 걸렸는지 확인해야 합니다.

느린 쓰기 노드

이러한 시간은 누적되므로 시계 시간이 아니라 모든 작업에 소요된 총 시간입니다. 그러나 시계 시간 및 비용과 상관 관계가 있으므로 여전히 매우 유용합니다.

DAG에서 시간이 소요되는 위치를 숙지하는 것이 유용합니다.

작은 파일을 많이 읽습니다.

스캔 연산자 중 하나가 많은 시간이 걸리는 것을 확인하면 이를 열고 읽은 파일 수를 찾습니다.

여러 파일 읽기

수만 개 이상의 파일을 읽는 경우 작은 파일 문제가 있을 수 있습니다. 파일은 8MB 이내여야 합니다. 작은 파일 문제는 너무 많은 열 또는 높은 카드 빈도 열에서 분할로 인해 가장 자주 발생합니다.

운이 좋다면 OPTIMIZE를 실행하기만 하면 됩니다. 그럼에도 불구하고 파일 레이아웃을 다시 고려해야 합니다.

작은 파일을 많이 작성

쓰기에 시간이 오래 걸리는 경우 파일을 열고 파일 수와 기록된 데이터의 양을 찾습니다.

여러 파일 작성

수만 개 이상의 파일을 작성하는 경우 작은 파일 문제가 있을 수 있습니다. 파일은 8MB 이내여야 합니다. 작은 파일 문제는 너무 많은 열 또는 높은 카드 빈도 열에서 분할로 인해 가장 자주 발생합니다. 파일 레이아웃을 다시 고려하거나 최적화된 쓰기를 켜야 합니다.

느린 UDF

UDF가 있다는 것을 알고 있거나 DAG에서 이와 같이 표시되는 경우 UDF가 느려질 수 있습니다.

UDF 노드

이 문제가 발생하는 경우 UDF를 주석으로 처리하여 파이프라인 속도에 미치는 영향을 확인합니다. UDF가 실제로 시간이 소요되는 경우 가장 좋은 방법은 네이티브 함수를 사용하여 UDF를 다시 작성하는 것입니다. 가능하지 않은 경우 UDF를 실행하는 단계의 작업 수를 고려합니다. 클러스터 repartition() 의 코어 수보다 작은 경우 UDF를 사용하기 전에 데이터 프레임을 사용합니다.

  (df
    .repartition(num_cores)
    .withColumn('new_col', udf(...))
  )

UDF는 메모리 문제로 인해 어려움을 겪을 수도 있습니다. 각 태스크는 파티션의 모든 데이터를 메모리에 로드해야 할 수 있습니다. 이 데이터가 너무 크면 상황이 매우 느리거나 불안정해질 수 있습니다. 또한 다시 분할은 각 작업을 더 작게 만들어 이 문제를 해결할 수 있습니다.

카티시안 조인

DAG에 카티시안 조인 또는 중첩 루프 조인이 표시되는 경우 이러한 조인은 매우 비싸다는 것을 알아야 합니다. 의도한 내용인지 확인하고 다른 방법이 있는지 확인합니다.

폭발 조인 또는 폭발

노드에 몇 개의 행이 들어가고 크기가 더 많이 나오는 경우 폭발 조인 또는 폭발()으로 인해 어려움을 겪을 수 있습니다.

쪼개진 조인

Databricks 최적화 가이드에서 폭발에 대해 자세히 알아보세요.