W tym poście spórbuję przedstawić Ci główną różnice pomiędzy metodami ReduceByKey i GroupByKey i dlaczego powinieneś unikać tej drugiej. A dlaczego? Odpowiedź kryję się pod pojęciem “shuffe“.
Shuffle
W środowisku gormadzenia danch przetwarzania równoległego tj. Haddop ważne jest, aby podczas obliczeń “wymiana” danych pomiędzy nodami była jak najmniejsza. “Wymiana danych” to nic innego jak ruch sieciowy pomiędzy maszynami. Dodatkowo za każdym razem dane muszą być serializowane i deserializowane. Im mniej danych przesyłamy tym mniej danych serializujemy deserializujemy. Każdy z tych kroków niesie za sobą zużycie mocy obliczeniowe, pamięci i co najważniejsze i jednocześnie najgorsze – czasu.
Przyjrzyjmy się poniższym dwóm analizom, aby na przykładzie zobaczyć co różni te dwie metody i dlaczego jedna z nich jest lepsza.
ReduceByKey
Zaczniemy od metody ReduceByKey, czyli tej “lepszej”. Zielone prostokąty przedstawiają poszczególne nody w klastrze.
Przeanalizujmy node 1, czyli pierwszy od lewej. Mamy tam trzy pary danych (big,1), (big,2) i (data,1). Chcemy zliczyć ile razy występuje każde słowo. Widzimy, żę na nodzie “lokalnie” zostały obliczone sumy dla każdego słowa (big,2) (data,1). Możemy inaczej powiedzieć, żę operacja “reduce” została najpierw wykonana na każdym nodzie bazując na swojej lokalnej porcji danych, zanim dane wysłane zostały do nodów, gdzie odbędzie się ostateczna faza “reduce“, dzięki której otrzymamy wynik.
Dzięki wykonaniu operacji reduce lokalnie ograniczmy ilość danych, która “krąży” pomiedzy nodami w klastrze. Dodatkowo zmniejszamy ilość danych poddaych procesowi Serializacji i Deserializacji.
GroupByKey
Teraz przyjrzyjmy się co się dzieje w przypadku, gdy używamy metody GroupByKey. Jak widać na poniższym rysunku nie występuje faza reduce. W wyniku czego wymiana danych pomiędzy nodami jest większa. Dodatkowo pamiętajmy o procesie Serializacji i Deserializacji, który w tym przypadku musi być wykonany na wiekszej ilości danych.
