Nejlepší odpověď
Ve všech možných srovnávacích testech je Spark Sql „mnohem“ rychlejší než Hive. Ačkoli Facebook přišel s Presto – levnou kopií designu Sparku pod kapucí úlu a na Tezu jsou také novější verze úlu – jehož nehoda s DAG je zde dobře zdokumentována The Tragédie Tezu , ale ve všech úlohách souvisejících s SQL (např. Map side sqls => filtr, mutace dat nebo snížení postranních Sqls => Funkce řazení / agregace / okna), Spark stále svítí jasně.
Jelikož se otázka neptá „Proč“, moc bych se těmito technickými podrobnostmi nezabýval. Ale jen pro představu, pomyslete na model zpracování distribuovaných dat, kde každý úkol musí před dokončením napsat celou datovou sadu (s replikací), kterou drží, kde aplikace nedokáže sama měřit využití zdrojů a kde je aplikace na milost manažera klastru při zahájení úkolu / fáze provádění a porovnat to s jiným modelem zpracování distribuovaných dat, kde úkoly mohou většinu času žít v paměti, kde může stroj inteligentně přidělit zdroj a kde může rámec sedět v horní části správce klastrů a záleží na správci klastrů pro nic – kromě alokace kontejnerů (a trochu De / Serializace, kterou lze dokonce obejít)
(a abych to stručně řekl, ne dokonce zmíníme, že Spark 1.6 / 2.x zintenzivňuje hru s implementací Tungsten nebo simd pro optimalizaci dotazů)
Který model by podle vás vyhrál bitvu latence?
Odpověď
Začněme s vaším dotazem : Hive implementuje podmnožinu jazyka SQL – Hive Language ( LanguageManual – Apache Hive – Apache Software Foundation ), který je specifický pro schopnosti Hives a Hadoop. Váš odeslaný dotaz je rozdělen na části, predikáty, které lze implementovat v operacích nebo fázích. SELECT col1 , col2 , … coln určuje, které sloupce každého vráceného řádku budou zachovány a vráceny v sadě řešení. Podobně by se LEFT nebo RIGHT spojení implementovalo v konkrétním stavu, pravděpodobně ve fázi Map-Reduce (M\_R). Jakmile je váš dotaz rozdělen na části odpovídající konkrétním operacím, optimalizátor nákladů (CBO) používá shromážděné a uložené statistiky k inteligentnímu rozhodování o tom, jak bude každá z těchto fází provedena. Například klauzule WHERE může být implementována jako skenování tabulky, pokud není příliš konkrétní (nízká mohutnost) nebo pokud tabulka není rozdělena na oddíly, nebo by to mohlo mít za následek vyloučení oddílu, pokud je tabulka rozdělena a klauzule WHERE určuje sloupce oddílu s vysokou specificitou. Pokud dotaz určuje více spojení, každé spojení bude implementováno jako fáze Map-Reduce. Pokud je jedna ze spojovacích tabulek velmi malá, může být pro lepší výkon vybrán CBO pro provedení CBO.
Jakmile CBO stanoví plán provádění, jsou naplánovány a provedeny fáze, obvykle jako více stupňů MR. Můžete prozkoumat plán provádění, který by CBO použil k provedení jakéhokoli daného dotazu, a to spuštěním příkazu VYSVĚTLENÍ na dotaz.
Měl jsem klienta ve video průmyslu, který shromažďoval statistiky o zvycích svých uživatelů. Tyto statistiky byly shromážděny do jedné velmi velké tabulky (100 TiB), kterou si klient přál spojit s přibližně 20 relativně malými tabulkami, které obsahovaly údaje o každém videu, aktérech videa, zápletce každého videa, produkčních datech atd. Vytvořil jsem pohledy, které se postupně spojily s menšími tabulkami, které byly nakonec spojeny s prohlížecí tabulkou, do zobrazení výsledků, které bylo poté zapsáno do výstupní tabulky. Když jsem zadal jednoduchý dotaz pro výběr z pohledu výsledku do výstupní tabulky (CREATE TABLE output (…) AS SELECT * FROM results\_view) Hive vytvořil 25stupňový dotaz, který zhmotnil všechny mezilehlé pohledy do konečného pohledu, který byl poté napsán do výstupní tabulky. Protože každá fáze byla úkolem M-R (pro YARN) a čas instalace pro úkol M-R byl pro tento klastr zhruba 30 sekund, bylo v době instalace M-R stráveno přibližně 12–14 minut. Většina fází MR byla provedena za 5 sekund, z nichž 2/3 byl čas nastavení MR a 1/3 skutečného provedení. Konečné připojení mapy menších stolů k tabulce statistik diváka trvalo dalších 20 minut. Vytvoření svazku pohledů, které byly postupně spojeny do tabulky výsledků, mi umožnilo vytvořit kanál, který byl sestaven s hromadou relativně jednoduchých dotazů, spíše než se snažit vytvořit masivní dotaz, který by se pokusil spojit 20+ tabulek v jednom dotazu.