Hive Tutorial - Hive Architecture og NASA Case Study

Apache Hive Tutorial: Introduktion

Hive er rigorøst brugt værktøj til Big Data Analytics i hele branchen og et fantastisk værktøj til at starte din med. I denne Hive-tutorial-blog vil vi diskutere Apache Hive i dybden. Apache Hive er et datalagerværktøj i , som leverer SQL-lignende sprog til forespørgsel og analyse af Big Data. Motivationen bag udviklingen af ​​Hive er den friktionsløse læringsvej for SQL-udviklere og analytikere. Hive er ikke kun en frelser for folk med ikke-programmeringsbaggrund, men det reducerer også arbejdet hos programmører, der bruger lange timer på at skrive MapReduce-programmer. I denne Apache Hive Tutorial-blog vil jeg tale om:

• Hvad er Hive?
• Historien om Apache Hive - Fra Facebook til Apache
• Fordele ved Apache Hive
• Apache Hive - NASA Case Study
• Apache Hive Arkitektur
• Metastore-konfiguration
• Hive Data Model

Apache Hive Tutorial: Hvad er Hive?

Apache Hive er et datalagersystem bygget oven på Hadoop og bruges til at analysere strukturerede og semistrukturerede data.Hive abstraherer kompleksiteten af ​​Hadoop MapReduce. Dybest set giver det en mekanisme til at projicere struktur på dataene og udføre forespørgsler skrevet i HQL (Hive Query Language), der ligner SQL-sætninger. Internt konverteres disse forespørgsler eller HQL til kortreduktion af job af Hive-kompilatoren. Derfor behøver du ikke bekymre dig om at skrive komplekse MapReduce-programmer til at behandle dine data ved hjælp af Hadoop. Det er målrettet mod brugere, der er fortrolige med SQL. Apache Hive understøtter Data Definition Language (DDL), Data Manipulation Language (DML) og User Defined Functions (UDF).

Hive Tutorial for begyndere | Forståelse af bikube i dybden Edureka

SQL + Hadoop MapReduce = HiveQL

Apache Hive Tutorial: Story of Hive - fra Facebook til Apache

Fig : Hive Tutorial - Facebook-brugssag

Udfordringer på Facebook: Eksponentiel vækst i data

Før 2008 blev al databehandlingsinfrastruktur i Facebook bygget op omkring et datalager baseret på kommerciel RDBMS. Disse infrastrukturer var i stand til at tilfredsstille behovene på Facebook på det tidspunkt. Men da dataene begyndte at vokse meget hurtigt, blev det en enorm udfordring at administrere og behandle dette enorme datasæt. Ifølge en Facebook-artikel skaleres dataene fra et datasæt på 15 TB i 2007 til en 2 PB-data i 2009. Også mange Facebook-produkter involverer analyse af dataene som Audience Insights, Facebook Lexicon, Facebook Ads osv. Så de havde brug for en skalerbar og økonomisk løsning til at klare netop dette problem og begyndte derfor at bruge Hadoop-rammen.

Demokratisering Hadoop - MapReduce

Men efterhånden som dataene voksede, voksede kompleksiteten af ​​Map-Reduce-koder proportionalt. Så det blev svært at træne folk med en ikke-programmeringsbaggrund til at skrive MapReduce-programmer. For at udføre enkel analyse skal man også skrive hundrede linjer MapReduce-kode. Siden blev SQL meget brugt af ingeniører og analytikere, herunder Facebook, og derfor syntes det at placere SQL på toppen af ​​Hadoop en logisk måde at gøre Hadoop tilgængeligt for brugere med SQL-baggrund.

Derfor er SQL's evne til at være tilstrækkelig til de fleste af de analytiske krav og skalerbarheden af ​​Hadoop fødte Apache Hive der gør det muligt at udføre SQL-lignende forespørgsler på de data, der findes i HDFS. Senere blev Hive-projektet åbent i august 2008 af Facebook og er frit tilgængeligt som Apache Hive i dag.

Lad os nu se på funktionerne eller fordelene ved Hive, der gør det så populært.

Apache Hive Tutorial: Fordele ved Hive

