Silniki przetwarzania dużych zbiorów danych – którego mam używać?:Część 1

Ten wpis na blogu został opublikowany na Hortonworks.com przed fuzją z Cloudera. Niektóre linki, zasoby lub odniesienia mogą nie być już dokładne.

Specjalne podziękowania dla Billa Preachuka i Brandona Wilsona za przejrzenie i udostępnienie ich ekspertyzy

Wprowadzenie

Przechowywanie kolumnowe to często poruszany temat w dzisiejszym świecie przetwarzania i przechowywania dużych zbiorów danych — istnieją setki formatów, struktur i optymalizacji, w których można przechowywać dane, a nawet więcej sposobów ich odzyskiwania w zależności od tego, co planujesz zrobić z tym. Ta mnogość opcji pojawiła się z powodu konieczności nie tylko szybkiego pozyskiwania danych przy użyciu narzędzi On-Line Transactional Processing (OLTP), ale także z powodu potrzeby konsumowania i analizowania danych z większą wydajnością przy użyciu On-Line Analytical Processing (OLAP). narzędzia. Tysiące różnych przypadków użycia ma swoje własne specyficzne potrzeby, a zatem pojawiło się wiele opcji. Na przykład odczytywanie danych giełdowych wymaga zupełnie innego sposobu myślenia niż analizowanie wskaźników jakości na linii produkcyjnej. Mając wszystkie te opcje, łatwo się zgubić podczas nawigowania do celu końcowego:wyboru narzędzia, które działa dla Ciebie.

HDP zawiera szereg rozwiązań pamięci masowej, z których każde jest dostosowane do konkretnych przypadków użycia. Chcemy rozpocząć tę serię blogów od omówienia następujących trzech narzędzi/silników i powiązanych z nimi formatów przechowywania:

• Apache Hive używa Apache ORC jako wydajnego kolumnowego formatu przechowywania, który zapewnia wydajność przetwarzania zarówno OLAP, jak i głębokiego SQL
• Apache Phoenix/Apache HBase razem tworzą bazę danych OLTP, która umożliwia zapytania w czasie rzeczywistym do miliardów rekordów i oferuje szybkie losowe wyszukiwania oparte na kluczach, a także aktualizacje
• Apache Druid to magazyn danych o wysokiej wydajności, który umożliwia analizę szeregów czasowych w czasie rzeczywistym na strumieniach zdarzeń i analizę OLAP na danych historycznych z bardzo małym opóźnieniem

W tym artykule zamierzamy określić, które narzędzie jest odpowiednie dla danego przypadku użycia, porównać i zestawić różne narzędzia oraz zapewnić podstawowe wytyczne dotyczące wyboru odpowiedniego narzędzia lub zestawu narzędzi do rozwiązania danego przypadku użycia.

To trochę jak gra w Tetrisa – każdy element ma inną niszę, ale każdy z nich dodaje niepowtarzalną wartość do większej struktury

Przetwarzanie Big Data i jego podobieństwa

Dane są grupowane według kolumn w pamięci, ponieważ często próbujemy zawęzić sumy, średnie lub inne obliczenia w określonej kolumnie. Wyobraź sobie, że jesteś linią lotniczą, która próbuje zrozumieć, ile paliwa należy dostarczyć samolotowi, gdy jest on zadokowany — możesz chcieć obliczyć średnią liczbę mil pokonanych w każdym locie na podstawie tabeli danych dotyczących przelotów. Wymagałoby to wykonania średniej funkcji na pojedynczej kolumnie. Przechowalibyśmy te dane w formacie kolumnowym, ponieważ sekwencyjne odczyty na dysku są szybkie, a w tym przypadku chcemy sekwencyjnie odczytać jedną pełną kolumnę z tabeli (a następnie wykonać średnie obliczenia).

