Migliore risposta
In ogni possibile benchmark Spark Sql è “molto” più veloce di Hive. Sebbene Facebook abbia inventato Presto, una copia economica del design di Spark messa sotto il cofano di hive e cè anche una versione più recente di hive su Tez, le cui disavventure con i DAG sono ben documentate qui Tragedia di Tez , ma in tutte le attività correlate a SQL (ad es. Map side sqls => filter, data mutazione o reduce side Sqls => Sort / aggregate / Window functions), Spark brilla ancora.
Poiché la domanda non chiede “Perché”, non mi addentrerei molto in questi dettagli tecnici. Ma solo per darti un senso, pensa a un modello di elaborazione dati distribuito in cui ogni attività deve scrivere lintero set di dati (con replica) che contiene prima del completamento, in cui lapplicazione non è in grado di valutare lutilizzo delle risorse da sola e dove si trova lapplicazione la misericordia del gestore del cluster nel lanciare lattività / fase di esecuzione e confrontarla con un altro modello di elaborazione dati distribuita in cui le attività possono vivere in memoria per la maggior parte del tempo, dove le risorse possono essere allocate in modo intelligente dal motore e dove può essere posizionato il framework allinizio di un gestore di cluster e non dipende dal gestore di cluster per niente – a parte lallocazione del contenitore (e un po di de / serializzazione che può anche essere aggirato)
(e per mantenerlo breve, non lha fatto menziona anche il fatto che Spark 1.6 / 2.x sta intensificando il gioco con limplementazione di Tungsten o simd per lottimizzazione delle query)
Quale modello pensi vincerebbe la battaglia della latenza?
Risposta
Cominciamo con la tua query : Hive implementa un sottoinsieme di SQL, il linguaggio Hive ( LanguageManual – Apache Hive – Apache Software Foundation ) specifico per le capacità di Hive e Hadoop. La query inviata viene suddivisa in parti, predicati, implementabili in operazioni o fasi. SELEZIONA col1 , col2 ,… coln specifica quali colonne di ogni riga restituita verranno mantenute e restituite nel set di soluzioni. Allo stesso modo, un join LEFT o RIGHT verrebbe implementato in uno stato specifico, probabilmente una fase Map-Reduce (M\_R). Una volta che la tua query è stata separata nelle parti corrispondenti a operazioni specifiche, il Cost-Based Optimizer (CBO) utilizza le statistiche raccolte e memorizzate per prendere decisioni intelligenti su come ciascuna di queste fasi verrà eseguita. Ad esempio, una clausola WHERE può essere implementata come scansione di una tabella, se non è molto specifica (bassa cardinalità) o se una tabella non è partizionata, oppure potrebbe comportare leliminazione della partizione se la tabella è partizionata e la clausola WHERE specifica le colonne della partizione con alta specificità. Se una query specifica più join, ogni join verrà implementato come una fase di riduzione della mappa. Se una delle tabelle di join è molto piccola, un Map-Join può essere selezionato per lesecuzione da parte del CBO per prestazioni migliori.
Una volta che il CBO ha definito un piano di esecuzione, le fasi vengono pianificate ed eseguite, in genere come più stadi di RM. Puoi esaminare il piano di esecuzione che il CBO avrebbe utilizzato per eseguire una determinata query eseguendo un EXPLAIN sulla query.
Avevo un cliente nel settore video che raccoglieva statistiche sulle abitudini di visualizzazione dei suoi utenti. Queste statistiche sono state raccolte in una tabella molto grande (100 di TiB) che il cliente desiderava unisse a circa 20 tabelle relativamente piccole che contenevano dati su ogni video, gli attori nel video, la trama di ogni video, i dati di produzione, ecc. Ho creato viste che successivamente univano le tabelle più piccole che sono state infine unite alla tabella di visualizzazione in una visualizzazione dei risultati, che è stata quindi scritta in una tabella di output. Quando ho inviato una semplice query per selezionare dalla vista dei risultati nella tabella di output (CREATE TABLE output (…) AS SELECT * FROM results\_view) Hive ha creato una query in 25 fasi che ha materializzato tutte le viste intermedie nella vista finale che è stata poi scritta alla tabella di output. Poiché ogni fase era un lavoro M-R (per YARN) e il tempo di configurazione per un lavoro M-R era di circa 30 secondi per quel cluster, sono stati spesi circa 12-14 minuti nel tempo di configurazione M-R. La maggior parte delle fasi M-R sono state eseguite in meno di 45 secondi, 2/3 dei quali erano il tempo di setup M-R e 1/3 delleffettiva esecuzione. Lunione finale della mappa dei tavoli più piccoli alla tabella delle statistiche del visualizzatore ha richiesto altri 20 minuti. La creazione di un gruppo di viste che sono state successivamente unite in una tabella dei risultati mi ha permesso di creare una pipeline che è stata assemblata con un gruppo di query relativamente semplici, piuttosto che provare a creare una query massiccia che avrebbe provato a unire più di 20 tabelle in una query.