• Nyttigt for folk, der ikke har programmeringsbaggrund, da det eliminerer behovet for at skrive et komplekst MapReduce-program.
• Udvidelig og skalerbar at klare den voksende mængde og mangfoldighed af data uden at påvirke systemets ydeevne.
• Det er som et effektivt ETL-værktøj (Extract, Transform, Load).
• Hive understøtter enhver klientapplikation skrevet i Java, PHP, Python, C ++ eller Ruby ved at udsætte dens Genbrugsserver . (Du kan bruge disse klientsidesprog indlejret i SQL til at få adgang til en database som DB2 osv.).
• Da metadataoplysningerne fra Hive er gemt i en RDBMS, reducerer det betydeligt tiden til at udføre semantisk kontrol under udførelse af forespørgsler.

Apache Hive-vejledning: Hvor skal jeg bruge Apache Hive?

Apache Hive drager fordel af begge verdener, dvs. SQL Database System og ramme. Derfor bruges det af et stort antal virksomheder. Det bruges mest til datalagring, hvor du kan udføre analyser og datamining, der ikke kræver behandling i realtid. Nogle af de felter, hvor du kan bruge Apache Hive, er som følger:

• Datalagring
• Ad hoc-analyse

Som det siges, kan du ikke kun klappe med den ene hånd, dvs. du kan ikke løse ethvert problem med et enkelt værktøj. Derfor kan du parre Hive med andre værktøjer til at bruge det på mange andre domæner. For eksempel kan Tableau sammen med Apache Hive bruges til datavisualisering, Apache Tez-integration med Hive giver dig realtidsbehandlingsfunktioner osv.
Gå videre i denne Apache Hive Tutorial-blog, lad os se på et casestudie af NASA, hvor du får at vide, hvordan Hive løste det problem, som NASA-forskere stod overfor, mens de udførte evaluering af klimamodeller.

Hive Tutorial: NASA Case Study

En klimamodel er en matematisk gengivelse af klimasystemer baseret på forskellige faktorer, der påvirker jordens klima. Grundlæggende beskriver den samspillet mellem forskellige drivere af klimaet som hav, sol, atmosfære osv. Tilgive et indblik i klimasystemets dynamik. Det bruges til at projicere klimaforhold ved at simulere klimaforandringerne baseret på faktorer, der påvirker klimaet. NASAs Jet Propulsion Laboratory har udviklet Regional Climate Model Evaluation System (RCMES) til analyse og evaluering af klimaproduktionsmodellen mod fjernmåling af data, der findes i forskellige eksterne lagre.

RCMES (Regional Climate Model Evaluation System) har to komponenter:

• RCMED (Regional Climate Model Evaluation Database):

Det er en skalerbar skydatabase, der indlæser data for fjernmåling og genanalyse, der er relateret til klima ved hjælp af ekstraktorer som Apache OODT-ekstraktorer, Apache Tika osv. Endelig transformerer det dataene som datapunktsmodellen, som er af formen (bredde , længdegrad, tid, værdi, højde) og gemmer det i min SQL-database. Klienten kan hente de data, der er til stede i RCMED, ved at udføre Space / Time-forespørgsler. Beskrivelsen af ​​sådanne forespørgsler er ikke relevant for os nu.

• RCMET (Regional Climate Model Evaluation Toolkit):

Det giver brugeren mulighed for at sammenligne de referencedata, der findes i RCMED, med klimamodelens outputdata hentet fra nogle andre kilder for at udføre forskellige former for analyse og evaluering. Du kan henvise til billedet nedenfor for at forstå RCMES 'arkitektur.

Referencedataene i RCMED kommer fra satellitbaseret fjernmåling i henhold til de forskellige parametre, der kræves til klimamodelevaluering. For eksempel - AIRS (Atmospheric Infrared Sounder) giver parametre som overfladelufttemperatur, temperatur og geopotential, TRMM (Tropical Rainfall Measurement Mission) giver månedlig nedbør osv.

Problemer, som NASA står over for ved hjælp af MySQL-databasesystemet:

• Efter indlæsning af MySQL-databasen med 6 mia. Tupler af formularen (breddegrad, længdegrad, tid, datapunktværdi, højde) styrtede systemet ned som vist på billedet ovenfor.
• Selv efter opdeling af hele tabellen i mindre delmængder genererede systemet enorme omkostninger under behandling af dataene.

Så de havde brug for en skalerbar løsning, der kan gemme og behandle denne enorme mængde data med SQL som forespørgsel. Endelig besluttede de at bruge Apache Hive til at overvinde ovennævnte problemer.

hvordan man laver en advarsel i html

Hvordan Apache Hive kan løse problemet?

Lad os nu se, hvad er de funktioner, der overbeviste NASAs JPL-team om at inkludere Apache Hive som en integreret del af deres løsningsstrategi:

• Da Apache Hive kører oven på Hadoop, er det skalerbart og kan behandle data distribueret og parallelt.
• Det giver Hive Query Language, der ligner SQL og dermed let at lære.

Implementering af bikuben:

Følgende billede forklarer RCMES-arkitekt med Apache Hive-integration:

Fig : Hive Tutorial - RCMES Architecture with Apache Hive

Ovenstående billede viser implementeringen af ​​apache-bikube i RCMES. Følgende trin blev taget af NASA-teamet under implementering af Apache Hive:

• De installerede Hive ved hjælp af Cloudera og Apache Hadoop som vist i ovenstående billede.
• De brugte Apache Sqoop til at indtage data i Hive fra MySQL-databasen.
• Apache OODT wrapper blev implementeret til at udføre forespørgsler på Hive og hente dataene tilbage til RCMET.

Indledende benchmarking observationer med bikube:

• Oprindeligt indlæste de 2,5 milliarder datapunkter i en enkelt tabel og udførte en tælleforespørgsel. For eksempel, Hive> vælg count (datapoint_id) fra dataPoint. Det tog 5-6 minutter at tælle alle optegnelserne (15-17 minutter for de fulde 6,8 milliarder poster).
• Reduktionsfasen var hurtig, men kortfasen tog 95% af den samlede behandlingstid. De brugte seks ( 4x quad-core ) systemer med 24 GB RAM (ca.) i hvert af systemerne.
• Selv efter tilføjelse af flere maskiner, ændring af HDFS-blokstørrelse (64 MB, 128 MB, 256 MB) og ændring af mange andre konfigurationsvariabler (io.sortere.faktor, i.sortere.mb), fik de ikke meget succes med at reducere tiden til at afslutte optællingen.

Indgange fra medlemmer af Hive Community:

Endelig kom medlemmer af Hive-samfundet til undsætning og leverede forskellige indsigter til at løse problemerne med deres nuværende Hive-implementeringer:

• De nævnte, at HDFS læsehastighed er ca. 60 MB / s sammenlignet med 1 GB / s i tilfælde af en lokal disk afhængigt af netværkskapacitet og arbejdsbelastning på NameNode.
• Medlemmerne foreslog det 16 kortlæggere kræves i deres nuværende system at matche I / O-udførelsen af ​​en lokal ikke-Hadoop-opgave.
• De foreslog også at reducere split-størrelse for hver kortlægger at øge antalletafkortlægger og derfor giver mere parallelitet.
• Endelig bad samfundets medlemmer dem om det brugstælling (1) i stedet for at henvise til tælle ( datapunkt_id) . Dette skyldes, at der i tilfælde af optælling (1) ikke er nogen referencekolonne, og at der derfor ikke finder nogen dekompression og deserialisering sted under udførelsen af ​​optællingen.

Endelig var NASA i stand til at indstille deres Hive-klynge op til deres forventninger ved at tage højde for alle forslagene fra Hive-community-medlemmerne. Og derfor var de i stand til at forespørge milliarder af rækker på kun 15 sekunder ved hjælp af de ovennævnte systemkonfigurationer.

Apache Hive Tutorial: Hive Architecture and its Components

Det følgende billede beskriver Hive-arkitekturen og det flow, som en forespørgsel sendes tilHiveog til sidst behandlet ved hjælp af MapReduce-rammen:

Fig : Hive Tutorial - Hive Architecture

Som vist i ovenstående billede kan Hive Architecture kategoriseres i følgende komponenter:

• Hive klienter: Hive understøtter applikationer skrevet på mange sprog som Java, C ++, Python osv. Ved hjælp af JDBC-, Thrift- og ODBC-drivere. Derfor kan man altid skrive hive-klientapplikation skrevet på et sprog efter eget valg.
• Hive Services: Apache Hive leverer forskellige tjenester som CLI, webgrænseflade osv. Til at udføre forespørgsler. Vi udforsker hver enkelt af dem snart i denne Hive-tutorial-blog.
• Processing framework og Resource Management: Internt,Hive bruger Hadoop MapReduce framework som de facto-motor til at udføre forespørgslerne. er et særskilt emne i sig selv og diskuteres derfor ikke her.
• Distribueret opbevaring: Da Hive er installeret oven på Hadoop, bruger den den underliggende HDFS til distribueret lager. Du kan henvise til HDFS-blog for at lære mere om det.

Lad os nu undersøge de to første hovedkomponenter i Hive Architecture:

1. Hive-klienter:

Apache Hive understøtter forskellige typer klientapplikationer til udførelse af forespørgsler på Hive. Disse klienter kan kategoriseres i tre typer:

• Genbrugsklienter: Da Hive-serveren er baseret på Apache Thrift, kan den tjene anmodningen fra alle de programmeringssprog, der understøtter Thrift.
• JDBC-klienter: Hive giver Java-applikationer mulighed for at oprette forbindelse til det ved hjælp af JDBC-driveren, der er defineret i klassen org.apache.hadoop.hive.jdbc.HiveDriver.
• ODBC-klienter: Hive ODBC Driver tillader applikationer, der understøtter ODBC-protokollen, at oprette forbindelse til Hive. (Ligesom JDBC-driveren bruger ODBC-driveren Thrift til at kommunikere med Hive-serveren.)

2. Hive Services:

Hive leverer mange tjenester som vist på billedet ovenfor. Lad os se på hver af dem:

• Hive CLI (Command Line Interface): Dette er standardskallen leveret af Hive, hvor du kan udføre dine Hive-forespørgsler og kommandoer direkte.
• Apache Hive-webgrænseflader: Bortset fra kommandolinjegrænsefladen leverer Hive også en webbaseret GUI til udførelse af Hive-forespørgsler og kommandoer.
• Hive Server: Hive-server er bygget på Apache Thrift og kaldes derfor også Thrift Server, der giver forskellige klienter mulighed for at indsende anmodninger til Hive og hente det endelige resultat.
• Apache Hive Driver: Det er ansvarligt for at modtage de forespørgsler, der sendes via CLI, web-UI, Thrift, ODBC eller JDBC-grænseflader af en klient. Derefter sender føreren forespørgslen til compileren, hvor parsing, typekontrol og semantisk analyse finder sted ved hjælp af skema til stede i metastore. I det næste trin genereres en optimeret logisk plan i form af en DAG (Directed Acyclic Graph) af kortreducerende opgaver og HDFS-opgaver. Endelig udfører eksekveringsmotoren disse opgaver i rækkefølgen af ​​deres afhængighed ved hjælp af Hadoop.
• Metastore: Du kan tænke metastoresom et centralt lager til lagring af alle Hive-metadataoplysningerne. Hive-metadata inkluderer forskellige typer information som struktur af tabeller og partitionersammen med den søjle, kolonnetype, serializer og deserializer, der kræves til læse / skrive-operation på de data, der findes i HDFS. Metastorebestår af to grundlæggende enheder:
  • En tjeneste, der leverer metastoreadgang til andrerHive-tjenester.
  • Disklagring til metadata, der er adskilt fra HDFS-lagring.

Lad os nu forstå de forskellige måder at implementere Hive-metastore påi det næste afsnit af denne Hive-tutorial.

Apache Hive-vejledning: Metastore-konfiguration

Metastore gemmer metadataoplysningerne ved hjælp af RDBMS og et open source ORM-lag (Object Relational Model) kaldet Data Nucleus, der konverterer objektrepræsentationen til relationskema og omvendt. Årsagen til at vælge RDBMS i stedet for HDFS er at opnå lav latenstid. Vi kan implementere metastore i følgende tre konfigurationer:

1. Indlejret metastore:

Både metastore-tjenesten og Hive-tjenesten kører som standard i den samme JVM ved hjælp af en indlejret Derby Database-forekomst, hvor metadata er gemt på den lokale disk. Dette kaldes integreret metastore-konfiguration. I dette tilfælde kan kun én bruger oprette forbindelse til metastore-databasen ad gangen. Hvis du starter en anden forekomst af Hive-driver, får du en fejl. Dette er godt til enhedstest, men ikke til de praktiske løsninger.

2. Lokal metastore:

Denne konfiguration giver os mulighed for at have flere Hive-sessioner, dvs. flere brugere kan bruge metastore-databasen på samme tid. Dette opnås ved at bruge enhver JDBC-kompatibel database som MySQL, der kører i en separat JVM eller en anden maskine end den i Hive-tjenesten og metastore-tjenesten, der kører i den samme JVM som vist ovenfor. Generelt er det mest populære valg at implementere en MySQL-server som metastore-database.

3. Fjernmetastore:

I den eksterne metastore-konfiguration kører metastore-tjenesten på sin egen separate JVM og ikke i Hive-tjenesten JVM. Andre processer kommunikerer med metastore-serveren ved hjælp af Thrift Network API'er. Du kan have en eller flere metastoreservere i dette tilfælde for at give mere tilgængelighed.Den største fordel ved at bruge fjernmetastore er, at du ikke behøver at dele JDBC-loginoplysninger med hver Hive-bruger for at få adgang til metastore-databasen.

