W jaki sposób Spark decyduje, jak podzielić partycję RDD?

Question

Załóżmy tworzę takie RDD (używam Pyspark):

list_rdd = sc.parallelize(xrange(0, 20, 2), 6) 

następnie wydrukować partycjonowanej elementy z metodą glom() i uzyskiwania

[[0], [2, 4], [6, 8], [10], [12, 14], [16, 18]] 

jaki sposób Spark postanowił jak na partycje moja lista? Skąd się bierze ten konkretny wybór elementów? Mogłoby to połączyć je w inny sposób, pozostawiając kilka innych elementów poza 0 i 10 samodzielnie, aby utworzyć 6 żądanych partycji. Przy drugim uruchomieniu partycje są takie same.

Korzystanie większy zasięg, z 29 elementów, mam partycje w strukturze 2 elementów, a następnie przez trzy elementy:

list_rdd = sc.parallelize(xrange(0, 30, 2), 6) 
[[0, 2], [4, 6, 8], [10, 12], [14, 16, 18], [20, 22], [24, 26, 28]] 

stosując mniejszy zakres 9 elementów uzyskać

list_rdd = sc.parallelize(xrange(0, 10, 2), 6) 
[[], [0], [2], [4], [6], [8]] 

Wynika z tego, że Spark generuje partycje, dzieląc listę na konfigurację, w której najmniejsze możliwe są po większych kolekcjach i powtarzane.

Pytanie brzmi, czy istnieje powód takiego wyboru, który jest bardzo elegancki, ale czy zapewnia także korzyści w zakresie wydajności?

Answer 1

Jeśli nie określisz konkretnego partycjonera, jest to "losowy", ponieważ zależy od konkretnej implementacji tego RDD. W takim przypadku możesz udać się do ParallelCollectionsRDD, aby zagłębić się w nią dalej.

getPartitions jest zdefiniowany jako:

val slices = ParallelCollectionRDD.slice(data, numSlices).toArray 
slices.indices.map(i => new ParallelCollectionPartition(id, i, slices(i))).toArray 

gdzie slice jest skomentował (sformatowany, aby lepiej dopasować):

/** 
* Slice a collection into numSlices sub-collections. 
* One extra thing we do here is to treat Range collections specially, 
* encoding the slices as other Ranges to minimize memory cost. 
* This makes it efficient to run Spark over RDDs representing large sets of numbers. 
* And if the collection is an inclusive Range, 
* we use inclusive range for the last slice. 
*/ 

Należy zauważyć, że istnieją pewne względy w odniesieniu do pamięci. Znowu będzie to dotyczyć konkretnej implementacji.