Apache Spark 튜닝 전략 이해 및 적용

이 글을 읽게 된 동기.

• 혼돈의 순간과 차분한 분석의 순간을 살아온 자신의 경험.
• 더 깊게 알아보고자 찾아본 내용
• Spark가 최적화를 위해 어떻게 작동하는지에 대해 배운 내용.
• 최적화를 위한 Databricks의 '플러스'는 무엇인가요?
• 조정 및 리팩터링이 필요 없는 모범 사례

소개

저는 항상 관계형 데이터베이스를 접했고 나중에는 Spark와 같은 분산 시스템을 접했습니다. 처음에는 복잡한 쿼리 설정, 관리 및 주로 DBMS에 대한 수행 스크립트를 구성하는 방법 등 DBMS에 대해 더 깊이 탐구했습니다. Spark로 작업을 시작하고 나중에 Databricks로 작업을 시작했을 때 처음에는 구축해야 하는 시나리오에 대해 성능 문제가 없었지만 빅데이터 영역이 실제로 빅데이터가 되면서 매번 30%씩 증가하는 루틴에서 성능 문제가 발생하기 시작했습니다. 이번 주에 Spark가 '내부적으로' 작동하는 방식을 찾게 되었습니다. 주로 DBMS가 어떻게 작동하는지 이미 알고 있었고 여기에 가져올 몇 가지 개념을 이해하는 데 도움이 되었기 때문입니다.

Apache Spark 구성 요소에 대한 간략한 설명

이 기사에서는 성능 분석 시나리오, 기술 및 모범 사례에 중점을 두고 있으므로 간단하게 설명하겠습니다.

스파크코어:

이 구성요소는 Spark의 기반이 되며 메모리 관리, 작업, 장애 복구, I/O 관리, 즉 RDD를 조작하는 역할을 합니다. 그러므로 클러스터의 큰 부분을 차지하고 있는 녀석입니다.

실행자:

이 구성 요소는 스파크 생태계(클러스터)의 실제 작업자이며 디스크, 메모리 또는 둘 다에 있을 수 있는 쓰기 또는 읽기 명령(작업)을 받는 사람입니다(이것이 왜 나오는지는 나중에 설명하겠습니다). 플레이).

노동자:

워커는 말 그대로 분산 컴퓨팅에 익숙한 사람들을 위한 것이며, 클러스터의 노드이므로 위에서 언급한 실행기를 '호스트'하는 것입니다. 각 워커는 하나 이상의 실행기를 포함할 수 있습니다. 유언집행자는 보조자, 작업자는 창고 직원인 것처럼 유언집행자에게 할당된 자원을 관리하는 역할을 담당합니다. 만일 그가 보고받는 창고업자라면?

클러스터 관리자:

이 사람은 관리자입니다. 그는 작업자를 위한 리소스(메모리 및 CPU)를 관리하며, 각 애플리케이션에 대해 실행자 수와 할당할 리소스 양을 결정하고, ' boss'는 아래에서 자세히 설명하겠지만, 책임이 더 높은 위치이기 때문에 장애 복구를 위해 클러스터 상태를 모니터링하고 필요에 따라 작업을 재분배하기도 합니다. (참고: 클러스터 관리자에는 Yarn, mesos, kubernetes 등 여러 유형이 있으며 가장 간단한 것은 독립 실행형입니다.)

스파크컨텍스트:

글쎄, 이것은 보스 또는 게이트웨이입니다. 모든 Spark 애플리케이션이 이를 통과하기 때문에 게이트웨이라고 말합니다. 애플리케이션이 클러스터, 즉 작업자 및 실행자와 상호 작용할 수 있도록 허용하고 관리하는 것입니다. 작업자 간의 작업을 관리하며 이러한 방식으로 구성, 실행자 수 및 메모리와 같은 리소스 측면에서 전체 애플리케이션을 관리합니다. 작업이 어떻게 수행되고 있는지 알아야 합니까? 여기 이 상사에게 말해보세요.

예를 들어 설명하면 다음과 같습니다.

이제 성능, 튜닝, 속도, 속도 및 다양한 위치에서 듣는 모든 것에 대해 이야기해 보겠습니다.

관계형뱅킹 측에서 작업했는데 주로 프로시저나 기능, 애플리케이션 쿼리 등에서 성능 문제가 발생했을 때 다음과 같은 측면을 분석했습니다.

