YARN에서 Spark 구성

하브르, 안녕하세요! 어제 Apache Spark 전용 모임, Rambler&Co 직원들로부터 이 도구 구성과 관련된 참가자들로부터 꽤 많은 질문이 있었습니다. 우리는 그의 발자취를 따르고 우리의 경험을 공유하기로 결정했습니다. 주제는 쉽지 않습니다. 따라서 의견을 통해 귀하의 경험을 공유해 주시기 바랍니다. 어쩌면 우리가 잘못된 것을 이해하고 사용할 수도 있습니다.

Spark 사용 방법에 대한 간략한 소개입니다. XNUMX개월 프로그램이 있어요 “빅데이터 전문가”, 두 번째 모듈 전체에서 참가자들은 이 도구를 사용합니다. 따라서 조직자로서 우리의 임무는 그러한 경우에 사용할 수 있도록 클러스터를 준비하는 것입니다.

우리 사용의 특징은 Spark에서 동시에 작업하는 사람들의 수가 전체 그룹과 동일할 수 있다는 것입니다. 예를 들어 세미나에서 모두가 동시에 뭔가를 시도하고 선생님의 말을 따라 반복하는 경우입니다. 그리고 이것은 많지 않습니다. 때로는 최대 40명까지 가능합니다. 아마도 이러한 사용 사례에 직면한 회사는 전 세계적으로 많지 않을 것입니다.

다음으로 특정 구성 매개변수를 선택한 방법과 이유를 설명하겠습니다.

처음부터 시작합시다. Spark에는 클러스터에서 실행할 수 있는 3가지 옵션(독립형, Mesos 사용, YARN 사용)이 있습니다. 우리는 그것이 타당했기 때문에 세 번째 옵션을 선택하기로 결정했습니다. 우리는 이미 hadoop 클러스터를 가지고 있습니다. 우리 참가자들은 이미 그 아키텍처에 대해 잘 알고 있습니다. YARN을 사용해 보겠습니다.

spark.master=yarn

더욱 더 흥미롭습니다. 이러한 3가지 배포 옵션에는 각각 클라이언트와 클러스터라는 2가지 배포 옵션이 있습니다. 기반을 둔 선적 서류 비치 인터넷의 다양한 링크를 통해 클라이언트가 대화형 작업에 적합하다는 결론을 내릴 수 있습니다. 예를 들어 jupyter 노트북을 통해 클러스터가 프로덕션 솔루션에 더 적합합니다. 우리의 경우 대화형 작업에 관심이 있었기 때문에 다음과 같습니다.

spark.deploy-mode=client

일반적으로 이제부터 Spark는 어떻게든 YARN에서 작동하지만 우리에게는 이것만으로는 충분하지 않았습니다. 우리는 빅데이터에 관한 프로그램을 갖고 있기 때문에 때로는 참가자들이 자원을 균등하게 분할하는 틀 내에서 얻은 것이 충분하지 않은 경우가 있었습니다. 그리고 우리는 흥미로운 점을 발견했습니다. 바로 동적 자원 할당입니다. 간단히 말해서 요점은 다음과 같습니다. 어려운 작업이 있고 클러스터가 비어 있는 경우(예: 아침) 이 옵션을 사용하면 Spark를 사용하여 추가 리소스를 얻을 수 있습니다. 교활한 공식에 따라 필요성이 계산됩니다. 자세한 내용은 다루지 않겠습니다. 잘 작동합니다.

spark.dynamicAllocation.enabled=true

이 매개변수를 설정했는데 시작 시 Spark가 충돌하여 시작되지 않았습니다. 그렇죠, 읽어야 했거든요. 문서 좀 더 조심스럽게. 모든 것이 정상이 되려면 추가 매개변수도 활성화해야 한다고 명시되어 있습니다.

spark.shuffle.service.enabled=true