Istnieje wiele różnic między tymi silnikami, ale niezależnie od tego, który silnik przetwarzania danych wybierzesz, skorzystasz z kilku cech wspólnych. Jednym z nich jest wspólna funkcja buforowania. Każdy z tych trzech silników współpracuje z buforowaniem w pamięci, aby zwiększyć wydajność przetwarzania bez zmiany formatu pamięci masowej zaplecza, osiągając czas odpowiedzi poniżej sekundy. HBase ma BlockCache, Hive ma warstwę LLAP IO, a Druid ma kilka opcji buforowania w pamięci. Często kosztowna część obsługi zapytania polega na przeanalizowaniu żądania i przejściu do trwałego magazynu w celu pobrania podzbioru danych, którymi użytkownik jest zainteresowany. Jednak tego całego kroku można uniknąć, używając mechanizmu buforowania w pamięci, jak wiele kolumnowych formatów pamięci użycia, dzięki czemu proces w ułamku sekundy może sięgnąć do pamięci po wcześniej odpytywane dane. Wróćmy do naszego przykładu obliczania paliwa:powiedzmy, że właśnie poprosiłem o podanie średniej liczby przejechanych mil dla wszystkich lotów w mojej firmie, ale zdajmy sobie sprawę, że loty krajowe będą miały wymagania dotyczące paliwa znacznie różniące się od lotów międzynarodowych. Następnie będę chciał przefiltrować moje poprzednie zapytanie za pomocą klauzuli WHERE country='US' (lub równoważnego kodu kraju). Ten wzorzec zapytania jest bardzo powszechny w przypadku eksploracji danych. Ponieważ mamy już dane z poprzedniego zapytania w pamięci, wyniki tego zapytania mogą zostać zwrócone bez konieczności wykonywania kosztownego odczytu dysku.

Struktura warstwy LLAP Hive — część jej przestrzeni pamięci jest wykorzystywana do buforowania, podczas gdy przechowywanie długoterminowe jest na HDFS. HBase i Druid również mają podobną koncepcję pamięci podręcznej i przechowywania.

Inne podobieństwo istnieje w skrótach, których używa każdy z tych silników, aby skupić się na konkretnych danych, które są odpytywane. HBase ma dostęp losowy O(1) oparty na HashMap, Druid używa odwróconych indeksów bitmapowych, aby dowiedzieć się, które wartości kolumn znajdują się w których wierszach, a tabele Hive mają statystyki, indeksy i partycjonowanie do skrótu dostępu do danych. Funkcje te umożliwiają silnikom łączenie sposobu przechowywania danych ze sposobem, w jaki uzyskuje się do nich dostęp, umożliwiając szybką analizę przy jednoczesnej optymalizacji wydajności sprzętu i maksymalnym wykorzystaniu dostępnego procesora i pamięci RAM.

Ostatnie podobieństwo to gotowość przedsiębiorstwa każdego z tych silników. Jeśli chodzi o nadmiarowość danych, wszystkie trzy silniki wykorzystują HDFS jako mechanizm głębokiego przechowywania; współczynnik replikacji HDFS równy 3x zapewnia, że ​​kopie danych istnieją w innym miejscu, nawet jeśli dwa węzły ulegną jednoczesnej awarii. Dane można natychmiast ponownie zreplikować do zdrowych węzłów, aby zachować nadmiarowość. Jeśli chodzi o odporność na awarie w klastrze, każde narzędzie w pewien sposób wypełnia lukę. HBase oferuje replikację regionów, Druid ma duplikację komponentów głównych i roboczych, a także zwiększony współczynnik replikacji na HDFS, a Hive ma HDFS wraz z logiką odporną na błędy frameworka YARN. Gotowość korporacyjna zapewnia, że ​​te silniki są odporne na awarie i gotowe do pracy w produkcji od pierwszego dnia.

Różnice między naszymi silnikami przetwarzania Big Data

Jaki jest najlepszy sposób pozyskiwania danych? Jak szybko wyciągniesz z nich wnioski po przyswojeniu danych? Przyjrzyjmy się, jak te trzy silniki przetwarzania dużych zbiorów danych obsługują ten zestaw zadań przetwarzania danych

Silniki te są czasami powiązane mentalnie i myśli się o nich podobnie ze względu na ich zdolność do przechowywania i przetwarzania Big Data, ale jak się przekonamy, są one wybierane do przypadków użycia i celów, które są specjalnie dopasowane do ich mocnych stron. Przekonasz się, że zestaw narzędzi zawartych w Hortonworks Data Platform jest dobrze dopasowany do każdego obciążenia związanego z dużymi zbiorami danych, które możesz na niego rzucić, zwłaszcza w przypadku HDP 3.0 i wprowadzonych przez nas funkcji baz danych w czasie rzeczywistym.

