Hive Tutorial - Hive Architecture en NASA Case Study

Apache Hive-zelfstudie: inleiding

Hive is een rigoureus door de hele industrie gebruikte tool voor Big Data Analytics en een geweldige tool om uw met. In deze Hive-tutorialblog zullen we uitgebreid ingaan op Apache Hive. Apache Hive is een datawarehousing-tool in de , dat een SQL-achtige taal biedt voor het opvragen en analyseren van Big Data. De drijfveer achter de ontwikkeling van Hive is het wrijvingsloze leertraject voor SQL-ontwikkelaars & analisten. Hive is niet alleen een redder voor mensen met een niet-programmerende achtergrond, maar het vermindert ook het werk van programmeurs die lange uren besteden aan het schrijven van MapReduce-programma's. In deze Apache Hive Tutorial-blog zal ik het hebben over:

• Wat is Hive?
• Verhaal van Apache Hive - van Facebook tot Apache
• Voordelen van Apache Hive
• Apache Hive - NASA-casestudy
• Apache Hive-architectuur
• Metastore-configuratie
• Hive-gegevensmodel

Apache Hive-zelfstudie: wat is Hive?

Apache Hive is een datawarehouse-systeem dat bovenop Hadoop is gebouwd en wordt gebruikt voor het analyseren van gestructureerde en semi-gestructureerde gegevens.Hive vat de complexiteit van Hadoop MapReduce samen. In feite biedt het een mechanisme om structuur op de gegevens te projecteren en query's uit te voeren die zijn geschreven in HQL (Hive Query Language) die vergelijkbaar zijn met SQL-instructies. Intern worden deze query's of HQL geconverteerd om het aantal banen door de Hive-compiler in kaart te brengen. Daarom hoeft u zich geen zorgen te maken over het schrijven van complexe MapReduce-programma's om uw gegevens met Hadoop te verwerken. Het is bedoeld voor gebruikers die vertrouwd zijn met SQL. Apache Hive ondersteunt Data Definition Language (DDL), Data Manipulation Language (DML) en User Defined Functions (UDF).

Hive-zelfstudie voor beginners | Hive In Depth begrijpen | Edureka

SQL + Hadoop MapReduce = HiveQL

Apache Hive-zelfstudie: Story of Hive - van Facebook tot Apache

Afb : Hive Tutorial - Facebook-gebruiksscenario

Uitdagingen bij Facebook: exponentiële groei van gegevens

Vóór 2008 was alle gegevensverwerkingsinfrastructuur op Facebook gebouwd rond een datawarehouse op basis van commerciële RDBMS. Deze infrastructuren waren capabel genoeg om op dat moment in de behoeften van Facebook te voorzien. Maar aangezien de gegevens erg snel begonnen te groeien, werd het een enorme uitdaging om deze enorme gegevensset te beheren en te verwerken. Volgens een Facebook-artikel zijn de gegevens opgeschaald van een gegevensset van 15 TB in 2007 naar gegevens van 2 PB in 2009. Ook bevatten veel Facebook-producten analyse van de gegevens, zoals Audience Insights, Facebook Lexicon, Facebook-advertenties, enz. had een schaalbare en economische oplossing nodig om dit probleem op te lossen en begon daarom het Hadoop-framework te gebruiken.

Democratiserend Hadoop - MapReduce

Maar naarmate de gegevens toenamen, groeide de complexiteit van Map-Reduce-codes evenredig. Het werd dus moeilijk om mensen met een niet-programmeerachtergrond te trainen om MapReduce-programma's te schrijven. Voor het uitvoeren van een eenvoudige analyse moet men ook honderd regels MapReduce-code schrijven. Omdat SQL veel werd gebruikt door ingenieurs en analisten, waaronder Facebook, leek het daarom een ​​logische manier om SQL bovenop Hadoop te plaatsen om Hadoop toegankelijk te maken voor gebruikers met een SQL-achtergrond.

Vandaar dat het vermogen van SQL om te voldoen aan de meeste analytische vereisten en de schaalbaarheid van Hadoop leidde tot Apache Hive waarmee SQL-achtige query's kunnen worden uitgevoerd op de gegevens die aanwezig zijn in HDFS. Later werd het Hive-project in augustus 2008 open source door Facebook en is het vandaag gratis beschikbaar als Apache Hive.

