Kompromisy między Stormem a Hadoopem (MapReduce)

Czy ktoś może mi powiedzieć o kompromisach związanych z wyborem między Storm a MapReduce w klastrze Hadoop do przetwarzania danych? Oczywiście oprócz oczywistego, że Hadoop (przetwarzanie przez MapReduce w klastrze Hadoop) jest systemem przetwarzania wsadowego, a Storm jest systemem przetwarzania w czasie rzeczywistym.

Pracowałem trochę z Hadoop Eco System, ale nie pracowałem z Storm. Po przejrzeniu wielu prezentacji i artykułów nadal nie znalazłem satysfakcjonującej i wyczerpującej odpowiedzi.

Uwaga: Pojęcie kompromis tutaj nie ma na celu porównania z podobnymi rzeczami. Ma on reprezentować konsekwencje uzyskiwania wyników w czasie rzeczywistym, których nie ma w systemie przetwarzania wsadowego.

MapReduce : Odporna na błędy rozproszona platforma obliczeniowa. MapReduce pozwala operować na ogromnych ilościach danych - z dużym nakładem pracy, aby zapobiec awariom spowodowanym przez sprzęt. MapReduce to zły wybór do obliczania wyników w locie, ponieważ jest powolny. (Typowe zadanie MapReduce zajmuje kolejność minut lub godzin, a nie mikrosekund)

Zadanie MapReduce pobiera plik (lub jakiś magazyn danych) jako dane wejściowe i zapisuje plik wyników. Jeśli chcesz, aby wyniki były dostępne dla aplikacji, Twoim obowiązkiem jest umieszczenie tych danych w dostępnym miejscu. Jest to prawdopodobnie powolne i między wartościami, które można wyświetlić, a wartościami reprezentującymi system w jego bieżącym stanie, będzie opóźnienie.

Ważnym rozróżnieniem, które należy wprowadzić, rozważając zastosowanie MapReduce w budowaniu systemów w czasie rzeczywistym, jest szkolenie modelu i stosowanie go. Jeśli uważasz, że parametry modelu nie zmieniają się szybko, możesz dopasować je za pomocą MapReduce, a następnie mieć mechanizm dostępu do tych parametrów dopasowania wstępnego, gdy chcesz zastosować model.

Storm : System obliczeniowy przesyłania strumieniowego w czasie rzeczywistym. Storm jest platformą online, co oznacza w tym sensie usługę współdziałającą z działającą aplikacją. W przeciwieństwie do MapReduce, otrzymuje małe fragmenty danych (nie cały plik), gdy są one przetwarzane w Twojej aplikacji. Definiujesz DAG operacji do wykonania na danych. Częstym i prostym przypadkiem użycia Storm jest śledzenie liczników i wykorzystanie tych informacji do wypełnienia pulpitu nawigacyjnego w czasie rzeczywistym.

Storm nie ma (koniecznie) nic wspólnego z utrwalaniem danych. Tutaj streaming to kolejny sposób na zachowanie ważnych informacji i wyrzucenie reszty. W rzeczywistości w aplikacji prawdopodobnie znajduje się warstwa trwałości, która już zarejestrowała dane, a zatem jest to dobry i uzasadniony podział problemów.

Jeśli chcesz dowiedzieć się więcej ... Jeśli chcesz dowiedzieć się więcej o systemach czasu rzeczywistego, które pasują do parametrów z MR i zastosują modele w inny sposób, oto slajdy do dyskusji na temat tworzenia silników rekomendacji w czasie rzeczywistym HBase.

Doskonały artykuł, który w ciekawy sposób łączy liczenie i trwałość w czasie rzeczywistym, to Personalizacja Google News: Skalowalne filtrowanie współpracujące online

Kolejnym interesującym małżeństwem MR i Storm jest SummingBird . Summingbird pozwala zdefiniować operacje analizy danych, które można zastosować za pomocą Storm lub MR.

To trochę jak pytanie o kompromisy między patelnią a szufladą sztućców. Tak naprawdę to nie dwie rzeczy, które porównujesz. Możesz użyć ich razem w ramach większego projektu.

Sam Hadoop nie jest jedną rzeczą, ale nazwą federacji usług, takich jak HDFS, Hive, HBase, MapReduce itp. Storm jest czymś, czego używasz w przypadku niektórych z tych usług, takich jak HDFS lub HBase. Jest to struktura przetwarzania strumieniowego. Istnieją inne elementy rozszerzonego ekosystemu Hadoop, takie jak Spark Streaming.

Kiedy wybierzesz strukturę przetwarzania strumieniowego? kiedy musisz reagować na nowe dane w czasie zbliżonym do rzeczywistego. Jeśli potrzebujesz tego rodzaju narzędzia, wdrażasz również tego rodzaju narzędzie.