🥇Co wyjątkowego w Cloudera i jak je przygotować

Rynek obliczeń rozproszonych i wielkich danych, jeśli wierzyć statystyk, rośnie o 18-19% rocznie. Oznacza to, że wybór oprogramowania do tych celów pozostaje aktualny. W tym wpisie zaczniemy od tego, dlaczego obliczenia rozproszone są potrzebne, szczegółowo omówimy wybór oprogramowania, opowiemy o zastosowaniu Hadoopa za pomocą Cloudera, a na koniec porozmawiamy o wyborze sprzętu i tym, jak różnymi sposobami wpływa on na wydajność.

Dlaczego obliczenia rozproszone są potrzebne w zwykłym biznesie? Tutaj wszystko jest proste i jednocześnie skomplikowane. Proste — ponieważ w większości przypadków wykonujemy stosunkowo nieskomplikowane obliczenia na jednostkę informacji. Skomplikowane — ponieważ informacji jest dużo. Bardzo dużo. W związku z tym musimy przetwarzać terabajty danych w 1000 strumieni. W ten sposób scenariusze użycia są dość uniwersalne: obliczenia mogą być stosowane wszędzie tam, gdzie trzeba uwzględnić dużą liczbę metryk na jeszcze większym zbiorze danych.

Jednym z niedawnych przykładów jest sieć pizzerii Dodo Pizza określił na podstawie analizy bazy zamówień klientów, która pokazuje, że przy wyborze pizzy z dowolnym nadzieniem użytkownicy zazwyczaj posługują się tylko sześcioma podstawowymi zestawami składników oraz parą losowych. W związku z tym pizzeria dostosowała zakupy. Ponadto udało się lepiej polecać użytkownikom dodatkowe produkty oferowane na etapie zamówienia, co przyczyniło się do zwiększenia zysku.

Kolejny przykład: analiza pozycje towarowe pozwoliły sklepom H&M zmniejszyć asortyment w niektórych lokalizacjach o 40%, zachowując przy tym poziom sprzedaży. Udało się to osiągnąć poprzez wykluczenie słabo sprzedających się pozycji, przy czym uwzględniono sezonowość.

Wybór narzędzia

Standardem branżowym w obliczeniach tego typu jest Hadoop. Dlaczego? Ponieważ Hadoop to doskonały, dobrze udokumentowany framework (ten sam Habr dostarcza mnóstwo szczegółowych artykułów na ten temat), który jest wspierany przez szereg narzędzi i bibliotek. Możesz dostarczać do systemu ogromne zbiory zarówno danych strukturalnych, jak i niestrukturalnych, a system sam będzie je rozdzielał między zasoby obliczeniowe. Co więcej, te zasoby można w każdej chwili powiększyć lub wyłączyć — właśnie taka jest horizontalna skalowalność w akcji.

W 2017 roku wpływowa firma doradcza Gartner zawarła, że Hadoop wkrótce wyginie. Powód jest dość banalny: analitycy uważają, że firmy masowo przejdą do chmury, ponieważ tam będą mogły płacić tylko za rzeczywiste wykorzystanie mocy obliczeniowych. Drugim ważnym czynnikiem, który rzekomo może „pogrzebać” Hadoop, jest prędkość działania. Ponieważ opcje takie jak Apache Spark czy Google Cloud DataFlow działają szybciej niż MapReduce, na którym oparty jest Hadoop.

Hadoop opiera się na kilku filarach, z których najbardziej zauważalne to technologie MapReduce (system dystrybucji danych do obliczeń między serwerami) oraz system plików HDFS. Ten ostatni został stworzony specjalnie do przechowywania informacji rozdzielonej między węzłami klastra: każdy blok o stałej wielkości może być umieszczony na kilku węzłach, a dzięki replikacji system jest odporny na awarie poszczególnych węzłów. Zamiast tablicy plików używana jest specjalna maszyna serwerowa, nazywana NameNode.

Na poniższej ilustracji przedstawiono schemat działania MapReduce. W pierwszym etapie dane są dzielone według określonego kryterium, w drugim — rozdzielane według mocy obliczeniowej, a w trzecim — następuje obliczenie.

Początkowo MapReduce została stworzona przez Google dla potrzeb swojej wyszukiwarki. Następnie MapReduce przeszła na wolny kod, a projektem zajęła się organizacja Apache. Z kolei Google stopniowo przeszedł na inne rozwiązania. Ciekawostką jest to, że obecnie Google ma projekt o nazwie Google Cloud Dataflow, który jest przedstawiany jako następny krok po Hadoop, swoiste szybkie zastąpienie.

Przy bliższym zbadaniu widać, że Google Cloud Dataflow bazuje na odmianie Apache Beam, a w Apache Beam znajduje się dobrze udokumentowany framework Apache Spark, co pozwala mówić o praktycznie tej samej prędkości wykonywania rozwiązań. A Apache Spark doskonale współpracuje z systemem plików HDFS, co pozwala na jego uruchomienie na serwerach Hadoop.

Dodajmy do tego objętość dokumentacji i gotowych rozwiązań dotyczących Hadoop i Spark w porównaniu do Google Cloud Dataflow, a wybór narzędzia staje się oczywisty. Co więcej, inżynierowie mogą sami decydować, jaki kod — dla Hadoop czy Spark — mają uruchomić, kierując się zadaniem, doświadczeniem i kwalifikacjami.

Chmura czy lokalny serwer