Hive to silnik OLAP, który jest reprezentatywny dla najszerszego zakresu zastosowań, najczęściej wykorzystujący Hadoop Distributed File System (HDFS) jako warstwę przechowywania, aby umożliwić przechowywanie niemal dowolnego typu danych. Może wyszukiwać, przetwarzać i analizować nieustrukturyzowane dane tekstowe, pliki CSV, XML, częściowo ustrukturyzowany JSON, kolumnowy Parquet i wiele innych formatów. Hive obsługuje również alternatywne nośniki pamięci, takie jak przechowywanie w chmurze, Isilon i inne. De facto standardem przechowywania dla Hive jest ORC, który optymalizuje najbardziej efektywnie i czerpie korzyści z przechowywania kolumnowego. Po przekonwertowaniu do formatu ORC dane są kompresowane, a kolumny w tabeli są przechowywane sekwencyjnie na dysku, dzięki czemu warstwa LLAP w pamięci podręcznej Hive może pobierać dane z dysku raz i wielokrotnie udostępniać je z pamięci. Kombinacja Hive + LLAP jest używana do analizy ad hoc, obliczania dużych agregatów i raportowania o niskim opóźnieniu. Świetnym przypadkiem użycia Hive jest codzienne uruchamianie zestawu raportów pulpitu dla użytkowników; powtarzające się zapytania nie tylko korzystają z pamięci podręcznej LLAP, ale także z funkcji „Pamięci podręcznej wyników zapytań” – która zwraca niemal natychmiastowe wyniki, jeśli dane nie uległy zmianie (na marginesie:pamięć podręczna wyników zapytań to funkcja dostępna w Hive 3.0 – wydana w HDP 3.0). Oprócz tego hurtownia danych Hive jest doskonałym wykorzystaniem analizy ad-hoc, do której jest w stanie Hive; użytkownicy mogą łączyć dane, uruchamiać współbieżne zapytania i uruchamiać transakcje ACID. Rozważ Hive jako gniazdo SQL we wszystkich transakcjach pod tym względem, podczas gdy pozostałe dwa silniki zapewniają niezwykle wysoką wydajność w określonych niszowych przypadkach użycia.

Nasz drugi aparat, HBase, to rozproszony magazyn klucz-wartość, który ma możliwości losowego odczytu, zapisu, aktualizacji i usuwania. HBase (wariant NoSQL) został zaprojektowany jako silnik OLTP, który pozwala na architekturę operacji transakcyjnych o dużej objętości — pomyśl o platformach komunikacyjnych ze stałymi komunikatami wymienianymi między użytkownikami lub transakcjami generowanymi w systemie finansowym. HBase jest niezwykle wydajny w szybkim wprowadzaniu danych, przechowywaniu ich i udostępnianiu z powrotem – losowe wstawianie/aktualizacje/usuwanie danych o bardzo niskim opóźnieniu. Nie jest przeznaczony do agregowania i łączenia danych – ta funkcjonalność jest realizowana przez Phoenix, warstwę SQL i silnik oparty na HBase, ale nie jest zalecana w przypadku większych ilości danych, ponieważ dane nie są ustrukturyzowane w sposób zapewniający optymalne wydajność (zamiast tego użyj Hive). Podsumowując, HBase świetnie radzi sobie z przetwarzaniem dużych ilości operacji tworzenia-aktualizacji-usuwania, ale nie radzi sobie z prezentacją tych danych w formacie zużywalnym dla użytkowników.

Wreszcie, Druid jest trzecim silnikiem i jest przystosowany do obciążeń OLAP z szeregiem czasowym o niskim opóźnieniu, a także do indeksowania danych strumieniowych w czasie rzeczywistym. Druid zapewnia wykonywanie zapytań OLAP z szybkością kostki dla Twojego klastra. Seria czasowa Druida jest podstawą silnika; został zaprojektowany w ten sposób, ponieważ czas jest głównym filtrem podczas analizy danych opartych na czasie. Zastanów się, kiedy analizujesz czas lotu, aby zarezerwować podróż – chcę wiedzieć, jaki jest najtańszy lot do Włoch w tym konkretnym 2-tygodniowym przedziale czasowym. Druid pasuje do niszy polegającej na bardzo szybkim przyswajaniu danych, a także lokalizowaniu ich na żądanie. Z drugiej strony umożliwia również użytkownikom biznesowym i analitykom zapytanie o dane i zrozumienie ich za pomocą Superset, warstwy wizualizacji ściśle powiązanej z Druidem. Druid przoduje w wskazywaniu kilku wierszy danych spośród setek milionów lub miliardów w czasie krótszym niż sekundę, a także w niezwykle szybkim obliczaniu zagregowanych wartości dla tego samego wolumenu danych. Jednak nie wykonuje łączeń i dlatego nie można go używać do łączenia zestawów danych w celu analizy. Jeśli planujesz analizować kombinację zestawów danych w Druidzie, rozsądnie byłoby wstępnie połączyć dane przed wstawieniem ich do Druida lub użyć Hive (i tabel Hive wspieranych przez Druida) do wykonania złączeń. Innymi słowy, Druid dobrze pasuje do roli ostatniego przystanku dla Twoich danych po ich przetworzeniu i przekształceniu w sposób, w jaki Twoi użytkownicy biznesowi będą mieli do nich dostęp. Druid jest świetny dla analityków biznesowych, ponieważ mogą logować się do Superset i wizualizować metryki w formie pulpitu nawigacyjnego bez konieczności pisania jakichkolwiek zapytań; po prostu używają graficznego interfejsu użytkownika, aby wybrać źródło danych zapytania i filtry. Jest również świetny jako zapasowe źródło danych dla pulpitów systemowych, zarówno operacyjnych, jak i analitycznych, ze względu na szybkie czasy zapytań.

