Najlepsza odpowiedź
W każdym możliwym teście porównawczym Spark Sql jest „znacznie” szybszy niż Hive. Chociaż Facebook wymyślił Presto – tanią kopię projektu Sparka pod maską ula, a na Tez jest też nowsza wersja ula – której nieszczęście z DAG jest dobrze udokumentowane tutaj Tragedia Tez , ale we wszystkich zadaniach związanych z SQL (np. Sqls => filtrowanie po stronie mapy, mutacja danych lub redukcja po stronie Sqls => funkcje sortowania / agregacji / okna), Spark nadal świeci jasno.
Ponieważ pytanie nie brzmi „dlaczego”, nie wdawałbym się zbytnio w te szczegóły techniczne. Ale żeby dać ci sens, pomyśl o modelu rozproszonego przetwarzania danych, w którym każde zadanie musi zapisać cały zestaw danych (z replikacją), które jest przechowywane przed ukończeniem, gdzie aplikacja nie jest w stanie samodzielnie ocenić wykorzystania zasobów i gdzie znajduje się aplikacja miłosierdzie menedżera klastra w uruchamianiu zadania / etapu wykonania i porównanie tego z innym rozproszonym modelem przetwarzania danych, w którym zadania mogą żyć w pamięci przez większość czasu, gdzie zasoby mogą być inteligentnie przydzielane przez silnik i gdzie można umieścić framework na górze menedżera klastra i nie zależy od menedżera klastra – poza alokacją kontenerów (i niewielką ilością de / serializacji, którą można nawet ominąć)
(i mówiąc krótko, nie nawet wspomnij o Spark 1.6 / 2.x, który przyspiesza grę z implementacją Tungsten lub Simd w celu optymalizacji zapytań)
Który model Twoim zdaniem wygrałby bitwę o opóźnienia?
Odpowiedź
Zacznijmy od zapytania : Hive implementuje podzbiór SQL – język Hive ( LanguageManual – Apache Hive – Apache Software Foundation ), który jest specyficzny dla możliwości Hive i Hadoop. Twoje zapytanie jest podzielone na części, predykaty, które można zaimplementować w operacjach lub etapach. SELECT col1 , col2 ,… coln określa, które kolumny każdego zwróconego wiersza zostaną zachowane i zwrócone w zestawie rozwiązań. Podobnie, złączenie LEFT lub RIGHT byłoby zaimplementowane w określonym stanie, prawdopodobnie na etapie Map-Reduce (M\_R). Gdy zapytanie zostanie podzielone na części odpowiadające konkretnym operacjom, Optymalizator oparty na kosztach (CBO) wykorzystuje zebrane i przechowywane statystyki, aby podejmować inteligentne decyzje dotyczące sposobu wykonania każdego z tych etapów. Na przykład klauzula WHERE może zostać zaimplementowana jako skanowanie tabeli, jeśli nie jest bardzo specyficzna (mała liczność) lub jeśli tabela nie jest podzielona na partycje, lub może spowodować eliminację partycji, jeśli tabela jest podzielona na partycje, a klauzula WHERE określa kolumny partycji o wysokiej specyficzności. Jeśli zapytanie określa wiele złączeń, każde złączenie zostanie zaimplementowane jako etap Map-Reduce. Jeśli jedna z tabel łączenia jest bardzo mała, CBO może wybrać Map-Join do wykonania w celu uzyskania lepszej wydajności.
Gdy CBO opracuje plan wykonania, etapy są planowane i wykonywane, zazwyczaj jako wiele etapów MR. Możesz sprawdzić plan wykonania, którego CBO użyłby do wykonania dowolnego zapytania, uruchamiając EXPLAIN na kwerendzie.
Miałem klienta z branży wideo, który zbierał statystyki dotyczące nawyków oglądania przez swoich użytkowników. Te statystyki zostały zebrane w jedną bardzo dużą tabelę (setki TiB), którą klient życzył sobie połączyć z około 20 stosunkowo małymi tabelami, które zawierały dane o każdym filmie, aktorach w filmie, fabułę każdego filmu, dane dotyczące produkcji itp. Utworzyłem widoki, które sukcesywnie łączyły mniejsze tabele, które ostatecznie były łączone z tabelą podglądu w widok wyników, który był następnie zapisywany w tabeli wyjściowej. Kiedy przesłałem proste zapytanie, aby wybrać z widoku wyników do tabeli wyjściowej (CREATE TABLE output (…) AS SELECT * FROM results\_view) Hive utworzył 25-etapowe zapytanie, które zmaterializowało wszystkie widoki pośrednie w ostatecznym widoku, który został następnie zapisany do tabeli wyjściowej. Ponieważ każdy etap był zadaniem M-R (dla YARN), a czas konfiguracji dla zadania M-R wynosił około 30 sekund dla tego klastra, około 12–14 minut poświęcono na ustawienie M-R. Większość etapów M-R wykonano w mniej niż 45 sekund, z czego 2/3 to czas konfiguracji M-R, a 1/3 faktyczna realizacja. Ostateczne dołączenie mapy mniejszych stolików do tabeli statystyk widzów zajęło kolejne 20 minut. Stworzenie zestawu widoków, które były sukcesywnie łączone w tabelę wyników, pozwoliło mi stworzyć potok składający się z kilku stosunkowo prostych zapytań, zamiast próbować tworzyć ogromne zapytania, które próbowałyby połączyć ponad 20 tabel w jednym zapytaniu.