Jak to się stało, że akurat ta technologia, pomimo wad i problemów wieku dziecięcego, stała się tak istotnym elementem mega trendu Big Data? Aby odpowiedzieć na to pytanie spróbujmy przyjrzeć się procesowi powstania i rozwoju Hadoopa jako oprogramowania, ale także towarzyszącemu mu rozwoju świadomości biznesu, pozwalającej na wykorzystanie tej technologii do zmierzenia się z wyzwaniami, którym tradycyjne metody nie były w stanie sprostać.
Apache Hadoop to ciekawe zjawisko na firmamencie technologicznych gwiazd ostatniej dekady. Z jednej strony jest przykładem obserwowanego od jakiegoś czasu silnego trendu rozwoju oprogramowania w modelu open-source. Dla wielu osób jest on z pewnością może być inspirującym to, że społeczność inżynierów postanawia dać coś od siebie i stworzyć całkiem złożone oprogramowanie po to, aby rozwiązać jakiś konkretny problem obliczeniowy, a potem bezinteresownie (przynajmniej na początku) podzielić się tym rozwiązaniem z innymi.
Z drugiej strony, Hadoop jest obarczony wszelkimi wadami takiego modelu rozwoju oprogramowania, takimi jak zmienność i pewna nieprzewidywalność związana z jego „społecznościową” naturą. Nierzadko są ona przeszkodą w skutecznym wdrażaniu rozwiązań realizowanych na jego kanwie w przedsiębiorstwach o nieco konserwatywnym podejściu do IT. Pomimo tych obiektywnych trudności Hadoop jako technologia święci obecnie triumfy i jest wymieniany jako jedno z najistotniejszych z narzędzi, których nowoczesne IT może użyć do przechowywania i przetwarzania dużych zbiorów danych.
Hadoop: Początek
Nagłówek tego akapitu brzmi trochę jak tytuł hollywoodzkiego filmu. To dość trafne skojarzenie, bo na podstawie historii powstania Hadoopa jako technologii mógłby powstać całkiem interesujący scenariusz filmu. Ilustrowałby jak – w skomplikowanym świecie korporacyjnych procedur – inwencja jednej osoby jest w stanie doprowadzić do powstania innowacji o zasięgu globalnym. Doug Cutting, pracując w Yahoo, miał do rozwiązania konkretny problem obliczeniowy związany z indeksowaniem treści. Rozwiązanie przekraczało możliwości przeciętnych serwerów dostępnych dla jego projektu. Doug Cutting zauważył natomiast, że większość komputerów biurowych pozostaje w nocy włączonych, choć nikt z nich nie korzysta. Stworzył więc framework umożliwiający uruchamianie zadań obliczeniowych w rozproszonym środowisku klasycznych maszyn typu x86.
W bieżących planach rozwoju poszczególnych dystrybucji pojawiają się śmiałe pomysły, aby Hadoop stał się centralną platformą obliczeniową, skupiając w ramach swojego ekosystemu nie tylko wymienione wyżej obszary tradycyjnie związane z Big Data, ale także pozwalając na uruchamianie de facto dowolnej klasy dedykowanych aplikacji. W praktyce mogłoby to zostać zrealizowane poprzez umożliwienie uruchamiania kontenerów dockerowych w ramach zasobów zarządzanych przez YARN. Jest to pomysł niezwykle ciekawy z perspektywy rozwoju koncepcji Data Lake, umożliwia bowiem udostępnienie nie tylko danych, ale także zasobów obliczeniowych kolejnym użytkownikom, zarówno osobowym jak i technicznym.
Można powiedzieć, że pomysł ten okazał się genialny z przynajmniej dwóch powodów. Pierwszy nasuwa się sam – Doug Cutting wykorzystał traconą moc obliczeniową, niedostrzegany i marnowany potencjał dużej ilości stosunkowo słabych maszyn. Drugi jest pochodną pierwszego. Skoro Hadoop miał być zaimplementowany w całości w warstwie software’owej, to musiał także w tej warstwie rozwiązać kwestie związane z bezpiecznym przechowywaniem dużego zbioru przetwarzanych danych na dyskach poszczególnych maszyn oraz zapewnić zdolność całego systemu do wydajnego ich przetwarzania. Dzisiaj nikt już nie buduje klastrów Hadoop’owych – realizujących skomplikowane obliczenia wspierające istotne z punktu widzenia ciągłości biznesu procesy – w oparciu o stacje robocze pracowników. Co nie znaczy, że nie można wykorzystać ich do realizacji całkiem interesującego Proof of Concept! Natomiast fakt, że Hadoop może funkcjonować w oparciu o tani hardware, przenosząc do warstwy oprogramowania np. mechanizmy replikacji bloków danych i zarządzania dostępem do nich, jest jedną z jego najistotniejszych przewag. Dzieje się tak, ponieważ bezpośrednimi benefitami takiej architektury są m.in. obniżenie kosztu zakupu samego sprzętu, możliwość budowy heterogenicznych środowisk i praktycznie liniowa skalowalność pozioma.
Hadoop: Kluczowe elementy
Kiedy myślimy o Hadoopie z tamtego okresu w zasadzie mamy na myśli dwa kluczowe komponenty tego ekosystemu: HDFS (Hadoop Distributed File System) oraz MapReduce.
HDFS to warstwa składowania. Dzięki niemu mówimy o Big Data w kontekście dużych wolumenów danych. To właśnie na HDFS są one zapisywane, dzielone na bloki, replikowane pomiędzy węzły klastra. Plikowy charakter tego protokołu sprawia, że w zasadzie nie możemy mówić jeszcze o modelu tych danych. Na HDFS może trafić dowolny plik w swojej źródłowej formie. To była prawdopodobnie jedna z najważniejszych decyzji architektonicznych twórców Hadoop, związanych z projektowaniem całego ekosystemu wokół tego rozwiązania. Z jednej strony od lat znane ograniczenia systemów plikowych (związane np. z równoległym dostępem do zasobów), z drugiej możliwość przechowywania także danych niestrukturalnych i oraz podejście Schema on read, znakomicie skracające czas potrzebny na zgromadzenie danych z wielu źródeł w jednym miejscu.
Twórca koncepcji Hadoop – Doug Cutting – pracując w Yahoo, miał do rozwiązania konkretny problem obliczeniowy związany z indeksowaniem treści. Rozwiązanie przekraczało możliwości przeciętnych serwerów dostępnych dla jego projektu. Doug Cutting zauważył natomiast, że większość komputerów biurowych pozostaje w nocy włączonych, choć nikt z nich nie korzysta. Stworzył więc framework umożliwiający uruchamianie zadań obliczeniowych w rozproszonym środowisku klasycznych maszyn typu x86.
MapReduce to dla wielu synonim wsadowego przetwarzania danych, choć jest tylko jednym z dostępnych modeli programowania. Chociaż w miarę upływu czasu Hadoop był coraz lepiej przystosowywany do realizowania zadań w tzw. user-accepted real-time, przetwarzanie w modelu MapReduce nadal jest szeroko wykorzystywane wszędzie tam, gdzie konieczne jest przetworzenie naprawdę szerokiego zbioru danych w ramach jednego zadania. Dzięki transformacji, jaką przeszła implementacja silnika MapReduce wraz z rozwojem Hadoopa i usprawnieniu zapisywania stanów kroków pośrednich, MapReduce stał się także podstawowym modelem wykorzystywanym przez Apache Hive, dając tym samym dostęp do klastra dla wielu użytkowników znających język SQL.
Hadoop: Rozwój
Hadoop szybko został wcielony od Apache Foundation i jako projekt open-source do dzisiaj jest rozwijany przez tę społeczność. W miarę upływu czasu silnie ewoluował, optymalizując mechanizmy przetwarzania danych, dodając nowe możliwości definiowania uprawnień dla użytkowników, czy też dostarczając nowych interfejsów dostępu do danych. Wraz z dynamicznym rozwojem skupiał wokół siebie coraz więcej technologii powstałych początkowo niezależnie, takich jak Spark, czy Kafka. Dzisiaj są one dostępne w ramach wiodących dystrybucji komercyjnych Hadoopa. W efekcie dzisiaj mówimy często o ekosystemie Hadoop, jako o mocno heterogenicznym zbiorze różnych technologii, frameworków i narzędzi. Nierzadko były one początkowo rozwijane w organizacjach o bardzo różnych kulturach pracy, stąd wiele pracy firm – takich jak Hortonworks i Cloudera – skupia się obecnie na unifikacji standardów dalszego rozwoju platformy.
To, co mogło stanowić o sukcesie Hadoopa jako technologii powszechnie dziś wdrażanej, to niewątpliwie jego zdolność adaptacji do korporacyjnych standardów. Pomimo początkowego braku np. mechanizmów bezpieczeństwa oraz braku wsparcia procesów audytowania dostępu, czy zarządzania metadanymi opisującymi zbiory danych, z czasem udogodnienia te zostały wprowadzone, nierzadko w oparciu o tymczasowe rozwiązana wypracowane wcześniej i udostępnione w modelu open-source przez poszczególne organizacje. Dzisiaj Hadoop adresuje za pomocą swoich komponentów zarówno tradycyjne obszary przechowywania i przetwarzania dużych zbiorów danych, ale także niezbędne w korporacyjnej rzeczywistości aspekty bezpieczeństwa danych w spoczynku, w ruchu, Data Governance, współdzielenia i monitorowania dostępności zasobów.
Fakt, że Hadoop może funkcjonować w oparciu o tani hardware, przenosząc do warstwy oprogramowania np. mechanizmy replikacji bloków danych i zarządzania dostępem do nich, jest jedną z jego najistotniejszych przewag. Dzieje się tak, ponieważ bezpośrednimi benefitami takiej architektury są m.in. obniżenie kosztu zakupu samego sprzętu, możliwość budowy heterogenicznych środowisk oraz praktycznie liniowa skalowalność pozioma.
Perspektywy dla rozwoju ekosystemu Hadoop jawią się dzisiaj niezwykle interesująco. W bieżących planach rozwoju poszczególnych dystrybucji pojawiają się śmiałe pomysły, aby Hadoop stał się centralną platformą obliczeniową, skupiając w ramach swojego ekosystemu nie tylko wymienione wyżej obszary tradycyjnie związane z Big Data, ale także pozwalając na uruchamianie de facto dowolnej klasy dedykowanych aplikacji. W praktyce mogłoby to zostać zrealizowane poprzez umożliwienie uruchamiania kontenerów dockerowych w ramach zasobów zarządzanych przez YARN. Jest to pomysł niezwykle ciekawy z perspektywy rozwoju koncepcji Data Lake, umożliwia bowiem udostępnienie nie tylko danych, ale także zasobów obliczeniowych kolejnym użytkownikom, zarówno osobowym jak i technicznym. To z kolei otwiera możliwości realizowania kolejnych przypadków biznesowych, które do tej pory były trudne lub niemożliwe do realizacji, np. ze względu na brak możliwości wyeksportowania wystarczająco dużego zbioru danych do platformy aplikacyjnej przy jednoczesnym braku wsparcia ze strony ekosystemu Hadoop’owego dla danej technologii w jakiej powstała aplikacja.
W jakim kierunku rozwinie się Hadoop jako technologia? To zależy w dużej mierze także od nas, jako jej użytkowników. Praktyka pokazuje, że poszczególne organizacje odpowiedzialne za jej rozwój biorą pod uwagę realne potrzeby rynku. Możemy więc oczekiwać, że w Hadoop’owym zoo wielu zwierzęco brzmiących nazw, znajdą się także takie, które wprost korespondować będą z wymaganiami pojawiającymi się w biznesowych zastosowaniach technologii Big Data.
Kamil Folkert to Big Data Expert w SILMINE.
To 2. artykuł z cyklu “Odczarowując Big Data” opublikowany w numerze ITwiz 10/2016. W kolejnych artykułach z cyklu postaramy się przybliżyć poszczególne elementy ekosystemu Hadoop, przedstawiając przykłady z realizacji konkretnych procesów biznesowych na bazie praktycznych wdrożeń. Zapraszamy serdecznie do lektury.