Tendencja do ogólnego przejścia do chmury stworzyła nawet tak interesujący termin jak Hadoop jako usługa. W takim scenariuszu niezwykle ważne stało się zarządzanie podłączonymi serwerami. Ponieważ, niestety, mimo swojej popularności, czysty Hadoop jest dość skomplikowanym narzędziem do konfiguracji, ponieważ wiele rzeczy trzeba robić ręcznie. Na przykład, osobno konfigurować serwery, monitorować ich parametry, starannie ustawiać wiele parametrów. Generalnie, to praca dla pasjonatów i istnieje duże ryzyko, że gdzieś popełnimy błąd lub coś przegapimy.

Dlatego dużą popularność zyskały różne dystrybucje, które pierwotnie wyposażone są w wygodne narzędzia do wdrażania i administracji. Jedną z najpopularniejszych dystrybucji, które wspierają Spark i wszystko ułatwiają, jest Cloudera. Ma zarówno wersję płatną, jak i darmową — w tej ostatniej dostępna jest cała podstawowa funkcjonalność, bez ograniczenia liczby węzłów.

Podczas konfiguracji Cloudera Manager połączy się przez SSH z twoimi serwerami. Interesujący moment: podczas instalacji lepiej wskazać, żeby odbywała się ona za pomocą tak zwanych pakietów: specjalnych paczek, w każdej z nich znajdują się wszystkie potrzebne komponenty, skonfigurowane do współpracy ze sobą. Zasadniczo to ulepszona wersja menedżera pakietów.

Po instalacji otrzymujemy konsolę zarządzania klastrem, na której można zobaczyć telemetrię dotyczącą klastrów, zainstalowane usługi, a także będzie można dodawać/usuwać zasoby i edytować konfigurację klastra.

W rezultacie przed tobą pojawia się wizja tej rakiety, która zabierze cię w świetlaną przyszłość Big Data. Ale zanim powiesz „start”, przenieśmy się pod maskę.

Wymagania dotyczące sprzętu

Na swojej stronie Cloudera wspomina różne możliwe konfiguracje. Ogólne zasady, na podstawie których są one budowane, przedstawione są na ilustracji:

Optymistyczny obraz może zepsuć MapReduce. Patrząc ponownie na schemat z poprzedniego rozdziału, staje się oczywiste, że w prawie wszystkich przypadkach zadanie MapReduce może napotkać "wąskie gardło" przy odczycie danych z dysku lub sieci. Zauważa to również blog Cloudera. W rezultacie, dla szybkich obliczeń, w tym za pomocą Sparka, który jest często wykorzystywany do obliczeń w czasie rzeczywistym, bardzo ważna jest prędkość wejścia/wyjścia. Dlatego przy użyciu Hadoop bardzo ważne jest, aby w klastrze znajdowały się zbalansowane i szybkie maszyny, co, delikatnie mówiąc, nie zawsze jest zapewnione w infrastrukturze chmurowej.

Zbalansowanie obciążenia osiąga się dzięki wykorzystaniu wirtualizacji Openstack na serwerach z potężnymi wielordzennymi procesorami. Węzły danych mają przypisane własne zasoby procesora i określone dyski. W naszym rozwiązaniu Atos Codex Data Lake Engine osiągamy szeroką wirtualizację, co przynosi korzyści zarówno w wydajności (minimalizuje wpływ infrastruktury sieciowej), jak i TCO (eliminacja zbędnych fizycznych serwerów).

W przypadku używania serwerów BullSequana S200 uzyskujemy bardzo równomierne obciążenie, pozbawione części wąskich gardeł. W minimalnej konfiguracji obejmuje 3 serwery BullSequana S200, każdy z dwoma JBOD, dodatkowo opcjonalnie można podłączyć dodatkowe S200, które zawierają cztery węzły danych. Oto przykład obciążenia w teście TeraGen:

Testy z różnymi rozmiarami danych i wartościami replikacji wykazują podobne wyniki pod względem rozkładu obciążenia między węzłami klastra. Poniżej znajduje się wykres rozkładu dostępu do dysku w testach wydajności.

Obliczenia wykonano na podstawie minimalnej konfiguracji z 3 serwerów BullSequana S200. Obejmuje ona 9 węzłów danych i 3 główne węzły, a także zarezerwowane maszyny wirtualne na wypadek wdrożenia ochrony na bazie Wirtualizacji OpenStack. Wynik testu TeraSort: rozmiar bloku 512 MB przy współczynniku replikacji równym trzy z szyfrowaniem wynosi 23,1 min.

Jak można rozszerzyć system? Dla Data Lake Engine dostępne są różne rodzaje rozszerzeń:

Węzły przesyłania danych: dla każdego 40 TB użytecznej przestrzeni
Węzły analityczne z możliwością zainstalowania procesora graficznego
Inne opcje w zależności od potrzeb biznesowych (na przykład, jeśli potrzebne jest Kafka i tym podobne)

W skład kompleksu Atos Codex Data Lake Engine wchodzą zarówno same serwery, jak i wstępnie zainstalowane oprogramowanie, w tym zestaw Cloudera z licencją; sam Hadoop, OpenStack z maszynami wirtualnymi opartymi na jądrze RedHat Enterprise Linux, systemy replikacji danych oraz kopie zapasowe (w tym za pomocą węzła kopii zapasowej oraz Cloudera BDR — Backup and Disaster Recovery). Atos Codex Data Lake Engine stał się pierwszym rozwiązaniem z zastosowaniem wirtualizacji, które zostało certyfikowane Cloudera.