HDInsight에서 Apache Spark 애플리케이션 최적화

이 문서에서는 Azure HDInsight에서 Apache Spark 애플리케이션을 최적화하기 위한 제반 전략의 개요를 제공합니다.

개요

아래의 일반적인 시나리오에 직면할 수 있습니다.

  • 동일한 Spark 작업이 동일한 HDInsight 클러스터에서 이전보다 느려집니다.
  • Spark 작업이 HDInsight 클러스터에서 온-프레미스 또는 타사 서비스 공급자보다 느려집니다.
  • Spark 작업이 하나의 HDI 클러스터에서 다른 HDI 클러스터보다 느려집니다.

Apache Spark 작업의 성능은 여러 요인에 따라 달라집니다. 이러한 성능 요인은 다음과 같습니다.

  • 데이터 저장 방법
  • 클러스터 구성 방법
  • 데이터를 처리할 때 사용되는 작업입니다.
  • 비정상 yarn 서비스
  • 잘못된 크기의 실행기 및 OutOfMemoryError로 인한 메모리 제약 조건
  • 작업이 너무 많거나 작업이 너무 적음
  • 데이터 기울이기로 인해 일부 과중한 작업 또는 느린 작업 발생
  • 잘못된 노드에서 느린 작업 발생

1단계: yarn 서비스가 정상인지 확인

  1. Ambari UI로 이동:
  • ResourceManager 또는 NodeManager 경고 확인
  • YARN에서 ResourceManager 및 NodeManager 상태 확인 > 요약: 모든 NodeManager가 시작됨이어야 하고 활성 ResourceManager만 시작됨이어야 함
  1. https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster를 통해 Yarn UI에 액세스할 수 있는지 확인

  2. /var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log의 ResourceManager 로그에서 예외 또는 오류 확인

자세한 내용은 Yarn 일반 문제 참조

2단계: yarn 사용 가능 리소스와 새로운 애플리케이션 리소스 비교

  1. Ambari UI > YARN > 요약으로 이동하고 ServiceMetrics에서 클러스터 메모리 확인

  2. yarn 큐 메트릭 세부 정보 확인:

  • Yarn UI로 이동하여 https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler를 통해 Yarn 스케줄러 메트릭 확인
  • 또는 Yarn Rest API를 통해 yarn 스케줄러 메트릭을 확인할 수 있습니다. 예: curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler". ESP의 경우 도메인 관리자 사용자를 사용해야 합니다.
  1. 새 애플리케이션의 총 리소스 계산
  • 모든 실행기 리소스: spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. 자세한 내용은 spark 실행기 구성 참조
  • ApplicationMaster
    • 클러스터 모드에서 spark.driver.memoryspark.driver.cores 사용
    • 클라이언트 모드에서 spark.yarn.am.memory+spark.yarn.am.memoryOverheadspark.yarn.am.cores 사용

참고 항목

yarn.scheduler.minimum-allocation-mb <= spark.executor.memory+spark.yarn.executor.memoryOverhead <= yarn.scheduler.maximum-allocation-mb

  1. 지정된 큐에서 yarn 사용 가능 리소스와 새 애플리케이션의 총 리소스 비교

3단계: Spark 애플리케이션 추적

  1. Spark UI를 통해 실행 중인 Spark 애플리케이션 모니터링

  2. Spark 기록 서버 UI를 통해 완료된 또는 완료되지 않은 Spark 애플리케이션 모니터링

Spark UI 또는 Spark 기록 UI를 통해 아래 증상을 식별해야 합니다.

  • 느린 단계
  • 스테이지 탭의 이벤트 타임라인에서 총 실행기 CPU v-코어가 완전히 활용되었는지 여부
  • spark sql을 사용하는 경우 SQL 탭의 실제 계획
  • 한 스테이지에서 DAG가 너무 긴지 여부
  • 스테이지 탭에서 작업 메트릭(입력 크기, 셔플 쓰기 크기, GC 시간) 관찰

자세한 내용은 Spark 애플리케이션 모니터링 참조

4단계: Spark 애플리케이션 최적화

이러한 문제(예: 캐싱)를 해결하는 데 도움이 될 뿐만 아니라 데이터 기울이기를 허용하는 많은 최적화가 있습니다.

다음 각 문서에서 Spark 최적화의 다양한 측면에 대한 정보를 찾을 수 있습니다.

Spark SQL 파티션 최적화

  • spark.sql.shuffle.paritions는 기본적으로 200입니다. 조인 또는 집계를 위해 데이터를 셔플할 때 비즈니스 요구에 맞게 조정할 수 있습니다.
  • spark.sql.files.maxPartitionBytes는 HDI에서 기본적으로 1G입니다. 파일을 읽을 때 단일 파티션으로 압축할 최대 바이트 수입니다. 이 구성은 Parquet, JSON 및 ORC와 같은 파일 기반 원본을 사용할 때만 유효합니다.
  • Spark 3.0의 AQE입니다. 적응형 쿼리 실행을 참조하세요.

다음 단계