Oto jeden ze sposobów, w jaki możesz podzielić proces podejmowania decyzji o tym, którego narzędzia użyć do swojego obciążenia pracą:

Ujednolicony SQL

Do tej pory omówiliśmy wiele systemów i każdy z nich ma własne sposoby dostępu do swoich danych. Jest to świetne rozwiązanie, gdy Twoi użytkownicy wiedzą, jak działają wszystkie te narzędzia, ale mogą mieć trochę czasu na naukę, zanim osiągną pełną produktywność, jeśli pochodzą ze świata SQL, SQL i nie tylko, tak jak robi to większość analityków. Dlatego staraliśmy się, aby ta interakcja była jak najprostsza; z Hive 3.0 w HDP 3.0, możesz używać składni HQL podobnej do SQL Hive do interakcji z tak wieloma różnymi magazynami danych w tej przestrzeni. Hive może służyć jako portal do uzyskiwania dostępu i modyfikowania Druid, HBase i wszystkiego, co zapewnia interfejs i sterownik JDBC. Hive może być używany do administrowania zadaniem druidowym, które nasłuchuje Kafki, zapewniając prosty sposób na pozyskiwanie w czasie rzeczywistym. I wreszcie, Hive może być używany do łączenia wszystkich elementów – przechowuj dane tam, gdzie jest to najbardziej sensowne i uzyskuj do nich dostęp z jednego miejsca. Połącz to razem, a może nawet przechowaj nowy wynik w innej lokalizacji. Możliwości jest wiele, ale interfejs został znacznie uproszczony, dzięki czemu Twoi użytkownicy mogą poświęcać mniej czasu na naukę innego narzędzia, a więcej na wnoszenie wartości do firmy.

Wniosek

Hive, Druid i HBase mają różne miejsca w architekturze danych, jak widzieliśmy w poprzedniej analizie. Są to jednak narzędzia uzupełniające; możesz pozyskiwać dane transakcyjne za pomocą HBase z jego szybkimi wyszukiwaniami, przenieść te dane do Druid w celu szybkiego drążenia/agregacji i zlecić Hive zintegrowanie ich z własnymi danymi zarządzanymi przez Hive, aby umożliwić użytkownikom łączenie danych w dowolnym miejscu pojedynczy widok i bogactwo spostrzeżeń. Dzięki takiemu podejściu Druid przechowuje dane, do których można uzyskać dostęp samodzielnie, ale ta funkcjonalność jest rozszerzana przez Hive, który może pobierać dane Druida i łączyć je z dodatkowymi danymi. Dodaj do tego główne ulepszenia, które weszły w grę z Hive 3.0, z których nie najmniej ważnym są zmaterializowane widoki, ulepszona integracja z Druidem i wieloma innymi silnikami oraz zwiększona funkcjonalność podobna do hurtowni danych, a otrzymasz grupę narzędzi, które mogą rozwiązać praktycznie każdy przypadek użycia.

Architektury, takie jak wspomniana powyżej, wnoszą to, co najlepsze w każdym narzędziu, aby zoptymalizować przepływ pracy, a jednocześnie wyabstrahować szczegóły dla tych użytkowników, których dotyczą tylko dane. Architekci przygotowali potoki, umieszczając dane tam, gdzie powinny, w zależności od przypadku użycia. To z kolei prowadzi do analityków danych, którzy używają Hive jako swojego pojedynczego interfejsu do zdobywania wiedzy i spostrzeżeń. Są w stanie znaleźć interesujące wzorce w danych, zamiast martwić się o to, gdzie dane są przechowywane lub uczyć się nowej składni, aby uzyskać do nich dostęp – zdziwiłbyś się, gdy dowiedziałbyś się, jak często widzimy to na świecie.

W tym momencie wykazaliśmy mocne i słabe strony oraz najlepsze praktyki każdego narzędzia; mamy nadzieję, że odejdziesz z lepszym zrozumieniem tego, co pasuje gdzie, a także z szerszym obrazem połączenia wszystkich trzech, aby uzyskać najlepsze wyniki.