Laten we nu eens kijken naar de kenmerken of voordelen van Hive die het zo populair maken.

Apache Hive-zelfstudie: voordelen van Hive

• Handig voor mensen die geen programmeerachtergrond hebben, omdat het de noodzaak om een ​​complex MapReduce-programma te schrijven overbodig maakt.
• Uitbreidbaar en schaalbaar om het hoofd te kunnen bieden aan het groeiende volume en de verscheidenheid aan gegevens, zonder de prestaties van het systeem te beïnvloeden.
• Het is als een efficiënte ETL-tool (Extract, Transform, Load).
• Hive ondersteunt elke clienttoepassing die is geschreven in Java, PHP, Python, C ++ of Ruby door zijn Thrift-server . (U kunt deze client-side talen gebruiken die zijn ingesloten met SQL voor toegang tot een database zoals DB2, enz.).
• Omdat de metadata-informatie van Hive wordt opgeslagen in een RDBMS, wordt de tijd voor het uitvoeren van semantische controles tijdens het uitvoeren van query's aanzienlijk verkort.

Apache Hive-zelfstudie: waar gebruik je Apache Hive?

Apache Hive maakt gebruik van beide werelden, d.w.z. SQL Database System en kader. Daarom wordt het gebruikt door een groot aantal bedrijven. Het wordt meestal gebruikt voor datawarehousing, waar u analyses en datamining kunt uitvoeren waarvoor geen realtime verwerking nodig is. Enkele van de velden waarin u Apache Hive kunt gebruiken, zijn als volgt:

• Data opslagplaats
• Ad-hoc analyse

Zoals gezegd, je kunt niet met één hand klappen, d.w.z. je kunt niet elk probleem met één stuk gereedschap oplossen. Daarom kunt u Hive aan andere tools koppelen om het in veel andere domeinen te gebruiken. Tableau kan bijvoorbeeld samen met Apache Hive worden gebruikt voor datavisualisatie, Apache Tez-integratie met Hive biedt u realtime verwerkingsmogelijkheden, enz.
Laten we verder gaan in deze Apache Hive Tutorial-blog, laten we eens kijken naar een casestudy van NASA, waar u zult ontdekken hoe Hive het probleem oploste waarmee NASA-wetenschappers werden geconfronteerd tijdens het evalueren van klimaatmodellen.

Hive-zelfstudie: NASA-casestudy

Een klimaatmodel is een wiskundige weergave van klimaatsystemen op basis van verschillende factoren die van invloed zijn op het klimaat op aarde. Kortom, het beschrijft de interactie van verschillende factoren van het klimaat, zoals oceaan, zon, atmosfeer, enzinzicht geven in de dynamiek van het klimaatsysteem. Het wordt gebruikt om klimaatomstandigheden te projecteren door de klimaatveranderingen te simuleren op basis van factoren die het klimaat beïnvloeden. Het Jet Propulsion Laboratory van NASA heeft een Regional Climate Model Evaluation System (RCMES) ontwikkeld voor analyse en evaluatie van het klimaatoutputmodel aan de hand van teledetectiegegevens die aanwezig zijn in verschillende externe opslagplaatsen.

Het RCMES (Regional Climate Model Evaluation System) bestaat uit twee componenten:

• RCMED (Regional Climate Model Evaluation Database):

Het is een schaalbare clouddatabase die de teledetectiegegevens en heranalysegegevens laadt die verband houden met het klimaat met behulp van extractors zoals Apache OODT-extractors, Apache Tika, enz. Ten slotte transformeert het de gegevens als het datapuntmodel dat de vorm heeft (breedtegraad , lengtegraad, tijd, waarde, hoogte) en slaat het op in Mijn SQL-database. De klant kan de in RCMED aanwezige gegevens ophalen door ruimte / tijd-queries uit te voeren. De beschrijving van dergelijke vragen is momenteel niet relevant voor ons.

• RCMET (Regional Climate Model Evaluation Toolkit):