왜 필요한가요? 작업에 더 이상 많은 리소스가 필요하지 않으면 Spark는 해당 리소스를 공통 풀로 반환해야 합니다. 거의 모든 MapReduce 작업에서 가장 시간이 많이 걸리는 단계는 Shuffle 단계입니다. 이 매개변수를 사용하면 이 단계에서 생성된 데이터를 저장하고 이에 따라 실행기를 해제할 수 있습니다. 그리고 실행자는 작업자의 모든 것을 계산하는 프로세스입니다. 특정 수의 프로세서 코어와 특정 양의 메모리가 있습니다.

이 매개변수가 추가되었습니다. 모든 것이 작동하는 것 같았습니다. 참가자들이 실제로 필요할 때 더 많은 자원을 제공받았다는 사실이 눈에 띄게 되었습니다. 그러나 또 다른 문제가 발생했습니다. 어느 시점에서 다른 참가자도 깨어나 Spark를 사용하고 싶었지만 모든 것이 바빠서 불행했습니다. 이해할 수 있습니다. 우리는 문서를 보기 시작했습니다. 프로세스에 영향을 미치는 데 사용할 수 있는 다른 매개변수가 많이 있다는 것이 밝혀졌습니다. 예를 들어, 실행기가 대기 모드에 있는 경우 몇 시간 후에 실행기에서 리소스를 가져올 수 있습니까?

spark.dynamicAllocation.executorIdleTimeout=120s

우리의 경우 실행자가 XNUMX분 동안 아무 작업도 하지 않으면 공용 풀로 되돌려주세요. 그러나 이 매개변수가 항상 충분하지는 않았습니다. 그 사람이 오랫동안 아무것도 하지 않았고 자원이 확보되지 않은 것이 분명했습니다. 캐시된 데이터가 포함된 실행기를 선택하는 시간 이후에 특별한 매개변수도 있는 것으로 밝혀졌습니다. 기본적으로 이 매개변수는 무한대였습니다! 우리는 그것을 수정했습니다.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

즉, 실행자가 5분 동안 아무 작업도 하지 않으면 공용 풀에 할당합니다. 이 모드에서는 다수의 사용자를 대상으로 리소스를 공개하고 발행하는 속도가 적당해졌습니다. 불만의 양이 감소했습니다. 그러나 우리는 더 나아가 애플리케이션당 최대 실행자 수를 제한하기로 결정했습니다. 기본적으로 프로그램 참가자당입니다.

spark.dynamicAllocation.maxExecutors=19

물론, 반대쪽에는 "클러스터가 유휴 상태이고 집행자가 19명 밖에 없습니다."라고 불만을 품은 사람들도 있지만, 무엇을 할 수 있습니까? 일종의 올바른 균형이 필요합니다. 모든 사람을 행복하게 만들 수는 없습니다.

그리고 우리 사건의 세부 사항과 관련된 또 하나의 작은 이야기입니다. 어떤 이유에서인지 여러 사람이 실습 수업에 늦었고, 어떤 이유로 Spark가 시작되지 않았습니다. 우리는 무료 리소스의 양을 살펴보았는데 거기에 있는 것 같습니다. 스파크가 시작되어야 합니다. 다행스럽게도 그 당시 문서는 이미 하위 피질 어딘가에 추가되어 있었고 Spark가 시작될 때 시작할 포트를 찾는다는 것을 기억했습니다. 범위의 첫 번째 포트가 사용 중인 경우 순서대로 다음 포트로 이동합니다. 무료라면 캡쳐됩니다. 그리고 이에 대한 최대 시도 횟수를 나타내는 매개변수가 있습니다. 기본값은 16입니다. 그 숫자는 우리 그룹의 수업 인원보다 적습니다. 그래서 16번의 시도 끝에 스파크는 포기하고 시작할 수 없다고 했습니다. 이 매개변수를 수정했습니다.

spark.port.maxRetries=50

다음으로 우리 사례의 세부 사항과 별로 관련이 없는 일부 설정에 대해 설명하겠습니다.