1. 이 스크립트는 언제 실행되며 현재 서버는 어떤가요?
2. 리소스나 테이블 잠금을 놓고 경쟁하는 사람이 있나요?
3. 모든게 순조롭게 진행되고 있고, 서버 리소스를 막는 사람도 없고, 훌륭하고, 훌륭합니다...
4. 이제 스크립트를 보겠습니다. 논리가 수행적인가요? 즉, 함께 읽고 쓰는 것을 생각하거나 한 줄씩 생각하는 사람(프로그래밍 중독)이 필요하지 않은 열을 너무 많이 참조하고, 하위 쿼리를 사용한 괴물 같은 쿼리, CTE 등을 참조하고 있습니까? 이 모든 사항을 수정(리팩토링)하고 응답 속도와 서버 리소스 사용을 모두 테스트했습니다. Apache Spark에 대해 이야기할 때 왜 이 모든 것을 설명하고 있습니까? 그래서.... 이것은 Spark에도 적용되며 제가 말하고 싶은 방식은 훨씬 더 복잡하지만 우리는 거기에 도달할 것입니다.
5. 마지막으로 대본이 좋았다면 '돌의 길', 즉 예상 실행 계획과 실제 실행 계획을 분석했을 것 같아요. 이를 통해 DBMS가 통계(히스토그램)를 통해 무엇을 하고 있는지, 정보를 어떤 경로로 따라갈 것인지, 현실은 무엇인지, 어떤 경로를 따르고 있는지 이해할 수 있었습니다. 그런 다음 쿼리의 추가 필터, 보다 성능이 뛰어난 JOIN, 인덱스 또는 임시 테이블 생성과 같은 사항을 식별할 수 있습니다.

글쎄요, 이제 이 점들이 Apache Spark와 어떤 공통점이 있을까요?

• 분산 세트 조작용으로 설계되지 않은 스크립트(Spark에는 난이도 '플러스'가 있다고 했습니다 ㅋㅋㅋ).
• 단순 Spark 작업이 모든 리소스를 소비하는 다른 수행 작업과 동일한 클러스터에서 실행 중인 경우(또는 그렇지 않은 경우) 특정 루틴이 실행되는 시간입니다. (여기서 유명한 DBMS 잠금의 일종을 살펴보세요.)
• 마지막으로 Apache Spark에는 실행 계획이 있습니다. 더 정확하게 말하면 다음 단계로 구성됩니다.

1. 논리적인 계획.
2. 실제 평면.
3. 실행전략.
4. 가끔 예상 비용을 보여줍니다.

각 항목이 무엇인지 요약하면 이름에도 불구하고 이미 아이디어를 얻을 수 있습니다.

논리적 계획:
원래 쿼리를 일련의 논리 연산으로 나타냅니다. 실제로 실행되는 방법을 고려하지 않은 쿼리의 추상 형식입니다. 필터링, 선택, 조인, 집계 등 수행할 작업에 대한 정보와 잘못된 '사소한 것'도 포함되어 있습니다 ㅋㅋㅋ

실제 평면:
Spark가 실제로 쿼리를 실행하는 방법을 자세히 설명합니다. 여기에는 작업 순서와 사용되는 알고리즘(예: DBMS 알고리즘)이 포함됩니다. 여기에는 실행자 간에 데이터를 분할하고 배포하는 방법에 대한 세부 정보가 포함될 수 있습니다.

실행 전략:
물리적 평면은 작업 및 데이터 크기에 따라 "Broadcast Join" 또는 "Shuffle Hash Join"과 같이 Spark가 사용할 수 있는 다양한 실행 전략을 표시할 수 있습니다. 실행계획의 주요 알고리즘도 설명드릴테니 진정하세요...

예상 비용:
항상 표시되는 것은 아니지만 일부 계획에는 계획의 여러 부분에 대한 예상 비용이 포함될 수 있으므로 처리 중 가장 비용이 많이 드는 부분을 이해하는 데 도움이 됩니다.

Apache Spark 실행 계획을 보는 방법

explane() 명령을 사용하여 텍스트로 표시되는 '루트' 형식이 있으며 간단한 필터와 데이터 프레임을 보여주는 아래와 유사한 출력이 표시됩니다.

== 물리적 계획 ==
*(2) 필터(값 > 1)
- *(2) 프로젝트 [이름#0, 값#1]
- *(1) 기존RDD[이름#0, 값#1] 검색

그리고 객관적으로 인터페이스를 통해 분석할 수 있으며 Spark UI를 통해 Databricks에서 셀 실행, 작업 또는 클러스터에서 액세스할 수 있습니다. Apache Spark에서는 기본 포트 4040의 IP입니다.

Spark UI는 여러 유용한 섹션으로 구분됩니다.

• 작업: 해당 애플리케이션에서 실행되는 모든 작업 목록을 표시합니다. 각 작업은 코드의 작업에 해당합니다.

• 단계: 각 작업을 구성하는 단계를 표시합니다. 스테이지는 병렬로 수행할 수 있는 작업의 세분화입니다.

• 작업: 작업 실행 시간 및 상태에 대한 정보를 포함하여 각 단계 내의 개별 작업을 자세히 설명합니다.

• 스토리지: RDD(Resilient Distributed Datasets)의 메모리 및 스토리지 사용량에 대한 정보를 제공합니다.

• 환경: Spark 구성 및 시스템 변수를 포함한 런타임 환경 속성을 표시합니다.

• 실행자: 메모리 사용량, 디스크 사용량, 성능 통계를 포함하여 애플리케이션용으로 생성된 실행자에 대한 정보를 표시합니다.

여기서는 계층적이었습니다. 그렇죠? 이것이 일이 진행되는 순서입니다.

화면에 이미지를 담고 싶어요!!

Spark 알고리즘 및 튜닝 위반자가 누구인지 확인하는 방법:

먼저 Spark UI 인터페이스와 실행 계획(논리적 계획이든 물리적 계획이든)에서 모두 시연되는 주요 알고리즘을 설명하겠습니다.

참고: 여기서 데이터 세트는 Spark 테이블과 동일하다는 점을 기억하세요. ;)

1. 가장 유명한 스캔부터 시작해 보겠습니다.

• FileScan: 입력 파일에서 데이터를 읽습니다. Parquet, ORC, CSV, JSON 등 다양한 파일 형식에 맞게 최적화할 수 있습니다.

2. 가입하세요(이것은 B.O를 제공합니다):

• Broadcast Hash Join: 데이터 세트 중 하나가 클러스터의 모든 노드에 전송될 만큼 작을 때 사용되며 Shuffle을 피합니다(이에 대해서는 더 자세히 설명하겠지만 간단히 말해서 데이터 셔플 작업입니다. 최종 가입).

• 셔플 해시 조인: 두 데이터 세트(원하는 경우 테이블)를 섞어 해당 키가 동일한 파티션에 있도록 합니다. 데이터셋의 용량이 커서 다른 노드로 전송할 수 없을 때 사용됩니다.

• 정렬 병합 조인: 조인하기 전에 두 데이터세트를 모두 정렬해야 합니다. 이미 분할되고 정렬된 대규모 데이터 세트에 효율적입니다. 즉, 분할되고 정렬된 열에 의해 조인이 수행됩니다(예: df.write.partitionBy("coluna1").sortBy("coluna2").parquet(" 경로 /to/save/partitioned")

3. 집계(합계, 개수, 그룹화 등...):

• HashAggregate: 해시 테이블을 사용하여 데이터를 집계합니다. 메모리에 맞는 대용량 데이터 세트에 효율적입니다.

• 집계 정렬. 데이터를 정렬한 후 집계합니다. 데이터가 메모리에 맞지 않을 때 사용됩니다.

4. 셔플(이 사람을 조심하세요):

• 셔플: 조인, 집계 등 재구성이 필요한 작업을 위해 파티션 간에 데이터를 재배포합니다. I/O와 네트워크 측면에서 비용이 많이 드는 작업입니다.

5. 교환:

• 파티션 간의 데이터 분포를 변경합니다. 클러스터 노드 전반에 걸쳐 작업 부하의 균형을 맞추는 데 사용할 수 있습니다. (셔플의 균형을 맞추고 탈출하는 전략)

6. 프로젝트:

• DataFrame 또는 RDD에서 열의 하위 집합을 선택합니다.

7. 필터:

• 데이터 행을 필터링하는 조건을 적용합니다.

8. 정렬:

• 하나 이상의 열을 기준으로 데이터를 정렬합니다.

위의 모든 알고리즘은 앞서 설명했듯이 explain() 명령을 통해 관찰할 수 있습니다.

실제 셔플 문제 시나리오:

1. 가입 및 GroupBy 작업
Join() 및 groupByKey()와 같은 작업은 종종 파티션 간에 데이터를 재분배하는 셔플을 트리거합니다. 이로 인해 다음이 발생할 수 있습니다.
높은 디스크 I/O 사용량: Shuffle은 실행자의 로컬 디스크를 포화시킬 수 있는 많은 중간 파일을 생성합니다.
높은 네트워크 로드: 필요한 연결 수(매퍼 수에 감속기 수를 곱함)에 따라 실행기 간에 전송되는 데이터의 양이 상당할 수 있습니다

• 신분증: Spark UI의 스테이지 탭에서 Shuffle Read Size/Records 및 Shuffle Spill(디스크) 값을 확인합니다. 이러한 지표의 양이 많다는 것은 잠재적인 문제를 나타냅니다.

1. 파티션 불균형(데이터 왜곡) 데이터가 파티션에 고르지 않게 분산되면 일부 작업은 다른 작업보다 훨씬 오래 걸리고 결과적으로 전체 성능이 저하될 수 있습니다. 식별은 동일하며 Spark UI에 가서 시간이 걸리는 구간을 참조하여 작업에 가서(여기서 아래에서 언급할 좋은 연습 포인트가 있습니다) 스턱 단계(실행 중이지만 실행되지 않음)를 확인합니다. 진행률) Shuffle 메트릭을 보면 일반적으로 메모리의 볼륨이 높고 새로 고칠 때 디스크의 볼륨이 생기기 시작합니다. 이는 이러한 불균형이 메모리에 도달하여 디스크에 쓰기 시작했고 분명히 디스크 속도가 느려졌다는 것을 나타냅니다. 이 시나리오를 놔두면 울어요.

완화

• 셔플 관련 문제를 완화하려면: 섞임을 유발하는 작업 줄이기: 가능하면 groupByKey()를 사용하고 ReduceByKey()를 선호합니다. 개수를 조정하세요. 파티션: Spark.sql.shuffle.partitions를 사용하여 파티션 수를 조정하세요. 셔플 작업 중 파티션. 브로드캐스트 조인과 같은 기술을 사용하십시오. 더 작은 세트의 데이터로 불필요한 셔플을 방지합니다.

Spark UI에서 측정항목 섞기:

셔플 작동 방식 및 비용이 많이 드는 이유:

마지막으로 아마도 가장 중요한 것은 - 모범 사례:

1. Databricks, Jupyter Notebook 및 Google Colab의 큰 인기로 인해 대다수가 노트북을 사용하여 작업합니다. 따라서 각 쿼리나 변환을 별도의 셀로 나누면 어느 부분이 성능 문제인지 쉽게 식별할 수 있습니다. 다 놓고 보면 여러 가지 직업이 있어서 어느 단계인지 알기 어렵습니다.

2. cache() 또는 persist()를 사용하여 중간 데이터를 메모리에 저장하세요. 특히 여러 작업에서 재사용되는 경우에는 더욱 그렇습니다. 이렇게 하면 재계산 시간이 줄어들고 성능이 향상될 수 있습니다.

3. 모르는 경우 Spark는 JVM에서 실행되므로 기본적으로 Java입니다. Python으로 유명한 UDF - 사용자 정의 함수를 생성하면 Spark에 일종의 "블랙 박스"가 남게 됩니다. 자동 최적화. 가능하다면 성능에 최적화된 내장 Spark SQL 함수를 사용하세요.

4. 글쎄요, 생각나는 대로 다 쓴 것 같아요. 몇 가지 시나리오를 기억하는 데 도움이 되기 때문에 기사를 쓰는 걸 좋아해요. 실제로 일부 공개 데이터를 사용하여 이 모든 것을 보여주는 비디오를 녹화할 예정입니다. 아마도 Kaggle에서 얻을 수 있을 것입니다. 따라서 LinkedIn에서 저를 팔로우하여 데이터, 인공 지능 및 소프트웨어 개발의 세계와 관련된 모든 것을 따라가세요

--> https://www.linkedin.com/in/airton-lira-junior-6b81a661

LinkedIn에서 저를 팔로우하고 힘을 실어주세요. 저는 피드백을 좋아하며 지식 공유 개선에도 전적으로 열려 있습니다.

여기까지 읽으셨다면 축하드립니다!!! 모든 성능 문제를 극복하길 바랍니다. 다음 기사에서는 Databricks의 장점에 대해 설명하겠습니다. LinkedIn에서 저를 팔로우하여 알아보세요. 감사합니다!!

위 내용은 Apache Spark 튜닝 전략 이해 및 적용의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!