Het biedt de gebruiker de mogelijkheid om de referentiegegevens die aanwezig zijn in de RCMED te vergelijken met de uitvoergegevens van het klimaatmodel die zijn opgehaald uit andere bronnen om verschillende soorten analyses en evaluaties uit te voeren. U kunt de onderstaande afbeelding raadplegen om de architectuur van RCMES te begrijpen.

spring in c ++

De referentiegegevens in de RCMED zijn afkomstig van op satelliet gebaseerde teledetectie, volgens de verschillende parameters die nodig zijn voor de evaluatie van klimaatmodellen. AIRS (Atmospheric Infrared Sounder) biedt bijvoorbeeld parameters zoals oppervlaktetemperatuur, temperatuur en geopotentieel, TRMM (Tropical Rainfall Measurement Mission) zorgt voor maandelijkse neerslag, enz.

Problemen waarmee NASA wordt geconfronteerd bij het gebruik van het MySQL-databasesysteem:

• Na het laden van de MySQL-database met 6 miljard tuples van het formulier (breedtegraad, lengtegraad, tijd, gegevenspuntwaarde, hoogte), crashte het systeem zoals weergegeven in de afbeelding hierboven.
• Zelfs nadat de hele tabel in kleinere subsets was verdeeld, genereerde het systeem enorme overhead tijdens het verwerken van de gegevens.

Ze hadden dus een schaalbare oplossing nodig die deze enorme hoeveelheid gegevens kan opslaan en verwerken met SQL-achtige querymogelijkheden. Ten slotte besloten ze Apache Hive te gebruiken om de hierboven genoemde problemen op te lossen.

Hoe Apache Hive het probleem kan oplossen?

Laten we nu eens kijken wat de kenmerken zijn die het JPL-team van NASA hebben overtuigd om Apache Hive als een integraal onderdeel in hun oplossingsstrategie op te nemen:

• Omdat Apache Hive bovenop Hadoop draait, is het schaalbaar en kan het gegevens op een gedistribueerde en parallelle manier verwerken.
• Het biedt Hive Query Language die vergelijkbaar is met SQL en daarom gemakkelijk te leren is.

Inzet van Hive:

In de volgende afbeelding wordt de RCMES-architect met Apache Hive-integratie uitgelegd:

Afb : Hive-zelfstudie - RCMES-architectuur met Apache Hive

De bovenstaande afbeelding toont de implementatie van apache-hive in RCMES. De volgende stappen zijn genomen door het NASA-team tijdens de implementatie van Apache Hive:

• Ze installeerden Hive met Cloudera en Apache Hadoop zoals weergegeven in de bovenstaande afbeelding.
• Ze gebruikten Apache Sqoop om gegevens op te nemen in de Hive vanuit de MySQL-database.
• Apache OODT-wrapper is geïmplementeerd om query's op Hive uit te voeren en de gegevens terug te halen naar RCMET.

Eerste benchmark-observaties met Hive:

• Aanvankelijk laadden ze 2,5 miljard datapunten in een enkele tabel en voerden ze een telquery uit. Bijvoorbeeld, Bijenkorf> selecteer count (datapoint_id) van dataPoint. Het kostte 5-6 minuten om alle records te tellen (15–17 minuten voor de volledige 6,8 miljard records).
• De verkleiningsfase was snel, maar de kaartfase nam 95% van de totale verwerkingstijd in beslag. Ze gebruikten zes ( 4x quad-core ) systemen met 24 GB RAM (ongeveer) in elk van de systemen.
• Zelfs na het toevoegen van meer machines, het wijzigen van de HDFS-blokgrootte (64 MB, 128 MB, 256 MB) en het wijzigen van vele andere configuratievariabelen (io.soort.factor, ik.soort.mb), hadden ze niet veel succes bij het verkorten van de tijd om de telling te voltooien.

Invoer van leden van de Hive-community:

Ten slotte kwamen leden van de Hive-gemeenschap te hulp en verschaften ze verschillende inzichten om de problemen met hun huidige Hive-implementaties op te lossen:

