Apache Hadoop i Spark – Współpraca czy rywalizacja?

W poprzednim wpisie „Czy potrzebujesz Big Data?” dowiedzieliśmy się, czym jest Big Data i odpowiedzieliśmy na pytanie, kiedy potrzebujemy narzędzi z tego obszaru. W tym artykule porównamy dwie najpopularniejsze platformy Big Data.

Apache Hadoop

Hadoop to open-sourcowa platforma, pozwalająca na przechowywanie i przetwarzanie zbiorów Big Data. Podobnie jak większość tego typu rozwiązań, bazuje na rozproszonym modelu obliczeniowym, dzieląc główny problem na mniejsze części i przetwarzając je równolegle na osobnych maszynach (węzłach w obrębię klastra).

Podstawowe elementy platformy:

  • HDFS – Hadoop Distributed File System. Pozwala na przechowywanie dużej ilości danych na wielu węzłach w klastrze.
  • YARN – Yet Another Resource Negotiator. Odpowiada za zarządzanie zasobami wewnątrz klastra. Bierze udział m.in. w planowaniu i rozdzielaniu zadań.
  • MapReduce – Model służący do równoległego przetwarzania danych. Nazwa wywodzi się z funkcyjnego paradygmatu programowania – połączenia funkcji „map” i „reduce”. Sama koncepcja nie jest ściśle związana z Apache Hadoop i występuje także na innych platformach Big Data. Szczegółowy opis mechanizmów MapReduce wymaga nieco dłuższego opisu.
  • Hadoop Common – Tak jak wiele projektów tak i Hadoop posiada swoje „common”. Jak się domyślasz, w tym module znajdują się głównie narzędzia wspomagające pracę pozostałych modułów.

Apache Spark

Podobnie jak Apache Hadoop, tak i Spark został zaprojektowany do przetwarzania Big Data. Został wydany w 2014 roku, a więc 8 lat po Hadoop. Skoro platformy mają wspólny cel – przetwarzanie dużej ilości danych, można zadać sobie pytanie – dlaczego Apache rozwija je obie? Żeby odpowiedzieć na to pytanie, sięgnijmy do genezy Apache Spark.

Celem autorów Sparka było zaprojektowanie rozwiązań do problemów, z którymi tradycyjne podejście MapReduce nie radziło sobie optymalnie. Jak możemy przeczytać, chodziło głównie o problemy i ich algorytmy, które wymagały małych opóźnień podczas dzielenia danych między równoległymi procesami. Były to m.in. algorytmy machine learning, data mining i problemy real-time-computing (przetwarzania danych napływających w czasie rzeczywistym).

Jak wskazują projektanci platformy, główny problem w tradycyjnym MapReduce polega na tym, że poszczególne iteracje zapisują i odczytują dane z dysku twardego(lub wielu dysków – w przypadku rozproszonego systemu plików takiego jak HDFS), co znacznie wydłuża czas trwania operacji.

Z pomocą przychodzi właśnie Apache Spark, a szczególnie jego podstawowy typ danych, którym jest RDD (Resilient Distributed Datasets). Podczas wykonywania obliczeń kolekcje te przechowują w pamięci wyniki poszczególnych kroków przetwarzania danych, zamiast wykonywania czasochłonnych zapisów i odczytów z dysku. Ponadto RDD są leniwe (Lazy Evaluation), a do momentu ich zmaterializowania stos wywołań przechowywany jest w skierowanym grafie acyklicznym (DAG), co ułatwia znalezienie optymalnej ścieżki przetwarzania.

Czy zatem Hadoop jest passé?

Nie bez powodu przy opisie Sparka pominęliśmy zbiór komponentów, z których jest zbudowany. O ile w przypadku usługi Hadoop możemy mówić o ekosystemie, to Apache Spark w gruncie rzeczy jest jedynie platformą do przetwarzania danych. Nie mamy w tym przypadku dedykowanej warstwy persystencji, jaką było HDFS w Hadoopie. Do przechowywania danych (np. wynikowych, ale też źródłowych) możemy użyć np. HDFS. Wiele źródeł wskazuje, że Spark został zaprojektowany właśnie po to, aby odczytać dane z HDFS, przetworzyć je, po czym z powrotem zapisać tam rezultaty. Integracja tych narzędzi jest stosunkowo łatwa, ale Spark nie narzuca nam tutaj wyboru.

