7 najpopularniejszych projektów Hadoop i Spark

Jest taki stary aksjomat, który brzmi mniej więcej tak: jeśli zaoferujesz komuś pełne wsparcie i wsparcie finansowe, aby zrobił coś innego i innowacyjnego, w końcu zrobi to, co robią wszyscy inni.

Tak samo jest z Hadoop, Spark i Storm. Wszyscy myślą, że robią coś wyjątkowego z tymi nowymi technologiami Big Data, ale nie trzeba długo czekać na te same wzorce. Poszczególne implementacje mogą się nieco różnić, ale z mojego doświadczenia wynika, że ​​przedstawiam siedem najpopularniejszych projektów.

Projekt nr 1: Konsolidacja danych

Nazwij to „centrum danych przedsiębiorstwa” lub „jezioro danych”. Chodzi o to, że masz różne źródła danych i chcesz przeprowadzić analizę na nich. Ten typ projektu polega na pobieraniu kanałów ze wszystkich źródeł (w czasie rzeczywistym lub zbiorczo) i umieszczaniu ich w Hadoop. Czasami jest to pierwszy krok do stania się „firmą opartą na danych”; czasami po prostu chcesz mieć ładne raporty. Jeziora danych zwykle materializują się jako pliki na HDFS i tabele w Hive lub Impala. Istnieje odważny, nowy świat, w którym wiele z tego pojawia się w HBase - i Phoenix w przyszłości, ponieważ Hive jest powolny.

Sprzedawcy lubią mówić takie rzeczy, jak „schemat przy czytaniu”, ale tak naprawdę, aby odnieść sukces, musisz dobrze wiedzieć, jakie będą twoje przypadki użycia (ten schemat Hive nie będzie wyglądał tak bardzo różnie od tego, co zrobiłbyś w hurtownia danych przedsiębiorstwa). Prawdziwym powodem jeziora danych jest skalowalność pozioma i znacznie niższy koszt niż Teradata czy Netezza. W celu „analizy” wiele osób konfiguruje Tableau i Excel w interfejsie użytkownika. Bardziej wyrafinowane firmy z „prawdziwymi naukowcami danych” (maniacy matematyki piszący zły Python) używają Zeppelina lub iPythona jako interfejsu użytkownika.

Projekt nr 2: Analiza specjalistyczna

Wiele projektów konsolidacji danych faktycznie rozpoczyna się tutaj, gdy masz specjalne potrzeby i pobierasz jeden zestaw danych dla systemu, który przeprowadza jeden rodzaj analizy. Są one zwykle niewiarygodnie specyficzne dla danej dziedziny, na przykład symulacje ryzyka płynności / Monte Carlo w banku. W przeszłości takie wyspecjalizowane analizy opierały się na przestarzałych, zastrzeżonych pakietach, których nie można było skalować tak jak dane, i często cierpiały z powodu ograniczonego zestawu funkcji (częściowo dlatego, że producent oprogramowania nie mógł wiedzieć tyle o domenie, co instytucja). zanurzony w nim).

W światach Hadoop i Spark te systemy wyglądają mniej więcej tak samo jak systemy konsolidacji danych, ale często mają więcej HBase, niestandardowy kod inny niż SQL i mniej źródeł danych (jeśli nie tylko jedno). Coraz częściej są oparte na Spark.

Projekt nr 3: Hadoop jako usługa

W każdej dużej organizacji z projektami „wyspecjalizowanej analizy” (i ironicznie jednym lub dwoma projektami „konsolidacji danych”) nieuchronnie zaczną odczuwać „radość” (to znaczy ból) zarządzania kilkoma różnie skonfigurowanymi klastrami Hadoop, czasem z różnych sprzedawcy. Następnie powiedzą: „Może powinniśmy to skonsolidować i połączyć zasoby”, zamiast pozostawiać połowę ich węzłów bezczynnie przez połowę czasu. Mogliby przejść do chmury, ale wiele firm nie może lub nie chce, często ze względów bezpieczeństwa (czytaj: polityka wewnętrzna i ochrona pracy). Zwykle oznacza to wiele przepisów szefa kuchni, a teraz pakiety kontenerów Docker.

Jeszcze go nie używałem, ale wydaje się, że Blue Data jest najbliżej rozwiązania gotowego do użycia, które spodoba się również mniejszym organizacjom, którym brakuje środków do wdrożenia Hadoop jako usługi.

Projekt nr 4: Analiza strumieniowa

