스파크-repartition () vs coalesce ()

Learning Spark에 따르면

데이터를 다시 파티션하는 것은 비용이 많이 드는 작업입니다. 또한 Spark에는 최적화 된 버전의 repartition()호출 coalesce()이있어 데이터 이동을 피할 수 있지만 RDD 파티션 수를 줄이는 경우에만 가능합니다.

내가 얻는 한 가지 차이점 repartition()은 파티션 수를 늘리거나 줄일 coalesce()수 있지만 파티션 수를 줄이면 줄일 수 있다는 것입니다.

파티션이 여러 시스템에 분산되어 coalesce()실행되는 경우 어떻게 데이터 이동을 피할 수 있습니까?

전체 셔플을 피합니다 . 숫자가 줄어드는 것으로 알려진 경우 실행 프로그램은 최소 수의 파티션에 데이터를 안전하게 보관할 수 있으며 추가 노드에서 데이터를 우리가 유지 한 노드로만 이동할 수 있습니다.

따라서 다음과 같이 진행됩니다.

Node 1 = 1,2,3
Node 2 = 4,5,6
Node 3 = 7,8,9
Node 4 = 10,11,12

그런 다음 coalesce2 개의 파티션으로 줄입니다.

Node 1 = 1,2,3 + (10,11,12)
Node 3 = 7,8,9 + (4,5,6)

노드 1과 노드 3은 원래 데이터를 이동할 필요가 없었습니다.

저스틴의 대답은 대단하고이 반응은 더 깊이 들어가게됩니다.

이 repartition알고리즘은 전체 셔플을 수행하고 고르게 분산 된 데이터로 새 파티션을 만듭니다. 1에서 12까지의 숫자로 DataFrame을 만듭니다.

val x = (1 to 12).toList
val numbersDf = x.toDF("number")

numbersDf 내 컴퓨터에 4 개의 파티션이 있습니다.

numbersDf.rdd.partitions.size // => 4

파티션에서 데이터를 나누는 방법은 다음과 같습니다.

Partition 00000: 1, 2, 3
Partition 00001: 4, 5, 6
Partition 00002: 7, 8, 9
Partition 00003: 10, 11, 12

이 repartition방법 으로 전체 셔플을 수행하고 두 노드에서이 데이터를 가져 오 겠습니다 .

val numbersDfR = numbersDf.repartition(2)

numbersDfR내 컴퓨터 에서 데이터가 분할되는 방법은 다음과 같습니다 .

Partition A: 1, 3, 4, 6, 7, 9, 10, 12
Partition B: 2, 5, 8, 11

이 repartition방법을 사용하면 새 파티션을 만들고 새 파티션에 데이터를 균등하게 분배 할 수 있습니다 (데이터 분배는 더 큰 데이터 세트에 대해 더 균일합니다).

차이 사이 coalesce와repartition

coalesce기존 파티션을 사용하여 섞은 데이터 양을 최소화합니다. repartition새 파티션을 만들고 전체 셔플을 수행합니다. coalesce데이터 양이 다른 파티션 (때로는 크기가 다른 파티션)을 생성하고 크기 repartition가 거의 같은 파티션을 생성합니다.

인가 coalesce또는 repartition빠른?

coalesce보다 빠른 실행이 가능 repartition하지만 크기가 다른 파티션은 일반적으로 같은 크기의 파티션보다 작동 속도가 느립니다. 일반적으로 큰 데이터 세트를 필터링 한 후 데이터 세트를 다시 파티셔닝해야합니다. 내가 발견 한 repartition스파크가 동일한 크기의 파티션 작업에 내장되어 있기 때문에 빠른 전체로.

주의 : 재 파티션으로 인해 디스크의 데이터 크기가 증가 할 수 있다는 것이 궁금 합니다. 대규모 데이터 세트에서 재 파티셔닝 / 연합을 사용할 때 테스트를 실행하십시오.

더 자세한 내용을 원하시면 이 블로그 게시물을 읽으십시오 .

실제로 통합 및 재 파티셔닝을 사용할 때