• Ze zeiden dat de leessnelheid van HDFS ongeveer is 60 MB / s in vergelijking met 1 GB / s in het geval van een lokale schijf, afhankelijk van de netwerkcapaciteit en de werkbelasting op NameNode.
• De leden stelden dat voor 16 kaartenmakers zullen in hun huidige systeem vereist zijn om te matchen met de I / O-prestaties van een lokale niet-Hadoop-taak.
• Ze stelden ook voor om de split-maat voor elke mapper om het aantal te verhogenvanmappers en daardoor voor meer parallellisme.
• Ten slotte vertelden de gemeenschapsleden hen dat te doen gebruik tellen (1) in plaats van te verwijzen naar tellen ( datapunt_id) . Dit komt doordat in het geval van telling (1) er geen referentiekolom is en daarom vindt er geen decompressie en deserialisatie plaats tijdens het tellen.

Ten slotte was NASA in staat om hun Hive-cluster af te stemmen op hun verwachtingen door rekening te houden met alle suggesties van de Hive-communityleden. En daarom konden ze miljarden rijen opvragen in slechts 15 seconden met behulp van de hierboven genoemde systeemconfiguraties.

Apache Hive-zelfstudie: Hive-architectuur en zijn componenten

De volgende afbeelding beschrijft de Hive-architectuur en de stroom waarin een query wordt ingediendBijenkorfen uiteindelijk verwerkt met behulp van het MapReduce-framework:

Afb : Hive-zelfstudie - Hive-architectuur

Zoals te zien is in de bovenstaande afbeelding, kan de Hive Architecture worden onderverdeeld in de volgende componenten:

• Hive-klanten: Hive ondersteunt applicaties die zijn geschreven in vele talen zoals Java, C ++, Python enz. Met behulp van JDBC-, Thrift- en ODBC-stuurprogramma's. Daarom kan men altijd een hive-clienttoepassing schrijven in een taal naar keuze.
• Bijenkorfdiensten: Apache Hive biedt verschillende services zoals CLI, webinterface enz. Om zoekopdrachten uit te voeren. We zullen ze allemaal kort verkennen in deze Hive-tutorialblog.
• Verwerkingskader en resourcebeheer: Intern,Hive gebruikt Hadoop MapReduce-framework als de facto-engine om de query's uit te voeren. is een apart onderwerp op zich en wordt daarom hier niet besproken.
• Gedistribueerde opslag: Omdat Hive bovenop Hadoop is geïnstalleerd, gebruikt het de onderliggende HDFS voor de gedistribueerde opslag. U kunt verwijzen naar de HDFS-blog om er meer over te leren.

Laten we nu de eerste twee hoofdcomponenten in de Hive Architecture verkennen:

1. Hive-klanten:

Apache Hive ondersteunt verschillende soorten clienttoepassingen voor het uitvoeren van query's op de Hive. Deze klanten kunnen worden onderverdeeld in drie typen:

• Thrift-klanten: Omdat de Hive-server is gebaseerd op Apache Thrift, kan deze het verzoek van al die programmeertalen uitvoeren die Thrift ondersteunen.
• JDBC-klanten: Met Hive kunnen Java-applicaties er verbinding mee maken met behulp van het JDBC-stuurprogramma dat is gedefinieerd in de klasseorganisatie.apache.hadoop.bijenkorf.jdbc.HiveDriver.
• ODBC-clients: Met het Hive ODBC-stuurprogramma kunnen toepassingen die het ODBC-protocol ondersteunen, verbinding maken met Hive. (Net als het JDBC-stuurprogramma gebruikt het ODBC-stuurprogramma Thrift om te communiceren met de Hive-server.)

2. Bijenkorfdiensten:

Hive biedt veel services zoals weergegeven in de bovenstaande afbeelding. Laten we ze allemaal eens bekijken:

