Rynek przetwarzania rozproszonego i big data wg , rośnie o 18-19% rocznie. Oznacza to, że kwestia wyboru oprogramowania do tych celów pozostaje aktualna. W tym poście zaczniemy od tego, dlaczego potrzebne jest przetwarzanie rozproszone, omówimy bardziej szczegółowo wybór oprogramowania, porozmawiamy o korzystaniu z Hadoopa w Clouderze, a na koniec porozmawiamy o wyborze sprzętu i jego wpływie na wydajność na różne sposoby.
Dlaczego przetwarzanie rozproszone jest potrzebne w regularnej działalności? Wszystko tutaj jest proste i złożone jednocześnie. Proste - ponieważ w większości przypadków wykonujemy stosunkowo proste obliczenia na jednostkę informacji. To trudne, bo takich informacji jest mnóstwo. Tak wiele. W konsekwencji jest to konieczne . Tym samym przypadki użycia są dość uniwersalne: obliczenia można zastosować wszędzie tam, gdzie konieczne jest uwzględnienie dużej liczby metryk na jeszcze większym zbiorze danych.
Jeden z ostatnich przykładów: sieć pizzerii Dodo Pizza z analizy bazy zamówień klientów wynika, że wybierając pizzę z losowym dodatkiem, użytkownicy zazwyczaj operują tylko sześcioma podstawowymi zestawami składników plus kilka losowych. Zgodnie z tym pizzeria dostosowała swoje zakupy. Dodatkowo potrafiła lepiej rekomendować użytkownikom dodatkowe produkty oferowane na etapie składania zamówienia, co zwiększało zyski.
Jeszcze jeden przykład: pozycji produktowych pozwoliło sklepowi H&M zmniejszyć asortyment w poszczególnych sklepach o 40%, przy jednoczesnym utrzymaniu poziomów sprzedaży. Osiągnięto to poprzez wykluczenie pozycji słabo sprzedających się, a w obliczeniach uwzględniono sezonowość.
Wybór narzędzia
Standardem branżowym dla tego typu obliczeń jest Hadoop. Dlaczego? Bo Hadoop to doskonały, dobrze udokumentowany framework (ten sam Habr udostępnia wiele szczegółowych artykułów na ten temat), do którego dołączony jest cały zestaw narzędzi i bibliotek. Możesz wprowadzać ogromne zbiory danych zarówno ustrukturyzowanych, jak i nieustrukturyzowanych, a system sam je rozdysponuje pomiędzy moc obliczeniową. Co więcej, te same pojemności można w dowolnym momencie zwiększyć lub wyłączyć – ta sama pozioma skalowalność w działaniu.
W 2017 roku wpływowa firma doradcza Gartner że Hadoop wkrótce stanie się przestarzały. Powód jest dość banalny: analitycy uważają, że firmy będą masowo migrować do chmury, bo tam będą mogły płacić w miarę wykorzystania mocy obliczeniowej. Drugim ważnym czynnikiem, który rzekomo może „zakopać” Hadoopa, jest jego prędkość. Ponieważ opcje takie jak Apache Spark lub Google Cloud DataFlow są szybsze niż MapReduce, na którym opiera się Hadoop.
Hadoop opiera się na kilku filarach, z których najbardziej godnymi uwagi są technologie MapReduce (system dystrybucji danych do obliczeń pomiędzy serwerami) oraz system plików HDFS. Ten ostatni jest specjalnie zaprojektowany do przechowywania informacji rozproszonych pomiędzy węzłami klastra: każdy blok o ustalonej wielkości można umieścić na kilku węzłach, a dzięki replikacji system jest odporny na awarie poszczególnych węzłów. Zamiast tabeli plików używany jest specjalny serwer o nazwie NameNode.
Poniższa ilustracja pokazuje, jak działa MapReduce. W pierwszym etapie dane są dzielone według określonego kryterium, w drugim – rozdzielane według mocy obliczeniowej, a w trzecim – przeprowadzane są obliczenia.
MapReduce został pierwotnie stworzony przez Google na potrzeby wyszukiwania. Następnie MapReduce przeszedł na darmowy kod, a projekt przejął Apache. Cóż, Google stopniowo migrowało do innych rozwiązań. Ciekawostka: Google ma obecnie projekt o nazwie Google Cloud Dataflow, pozycjonowany jako kolejny krok po Hadoopie, jako jego szybki zamiennik.
Bliższe przyjrzenie się pokazuje, że Google Cloud Dataflow opiera się na odmianie Apache Beam, natomiast Apache Beam zawiera dobrze udokumentowany framework Apache Spark, co pozwala mówić o niemal takiej samej szybkości wykonywania rozwiązań. Cóż, Apache Spark doskonale działa na systemie plików HDFS, co pozwala na wdrożenie go na serwerach Hadoop.
Dodajmy tutaj ilość dokumentacji i gotowych rozwiązań dla Hadoop i Spark kontra Google Cloud Dataflow, a wybór narzędzia stanie się oczywisty. Co więcej, inżynierowie mogą sami decydować, jaki kod – dla Hadoopa czy Sparka – uruchomić, skupiając się na zadaniu, doświadczeniu i kwalifikacjach.
Serwer w chmurze lub lokalny
Trend w kierunku ogólnego przejścia na chmurę dał nawet początek tak interesującemu terminowi, jak Hadoop-as-a-service. W takim scenariuszu bardzo ważne stało się administrowanie podłączonymi serwerami. Ponieważ, niestety, pomimo swojej popularności, czysty Hadoop jest dość trudnym narzędziem do skonfigurowania, ponieważ wiele trzeba robić ręcznie. Na przykład konfiguruj serwery indywidualnie, monitoruj ich wydajność i dokładnie konfiguruj wiele parametrów. Ogólnie rzecz biorąc, praca jest dla amatora i jest duże ryzyko, że gdzieś coś namieszam lub coś przeoczę.
Dlatego dużą popularnością cieszą się różne zestawy dystrybucyjne, które początkowo wyposażone są w wygodne narzędzia do wdrażania i administrowania. Jedną z najpopularniejszych dystrybucji obsługujących Spark i ułatwiającą wszystko jest Cloudera. Ma zarówno wersję płatną, jak i bezpłatną - 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. Ciekawostka: podczas instalacji lepiej określić, że ma to być wykonane przez tzw parsele: specjalne pakiety, z których każdy zawiera wszystkie niezbędne komponenty skonfigurowane do współpracy ze sobą. Zasadniczo jest to ulepszona wersja menedżera pakietów.
Po instalacji otrzymujemy konsolę zarządzania klastrem, w której można zobaczyć telemetrię klastra, zainstalowane usługi, a także można dodawać/usuwać zasoby i edytować konfigurację klastra.
W efekcie przed Tobą pojawia się kabina rakiety, która zabierze Cię w świetlaną przyszłość BigData. Zanim jednak powiemy „chodźmy”, przejdźmy pod maskę.
Wymagania sprzętowe
Cloudera na swojej stronie internetowej wspomina o różnych możliwych konfiguracjach. Ogólne zasady ich budowy pokazano na ilustracji:
MapReduce może zamazać ten optymistyczny obraz. Jeśli ponownie spojrzysz na diagram z poprzedniej sekcji, stanie się jasne, że prawie we wszystkich przypadkach zadanie MapReduce może napotkać wąskie gardło podczas odczytu danych z dysku lub z sieci. Odnotowano to również na blogu Cloudera. W rezultacie w przypadku szybkich obliczeń, w tym za pomocą platformy Spark, która jest często używana do obliczeń w czasie rzeczywistym, szybkość operacji we/wy jest bardzo ważna. Dlatego przy korzystaniu z Hadoopa bardzo ważne jest, aby w klastrze znajdowały się zrównoważone i szybkie maszyny, co, delikatnie mówiąc, nie zawsze jest zapewnione w infrastrukturze chmurowej.
Równowagę w dystrybucji obciążenia osiąga się poprzez zastosowanie wirtualizacji Openstack na serwerach z wydajnymi wielordzeniowymi procesorami. Węzły danych mają przydzielone własne zasoby procesora i określone dyski. W naszej decyzji Silnik Atos Codex Data Lake Osiągana jest szeroka wirtualizacja, dlatego zyskujemy zarówno pod względem wydajności (minimalizacja wpływu infrastruktury sieciowej), jak i TCO (eliminacja dodatkowych serwerów fizycznych).
Korzystając z serwerów BullSequana S200 uzyskujemy bardzo równomierne obciążenie, pozbawione wąskich gardeł. Minimalna konfiguracja obejmuje 3 serwery BullSequana S200, każdy z dwoma JBODami, plus opcjonalnie podłączone dodatkowe S200 zawierające cztery węzły danych. Oto przykład obciążenia w teście TeraGen:
Testy z różnymi wolumenami danych i wartościami replikacji wykazują te same wyniki pod względem rozkładu obciążenia pomiędzy węzłami klastra. Poniżej znajduje się wykres rozkładu dostępu do dysku według testów wydajnościowych.
Obliczenia przeprowadzono w oparciu o minimalną konfigurację 3 serwerów BullSequana S200. Zawiera 9 węzłów danych i 3 węzły główne, a także zarezerwowane maszyny wirtualne na wypadek wdrożenia ochrony opartej na wirtualizacji OpenStack. Wynik testu TeraSort: rozmiar bloku 512 MB, współczynnik replikacji równy trzy przy szyfrowaniu wynosi 23,1 minuty.
Jak można rozbudować system? Istnieją różne typy rozszerzeń dostępnych dla Data Lake Engine:
- Węzły danych: na każde 40 TB przestrzeni użytkowej
- Węzły analityczne z możliwością instalacji procesora graficznego
- Inne opcje w zależności od potrzeb biznesowych (na przykład, jeśli potrzebujesz Kafki i tym podobnych)
Atos Codex Data Lake Engine obejmuje zarówno same serwery, jak i preinstalowane oprogramowanie, w tym licencjonowany zestaw Cloudera; Sam Hadoop, OpenStack z maszynami wirtualnymi opartymi na jądrze RedHat Enterprise Linux, systemy replikacji danych i tworzenia kopii zapasowych (m.in. wykorzystanie węzła kopii zapasowych oraz Cloudera BDR – Backup i Disaster Recovery). Atos Codex Data Lake Engine stał się pierwszym rozwiązaniem do wirtualizacji, które uzyskało certyfikat .
Jeśli interesują Cię szczegóły, chętnie odpowiemy na nasze pytania w komentarzach.
Źródło: www.habr.com