• 통합 및 재 파티셔닝을 사용하여 단일 파일에 DataFrame을 작성하는 방법에 대한 이 질문 을 참조하십시오.
• 필터링 쿼리를 실행 한 후 파티션을 다시 나누는 것이 중요 합니다 . 필터링 후 파티션 수는 변경되지 않으므로 다시 파티션하지 않으면 메모리 파티션이 너무 많아집니다 (필터가 많을수록 데이터 세트 크기가 줄어들수록 문제가 커짐). 조심 빈 파티션 문제 .
• partitionBy는 디스크의 파티션에있는 데이터를 쓰는 데 사용됩니다. partitionBy 를 사용 하기 전에 repartition / coalesce 를 사용하여 데이터를 메모리에 올바르게 분할해야 합니다.

여기서 주목할 점은 Spark RDD의 기본 원칙이 불변성이라는 것입니다. 재 파티션 또는 병합으로 새로운 RDD가 생성됩니다. 기본 RDD는 원래 파티션 수로 계속 존재합니다. 사용 사례가 캐시에서 RDD를 유지해야하는 경우 새로 작성된 RDD에 대해서도 동일하게 수행해야합니다.

scala> pairMrkt.repartition(10)
res16: org.apache.spark.rdd.RDD[(String, Array[String])] =MapPartitionsRDD[11] at repartition at <console>:26

scala> res16.partitions.length
res17: Int = 10

scala>  pairMrkt.partitions.length
res20: Int = 2

repartition -모든 데이터를 섞기 때문에 파티션 수를 늘리면서 사용하는 것이 좋습니다.

coalesce-파티션 수를 줄이면서 사용하는 것이 좋습니다. 예를 들어 3 개의 파티션이 있고이를 2로 줄이려면 coalesce세 번째 파티션 데이터를 파티션 1과 2로 이동합니다. 파티션 1과 2는 동일한 컨테이너에 남아 있습니다. 반면, repartition모든 파티션에서 데이터를 섞으면 실행기 간의 네트워크 사용량이 높아져 성능에 영향을 미칩니다.

coalescerepartition파티션 수를 줄이는 동안 보다 성능이 우수 합니다.

무엇에서 다음 코드 와 코드 워드 프로세서 것은 즉 coalesce(n)과 동일 coalesce(n, shuffle = false)과 repartition(n)동일하다coalesce(n, shuffle = true)

따라서 coalesce및 repartition파티션 수를 늘리는 데 사용할 수 있습니다.

을 사용하면 shuffle = true실제로 더 많은 파티션으로 통합 할 수 있습니다. 이것은 소수의 파티션이 비정상적으로 클 수있는 소수의 파티션 (예 : 100)이있는 경우에 유용합니다.

강조해야 할 또 다른 중요한 참고 사항 은 파티션 수 를 크게 줄이면 셔플 버전 coalesce( repartition이 경우 와 동일) 을 사용하는 것이 좋습니다. 이렇게하면 부모 파티션 (여러 작업) 에서 계산 을 병렬 로 수행 할 수 있습니다 .

그러나 과도하게 병합을 수행하는 경우 numPartitions = 1(예 :의 경우 하나의 노드) 원하는 노드보다 적은 수의 노드에서 계산이 수행 될 수 있습니다 numPartitions = 1. 이를 피하기 위해을 전달할 수 있습니다 shuffle = true. 이렇게하면 셔플 단계가 추가되지만 현재 업스트림 파티션이 병렬로 실행됩니다 (현재 파티션이 무엇이든간에).

여기 에서 관련 답변을 참조 하십시오

모든 답변은이 자주 묻는 질문에 훌륭한 지식을 추가하고 있습니다.

이 질문의 타임 라인의 전통에 따라 여기 2 센트가 있습니다.

매우 특별한 경우에, repartition이 coalesce보다 빠르다는 것을 알았습니다 .

내 응용 프로그램에서 우리가 추정하는 파일 수가 특정 임계 값보다 적을 때 재 파티션이 더 빨리 작동합니다.

여기 내가 무슨 뜻인지

if(numFiles > 20)
    df.coalesce(numFiles).write.mode(SaveMode.Overwrite).parquet(dest)
else
    df.repartition(numFiles).write.mode(SaveMode.Overwrite).parquet(dest)

위의 스 니펫에서 파일이 20 미만인 경우 병합이 끝나는 데 시간이 오래 걸리고 파티션이 훨씬 빠르며 위의 코드가되었습니다.

물론이 숫자 (20)는 작업자 수와 데이터 양에 따라 다릅니다.

희망이 도움이됩니다.

다시 파티션 : 데이터를 새로운 수의 파티션으로 섞습니다.