Spark를 더 빠르게 시작하려면 SPARK_HOME 홈 디렉터리에 있는 jars 폴더를 아카이브하여 HDFS에 배치하는 것이 좋습니다. 그러면 그는 작업자가 이러한 jarnik을 싣는 데 시간을 낭비하지 않을 것입니다.

spark.yarn.archive=hdfs:///tmp/spark-archive.zip

또한 더 빠른 작업을 위해 kryo를 직렬 변환기로 사용하는 것이 좋습니다. 기본보다 더 최적화되어 있습니다.

spark.serializer=org.apache.spark.serializer.KryoSerializer

그리고 Spark에는 종종 메모리에서 충돌이 발생한다는 오랜 문제도 있습니다. 종종 이런 일은 작업자가 모든 것을 계산하고 그 결과를 운전자에게 보내는 순간에 발생합니다. 우리는 이 매개변수를 더 크게 만들었습니다. 기본적으로 1GB인데 저희는 3개로 만들었습니다.

spark.driver.maxResultSize=3072

그리고 마지막으로 디저트로. HortonWorks 배포판 - HDP 2.1에서 Spark를 버전 2.5.3.0로 업데이트하는 방법. 이 HDP 버전에는 사전 설치된 버전 2.0이 포함되어 있지만 Spark가 매우 활발하게 개발되고 있으며 각각의 새 버전은 일부 버그를 수정하고 Python API를 포함한 추가 기능을 제공한다고 스스로 결정했습니다. 업데이트가 완료되었습니다.

Hadoop 2.7 공식 웹사이트에서 버전을 다운로드했습니다. 압축을 풀고 HDP 폴더에 넣어주세요. 필요에 따라 심볼릭 링크를 설치했습니다. 시작했는데 시작되지 않습니다. 매우 불분명한 오류를 작성합니다.

java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig

인터넷 검색 끝에 Spark는 Hadoop이 탄생할 때까지 기다리지 않고 새 버전의 Jersey를 사용하기로 결정했다는 사실을 알게 되었습니다. 그들은 JIRA에서 이 주제에 관해 서로 논쟁합니다. 해결책은 다운로드하는 것이 었습니다. 저지 버전 1.17.1. SPARK_HOME의 jars 폴더에 넣고 다시 압축한 후 HDFS에 업로드하세요.

우리는 이 오류를 해결했지만 새롭고 다소 간소화된 오류가 발생했습니다.

org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application master

동시에 버전 2.0을 실행하려고 합니다. 모든 것이 정상입니다. 무슨 일이 일어나고 있는지 추측해 보세요. 이 애플리케이션의 로그를 조사한 결과 다음과 같은 내용을 확인했습니다.

/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jar

일반적으로 어떤 이유로 hdp.version이 해결되지 않았습니다. 인터넷 검색 후 해결책을 찾았습니다. Ambari의 YARN 설정으로 이동하여 사용자 정의 YaRN 사이트에 매개변수를 추가해야 합니다.

hdp.version=2.5.3.0-37

이 마법이 도움이 되었고 스파크는 성공했습니다. 우리는 여러 jupyter 노트북을 테스트했습니다. 모든 것이 작동하고 있습니다. 토요일(내일) 첫 스파크 레슨 준비가 완료되었습니다!

UPD. 수업 중에 또 다른 문제가 드러났습니다. 어떤 시점에서 YARN은 Spark용 컨테이너 제공을 중단했습니다. YARN에서는 기본적으로 0.2인 매개변수를 수정해야 했습니다.

yarn.scheduler.capacity.maximum-am-resource-percent=0.8

즉, 자원의 20%만이 자원 분배에 참여했습니다. 매개변수를 변경한 후 YARN을 다시 로드했습니다. 문제는 해결되었고 나머지 참가자들도 스파크 컨텍스트를 실행할 수 있었습니다.

출처 : habr.com