2015-02-24 12 views
8

Podobne do Spark - Joining 2 PairRDD elementsW sprzężeniu iskry, czy kolejność tabel ma znaczenie jak w przypadku świni?

Podczas regularnych przyłączyć świni, ostatnia tabela w sprzężeniu nie doprowadza do pamięci, lecz transmitowane przez zamiast, więc jeśli ma małą liczność za klucz i B dużej liczności, że jest znacznie lepiej wykonać join A, B niż join A by B, z perspektywy wydajności (unikając wycieku i OOM)

Czy istnieje podobne pojęcie w iskrze? Nie widziałem żadnej takiej rekomendacji i zastanawiam się, jak to jest możliwe? Implementacja wygląda tak samo jak w przypadku świni: https://github.com/apache/spark/blob/master/core/src/main/scala/org/apache/spark/rdd/CoGroupedRDD.scala

A może czegoś brakuje?

Odpowiedz

3

Nie ma znaczenia, w iskrze RDD zostanie wprowadzony do pamięci tylko wtedy, gdy jest buforowany. Więc w iskrze, aby osiągnąć ten sam efekt, możesz buforować mniejsze RDD. Inną rzeczą, którą możesz zrobić w iskrze, której nie jestem pewien, czy świnia robi, jest to, że jeśli wszystkie RDD są połączone, mają ten sam partycjoner, którego nie trzeba wykonywać.

+0

ok, ale załóżmy, że nie buforujemy żadnego RDD. Zakładam, że iskra tworzy rodzaj pętli zagnieżdżonych między 2 RDD. Jeśli A ma 1M rekordów na klucz sprzężenia, a B ma tylko 3 rekordy na klucz sprzężenia, ale oba są ogromne. Jeśli zewnętrzna (lewa) tabela to A, każdy klucz do złączenia spowoduje rozlanie dysku na dysk ... prawda? – ihadanny

+0

@ihadanny, jeśli spojrzeć na [źródło] (https://github.com/apache/spark/blob/master/core/src/main/scala/org/apache/spark/rdd/PairRDDFunctions.scala#L503) wszystko jest iteratorem, więc nic nie jest koniecznie wczytywane do pamięci, kiedy iterator jest wyczerpany, zaczynałoby się od początku, mówiąc, że wygląda na to, że pętla for zostawi wyjście w pamięci – aaronman

Powiązane problemy