예 : 초기 데이터 프레임은 200 개의 파티션으로 분할됩니다.

df.repartition(500): 200 개의 파티션에서 새로운 500 개의 파티션으로 데이터가 섞입니다.

Coalesce : 기존 파티션 수로 데이터를 섞습니다 .

df.coalesce(5): 나머지 195 개의 파티션에서 5 개의 기존 파티션으로 데이터가 섞입니다.

저스틴과 파워의 대답에 추가하고 싶습니다-

repartition기존 파티션을 무시하고 새 파티션을 만듭니다. 따라서 데이터 왜곡을 수정하는 데 사용할 수 있습니다. 분배를 정의하기 위해 파티션 키를 언급 할 수 있습니다. 데이터 스큐는 '빅 데이터'문제 공간에서 가장 큰 문제 중 하나입니다.

coalesce기존 파티션에서 작동하고 서브 세트를 섞습니다. 데이터 비뚤어 짐을 수정 repartition하지는 못합니다. 따라서 가격이 저렴하더라도 필요한 것이 아닐 수도 있습니다.

모든 훌륭한 답변 repartition에 데이터 병렬화를 활용하는 가장 좋은 옵션 중 하나 를 추가하고 싶습니다 . coalesce파티션을 줄이는 저렴한 옵션을 제공 하지만 HDFS 또는 다른 싱크에 데이터를 쓸 때 큰 쓰기를 활용하는 데 매우 유용합니다.

나는 이것을 최대한 활용하기 위해 마루 형식으로 데이터를 쓸 때 유용하다는 것을 알았습니다.

PySpark (AWS EMR)에서 단일 csv 파일을 출력으로 생성하고 s3에 저장하는 데 문제가있는 사람은 재 파티셔닝을 사용하여 도움을 받았습니다. 그 이유는 유일하게 전체 셔플을 수행 할 수 없지만 재분할은 가능합니다. 기본적으로 재 파티셔닝을 사용하여 파티션 수를 늘리거나 줄일 수 있지만 병합을 사용하여 파티션 수 (1은 아님) 만 줄일 수 있습니다. 다음은 AWS EMR에서 s3으로 CSV를 작성하려는 사람을위한 코드입니다.

df.repartition(1).write.format('csv')\
.option("path", "s3a://my.bucket.name/location")\
.save(header = 'true')

간단한 방법으로 COALESCE :-는 파티션 수를 줄이기위한 것입니다. 데이터를 섞지 않고 파티션을 압축합니다.

반복 :-파티션의 수를 늘리고 줄일 수 있지만 셔플 링이 발생합니다.

예:-

val rdd = sc.textFile("path",7)
rdd.repartition(10)
rdd.repartition(2)

둘 다 잘 작동합니다

그러나 우리는 일반적으로 하나의 클러스터에서 출력을 볼 필요가있을 때이 두 가지를 수행합니다.

그러나 대규모 데이터를 처리하는 경우 통합 노드에 제공되는 데이터가 고도로 구성되어 있는지 확인해야합니다. 모든 데이터가 해당 노드에로드되므로 메모리 예외가 발생할 수 있습니다. 배상은 비용이 많이 들지만 사용하는 것을 선호합니다. 데이터를 셔플하고 균등하게 분배하기 때문입니다.

합체와 재분할 중에서 선택하는 것이 현명합니다.

repartition알고리즘은 전체 데이터 셔플을 수행하고 데이터를 동일 크기의 파티션을 생성한다. coalesce전체 파티션을 피하기 위해 기존 파티션을 결합합니다.

Coalesce는 많은 파티션으로 RDD를 수행하고 단일 작업자 노드에서 파티션을 결합하여 더 적은 파티션으로 최종 RDD를 생성하는 데 효과적입니다.

Repartition요청한 최종 파티션 수를 생성하기 위해 RDD의 데이터를 다시 섞습니다. DataFrame의 파티셔닝은 프레임 워크에서 관리해야하는 낮은 수준의 구현 세부 사항처럼 보이지만 그렇지 않습니다. 큰 DataFrame을 작은 것으로 필터링 할 때는 거의 항상 데이터를 다시 분할해야합니다. 큰 DataFrame을 자주 작은 DataFrame으로 필터링하므로 파티션을 다시 나누는 데 익숙해집니다.

더 자세한 내용을 원하시면 이 블로그 게시물을 읽으십시오 .