Bedste svar
I ethvert muligt benchmark er Spark Sql meget hurtigere end Hive. Selvom Facebook kom med Presto – en billig kopi af Sparks design lagt under bikubens hætte, og der også er en nyere version af bikube på Tez – hvis misadventure med DAGer er veldokumenteret her The Tragedie af Tez , men i alle SQL-relaterede opgaver (f.eks. Map side sqls => filter, datamutation eller reducer side Sqls => Sorter / samlet / Window-funktioner), lyser gnist stadig lyst.
Da spørgsmålet ikke spørger Hvorfor, vil jeg ikke gå meget ind på disse tekniske detaljer. Men bare for at give dig en fornemmelse, tænk på en distribueret databehandlingsmodel, hvor hver opgave skal skrive hele datasættet (med replikering), det holder, inden det er afsluttet, hvor applikationen ikke er i stand til at måle ressourceudnyttelsen alene, og hvor applikationen er på klyngestyringens nåde ved at starte opgave / udførelsesfase og sammenligne det med en anden distribueret databehandlingsmodel, hvor opgaver kan leve i hukommelsen det meste af tiden, hvor ressourcen kan tildeles intelligent af motoren, og hvor rammen kan sidde øverst i en klyngemanager og afhænger ikke af klyngemanageren for intet – andet end containerallokering (og lidt De / Serialization, som endda kan omgåes)
(og for at holde det kort, gjorde det ikke endda nævne Spark 1.6 / 2.xs intensivering af spillet med Wolfram eller simd-implementering til optimering af forespørgsler)
Hvilken model tror du ville vinde kampen om latenstid?
Svar
Lad os starte med din forespørgsel : Hive implementerer et undersæt af SQL – Hive Language ( LanguageManual – Apache Hive – Apache Software Foundation ), der er specifikt for Hives og Hadoops muligheder. Din indsendte forespørgsel er opdelt i stykker, prædikater, der kan implementeres i operationer eller faser. VÆLG col1 , col2 ,… coln angiver, hvilke kolonner i hver returneret række, der bevares og returneres i løsningssættet. Ligeledes ville en VENSTRE eller HØJRE sammenføjning blive implementeret i en bestemt tilstand, sandsynligvis et M-R-trin (Map-Reduce). Når din forespørgsel er blevet adskilt i de stykker, der matcher specifikke operationer, bruger Cost-Based Optimizer (CBO) indsamlede og lagrede statistikker til at træffe intelligente beslutninger om, hvordan hvert af disse trin skal udføres. For eksempel kan en WHERE-klausul implementeres som en tabellscanning, hvis den ikke er særlig specifik (lav kardinalitet) eller hvis en tabel ikke er opdelt, eller det kan resultere i partitioneliminering, hvis tabellen er partitioneret, og WHERE-klausulen specificerer partitionskolonner med høj specificitet. Hvis en forespørgsel angiver flere sammenføjninger, implementeres hver sammenføjning som et kort-reducer-trin. Hvis en af sammenføjningstabellerne er meget lille, kan en Map-sammenkædning vælges til udførelse af CBO for bedre ydeevne.
Når CBO har udarbejdet en udførelsesplan, planlægges og udføres stadierne, typisk som flere MR-faser. Du kan undersøge den udførelsesplan, som CBO ville bruge til at udføre en given forespørgsel ved at køre en FORKLARING på forespørgslen.
Jeg havde en klient i videoindustrien, der samlede statistikker om brugernes synsvaner. Disse statistikker blev samlet i en meget stor tabel (100ere TiB), som klienten ønskede sluttede sig til omkring 20 relativt små tabeller, der indeholdt data om hver video, skuespillerne i videoen, plot af hver video, produktionsdata osv. Jeg oprettede visninger, der successivt sluttede sig til de mindre tabeller, som endelig blev forbundet med visningstabellen til en resultatvisning, som derefter blev skrevet i en outputtabel. Da jeg sendte en simpel forespørgsel for at vælge fra resultatvisningen til outputtabellen (CREATE TABLE output (…) AS SELECT * FROM results\_view) oprettede Hive en 25-trins forespørgsel, der materialiserede alle de mellemliggende visninger i den endelige visning, som derefter blev skrevet til output-tabellen. Da hvert trin var et M-R-job (for YARN), og opsætningstiden for et M-R-job var ca. 30 sekunder for denne klynge, blev der brugt cirka 12-14 minutter på M-R-opsætningstid. De fleste af M-R-stadierne blev udført på 5 sekunder, hvoraf 2/3 var M-R-opsætningstid og 1/3 den faktiske udførelse. Den endelige korttilslutning af de mindre tabeller til seerstatistabellen tog yderligere 20 minutter. Oprettelse af en flok visninger, der successivt blev sammenføjet i en resultattabel, tillod mig at oprette en pipeline, der blev samlet med en masse relativt enkle forespørgsler, snarere end at forsøge at oprette en massiv forespørgsel, der ville forsøge at deltage i 20+ tabeller i en forespørgsel.