BIG DATA

Ewolucja Big Data: Hadoop vs. Spark

Choć większość analiz i opinii eksperckich wskazuje na zmierzch technologii Apache Hadoop, upatrując w Apache Spark i ekspansji dedykowanych platform chmurowych dla Big Data głównych przyczyn tej tendencji – to jednak doniesienia o śmierci Hadoop są raczej przesadzone i przedwczesne.

Trzech wiodących dostawców platform Big Data: Cloudera, Hortonworks i MapR, posiada ofertę produktów zbudowaną na bazie Apache Hadoop. Ale też wszyscy trzej ewoluują rodziny swoich produktów – a cechą wspólną tych działań jest to, że większy nacisk jest kładziony na Spark, a więc analizę danych on-line i strumieniową, a spada znaczenie i wykorzystanie Hadoop, MapReduce i powiązanych narzędzi (jak np. Pig). Oczywiście ewolucja produktów jest zjawiskiem naturalnym, zwłaszcza w szybko zmieniającej się branży technologicznej. Warto jednak zwrócić uwagę na pewien fakt wskazywany również przez ekspertów na konferencjach branżowych – wiele narzędzi open source po prostu się dubluje  i nie ma możliwości rynkowych aby wszystkie równolegle były rozwijane i utrzymywane – poddawane są naturalnej selskcji. Biznes poszukuje rozwiązań dla swoich problemów a nie tylko wachlarza ciekawych narzędzi do wykorzystania.

Hadoop na równi pochyłej

Jeszcze do niedawna  Hadoop był postrzegany jako siła napędowa ekspansji big data w większości organizacji. Obecnie wszystko wskazuje na to, że osiągnął swoje apogeum – a przynajmniej tak ujmuje stan rzeczy Tony Baer, analityk firmy Ovum. Oczywiście nie może być mowy o całkowitym zmierzchu platformy czy wręcz jej agonii. Zdaniem Baer’a – możliwości w obszarze zarządzania danymi jakie prezentuje Hadoop nadal przewyższają te prezentowane przez młodsze technologie, takie jak Spark czy dedykowane platformy chmurowe. Poza tym, nawet jeśli nie używamy platformy Hadoop jako trzonu naszej architektury przetwarzania wielkich zbiorów danych, ponieważ koncentrujemy się na przetwarzaniu w czasie rzeczywistym, w pamięci (in-memory) na bazie Apache Spark, to finalnie bardzo często i tak musimy użyć składników Hadoop w niektórych zadaniach.

Jednak ogólnie rzecz ujmując Hadoop zaczyna być passe. Nawet przez dostawców rozwiązań big data dotąd zdeklarowanych zwolenników Hadoop, jak Cloudera. Firma co prawda twierdzi, że jej sztandarowy produkt Enterprise jest napędzany Apache Hadoop (powered by Apache Hadoop), ale spoglądając szczegółowo w jego komponenty dojdziemy do wniosku, że zbyt dużo z Hadoop w nim nie zostało. IBM ze swojej strony wciąż wykorzystuje Hadoop w swojej linii produktowej BigInsights. Ale jeśli chodzi o jego bardziej modną platformę Watson, tam nic z Hadoop już nie znajdziemy.

Narzędzia do wymiany?

Narzędzia i platformy do przetwarzania dużych zbiorów danych ewoluują, nowe narzędzia – bardziej odpowiadające realnym potrzebom – zastępują aktualne, które powoli odchodzą w przeszłość i przestają być rozwijane. Dotyczy to tak narzędzi Open Source jak i rozwijanych przez dostawców platform Big Data. Jakim elementom rodziny narzędzi przetwarzania i zarządzania dużymi zbiorami danych (Big Data stack), głównie Hadoop, należy się bliżej przyjrzeć i rozważyć ich zastępstwo?

  1. MapReduce – w porównaniu do Apache Spark i innych narzędzi opartych na modelu przetwarzania DAG (Direct Acyclic Graph), którego to modelu jest podzbiorem, MapReduce jest zbyt wolny. Jeśli czas przetwarzania jest w naszym biznesie krytyczny i da się go wrazić ilościowo w przeliczeniu finansowym, może się okazać że opłaca się zainwestować w zmianę platformy (np. na Spark)
  2. Storm – takie narzędzia jak Apex, Flink a przede wszystkim Spark są obecnie lepszymi, szybszymi alternatywami, dodatkowo Storm nie posiada już dobrego, aktywnego wsparcia, z dostawców w zasadzie tylko Hortonworks realnie wspiera Storm.
  3. Pig – pomyślany jako „PL/SQL dla Big Data”, obecnie już nie tak użyteczny, większość funkcji możemy wykonać w Spark bądź innych, przyjaznych narzędziach.
  4. Java – środowisko związane z analityką dużych zbiorów danych skłania się coraz bardziej w kierunku języków Scala i Python, choć oczywiście język Java pozostaje preferowanym, jeśli chodzi o aplikacje biznesowe klasy enterpris.
  5. Tez – rozwiązanie wspierane w zasadzie tylko przez Hortonworks, będące implementacją DAG, ale w przeciwieństwie do Spark’a, niskopoziomową.
  6. Oozie – będący trochę narzędziem workflow a trochę do planowania zadań, posiada dużo zaraportowanych błędów i w większości da się zastąpić innymi narzędziami.
  7. Flume – narzędzie powoli wypierane przez Kafka i inne. Od dłuższego czasu brak nowej wersji.

Nowości

Nowym, ciekawym trendem jest zarządzanie tzw. danymi w ruchu (data in motion). DataFlow – oparta na Apache NiFi, Storm i Kafka platforma do zarządzania przepływem danych oferowana przez Hortonworks powstała na bazie zakupionej firmy Onyara. „Dane w ruchu to więcej niż zwykłe przetwarzanie strumienia” – twierdzi Scott Gnau, CTO Hortonworks, i upatruje w tym obszarze dynamicznego rozwoju generowanego przez Internet rzeczy.
Wracając do Hadoop – w kolejnym artykule przyjrzymy się trendom w jego adopcji oraz gdzie należy upatrywać w najbliższym czasie akcentów w jego rozwoju.


Źródła informacji:

InfoWorld, Q&A: Hortonworks CTO unfolds the big data road map.
InfoWorld, Hadoop, we hardly knew ye.

Chmura w Polsce: Dołącz do nas