Bästa svaret
I alla möjliga riktmärken är Spark Sql ”mycket” snabbare än Hive. Även om Facebook kom med Presto – en billig kopia av Sparks design som placerades under bikupans huva och det finns också en nyare version av bikupan på Tez – vars missupplevelse med DAG är väl dokumenterade här The Tragedy of Tez , men i alla SQL-relaterade uppgifter (t.ex. Map side sqls => filter, datamutation eller reducera sid-SQL => Sortera / aggregera / Window-funktioner), lyser fortfarande Spark.
Eftersom frågan inte ställer ”Varför”, skulle jag inte gå mycket in på dessa tekniska detaljer. Men bara för att ge dig en känsla, tänk på en distribuerad databehandlingsmodell där varje uppgift behöver skriva hela datamängden (med replikering) som den har innan den är klar, där applikationen inte kan mäta resursanvändningen på egen hand och där applikationen är klusterhanterarens barmhärtighet vid att starta uppgift / exekveringsstadium och jämföra det med en annan distribuerad databehandlingsmodell där uppgifter kan leva i minnet för det mesta, där resurser kan tilldelas intelligent av motorn och där ramverket kan sitta högst upp i en klusterhanterare och beror på klusterhanteraren för ingenting – förutom behållartilldelning (och lite De / Serialization som till och med kan kringgå)
(och för att hålla det kort, gjorde det inte till och med nämna Spark 1.6 / 2.x: s förstärkning av spelet med Tungsten eller simd-implementering för frågeoptimering)
Vilken modell tror du skulle vinna slaget vid latens?
Svar
Låt oss börja med din fråga : Hive implementerar en delmängd av SQL – Hive Language ( LanguageManual – Apache Hive – Apache Software Foundation ) som är specifik för Hives och Hadoops kapacitet. Din skickade fråga är uppdelad i bitar, predikat, som kan implementeras i operationer eller steg. VÄLJ col1 , col2 ,… coln anger vilka kolumner i varje returnerad rad som ska sparas och returneras i lösningsuppsättningen. På samma sätt skulle en VÄNSTER- eller HÖGER-koppling implementeras i ett specifikt tillstånd, troligen ett M-R-steg (Map-Reduce). När din fråga har delats in i bitar som matchar specifika operationer använder Cost-Based Optimizer (CBO) samlad och lagrad statistik för att fatta intelligenta beslut om hur vart och ett av dessa steg ska utföras. Till exempel kan en WHERE-sats implementeras som en tabellavsökning, om den inte är särskilt specifik (låg kardinalitet) eller om en tabell inte är partitionerad, eller det kan resultera i partition eliminering om tabellen är partitionerad och WHERE-satsen specificerar partitionskolumner med hög specificitet. Om en fråga anger flera sammanfogningar, kommer varje koppling att implementeras som ett Map-Reduce-steg. Om en av kopplingstabellerna är väldigt liten kan en Map-Join väljas för körning av CBO för bättre prestanda.
När CBO har lagt fram en exekveringsplan planeras och genomförs stegen, vanligtvis som flera MR-steg. Du kan undersöka den exekveringsplan som CBO skulle använda för att utföra en viss fråga genom att köra en EXPLAIN på frågan.
Jag hade en klient i videobranschen som samlade statistik om användarnas visningsvanor. Denna statistik samlades in i en mycket stor tabell (100-talet TiB) som kunden önskade förenade med cirka 20 relativt små tabeller som innehöll data om varje video, skådespelarna i videon, plot för varje video, produktionsdata etc. Jag skapade vyer som successivt gick med i de mindre tabellerna som slutligen förenades med visningstabellen till en resultatvy, som sedan skrevs in i en utdatatabell. När jag skickade en enkel fråga för att välja från resultatvyn i utgångstabellen (CREATE TABLE output (…) AS SELECT * FROM results\_view) Hive skapade en 25-stegs fråga som materialiserade alla mellanliggande vyer till den slutliga vyn som sedan skrevs till utgångstabellen. Eftersom varje steg var ett M-R-jobb (för YARN) och installationstiden för ett M-R-jobb var ungefär 30 sekunder för det klustret, spenderades cirka 12–14 minuter i M-R-installationstiden. De flesta av M-R-stegen utfördes på 5 sekunder, varav 2/3 var M-R-inställningstid och 1/3 den faktiska körningen. Den sista kartanslutningen av de mindre tabellerna till tabellen för tittarstatistik tog ytterligare 20 minuter. Att skapa en massa vyer som successivt sammanfogades i en resultattabell gjorde det möjligt för mig att skapa en pipeline som samlades med en massa relativt enkla frågor, snarare än att försöka skapa en massiv fråga som skulle försöka gå med i 20+ tabeller i en fråga.