Kolejną kwestią którą warto poruszyć mówiąc o wspólnych elementach jest konfiguracja klastra. Spójrzmy na najpopularniejsze możliwości klastra dla Apache Spark:

Dostępne rodzaje klastrów obliczeniowych

Standalone – Podstawowy, najprostszy sposób konfiguracji klastra. Otrzymujemy go w pakiecie wraz z pobraniem Sparka. Mamy tutaj do czynienia z niezależnym od zewnętrznych komponentów rodzajem klastra.
Uwaga: Często Standalone mylony jest z trybem local[N]. Ten drugi, w przeciwieństwie do Standalone, umożliwia jedynie uruchomienie na pojedynczej maszynie, gdzie N jest ilością równoległych wątków przetwarzania.
Yarn – Tutaj korzystamy z wcześniej już wspomnianego menedżera zasobów. Musimy więc postawić klaster Hadoopa i na nim uruchomić Sparka. Według znanego tytułu Learning Spark po takie rozwiązanie powinniśmy sięgnąć, kiedy platforma będzie funkcjonować z współistniejącymi aplikacjami lub potrzebujemy szerszych możliwości harmonogramowania zadań (Standalone oferuje jedynie FIFO).
SIMR – Konfiguracja Sparka wewnątrz MapReduce Hadoopa. Paczka zawierająca Sparka wysyłana jest na węzły klastra. Od tej pory możemy używać Spark Shella do wydawania poleceń i wykorzystania mocy obliczeniowej klastra Hadoop. Nie jest to podejście przystosowane na środowiska produkcyjne, ale umożliwia użycie funkcjonalności Sparka przed wdrożeniem docelowego menedżera zasobów.

Choć najpopularniejszym wyborem do magazynowania jest HDFS, w każdej z powyższych konfiguracji możemy użyć innego systemu. Podobnie w przypadku użycia zewnętrznego menedżera zasobów nie musimy ograniczać się tylko do Yarna. Możemy skorzystać z rozwiązań spoza ekosystemu Hadoop, takich jak Mesos, ale musimy się liczyć z dodatkowym nakładem pracy podczas integracji tych komponentów.

Podsumowanie

Apache Spark został zaprojektowany w celu rozszerzenia możliwości Hadoopa, a nie jego zastąpienia. Sam Spark jest wydajnym narzędziem do przetwarzania danych, ale w celu kompletnego działania w trybie rozproszonym potrzebuje zewnętrznych komponentów. Taką kompletność może osiągnąć dzięki stosunkowo prostej integracji z usługami takimi jak HDFS czy YARN, oferowanymi przez Apache Hadoop.

2 thoughts on “Apache Hadoop i Spark – Współpraca czy rywalizacja?

  1. Świetny artykuł Łukasz! A przyglądałeś się może bardziej nowoczesnym podejściom do processowania danych z HDFSa jak na przykład Apache Flink? Zdaje się, że oferują one (a przynajmniej Flink) zdecydowanie lepszą wydajność od troche leciwego już Sparka

  2. Hej,
    Dzięki za opinię!

    Akurat z Apache Flink nie miałem jeszcze okazji podziałać. Z materiałów do których dotarłem, to Flink ma przewagę nad Sparkiem szczególnie w przetwarzaniu real-time. No i sam Spark chyba taki dziadek jeszcze nie jest 😉 Podejrzewam, że jak to zwykle bywa, wybór zależy też od tego jakie mamy dane i co chcemy z nimi zrobić. Nie wiem jak sytuacja wygląda np. z Apache Flink, ale jeśli chodzi o wdrożenie Sparka to tutaj całkiem szeroki wybór – Databricks, Azure Synapse, Cloudera i pewnie jeszcze wiele innych. To na pewno wielki plus jeśli ja miałbym wybierać.
    Zarzuciłeś Tomku na pewno ciekawy temat na przyszły wpis – porównanie przetwarzania w Apache Spark, Flink i np. Kafka.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *