Spark 3.0의 7 가지 필수 SQL 성능 최적화
과거 기억 빅 데이터 과거 기억 빅 데이터
이 기사는 Spark Summit North America 2020에서 IBM Tokyo Research Institute의 선임 기술자 인 Kazuaki Ishizaki 박사가 "Apache Spark 3.0의 SQL 성능 개선 사항 한 눈에보기"주제를 공유 한 것입니다.이 기사의 비디오는 오늘 트윗의 세 번째 기사를 참조하십시오. PPT 과거 메모리 빅 데이터에주의를 기울이고 백그라운드에서 sparksql3에 답장하여 획득하세요.
지난달 스파크 3.0의 공식 버전이 출시되었고 많은 기능이 업데이트되었으며 과거의 빅 데이터를 기억 한 아파치 스파크 3.0.0의 공식 버전이 드디어 출시되고 중요한 기능이 완전히 분석되었습니다. 이 기사에서는 SQL에서 Spark 3.0의 최적화를 소개합니다. 
SQL 최적화에는 주로 네 가지 방향이 포함됩니다.
- 개발자 상호 작용을 위해;
- 동적 최적화;
- 촉매 개선;
- 인프라 갱신.
또한 Spark 3.0이 총 3464 개의 문제를 처리했다고 이전 기사에서 언급했습니다! 너무 많은 문제를 하나씩 처리하는 것이 어렵 기 때문에 이번 세션에서 Kazuaki Ishizaki 박사는 SQL을 개선했습니다. 
SQL의 개선에는 주로 7 가지 측면이 포함됩니다.
- 새로운 형식을 설명하십시오.
- 모든 조인은 힌트를 지원합니다.
- 적응 형 쿼리 실행;
- 동적 파티션 절단;
- 중첩 된 열의 자르기 및 푸시 다운을 향상시킵니다.
- 집계를위한 향상된 코드 생성;
- 새로운 Scala 및 Java 버전 지원.
새로운 형식 설명
쿼리 성능을 향상 시키려면 쿼리 최적화 방법을 이해해야하며 먼저 쿼리 계획을 이해해야합니다. 다음과 같은 쿼리가 있다고 가정합니다.
SELECT key, Max(val)
FROM temp
WHERE key > 0
GROUP BY key
HAVING max(val) > 0이 SQL에 대한 Spark 2.4 및 Spark 3.0 쿼리 계획을 살펴 보겠습니다. 
Spark 2.4에서 EXLPAIN을 사용하여 쿼리 계획을 보면 출력이 너무 길다는 것을 알 수 있습니다! ! 각 행에 불필요한 속성이 많이 있기 때문입니다. 이것이 무엇인지 한 눈에보기는 어렵습니다. 
Spark 3.0은 EXPLAIN을 기반으로 FORMATTED 지원을 추가하고 자세한 정보를 매우 간결한 형식으로 표시합니다.이 출력은 주로 두 부분으로 구성됩니다.
첫 번째 부분은 주로 일련의 연산자이고
두 번째 부분은 일련의 속성입니다.
위 출력에서 Spark SQL이이 쿼리를 어떻게 처리하는지 한 눈에 볼 수 있습니다. 출력과 같은 더 자세한 정보를 보려면 두 번째 부분에서 Attribute를 볼 수 있습니다.
모든 조인은 힌트를 지원합니다.
SQL의 두 번째 최적화는 조인 유형 힌트입니다.
Spark 2.4에서는 Broadcast에 힌트 힌트 만 제공 할 수 있으며 다른 유형의 Join은 지원되지 않습니다. Spark 3.0에서는 모든 유형의 조인에 대해 힌트 힌트가 지원됩니다. SQL 또는 DSL에서 직접 힌트를 사용할 수 있습니다. Spark에서 선택한이 조인 전략은 우리가 원하지 않을 때 매우 유용합니다.
적응 형 쿼리 실행
세 번째 최적화는 적응 형 쿼리 최적화입니다.
- 통계 실행을 통해 세 가지 측면이 최적화됩니다.
- 합리적인 수의 Reduce를 자동으로 설정하십시오.
- 성능을 향상 시키려면 더 나은 조인 전략을 선택하십시오.
- Tilt Join에서 데이터를 최적화합니다.
이러한 최적화는 수동으로 조정할 필요가 없습니다. TPC-DS의 Q77 쿼리에서 성능이 8 배 향상되었습니다.
위는 2.4에서 SQL의 동작 상태입니다. 5 개의 파티션에 대해 5 개의 reduce 프로세스가있는 경우 데이터가 적기 때문에 Reduce 0이 매우 빠르게 완료 될 수 있음을 알 수 있으며, 두 번째는 Reduce 4, 가장 느린 것은 Reduce 3, 결과적으로이 SQL 쿼리의 시간 소비는 주로 Reduce 3에 소비되고 다른 CPU는 유휴 상태입니다!
Spark 3.0에서는 적절한 수의 Reduce가 자동으로 선택되므로 Redue가 유휴 상태가 아닙니다.
Spark 2.4는 정적 통계를 기반으로 Join 전략을 선택합니다. 예를 들어 위의 table1 및 table2의 정적 통계는 각각 100GB 및 80GB이므로 위의 Join은 Sort merge Join을 사용합니다.
Spark 3.0은이 조인이 런타임에 통계를 기반으로 브로드 캐스트 조인을 선택해야한다는 것을 알고 있습니다.
두 테이블의 조인 시간은 가장 큰 파티션의 시간에 따라 다릅니다. 따라서 조인 프로세스 중에 파티션에 데이터 스큐가 있으면 처리 시간을 상상할 수 있습니다. 
Spark 3.0의 적응 형 실행은 왜곡 된 파티션을 분할 할 수 있습니다. 상대적으로 상당한 실행 시간을 달성하기 위해. Spark 3.0의 적응 형 실행에 대해서는 과거 메모리 빅 데이터를위한 Spark 3.0 적응 형 쿼리 최적화 소개를 참조하십시오.이 기사는 런타임시 Spark SQL의 실행 성능을 가속화합니다.
동적 파티션 자르기
네 번째 최적화는 동적 파티션 정리입니다. 이는 Apache Spark 3.0 동적 파티션 정리 이해 문서 및 Apache Spark 3.0 동적 파티션 정리 사용 이해 문서에서 확인할 수 있습니다. 여기서 소개하지 않겠습니다. 다음은 동적 파티션 절단의 예입니다.
중첩 된 열의 향상된 자르기 및 푸시 다운
다섯 번째 최적화는 중첩 된 열의 최적화입니다.
Spark 2.4는 Parquet의 중첩 열 최적화를 지원하고 필요한 부분 만 읽지 만이 기능은 매우 제한적입니다. 예를 들어 Repartition은 중첩 된 열 클리핑을 지원하지 않으며 필요한 부분을 선택하기 전에 전체 열을 다시 분할해야합니다.
Spark 3.0은이 부분을 최적화하므로 중첩 된 열의 조정이 위의 재분할을 포함한 모든 연산자를 지원하므로 데이터 읽기가 줄어들 기 때문에 IO가 크게 감소합니다. 다음은 중첩 된 열 클리핑의 예입니다.
Spark 2.4는 중첩 열 (Parquet 및 ORC)에 대한 푸시 다운을 지원하지 않습니다. 모든 데이터를 읽은 다음 필터 작업을 수행해야합니다.
Spark는이 부분을 최적화했으며 이제 Parquet 및 ORC 중첩 열 모두에 대해 필터링 푸시 다운을 지원합니다.
집계를위한 향상된 코드 생성
여섯 번째 최적화는 집계를위한 코드 생성을 향상시키는 것입니다.
Spark 2.4의 복잡한 집계는 매우 느린데 이는 Spark 2.4의 복잡한 쿼리가 로컬 코드로 컴파일되지 않기 때문입니다. 따라서 TPC-DS를 실행하면 Q66이 매우 느리다는 것을 알 수 있습니다.
Spark에서 Catalyst는 쿼리를 Java 코드로 변환하는 작업을 담당합니다. OpenJDK의 HotSpot 컴파일러는 Java 코드를 로컬 코드로 변환합니다.
그러나 메소드의 명령어가 8000 Java 바이트 코드를 초과하면 HotSpot 컴파일러는 Java 코드를 로컬 코드로 변환하는 것을 포기합니다. 
Catalyst of Spark 3.0은 집계 된 논리를 여러 개의 작은 메서드로 분할하여 HotSpot 컴파일러가이를 로컬 코드로 변환 할 수 있으므로 쿼리 성능이 2.4보다 훨씬 빠릅니다. 다음은 예입니다. 
위 그림의 상단은 Spark 3.0을 사용하고 있으며, 가장 큰 메서드 크기가 8000 미만임을 알 수 있으며 다음 그림은이 기능을 끄고 가장 큰 메서드 크기가 8000을 초과했습니다.
새로운 Scala 및 Java 버전 지원
