캐시가 작동하는 이유 때문입니다.
당신이 계획은 아래 참조있는 DataFrame, RDD 또는 데이터 집합을 실행에 프로세스의 어떤 종류를 호출
:
val df = sc.parallelize(1 to 10000).toDF("line")
df.withColumn("new_line", col("line") * 10).queryExecution
명령 당신에게 queryExecution
복귀 계획. 아래 코드의 논리 계획을 참조하십시오.
== Parsed Logical Plan ==
Project [*,('line * 10) AS new_line#7]
+- Project [_1#4 AS line#5]
+- LogicalRDD [_1#4], MapPartitionsRDD[9] at
== Analyzed Logical Plan ==
line: int, new_line: int
Project [line#5,(line#5 * 10) AS new_line#7]
+- Project [_1#4 AS line#5]
+- LogicalRDD [_1#4], MapPartitionsRDD[9] at
== Optimized Logical Plan ==
Project [_1#4 AS line#5,(_1#4 * 10) AS new_line#7]
+- LogicalRDD [_1#4], MapPartitionsRDD[9] at intRddToDataFrameHolder at
== Physical Plan ==
Project [_1#4 AS line#5,(_1#4 * 10) AS new_line#7]
+- Scan ExistingRDD[_1#4]
이 경우 코드에서 수행 할 모든 프로세스를 볼 수 있습니다. 이 같은 cache
함수를 호출 할 때 :
df.withColumn("new_line", col("line") * 10).cache().queryExecution
이 결과는 다음과 같이 될 것입니다 :
이 실행이 당신에게 optmized 논리적 인 계획에
InMemoryRelation
의 실행을 반환합니다
== Parsed Logical Plan ==
'Project [*,('line * 10) AS new_line#8]
+- Project [_1#4 AS line#5]
+- LogicalRDD [_1#4], MapPartitionsRDD[9] at intRddToDataFrameHolder at <console>:34
== Analyzed Logical Plan ==
line: int, new_line: int
Project [line#5,(line#5 * 10) AS new_line#8]
+- Project [_1#4 AS line#5]
+- LogicalRDD [_1#4], MapPartitionsRDD[9] at intRddToDataFrameHolder at <console>:34
== Optimized Logical Plan ==
InMemoryRelation [line#5,new_line#8], true, 10000, StorageLevel(true, true, false, true, 1), Project [_1#4 AS line#5,(_1#4 * 10) AS new_line#8], None
== Physical Plan ==
InMemoryColumnarTableScan [line#5,new_line#8], InMemoryRelation [line#5,new_line#8], true, 10000, StorageLevel(true, true, false, true, 1), Pro...
이 저장됩니다 귀하의 메모리에있는 데이터의 구조, 또는 귀하의 데이터가 정말 큰 경우 디스크에 엎질러 질 것입니다.
클러스터에이 시간을 저장하는 데 시간이 걸리므로 처음 실행시 약간 느려지지만 다른 곳에서 동일한 데이터를 다시 액세스해야 할 경우 DF 또는 RDD가 저장되고 스파크는 실행을 다시 요청하지 않습니다.
안녕하세요, 귀하의 의견을 보내 주셔서 감사합니다. 사실 저는 마루에 데이터를 쓰기 전에 다시 분할 작업을 수행합니다. 나는 또한 위의 쿼리를 repartitioning으로 테스트했으며 쿼리 시간이 20 초인 경우 더 효율적이지만 여전히 캐리지없이 마루 파일을 읽는 것보다 느립니다. 제 목적은 마루 파일에 모두 쓰는 것을 피하는 것입니다. 어쩌면 소스를 제공 할 수 있습니까? 캐싱 후에 파티션 정리가 지원되지 않는다는 것을 어떻게 알 수 있습니까? 여기에 답을 쓸 수 있다면 받아 들일 수 있습니다. –
수정, 메모리에서 캐싱은 쿼리 시간을 1 초 미만으로 줄입니다. 물론 이것은 이미 수용 가능합니다. 나는 그것이 비늘다는 것을 의아해한다 : 이것은 나의 dasta의 단지 일부분이다, 나는 실제로 200 시간 이상 계속적으로 성장하고있다, 그래서 더 많은 자료, 모든 파티션을 통한 스캐닝에 더 많은 시간이 걸린다. 그래서 파티션 정리는 여기서 도움이되는 것처럼 보일 것이다. . –