• Hive CLI (opdrachtregelinterface): Dit is de standaardshell van de Hive, waar u uw Hive-query's en -opdrachten rechtstreeks kunt uitvoeren.
• Apache Hive-webinterfaces: Afgezien van de opdrachtregelinterface biedt Hive ook een webgebaseerde GUI voor het uitvoeren van Hive-query's en -opdrachten.
• Hive-server: De Hive-server is gebouwd op Apache Thrift en wordt daarom ook wel Thrift Server genoemd, waarmee verschillende clients verzoeken bij Hive kunnen indienen en het eindresultaat kunnen ophalen.
• Apache Hive-stuurprogramma: Het is verantwoordelijk voor het ontvangen van de vragen die door een klant zijn ingediend via de CLI, de web-UI, Thrift, ODBC of JDBC-interfaces. Vervolgens geeft de driver de query door aan de compiler waar het parseren, typecontrole en semantische analyse plaatsvindt met behulp van het schema dat aanwezig is in de metastore.. In de volgende stap wordt een geoptimaliseerd logisch plan gegenereerd in de vorm van een DAG (Directed Acyclic Graph) van kaartverminderende taken en HDFS-taken. Ten slotte voert de uitvoeringsengine deze taken uit in de volgorde van hun afhankelijkheden, met behulp van Hadoop.
• Metastore: Je kunt metastore denkenals een centrale opslagplaats voor het opslaan van alle Hive-metadata-informatie. Hive-metagegevens bevatten verschillende soorten informatie, zoals de structuur van tabellen en de partitiessamen met de kolom, het kolomtype, de serialisator en de deserialisator die vereist zijn voor lees- / schrijfbewerkingen op de gegevens die aanwezig zijn in HDFS. De metastorebestaat uit twee fundamentele eenheden:
  • Een service die metastore biedttoegang tot andererBijenkorfdiensten.
  • Schijfopslag voor de metadata die los staat van HDFS-opslag.

Laten we nu de verschillende manieren begrijpen om Hive-metastore te implementerenin de volgende sectie van deze Hive-zelfstudie.

Apache Hive-zelfstudie: Metastore-configuratie

Metastore slaat de metagegevensinformatie op met behulp van RDBMS en een open source ORM-laag (Object Relational Model) genaamd Data Nucleus, die de objectweergave omzet in een relationeel schema en vice versa. De reden om RDBMS te kiezen in plaats van HDFS is om een ​​lage latentie te bereiken. We kunnen metastore implementeren in de volgende drie configuraties:

1. Ingebouwde metastore:

Zowel de metastore-service als de Hive-service worden standaard in dezelfde JVM uitgevoerd met behulp van een ingebedde Derby Database-instantie waarbij metagegevens op de lokale schijf worden opgeslagen. Dit wordt een embedded metastore-configuratie genoemd. In dit geval kan slechts één gebruiker tegelijk verbinding maken met de metastore-database. Als u een tweede exemplaar van de Hive-driver start, krijgt u een foutmelding. Dit is goed voor het testen van eenheden, maar niet voor de praktische oplossingen.

2. Lokale metastore:

Deze configuratie stelt ons in staat om meerdere Hive-sessies te hebben, d.w.z. meerdere gebruikers kunnen de metastore-database tegelijkertijd gebruiken. Dit wordt bereikt door elke JDBC-compatibele database zoals MySQL te gebruiken die in een afzonderlijke JVM of een andere machine draait dan die van de Hive-service en metastore-service die in dezelfde JVM worden uitgevoerd zoals hierboven weergegeven. Over het algemeen is de meest populaire keuze om een ​​MySQL-server te implementeren als de metastore-database.

3. Metastore op afstand:

In de configuratie van de externe metastore draait de metastore-service op zijn eigen aparte JVM en niet in de Hive-service JVM. Andere processen communiceren met de metastore-server met behulp van Thrift Network API's. U kunt in dit geval een of meer metastore-servers hebben om meer beschikbaarheid te bieden.Het belangrijkste voordeel van het gebruik van externe metastore is dat u geen JDBC-inloggegevens met elke Hive-gebruiker hoeft te delen om toegang te krijgen tot de metastore-database.

Apache Hive-zelfstudie: gegevensmodel

Gegevens in Hive kunnen op granulair niveau worden onderverdeeld in drie typen:

• Tafel
• Partitie
• Emmer

Tabellen:

Tabellen in Hive zijn hetzelfde als de tabellen in een relationele database. U kunt er filter-, project-, join- en vakbondsbewerkingen op uitvoeren. Er zijn twee soorten tabellen in Hive:

1. Beheerde tabel:

Opdracht:

TABEL MAKEN (kolom1 gegevenstype, kolom2 gegevenstype)

LAAD GEGEVENS INPATH IN tabel managed_table

