Cel mai bun răspuns
În orice posibil punct de referință Spark Sql este „mult” mai rapid decât Hive. Deși Facebook a venit cu Presto – o copie ieftină a design-ului lui Spark pus sub capota stupului și există, de asemenea, o versiune mai nouă a stupului pe Tez – a cărui nefericire cu DAG-uri este bine documentată aici Tragedia lui Tez , dar în toate sarcinile legate de SQL (de exemplu, partea Harta sqls => filtru, mutația datelor sau reducerea Sqls laterale => Sortare / agregare / funcții Window), Spark încă strălucește puternic.
Deoarece întrebarea nu pune „De ce”, nu aș intra prea mult în aceste detalii tehnice. Dar, doar pentru a vă da un sens, gândiți-vă la un model de prelucrare a datelor distribuit în care fiecare sarcină trebuie să scrie întregul set de date (cu replicare) pe care îl deține înainte de finalizare, în care aplicația nu este capabilă să evalueze utilizarea resurselor singură și unde se află aplicația mila managerului de cluster în lansarea sarcinii / stadiului de execuție și comparați-o cu un alt model de procesare a datelor distribuite în care sarcinile pot trăi în memorie de cele mai multe ori, unde resursa poate fi alocată inteligent de către motor și unde cadrul poate sta în partea de sus a unui manager de cluster și depinde de managerul de cluster pentru nimic – în afară de alocarea containerelor (și puțin de De / Serializare care chiar poate fi ocolită)
(și pentru a fi scurt, nu menționează chiar Spark 1.6 / 2.x intensificarea jocului cu implementarea Tungsten sau simd pentru optimizarea interogărilor)
Ce model crezi că ar câștiga bătălia latenței?
Răspuns
Să începem cu interogarea dvs. : Hive implementează un subset de SQL – Limbajul Hive ( LanguageManual – Apache Hive – Apache Software Foundation ) care este specific capacităților Hive și Hadoop. Interogarea dvs. trimisă este împărțită în bucăți, predicate, care sunt implementabile în operațiuni sau etape. SELECT col1 , col2 , … coln specifică ce coloane din fiecare rând returnat vor fi păstrate și returnate în setul de soluții. La fel, o asociere STÂNGA sau DREAPTA ar fi implementată într-o stare specifică, probabil o etapă Map-Reduce (M\_R). Odată ce interogarea dvs. a fost separată în piese care se potrivesc cu operațiuni specifice, Optimizatorul bazat pe costuri (CBO) utilizează statistici colectate și stocate pentru a lua decizii inteligente cu privire la modul în care vor fi executate fiecare dintre aceste etape. De exemplu, o clauză WHERE poate fi implementată ca o scanare a tabelelor, dacă nu este foarte specifică (cardinalitate redusă) sau dacă o tabelă nu este partiționată sau poate duce la eliminarea partiției dacă tabela este partiționată și clauza WHERE specifică coloanele partiției cu specificitate ridicată. Dacă o interogare specifică mai multe asocieri, fiecare asociere va fi implementată ca etapă Map-Reduce. Dacă unul dintre tabelele de asociere este foarte mic, o asociere cu hărți poate fi selectată pentru executare de către OBC pentru o performanță mai bună.
Odată ce OCB stabilește un plan de execuție, etapele sunt programate și executate, de obicei ca etape multiple de MR. Puteți examina planul de execuție pe care CBO l-ar folosi pentru a executa orice interogare dată executând un EXPLAIN pentru interogare.
Am avut un client din industria video care a adunat statistici privind obiceiurile de vizualizare ale utilizatorilor săi. Aceste statistici au fost adunate într-un tabel foarte mare (100 de TiB) pe care clientul și-a dorit să îl alăture cu aproximativ 20 de tabele relativ mici care conțin date despre fiecare videoclip, actorii din videoclip, complotul fiecărui videoclip, datele de producție etc. Am creat vizualizări care s-au alăturat succesiv tabelelor mai mici, care au fost în cele din urmă alăturate cu tabelul de vizualizare la o vizualizare a rezultatului, care a fost apoi scrisă într-un tabel de ieșire. Când am trimis o interogare simplă pentru a selecta din vizualizarea rezultatului în tabelul de ieșire (ieșirea CREATE TABLE (…) AS SELECT * FROM results\_view) Hive a creat o interogare în 25 de etape care a materializat toate vizualizările intermediare în vizualizarea finală care a fost apoi scrisă la tabelul de ieșire. Deoarece fiecare etapă a fost o lucrare M-R (pentru YARN) și timpul de configurare pentru o lucrare M-R a fost de aproximativ 30 de secunde pentru acel cluster, s-au petrecut aproximativ 12-14 minute în timpul de configurare M-R. Majoritatea etapelor M-R executate în 5 secunde, dintre care 2/3 au reprezentat timpul de configurare M-R și 1/3 executarea efectivă. Unirea finală a hărții tabelelor mai mici cu tabelul cu statistici al vizualizatorului a durat încă 20 de minute. Crearea unei grămezi de vizualizări care s-au alăturat succesiv într-un tabel de rezultate mi-a permis să creez o conductă care a fost asamblată cu o grămadă de interogări relativ simple, mai degrabă decât să încerc să creez o interogare masivă care să încerce să alăture peste 20 de tabele într-o singură interogare.