[SCALA] (왜) 우리는 캐시를 호출하거나 RDD에 유지해야합니까

(왜) 우리는 캐시를 호출하거나 RDD에 유지해야합니까

탄력적 인 분산 데이터 세트 (RDD)를 텍스트 파일 또는 수집 (또는 다른 RDD)에서, 우리가 호출해야 "캐시"를 수행하거나에서 생성 될 때 메모리에 RDD 데이터를 저장하기 위해 명시 적으로 "지속"? 또는 RDD 데이터는 기본적으로 메모리에 분산 방식으로 저장됩니다?

val textFile = sc.textFile("/user/emp.txt")

나의 이해에 따라, 위의 단계 이후, TEXTFILE는 RDD이며 모든 / 노드의 메모리 중 일부에서 사용할 수 있습니다.

그렇다면, 왜 우리는 "캐시"전화하거나 다음 TEXTFILE RDD의 "유지"해야합니까?

해결법

1. ==============================

   1.대부분의 RDD 작업은 게으르다. 일련의 작업에 대한 설명과 같은 RDD 생각. RDD 데이터가 없습니다. 이 라인 그래서 :

   대부분의 RDD 작업은 게으르다. 일련의 작업에 대한 설명과 같은 RDD 생각. RDD 데이터가 없습니다. 이 라인 그래서 :

   val textFile = sc.textFile("/user/emp.txt")
   

   그것은 아무것도하지 않는다. 그것은 "우리가이 파일을로드해야합니다"라는 RDD을 만듭니다. 이 파일은이 시점에서로드되지 않습니다.

   데이터의 내용을 관찰 필요 RDD 작업이 지연 될 수 없습니다. (이러한 행동이라고합니다.) 예는 RDD.count - 당신에게 파일의 행의 수를 알려는 파일을 읽을 필요가있다. 당신이 textFile.count를 작성하는 경우,이 시점에서 파일을 읽을 수 있도록, 라인이 계산되며, 개수가 반환됩니다.

   다시 textFile.count 무엇을 호출하는 경우? 같은 일 : 파일을 읽고 다시 계산됩니다. 아무것도 저장되지 않습니다. RDD 데이터가 없습니다.

   그래서 RDD.cache은 무엇입니까? 당신은 위의 코드에 텍스트 File.cache를 추가하는 경우 :

   val textFile = sc.textFile("/user/emp.txt")
   textFile.cache
   

   그것은 아무것도하지 않는다. RDD.cache 또한 게으른 작업입니다. 이 파일은 여전히 ​​읽을 수 없습니다. 하지만 지금은 RDD "는 내용을 캐시 한 후이 파일을 읽고"말했다. 당신이 다음 textFile.count를 처음 실행하면, 파일이,로드 캐시 및 계산됩니다. 두 번째 시간을 textFile.count 호출하면 작업이 캐시를 사용합니다. 그냥 캐시에서 데이터를 가져 와서 줄을 계산합니다.

   캐시 동작은 사용 가능한 메모리에 따라 달라집니다. 파일이 메모리에 맞지 않을 경우, 예를 들어, 다음 textFile.count 다시 평소 행동 하락하고 파일을 다시 읽습니다.

2. ==============================

   2.나는 질문이 더 잘 공식화 될 것이라고 생각 :

   나는 질문이 더 잘 공식화 될 것이라고 생각 :

   스파크 프로세스가 필요한 때까지 즉, 아무 일도 일어나지 않습니다되어, 게으르다. 신속한 답변에 발을 TEXTFILE이 = sc.textFile은 ( "/ 사용자 / emp.txt"), 아무것도 데이터에 변화가 없습니다 발급은 만 HadoopRDD 소스로 파일을 사용하여 구성 후 질문.

   이제 우리는 데이터를 조금 변형 해 봅시다 :

   val wordsRDD = textFile.flatMap(line => line.split("\\W"))
   

   다시 말하지만, 아무것도 데이터에 변화가 없습니다. 이제 필요할 때 적용 할 TESTFILE 및 함수에 대한 참조를 포함하는 새로운 RDD wordsRDD이있다.

   조치가 RDD에 호출 될 때에 만, wordsRDD.count의 RDD 체인처럼라는 혈통이 실행됩니다. 즉,이 파티션으로 나누어 데이터, 스파크 클러스터 실행기에 의해 로딩 될 것이다의 flatMap 함수가 적용되며, 그 결과를 산출한다.

   선형 혈통이 예에서처럼, 캐시 ()은 필요하지 않다. 데이터가 실행기에로드되며, 모든 변환이 적용되며, 최종적으로 상기 카운트 메모리에 모두 계산한다 - 데이터는 메모리에 맞는지.

   캐시 때 RDD 가지의 혈통이 밖으로 유용합니다. 의 당신이 긍정적이고 부정적인 단어 카운트로 이전 예제의 말씀을 필터링 할 가정 해 봅시다. 당신은 그런이 작업을 수행 할 수 있습니다 :

   val positiveWordsCount = wordsRDD.filter(word => isPositive(word)).count()
   val negativeWordsCount = wordsRDD.filter(word => isNegative(word)).count()
   

   여기서, 각 지점은 데이터를 다시로드를 발행합니다. 명시 적으로 캐시 문을 추가하면 이전에 수행하는 처리가 보존 및 재사용되도록해야합니다. 이 작업은 다음과 같이 표시됩니다

   val textFile = sc.textFile("/user/emp.txt")
   val wordsRDD = textFile.flatMap(line => line.split("\\W"))
   wordsRDD.cache()
   val positiveWordsCount = wordsRDD.filter(word => isPositive(word)).count()
   val negativeWordsCount = wordsRDD.filter(word => isNegative(word)).count()
   

   그 때문에, 캐시가 추가 처리를 위해 재사용 할 수있는 검사를 생성 같이 '혈통 휴식'라고한다.

   엄지 손가락의 규칙 : 사용 캐시 때 RDD 가지 밖으로의 혈통 또는 RDD 루프에서와 같이 여러 번 사용하는 경우.

3. ==============================

   3.우리는 "캐시"를 전화 또는 메모리에 RDD 데이터를 저장하기 위해 명시 적으로 "유지"해야합니까?

   우리는 "캐시"를 전화 또는 메모리에 RDD 데이터를 저장하기 위해 명시 적으로 "유지"해야합니까?

   예, 필요한 경우에만.

   기본적으로 메모리에 분산 방법에 저장된 RDD 데이터?

   아니!

   그리고 이러한 이유는 다음과 같습니다

   자세한 내용은 스파크 프로그래밍 가이드를 확인하시기 바랍니다.

4. ==============================

   4.다음은 당신의 RDDs를 캐시해야 할 세 가지 상황은 다음과 같습니다 :

   다음은 당신의 RDDs를 캐시해야 할 세 가지 상황은 다음과 같습니다 :

5. ==============================

   5.캐시 메서드 호출을 추가 (또는 일시적으로 추가)하는 또 다른 이유를 추가.

   캐시 메서드 호출을 추가 (또는 일시적으로 추가)하는 또 다른 이유를 추가.

   캐시 방법, 스파크는 RDD의 크기에 대한 디버깅 정보를 제공한다. 그래서 스파크 통합 UI, 당신은 RDD 메모리 사용량 정보를 얻을 것이다. 이것은 매우 도움이 진단 메모리 문제를 입증했다.

from https://stackoverflow.com/questions/28981359/why-do-we-need-to-call-cache-or-persist-on-a-rdd by cc-by-sa and MIT license