Beste antwoord
In elke mogelijke benchmark is Spark Sql ‘veel’ sneller dan Hive. Hoewel Facebook met Presto kwam – een goedkope kopie van het ontwerp van Spark onder de hoede van de bijenkorf en er is ook een nieuwere versie van de bijenkorf op Tez – wiens tegenslagen met DAGs hier goed worden gedocumenteerd Tragedie van Tez , maar in alle SQL-gerelateerde taken (bijv. Map side sqls => filter, data mutatie of verklein side Sqls => Sort / aggregate / Window functies), schittert Spark nog steeds.
Aangezien de vraag niet waarom vraagt, wil ik niet veel ingaan op die technische details. Maar om u een idee te geven, denk eens aan een gedistribueerd gegevensverwerkingsmodel waarbij elke taak de volledige gegevensset moet schrijven (met replicatie) die deze bevat voordat deze wordt voltooid, waarbij de toepassing het gebruik van bronnen niet zelf kan meten en waar de toepassing zich bevindt. de genade van de clustermanager bij het starten van de taak / uitvoeringsfase en vergelijk dat met een ander gedistribueerd gegevensverwerkingsmodel waar taken het grootste deel van de tijd in het geheugen kunnen leven, waar middelen intelligent kunnen worden toegewezen door de motor en waar het raamwerk kan zitten aan de top van een clustermanager en is voor niets afhankelijk van de clustermanager – behalve containertoewijzing (en een klein beetje de / serialisering die zelfs kan worden omzeild)
(en om het kort te houden, niet vermeld zelfs dat Spark 1.6 / 2.x het spel opvoert met Tungsten of simd implementatie voor query-optimalisatie)
Welk model zou volgens jou de strijd om latentie winnen?
Antwoord
Laten we beginnen met uw vraag : Hive implementeert een subset van SQL – de Hive-taal ( LanguageManual – Apache Hive – Apache Software Foundation ) die specifiek is voor de mogelijkheden van Hive en Hadoop. Uw ingediende zoekopdracht is onderverdeeld in stukjes, predikaten, die in bewerkingen of fasen kunnen worden geïmplementeerd. De SELECT col1 , col2 ,… coln specificeert welke kolommen van elke geretourneerde rij zullen worden behouden en geretourneerd in de oplossingsset. Evenzo zou een LINKS- of RECHTS-join worden geïmplementeerd in een specifieke staat, waarschijnlijk een Map-Reduce (M\_R) -fase. Zodra uw zoekopdracht is opgesplitst in onderdelen die overeenkomen met specifieke bewerkingen, gebruikt de Cost-Based Optimizer (CBO) verzamelde en opgeslagen statistieken om intelligente beslissingen te nemen over hoe elk van die fasen zal worden uitgevoerd. Een WHERE-clausule kan bijvoorbeeld worden geïmplementeerd als een tabelscan, als deze niet erg specifiek is (lage kardinaliteit) of als een tabel niet is gepartitioneerd, of het kan resulteren in eliminatie van partities als de tabel is gepartitioneerd en de WHERE-component partitiekolommen specificeert met hoge specificiteit. Als een query meerdere joins specificeert, wordt elke join geïmplementeerd als een Map-Reduce-fase. Als een van de join-tafels erg klein is, kan een Map-Join worden geselecteerd voor uitvoering door de CBO voor betere prestaties.
Zodra de CBO een uitvoeringsplan heeft opgesteld, worden de fasen gepland en uitgevoerd, meestal als meerdere MR-stadia. Je kunt het uitvoeringsplan bekijken dat de CBO zou gebruiken om een bepaalde zoekopdracht uit te voeren door een EXPLAIN op de zoekopdracht uit te voeren.
Ik had een klant in de video-industrie die statistieken verzamelde over de kijkgewoonten van zijn gebruikers. Die statistieken werden verzameld in een zeer grote tabel (honderden TiB) die de klant wenste samen te voegen met ongeveer 20 relatief kleine tabellen die gegevens bevatten over elke video, de acteurs in de video, de plot van elke video, de productiegegevens, enz. Ik creëerde views die achtereenvolgens aansloten bij de kleinere tabellen die uiteindelijk met de viewtafel werden samengevoegd tot een resultaatweergave, die vervolgens in een uitvoertabel werd geschreven. Toen ik een eenvoudige vraag instuurde om te selecteren uit de resultatenweergave in de uitvoertabel (CREATE TABLE output (…) AS SELECT * FROM results\_view), creëerde Hive een 25-traps query die alle tussenliggende weergaven materialiseerde in de uiteindelijke weergave die vervolgens werd geschreven naar de uitvoertabel. Aangezien elke fase een MR-taak was (voor YARN) en de insteltijd voor een MR-taak ongeveer 30 seconden bedroeg voor dat cluster, werden er ongeveer 12–14 minuten besteed aan de insteltijd van MR. De meeste MR-fasen werden uitgevoerd in 5 seconden, waarvan 2/3 de M-R-insteltijd was en 1/3 de daadwerkelijke uitvoering. De laatste kaartverbinding van de kleinere tafels met de tafel met kijkerstatistieken duurde nog eens 20 minuten. Door een aantal views te maken die achtereenvolgens in een resultatentabel werden samengevoegd, kon ik een pijplijn maken die was samengesteld met een aantal relatief eenvoudige querys, in plaats van te proberen een enorme query te maken die zou proberen om 20+ tabellen in één query samen te voegen.