Zoals de naam doet vermoeden (beheerde tabel), is Hive verantwoordelijk voor het beheer van de gegevens van een beheerde tabel. Met andere woorden, wat ik bedoelde met te zeggen: 'Hive beheert de gegevens', is dat als je de gegevens van een bestand in HDFS laadt in een Hive Beheerde tabel en geef er een DROP-commando op, de tabel samen met zijn metadata zal worden verwijderd. Dus de gegevens die bij de drop managed_table bestaat nergens meer in HDFS en u kunt het op geen enkele manier terughalen. Kortom, u verplaatst de gegevens wanneer u de LOAD-opdracht geeft van de HDFS-bestandslocatie naar de Hive-magazijndirectory.

Opmerking: Het standaardpad van de magazijndirectory is ingesteld op / user / hive / warehouse. De gegevens van een Hive-tabel bevinden zich in warehouse_directory / tabelnaam (HDFS). U kunt ook het pad van de magazijndirectory opgeven in de configuratieparameter hive.metastore.warehouse.dir die aanwezig is in de hive-site.xml.

2. Externe tafel:

Opdracht:

EXTERNE TABEL MAKEN (kolom1 gegevens_type, kolom2 gegevens_type) LOCATIE ‘’

LAAD GEGEVENS INPATH ‘’ IN TAFEL

Voor externe tafel , Hive is niet verantwoordelijk voor het beheer van de gegevens. In dit geval, wanneer u de opdracht LOAD geeft, verplaatst Hive de gegevens naar de bijbehorende magazijndirectory. Vervolgens maakt Hive de metagegevensinformatie voor de externe tabel. Als u nu een DROP-opdracht geeft op het externe tafel , wordt alleen metadata-informatie met betrekking tot de externe tabel verwijderd. Daarom kunt u de gegevens van die zeer externe tabel nog steeds ophalen uit de magazijndirectory met behulp van HDFS-opdrachten.

Partities:

Opdracht:

CREATE TABLE table_name (kolom1 data_type, kolom2 data_type) PARTITIONED BY (partitie1 data_type, partitie2 data_type, & hellip.)

Hive organiseert tabellen in partities voor het groeperen van vergelijkbare typen gegevens op basis van een kolom of partitiesleutel. Elke tabel kan een of meer partitiesleutels hebben om een ​​bepaalde partitie te identificeren. Dit stelt ons in staat om een ​​snellere query uit te voeren op delen van de gegevens.

Opmerking: Onthoud dat de meest gemaakte fout bij het aanmaken van partities is om een ​​bestaande kolomnaam als partitiekolom op te geven. Terwijl u dit doet, krijgt u een foutmelding - 'Fout in semantische analyse: kolom herhaald in partitioneringskolommen'.

Laten we de partitie begrijpen door een voorbeeld te nemen waarin ik een tabel heb student_details met de studentinformatie van een technische hogeschool zoals student_id, naam, afdeling, jaar, enz. Nu, als ik partitionering uitvoer op basis van de afdelingskolom, de informatie van alle studenten die tot een bepaalde afdeling behoren, worden samen in diezelfde partitie opgeslagen. Fysiek is een partitie niets anders dan een submap in de tabeldirectory.

Stel dat we gegevens hebben voor drie afdelingen in onze tabel met studentdetails: CSE, ECE en Civil. Daarom hebben we in totaal drie partities voor elk van de afdelingen, zoals weergegeven in de onderstaande afbeelding. En voor elke afdeling hebben we alle gegevens over diezelfde afdeling in een aparte submap onder de Hive-tabeldirectory. Alle studentgegevens met betrekking tot CSE-afdelingen worden bijvoorbeeld opgeslagen in user / hive / warehouse / student_details / dept. = CSE. De vragen met betrekking tot CSE-studenten zouden dus alleen de gegevens in de CSE-partitie hoeven te doorzoeken. Dit maakt partitionering erg handig omdat het de wachttijd van de query vermindert door alleen te scannen relevant gepartitioneerde gegevens in plaats van de hele gegevensset. In feite krijgt u bij implementaties in de echte wereld te maken met honderden TB aan gegevens. Dus stel je voor dat je deze enorme hoeveelheid gegevens scant voor een zoekopdracht waar 95% door u gescande gegevens waren niet relevant voor uw vraag.

Ik zou je aanraden om de blog verder te lezen Hive-opdrachten waar u verschillende manieren vindt om partities te implementeren met een voorbeeld.