Apache Hive-vejledning: datamodel

Data i Hive kan kategoriseres i tre typer på det granulære niveau:

• Bord
• Skillevæg
• Spand

Borde:

Tabeller i Hive er de samme som tabellerne i en relationsdatabase. Du kan udføre filtrering, projekt, tilslutning og fagforeningsoperationer på dem. Der er to typer borde i Hive:

1. Administreret tabel:

Kommando:

Opret TABEL (kolonne1-datatype, kolonne2-datatype)

LOAD DATA INPATH INTO table managed_table

Som navnet antyder (administreret tabel), er Hive ansvarlig for at administrere dataene i en administreret tabel. Med andre ord, hvad jeg mente med at sige, 'Hive administrerer dataene', er at hvis du indlæser dataene fra en fil, der er til stede i HDFS, i en Hive Administreret tabel og udstede en DROP-kommando på den, vil tabellen sammen med dens metadata blive slettet. Så dataene, der hører til de faldt managed_table findes ikke længere hvor som helst i HDFS, og du kan ikke hente det på nogen måde. Dybest set flytter du dataene, når du udsteder LOAD-kommandoen fra HDFS-filplaceringen til Hive-lagermappen.

Bemærk: Standardstien til lagermappen er indstillet til / bruger / bikube / lager. Dataene i en Hive-tabel findes i warehouse_directory / tabelnavn (HDFS). Du kan også angive stien til lagermappen i konfigurationsparameteren hive.metastore.warehouse.dir, der findes i hive-site.xml.

2. Ekstern tabel:

Kommando:

Opret EKSTERN TABEL (kolonne1 datatype, kolonne2 datatype) PLACERING ''

LAD DATA INPATH '' IN TABLE

Til eksternt bord , Hive er ikke ansvarlig for administration af dataene. I dette tilfælde, når du udsteder LOAD-kommandoen, flytter Hive dataene til sin lagermappe. Derefter opretter Hive metadataoplysningerne til den eksterne tabel. Nu, hvis du udsteder en DROP-kommando på eksternt bord , kun metadataoplysninger vedrørende den eksterne tabel slettes. Derfor kan du stadig hente dataene fra den meget eksterne tabel fra lagermappen ved hjælp af HDFS-kommandoer.

Skillevægge:

Kommando:

OPRET TABEL tabelnavn (kolonne1 datatype, kolonne2 datatype) DELET AF (partition1 datatype, partition2 datatype og hellip.)

Hive organiserer tabeller i partitioner til gruppering af lignende type data baseret på en kolonne eller partitionsnøgle. Hver tabel kan have en eller flere partitionstaster til at identificere en bestemt partition. Dette giver os mulighed for at få en hurtigere forespørgsel om udsnit af dataene.

Bemærk: Husk, at den mest almindelige fejl, der blev lavet under oprettelse af partitioner, er at angive et eksisterende kolonnenavn som en partitionskolonne. Mens du gør det, vil du modtage en fejl - 'Fejl i semantisk analyse: Kolonne gentaget i partitioneringskolonner'.

Lad os forstå partitionen ved at tage et eksempel, hvor jeg har en tabel student_detaljer, der indeholder studenteroplysningerne på et eller andet ingeniørhøjskole som student_id, navn, afdeling, år osv. Hvis jeg nu udfører partitionering baseret på afdelingskolonne, informationen om alle studerende der tilhører en bestemt afdeling, gemmes sammen i netop den partition. Fysisk er en partition intet andet end en underkatalog i tabelkataloget.

Lad os sige, at vi har data for tre afdelinger i vores student_details-tabel - CSE, ECE og Civil. Derfor har vi i alt tre partitioner for hver af afdelingerne som vist på billedet nedenfor. Og for hver afdeling har vi alle data vedrørende netop den afdeling, der er bosat i en separat underkatalog under Hive-tabelkataloget. For eksempel lagres alle studentdata vedrørende CSE-afdelinger i bruger / bikube / lager / student_details / afd. = CSE. Så forespørgsler vedrørende CSE-studerende behøver kun at gennemse de data, der er til stede i CSE-partitionen. Dette gør partitionering meget nyttig, da det reducerer forespørgslens latenstid ved kun at scanne relevant partitionerede data i stedet for hele datasættet. Faktisk vil du i virkelige verdensimplementeringer beskæftige dig med hundreder af TB'er data. Så forestil dig at scanne denne enorme mængde data for nogle forespørgsler hvor 95% data scannet af dig var ikke relevant for din forespørgsel.