Wiele osób nazwałoby to „przesyłaniem strumieniowym”, ale analiza strumieniowa różni się raczej od przesyłania strumieniowego z urządzeń. Często analiza strumieniowa jest wersją w czasie rzeczywistym tego, co organizacja robiła partiami. Weźmy na przykład pranie pieniędzy lub wykrywanie oszustw: dlaczego nie zrobić tego na podstawie transakcji i nie złapać tego na bieżąco, a nie na końcu cyklu? To samo dotyczy zarządzania zapasami lub czegokolwiek innego.

W niektórych przypadkach jest to nowy typ systemu transakcyjnego, który analizuje dane bit po bicie, gdy równolegle przetaczasz je do systemu analitycznego. Takie systemy pojawiają się jako Spark lub Storm z HBase jako zwykłym magazynem danych. Należy pamiętać, że analiza strumieniowa nie zastępuje wszystkich form analizy; nadal będziesz chciał wykryć historyczne trendy lub spojrzeć na dane z przeszłości, aby znaleźć coś, czego nigdy nie brałeś pod uwagę.

Projekt nr 5: Kompleksowa obsługa zdarzeń

Tutaj mówimy o przetwarzaniu zdarzeń w czasie rzeczywistym, gdzie znaczenie mają sekundy. Chociaż nadal nie jest wystarczająco szybki dla aplikacji o bardzo niskich opóźnieniach (pikosekundowych lub nanosekundowych), takich jak zaawansowane systemy transakcyjne, możesz spodziewać się milisekundowych czasów odpowiedzi. Przykłady obejmują ocenę w czasie rzeczywistym rekordów danych połączeń dla firm telekomunikacyjnych lub przetwarzanie zdarzeń Internetu rzeczy. Czasami zobaczysz, że takie systemy używają Spark i HBase - ale generalnie upadają na twarz i muszą zostać przekonwertowane na Storm, który jest oparty na wzorcu Disruptor opracowanym przez giełdę LMAX.

W przeszłości takie systemy były oparte na spersonalizowanym oprogramowaniu do przesyłania wiadomości - lub gotowych do sprzedaży produktach o wysokiej wydajności do przesyłania wiadomości typu klient-serwer - ale dzisiejsze ilości danych to za dużo. Wolumeny handlowe i liczba osób posiadających telefony komórkowe wzrosły od czasu stworzenia tych starszych systemów, a czujniki medyczne i przemysłowe wypompowują zbyt wiele bitów. Jeszcze go nie używałem, ale projekt Apex wygląda obiecująco i twierdzi, że jest szybszy niż Storm.

Projekt nr 6: Transmisja strumieniowa jako ETL

Czasami chcesz przechwycić dane przesyłane strumieniowo i gdzieś je przechowywać. Projekty te zwykle pokrywają się z nr 1 lub nr 2, ale dodają swój własny zakres i charakterystykę. (Niektórzy myślą, że zajmują 4 lub 5 miejsce, ale w rzeczywistości zrzucają na dysk i analizują dane później). Są to prawie zawsze projekty Kafki i Storm. Spark jest również używany, ale bez uzasadnienia, ponieważ tak naprawdę nie potrzebujesz analizy w pamięci.

Projekt nr 7: Zastąpienie lub rozszerzenie SAS

SAS jest w porządku; SAS jest fajny. SAS jest również drogi i nie kupujemy pudełek dla wszystkich naukowców i analityków danych, abyście mogli „bawić się” danymi. Poza tym chciałeś zrobić coś innego niż mógłby zrobić SAS lub wygenerować ładniejszy wykres. Oto twoje ładne jezioro danych. Oto iPython Notebook (teraz) lub Zeppelin (później). Przekażemy wyniki do SAS i będziemy przechowywać wyniki z SAS tutaj.

Chociaż widziałem inne projekty Hadoop, Spark lub Storm, są to „normalne”, codzienne typy. Jeśli używasz Hadoop, prawdopodobnie je rozpoznajesz. Niektóre przypadki użycia tych systemów zaimplementowałem lata wcześniej, pracując z innymi technologiami.

Jeśli jesteś weteranem, zbytnio boisz się „dużych” w Big Data lub „do” w Hadoop, nie bój się. Im bardziej rzeczy się zmieniają, tym bardziej pozostają takie same. Znajdziesz wiele podobieństw między materiałami, które wykorzystałeś do wdrożenia, a technologiami hipsterskimi krążącymi w Hadooposferze.