Emmers:

Opdrachten:

CREATE TABLE table_name PARTITIONED BY (partitie1 data_type, partitie2 data_type, & hellip.) GECLUSTERD DOOR (column_name1, column_name2, ...) GESORTEERD OP (column_name [ASC | DESC], ...)] IN num_buckets BUCKETS

Nu kunt u elke partitie of de niet-gepartitioneerde tabel in buckets verdelen op basis van de hash-functie van een kolom in de tabel. Eigenlijk is elke bucket slechts een bestand in de partitiemap of de tabeldirectory (niet-gepartitioneerde tabel). Daarom, als je ervoor hebt gekozen om de partities in n buckets te verdelen, heb je n bestanden in elke partitiemap. U kunt bijvoorbeeld de bovenstaande afbeelding zien waarin we elke partitie in 2 emmers hebben gegooid. Dus elke partitie, bijvoorbeeld CSE, heeft twee bestanden waarin elk de gegevens van de CSE-student zal opslaan.

Hoe verdeelt Hive de rijen in emmers?

Welnu, Hive bepaalt het bucketnummer voor een rij met behulp van de formule: hash_function (bucketing_column) modulo (aantal_blokken) . Hier, hash_function hangt af van het gegevenstype van de kolom. Als u de tabel bijvoorbeeld op basis van een kolom, laten we zeggen user_id, van INT-datatype bucketing geeft, zal de hash_functie - hash_function (user_id ) = integer waarde van user_id . En stel dat je twee buckets hebt gemaakt, dan bepaalt Hive de rijen die naar bucket 1 gaan in elke partitie door te berekenen: (waarde van user_id) modulo (2). Daarom zullen in dit geval rijen met user_id die eindigen op een even geheel getal zich in dezelfde bucket bevinden die overeenkomt met elke partitie. De hash_functie voor andere datatypes is een beetje ingewikkeld om te berekenen en in feite is het voor een string niet eens menselijk herkenbaar.

Opmerking: Als u Apache Hive 0.x of 1.x gebruikt, moet u command - set hive.enforce.bucketing = true uit uw Hive-terminal geven voordat u bucketing uitvoert. Hierdoor kunt u het juiste aantal reducer hebben terwijl u cluster per clausule gebruikt voor het bucketing van een kolom. Als u dit nog niet heeft gedaan, kan het zijn dat het aantal bestanden dat in uw tabeldirectory is gegenereerd niet gelijk is aan het aantal buckets. Als alternatief kunt u ook het aantal reducer gelijk aan het aantal emmers instellen door set mapred.reduce.task = num_bucket te gebruiken.

Waarom hebben we emmers nodig?

Er zijn twee hoofdredenen om bucketing naar een partitie uit te voeren:

• NAAR kaartzijde toetreden vereist dat de gegevens die bij een unieke verbindingssleutel horen, aanwezig zijn in dezelfde partitie. Maar hoe zit het met die gevallen waarin uw partitiesleutel verschilt van join? Daarom kunt u in deze gevallen een samenvoeging aan de kaartzijde uitvoeren door de tabel te bucketing met de samenvoegsleutel.
• Bucketing maakt het bemonsteringsproces efficiënter en stelt ons daarom in staat om de zoektijd te verkorten.

Ik zou deze Hive-tutorialblog hier graag willen afsluiten. Ik ben er vrij zeker van dat je na het doornemen van deze Hive-tutorialblog de eenvoud van Apache Hive zou hebben gerealiseerd. Sindsdien hebben jullie alle basisprincipes van Hive geleerd, is het hoog tijd om wat praktische ervaring op te doen met Apache Hive. Bekijk dus de volgende blog in deze Hive Tutorial-blogserie over de installatie van Hive en begin te werken aan Apache Hive.

Nu je Apache Hive en zijn functies hebt begrepen, kun je het door Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld. De Edureka Big Data Hadoop-certificeringstraining helpt leerlingen expert te worden in HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume en Sqoop met behulp van real-time use cases op het gebied van Retail, Social Media, Aviation, Tourism, Finance.

Heeft u een vraag voor ons? Vermeld het in het opmerkingengedeelte en we nemen contact met u op.