Jeg vil foreslå dig at gå igennem bloggen Hive-kommandoer hvor du finder forskellige måder at implementere partitioner på med et eksempel.

Skovle:

Kommandoer:

OPRET TABEL tabelnavn DELET AF (partition1 data_type, partition2 data_type, & hellip.) CLUSTERED BY (column_name1, column_name2,…) SORTED BY (column_name [ASC | DESC],…)] INTO num_buckets BUCKETS

Nu kan du opdele hver partition eller den ikke-partitionerede tabel i spande baseret på hash-funktionen i en kolonne i tabellen. Faktisk er hver skov kun en fil i partitionskataloget eller tabelkataloget (upartitioneret tabel). Derfor, hvis du har valgt at opdele partitionerne i n spande, vil du have n filer i hver af dine partitionskataloger. For eksempel kan du se ovenstående billede, hvor vi har skænket hver partition i 2 spande. Så hver partition, siger CSE, vil have to filer, hvor hver af dem gemmer CSE-studerendes data.

Hvordan Hive fordeler rækkerne i spande?

Nå, Hive bestemmer skovnummeret for en række ved hjælp af formlen: hash_function (bucketing_column) modulo (num_of_buckets) . Her, hash_function afhænger af kolonnens datatype. For eksempel, hvis du skifter tabellen på basis af en kolonne, lad os sige user_id af INT-datatype, vil hash_funktionen være - hash_funktion (bruger_id ) = heltalsværdi af user_id . Og antag at du har oprettet to skovle, så bestemmer Hive rækkerne, der skal til skovl 1 i hver partition ved at beregne: (værdi af bruger_id) modulo (2). I dette tilfælde vil rækker, der har user_id, der slutter med et jævnt heltal, ligge i samme bucket svarende til hver partition. Hashfunktionen for andre datatyper er lidt kompleks at beregne, og for en streng er den ikke engang menneskeligt genkendelig.

Bemærk: Hvis du bruger Apache Hive 0.x eller 1.x, skal du udstede kommando - indstil hive.enforce.bucketing = true fra din Hive-terminal, inden du udfører bucketing. Dette giver dig mulighed for at have det rigtige antal reduceringsanordninger, mens du bruger klynge efter klausul til at skifte en kolonne. Hvis du ikke har gjort det, kan du finde ud af, at antallet af filer, der er genereret i din tabelmappe, ikke svarer til antallet af spande. Som et alternativ kan du også indstille antallet af reduceringsværktøj svarende til antallet af spande ved hjælp af sæt mapred.reduce.task = num_bucket.

Hvorfor har vi brug for spande?

Der er to hovedårsager til at udføre bucketing til en partition:

• TIL kort side sammenføjning kræver, at dataene, der hører til en unik sammenkædningsnøgle, er til stede i den samme partition. Men hvad med de tilfælde, hvor din partitionsnøgle adskiller sig fra sammenføjning? Derfor kan du i disse tilfælde udføre en kortsidesammenkædning ved at sætte tabellen sammen ved hjælp af sammenkædetasten.
• Bucketing gør prøveudtagningsprocessen mere effektiv og giver os derfor mulighed for at reducere forespørgselstiden.

Jeg vil gerne afslutte denne Hive-tutorial-blog her. Jeg er ret sikker på, at efter at have gennemgået denne Hive-tutorial-blog, ville du have forstået enkelheden af ​​Apache Hive. Siden har jer lært alle Hive-grundlæggende, det er på høje tid at have nogle praktiske erfaringer med Apache Hive. Så tjek den næste blog i denne Hive Tutorial-blogserie, der er på Hive-installation, og begynd at arbejde på Apache Hive.

Nu hvor du har forstået Apache Hive og dens funktioner, skal du tjekke af Edureka, et pålideligt online læringsfirma med et netværk på mere end 250.000 tilfredse elever spredt over hele kloden. Edureka Big Data Hadoop-certificeringskursus hjælper elever med at blive eksperter i HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume og Sqoop ved hjælp af realtidsanvendelsessager på Retail, Social Media, Aviation, Tourism, Finance domæne.

Har du et spørgsmål til os? Nævn det i kommentarfeltet, og vi vender tilbage til dig.