Hive Tutorial - Hive Architecture and NASA Case Study



Denne Hive-opplæringsbloggen gir deg grundig kunnskap om Hive Architecture og Hive Data Model. Det forklarer også NASAs casestudie om Apache Hive.

Apache Hive Tutorial: Introduksjon

Hive er et strengt industrielt brukt verktøy for Big Data Analytics og et flott verktøy for å starte med. I denne Hive-opplæringsbloggen vil vi diskutere Apache Hive i dybden. Apache Hive er et datalagerverktøy i , som gir SQL-lignende språk for spørring og analyse av Big Data. Motivasjonen bak utviklingen av Hive er den friksjonsløse læringsveien for SQL-utviklere og analytikere. Hive er ikke bare en frelser for folk fra ikke-programmeringsbakgrunn, men reduserer også arbeidet til programmerere som bruker lange timer på å skrive MapReduce-programmer. I denne Apache Hive-opplæringsbloggen vil jeg snakke om:





Apache Hive Tutorial: Hva er Hive?

Apache Hive er et datalagersystem bygget på toppen av Hadoop og brukes til å analysere strukturerte og semistrukturerte data.Hive abstrakte kompleksiteten til Hadoop MapReduce. I utgangspunktet gir det en mekanisme for å projisere strukturen på dataene og utføre spørsmål skrevet i HQL (Hive Query Language) som ligner på SQL-setninger. Internt blir disse spørsmålene eller HQL konvertert til kartreduserende jobber av Hive-kompilatoren. Derfor trenger du ikke bekymre deg for å skrive komplekse MapReduce-programmer for å behandle dataene dine ved hjelp av Hadoop. Det er rettet mot brukere som er komfortable med SQL. Apache Hive støtter Data Definition Language (DDL), Data Manipulation Language (DML) og User Defined Functions (UDF).

Hive Tutorial for nybegynnere | Forståelse av bikube i dybden | Edureka



SQL + Hadoop MapReduce = HiveQL

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

Facebook Use Case - Hive Tutorial - EdurekaFig : Hive Tutorial - Facebook use case

Utfordringer på Facebook: Eksponentiell vekst av data

Før 2008 ble all databehandlingsinfrastrukturen i Facebook bygget rundt et datalager basert på kommersiell RDBMS. Disse infrastrukturene var i stand til å tilfredsstille behovene til Facebook på den tiden. Men ettersom dataene begynte å vokse veldig raskt, ble det en stor utfordring å administrere og behandle dette enorme datasettet. Ifølge en Facebook-artikkel skaleres dataene fra et datasett på 15 TB i 2007 til 2 PB-data i 2009. Også mange Facebook-produkter involverer analyse av dataene som Audience Insights, Facebook Lexicon, Facebook Ads, etc. Så de trengte en skalerbar og økonomisk løsning for å takle dette problemet, og begynte derfor å bruke Hadoop-rammeverket.



Demokratisering Hadoop - MapReduce

Men etter hvert som dataene vokste, vokste kompleksiteten til Map-Reduce-koder proporsjonalt. Så det ble vanskelig å trene folk med ikke-programmeringsbakgrunn til å skrive MapReduce-programmer. For å utføre enkel analyse må man også skrive hundre linjer MapReduce-kode. Siden SQL ble mye brukt av ingeniører og analytikere, inkludert Facebook, så det å sette SQL på toppen av Hadoop virket en logisk måte å gjøre Hadoop tilgjengelig for brukere med SQL-bakgrunn.

java vent og varsle eksempel

Derfor fikk SQL muligheten til å være tilstrekkelig for de fleste analytiske krav og skalerbarheten til Hadoop Apache Hive som gjør det mulig å utføre SQL-lignende spørsmål på dataene som er tilstede i HDFS. Senere ble Hive-prosjektet åpent i august 2008 av Facebook og er fritt tilgjengelig som Apache Hive i dag.

La oss nå se på funksjonene eller fordelene med Hive som gjør den så populær.

Apache Hive Tutorial: Fordeler med Hive

  • Nyttig for folk som ikke har programmeringsbakgrunn, da det eliminerer behovet for å skrive et komplekst MapReduce-program.
  • Utvidbart og skalerbar å takle det økende volumet og mangfoldet av data, uten å påvirke systemets ytelse.
  • Det er som et effektivt ETL-verktøy (Extract, Transform, Load).
  • Hive støtter ethvert klientprogram skrevet i Java, PHP, Python, C ++ eller Ruby ved å utsette det Sparsommelighetsserver . (Du kan bruke disse klientsidespråkene som er innebygd med SQL for å få tilgang til en database som DB2 osv.).
  • Ettersom metadatainformasjonen til Hive er lagret i en RDBMS, reduserer den tiden for å utføre semantiske kontroller betydelig under utførelse av spørring.

Apache Hive Opplæring: Hvor skal jeg bruke Apache Hive?

Apache Hive utnytter begge verdens, dvs. SQL Database System og rammeverk. Derfor brukes den av et stort antall selskaper. Det brukes mest til datalagring der du kan utføre analyse og datautvinning som ikke krever sanntidsbehandling. Noen av feltene der du kan bruke Apache Hive er som følger:

  • Datavarehus
  • Ad-hoc analyse

Som det er sagt, kan du ikke klappe bare med en hånd, dvs. du kan ikke løse alle problemer med et enkelt verktøy. Derfor kan du koble Hive med andre verktøy for å bruke det på mange andre domener. For eksempel kan Tableau sammen med Apache Hive brukes til datavisualisering, Apache Tez-integrering med Hive vil gi deg sanntidsbehandlingsfunksjoner, etc.
La oss gå videre i denne Apache Hive-opplæringsbloggen, og la oss ta en titt på en casestudie av NASA der du vil bli kjent med hvordan Hive løste problemet som NASA-forskere sto overfor under evaluering av klimamodeller.

Hive Tutorial: NASA Case Study

En klimamodell er en matematisk fremstilling av klimasystemer basert på ulike faktorer som påvirker jordens klima. I utgangspunktet beskriver den samspillet mellom ulike drivere av klima som hav, sol, atmosfære, etc. tilgi et innblikk i dynamikken i klimasystemet. Den brukes til å projisere klimaforhold ved å simulere klimaendringene basert på faktorer som påvirker klimaet. NASAs Jet Propulsion Laboratory har utviklet Regional Climate Model Evaluation System (RCMES) for analyse og evaluering av klimaproduksjonsmodellen mot data fra fjernmåling i forskjellige eksterne lagre.

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

  • RCMED (Regional Climate Model Evaluation Database):

Det er en skalerbar skydatabase som laster data for fjernmåling og omanalyse som er relatert til klima ved hjelp av ekstraktorer som Apache OODT-ekstraktorer, Apache Tika, etc. Til slutt transformerer den dataene som datapunktmodellen som er av formen (breddegrad) , lengdegrad, tid, verdi, høyde) og lagrer den i Min SQL-database. Klienten kan hente dataene som er tilstede i RCMED ved å utføre Space / Time-spørsmål. Beskrivelsen av slike spørsmål er ikke relevant for oss nå.

  • RCMET (Regional Climate Model Evaluation Toolkit):

Det gir brukeren en mulighet til å sammenligne referansedataene som er tilstede i RCMED med klimamodellens outputdata hentet fra noen andre kilder for å utføre forskjellige typer analyse og evaluering. Du kan referere til bildet gitt nedenfor for å forstå RCMES arkitektur.

Referansedataene i RCMED kommer fra satellittbasert fjernmåling, i henhold til de forskjellige parametrene som kreves for evaluering av klimamodell. For eksempel - AIRS (Atmospheric Infrared Sounder) gir parametere som overflatetemperatur, temperatur og geopotensial, TRMM (Tropical Rainfall Measurement Mission) gir månedlig nedbør osv.

Problemer som NASA møter ved bruk av MySQL Database System:

  • Etter å ha lastet MySQL-databasen med 6 milliarder tupler av skjemaet (breddegrad, lengdegrad, tid, datapunktverdi, høyde), krasjet systemet som vist på bildet ovenfor.
  • Selv etter å ha delt hele tabellen i mindre delmengder, genererte systemet enorme omkostninger under behandlingen av dataene.

Så de trengte en skalerbar løsning som kan lagre og behandle denne enorme mengden data med SQL som spørringsfunksjon. Til slutt bestemte de seg for å bruke Apache Hive for å overvinne problemene som er nevnt ovenfor.

Hvordan Apache Hive kan løse problemet?

La oss nå se hva som er de funksjonene som overbeviste NASAs JPL-team om å inkludere Apache Hive som en integrert del i løsningsstrategien:

  • Siden Apache Hive kjører på toppen av Hadoop, er den skalerbar og kan behandle data distribuert og parallelt.
  • Det gir Hive Query Language som ligner på SQL og dermed lett å lære.

Distribusjon av bikube:

Følgende bilde forklarer RCMES Architect med Apache Hive-integrering:

Fig : Hive Tutorial - RCMES Architecture with Apache Hive

Ovenstående bilde viser distribusjonen av apache-bikube i RCMES. Følgende trinn ble tatt av NASA-teamet mens de distribuerte Apache Hive:

  • De installerte Hive ved hjelp av Cloudera og Apache Hadoop som vist i bildet ovenfor.
  • De brukte Apache Sqoop til å innta data i Hive fra MySQL-databasen.
  • Apache OODT wrapper ble implementert for å utføre spørsmål på Hive og hente dataene tilbake til RCMET.

Innledende benchmarking observasjoner med bikube:

  • Opprinnelig lastet de inn 2,5 milliarder datapunkter i en enkelt tabell og utførte et tellespørsmål. For eksempel, Hive> velg count (datapoint_id) fra dataPoint. Det tok 5-6 minutter å telle alle postene (15–17 minutter for hele 6,8 milliarder poster).
  • Reduksjonsfasen var rask, men kartfasen tok 95% av total behandlingstid. De brukte seks ( 4x firekjerners ) systemer med 24 GB RAM (ca.) i hvert av systemene.
  • Selv etter å ha lagt til flere maskiner, endret HDFS-blokkstørrelse (64 MB, 128 MB, 256 MB) og endret mange andre konfigurasjonsvariabler (io.sortere.faktor, jeg.sortere.mb), fikk de ikke mye suksess med å redusere tiden for å fullføre tellingen.

Innspill fra medlemmer av Hive Community:

Til slutt kom medlemmer av Hive-samfunnet til unnsetning og ga ulike innsikter for å løse problemene med deres nåværende Hive-implementeringer:

  • De nevnte at HDFS lesehastighet er omtrent 60 MB / s sammenlignet med 1 GB / s i tilfelle en lokal plate, avhengig av nettverkskapasitet og arbeidsbelastning på NameNode.
  • Medlemmene foreslo det 16 kartleggere vil være påkrevd i deres nåværende system for å matche I / O-ytelsen til en lokal ikke-Hadoop-oppgave.
  • De foreslo også å redusere delt størrelse for hver kartlegger for å øke antalletavkartleggere og derfor gir mer parallellitet.
  • Til slutt ba samfunnets medlemmer dem om det brukstall (1) i stedet for å referere til telle ( datapoint_id) . Dette skyldes at det i tilfelle telling (1) ikke er noen referansekolonne, og at det derfor ikke skjer noen dekompresjon og deserialisering mens du utfører tellingen.

Endelig var NASA i stand til å stille Hive-klyngen opp til forventningene sine ved å ta hensyn til alle forslagene som ble gitt av medlemmene i Hive-samfunnet. Og derfor klarte de å spørre milliarder av rader på bare 15 sekunder ved hjelp av systemkonfigurasjonene nevnt ovenfor.

Apache Hive Tutorial: Hive Architecture and its Components

Følgende bilde beskriver Hive Architecture og flyten som et spørsmål sendes inn iHiveog til slutt behandlet ved hjelp av MapReduce-rammeverket:

Fig : Hive Tutorial - Hive Architecture

Som vist i bildet ovenfor, kan Hive Architecture kategoriseres i følgende komponenter:

  • Hive klienter: Hive støtter applikasjoner skrevet på mange språk som Java, C ++, Python etc. ved hjelp av JDBC-, Thrift- og ODBC-drivere. Derfor kan man alltid skrive hive-klientapplikasjon skrevet på et språk de ønsker.
  • Hive Services: Apache Hive tilbyr forskjellige tjenester som CLI, webgrensesnitt etc. for å utføre spørsmål. Vi vil utforske hver enkelt av dem snart i denne Hive-opplæringsbloggen.
  • Rammeverk for behandling og ressursadministrasjon Internt,Hive bruker Hadoop MapReduce framework som de facto-motor for å utføre spørsmålene. er et eget tema i seg selv og blir derfor ikke diskutert her.
  • Distribuert lagring: Ettersom Hive er installert på toppen av Hadoop, bruker den den underliggende HDFS til distribuert lagring. Du kan referere til HDFS blogg for å lære mer om det.

La oss nå utforske de to første hovedkomponentene i Hive Architecture:

1. Hive-klienter:

Apache Hive støtter forskjellige typer klientapplikasjoner for å utføre spørsmål på Hive. Disse klientene kan kategoriseres i tre typer:

  • Sparsommelige kunder: Siden Hive-serveren er basert på Apache Thrift, kan den betjene forespørselen fra alle de programmeringsspråkene som støtter Thrift.
  • JDBC-klienter: Hive lar Java-applikasjoner koble til den ved hjelp av JDBC-driveren som er definert i klassen org.apache.hadoop.hive.jdbc.HiveDriver.
  • ODBC-klienter: Hive ODBC Driver tillater applikasjoner som støtter ODBC-protokollen å koble til Hive. (I likhet med JDBC-driveren bruker ODBC-driveren Thrift til å kommunisere med Hive-serveren.)

2. Hive-tjenester:

Hive tilbyr mange tjenester som vist på bildet ovenfor. La oss ta en titt på hver av dem:

  • Hive CLI (Command Line Interface): Dette er standard skallet fra Hive der du kan utføre Hive-spørsmålene og kommandoene direkte.
  • Apache Hive-nettgrensesnitt: Bortsett fra kommandolinjegrensesnittet, gir Hive også et nettbasert GUI for utføring av Hive-spørsmål og -kommandoer.
  • Hive Server: Hive-serveren er bygget på Apache Thrift og blir derfor også referert til som Thrift Server som lar forskjellige klienter sende inn forespørsler til Hive og hente det endelige resultatet.
  • Apache Hive Driver: Det er ansvarlig for å motta spørsmålene som sendes inn via CLI, nettgrensesnittet, sparsommelighet, ODBC eller JDBC-grensesnitt fra en klient. Deretter sender sjåføren spørringen til kompilatoren der parsing, typekontroll og semantisk analyse foregår ved hjelp av skjema som er tilstede i metastore.. I neste trinn genereres en optimalisert logisk plan i form av en DAG (Directed Acyclic Graph) av kartreduserende oppgaver og HDFS-oppgaver. Til slutt utfører kjøringsmotoren disse oppgavene i rekkefølgen av deres avhengighet, ved hjelp av Hadoop.
  • Metastore: Du kan tenke metastoresom et sentralt depot for lagring av all informasjon fra Hive-metadata. Hive-metadata inkluderer forskjellige typer informasjon som struktur av tabeller og partisjonersammen med kolonnen, kolonnetypen, serialisereren og deserialisereren som kreves for lese- / skrivedrift på dataene som er tilstede i HDFS. Metastorebestår av to grunnleggende enheter:
    • En tjeneste som gir metastoretilgang til andrerHive-tjenester.
    • Disklagring for metadataene som er atskilt fra HDFS-lagring.

La oss nå forstå de forskjellige måtene å implementere Hive-metastore påi neste del av denne Hive-opplæringen.

Apache Hive Tutorial: Metastore Configuration

Metastore lagrer metadatainformasjonen ved hjelp av RDBMS og et åpen kildekode-ORM-lag (Object Relational Model) kalt Data Nucleus som konverterer objektrepresentasjonen til relasjonsskjema og omvendt. Årsaken til å velge RDBMS i stedet for HDFS er å oppnå lav ventetid. Vi kan implementere metastore i følgende tre konfigurasjoner:

1. Innebygd metastore:

Både metastore-tjenesten og Hive-tjenesten kjøres i samme JVM som standard ved hjelp av en innebygd Derby Database-forekomst der metadata er lagret på den lokale disken. Dette kalles innebygd metastore-konfigurasjon. I dette tilfellet kan bare én bruker koble til metastore-databasen om gangen. Hvis du starter en annen forekomst av Hive-driveren, vil du få en feil. Dette er bra for enhetstesting, men ikke for de praktiske løsningene.

2. Lokal metastore:

Denne konfigurasjonen lar oss ha flere Hive-økter, dvs. flere brukere kan bruke metastore-databasen samtidig. Dette oppnås ved å bruke en hvilken som helst JDBC-kompatibel database som MySQL som kjører i en egen JVM eller en annen maskin enn den for Hive-tjenesten og metastore-tjenesten som kjører i samme JVM som vist ovenfor. Generelt sett er det mest populære valget å implementere en MySQL-server som metastore-database.

3. Fjernmetastore:

hvordan du bruker anaconda python

I den eksterne metastore-konfigurasjonen kjører metastore-tjenesten på sin egen separate JVM og ikke i Hive-tjenesten JVM. Andre prosesser kommuniserer med metastore-serveren ved hjelp av Thrift Network API-er. Du kan ha en eller flere metastoreservere i dette tilfellet for å gi mer tilgjengelighet.Den største fordelen med å bruke ekstern metastore er at du ikke trenger å dele JDBC-påloggingsinformasjon med hver Hive-bruker for å få tilgang til metastore-databasen.

Apache Hive-veiledning: datamodell

Data i Hive kan kategoriseres i tre typer på granulært nivå:

  • Bord
  • Skillevegg
  • Bøtte

Tabeller:

Tabeller i Hive er de samme som tabellene i en relasjonsdatabase. Du kan utføre filter, prosjekt, delta og fagforeningsoperasjoner på dem. Det er to typer bord i Hive:

1. Administrert tabell:

Kommando:

OPPRETT TABELL (kolonne1 datatype, kolonne2 datatype)

LAST DATA INPATH INTO table managed_table

Som navnet antyder (administrert tabell), er Hive ansvarlig for å administrere dataene til en administrert tabell. Med andre ord, det jeg mente med å si, “Hive administrerer dataene”, er at hvis du laster inn dataene fra en fil som er tilstede i HDFS til en Hive Administrert bord og utstede en DROP-kommando på den, vil tabellen sammen med metadataene bli slettet. Så, dataene som tilhører den droppede managed_table eksisterer ikke lenger hvor som helst i HDFS, og du kan ikke hente den på noen måte. I utgangspunktet flytter du dataene når du utsteder LOAD-kommandoen fra HDFS-filplasseringen til Hive-lagerkatalogen.

Merk: Standardstien til lagerkatalogen er satt til / bruker / bikube / lager. Dataene i en Hive-tabell ligger i warehouse_directory / tabellnavn (HDFS). Du kan også spesifisere banen til varehuskatalogen i konfigurasjonsparameteren hive.metastore.warehouse.dir i hive-site.xml.

2. Eksternt bord:

Kommando:

OPPRETT EKSTERN TABELL (kolonne1 datatype, kolonne2 datatype) BELIGGENHET ‘'

LAST DATA INPATH ‘’ IN TABLE

Til eksternt bord , Hive er ikke ansvarlig for å administrere dataene. I dette tilfellet, når du utsteder LOAD-kommandoen, flytter Hive dataene til lagerkatalogen. Deretter oppretter Hive metadatainformasjonen for den eksterne tabellen. Nå, hvis du utsteder en DROP-kommando på eksternt bord , bare metadatainformasjon angående den eksterne tabellen vil bli slettet. Derfor kan du fortsatt hente dataene til den svært eksterne tabellen fra lagerkatalogen ved hjelp av HDFS-kommandoer.

Skillevegger:

Kommando:

OPPRETT TABELL tabellnavn (kolonne1 datatype, kolonne2 datatype) DELT AV: (partisjon1 datatype, partisjon2 datatype og hellip.)

Hive organiserer tabeller i partisjoner for å gruppere lignende type data sammen basert på en kolonne eller partisjonsnøkkel. Hver tabell kan ha en eller flere partisjonsnøkler for å identifisere en bestemt partisjon. Dette gjør det mulig for oss å få en raskere spørring på dataene.

Merk: Husk at den vanligste feilen som ble gjort når du oppretter partisjoner, er å spesifisere et eksisterende kolonnenavn som en partisjonskolonne. Mens du gjør det, vil du motta en feil - 'Feil i semantisk analyse: Kolonne gjentatt i partisjoneringskolonner'.

La oss forstå partisjonen ved å ta et eksempel der jeg har en tabell student_detaljer som inneholder studentinformasjonen til en eller annen ingeniørhøyskole som student_id, navn, institutt, år osv. Nå, hvis jeg utfører partisjonering basert på instituttkolonne, informasjonen til alle studentene tilhører en bestemt avdeling vil bli lagret sammen i akkurat den partisjonen. Fysisk er en partisjon ingenting annet enn en underkatalog i tabellkatalogen.

La oss si at vi har data for tre avdelinger i tabellen student_detaljer - CSE, ECE og Civil. Derfor vil vi ha tre partisjoner totalt for hver avdelingene som vist på bildet nedenfor. Og for hver avdeling vil vi ha all data om den avdelingen som er bosatt i en egen underkatalog under Hive-tabellkatalogen. For eksempel vil alle studentdata vedrørende CSE-avdelinger bli lagret i bruker / bikube / lager / student_details / avd. = CSE. Så spørsmålene om CSE-studenter trenger bare å se gjennom dataene i CSE-partisjonen. Dette gjør partisjonering veldig nyttig ettersom det reduserer spørringsforsinkelsen ved å skanne bare relevant partisjonerte data i stedet for hele datasettet. I virkelighetsimplementeringer vil du faktisk håndtere hundrevis av TB-er med data. Så forestill deg å skanne denne enorme mengden data for noen spørsmål hvor 95% data skannet av deg var ikke relevant for spørsmålet ditt.

Jeg vil foreslå at du går gjennom bloggen videre Hive-kommandoer hvor du finner forskjellige måter å implementere partisjoner med et eksempel på.

Skuffer:

Kommandoer:

OPPRETT TABELL tabellnavn DELT AV (partisjon1 datatype, partisjon2 datatype og hellip.) KLASSERT AV (kolonnenavn1, kolonnenavn2,…) Sortert etter (kolonnenavn [ASC | DESC],…)] INTO antall_bukker BUCKETS

Nå kan du dele hver partisjon eller den ikke-partisjonerte tabellen i skuffer basert på hash-funksjonen til en kolonne i tabellen. Egentlig er hver bøtte bare en fil i partisjonskatalogen eller tabellkatalogen (upartisjonert tabell). Derfor, hvis du har valgt å dele partisjonene i n bøtter, vil du ha n filer i hver av partisjonskatalogene dine. For eksempel kan du se bildet ovenfor der vi har bøyd hver partisjon i 2 bøtter. Så hver partisjon, si CSE, vil ha to filer der hver av dem vil lagre CSE-studentens data.

Hvordan Hive fordeler radene i bøtter?

Vel, Hive bestemmer bøttenummeret for en rad ved hjelp av formelen: hash_function (bucketing_column) modulo (num_of_buckets) . Her, hash_function avhenger av kolonnedatatypen. Hvis du for eksempel legger ut tabellen på grunnlag av en kolonne, la oss si bruker_id, av INT-datatype, vil hash_funksjonen være - hash_function (bruker_id ) = heltallverdi av bruker_id . Og antar at du har opprettet to bøtter, så bestemmer Hive radene som skal til bøtte 1 i hver partisjon ved å beregne: (verdien av bruker_id) modulo (2). Derfor, i dette tilfellet, vil rader som har user_id som slutter med et jevnt heltall, ligge i samme bøtte som tilsvarer hver partisjon. Hashfunksjonen for andre datatyper er litt kompleks å beregne, og faktisk er den ikke engang menneskelig gjenkjennelig for en streng.

Merk: Hvis du bruker Apache Hive 0.x eller 1.x, må du utstede kommando - sett hive.enforce.bucketing = true fra Hive-terminalen før du utfører bucketing. Dette vil tillate deg å ha riktig antall reduksjonsmidler mens du bruker klynge for klausul for å skuffe en kolonne. Hvis du ikke har gjort det, kan det hende at antall filer som er generert i tabellkatalogen ikke er lik antall bøtter. Som et alternativ kan du også angi antall reduksjonsmidler som tilsvarer antall bøtter ved å bruke sett mapred.reduce.task = num_bucket.

Hvorfor trenger vi bøtter?

Det er to hovedårsaker til å utføre skuffing til en partisjon:

  • TIL kartsiden bli med krever at dataene som tilhører en unik sammenkoblingsnøkkel, skal være til stede i samme partisjon. Men hva med de tilfellene der partisjonsnøkkelen din skiller seg fra å bli med? Derfor kan du i disse tilfellene utføre en kortsidesammenkobling ved å legge tabellen sammen ved hjelp av sammenføyningstasten.
  • Bucketing gjør prøvetakingsprosessen mer effektiv og lar oss derfor redusere spørringstiden.

Jeg vil avslutte denne Hive-opplæringsbloggen her. Jeg er ganske sikker på at etter å ha gått gjennom denne Hive-opplæringsbloggen, ville du ha forstått enkelheten til Apache Hive. Siden har dere lært alt det grunnleggende av Hive, det er på høy tid å ha litt erfaring med Apache Hive. Så sjekk ut neste blogg i denne Hive Tutorial-bloggserien som er på Hive-installasjon, og begynn å jobbe med Apache Hive.

Nå som du har forstått Apache Hive og dens funksjoner, sjekk ut av Edureka, et pålitelig online læringsfirma med et nettverk med mer enn 250 000 fornøyde elever spredt over hele verden. Edureka Big Data Hadoop Certification Training-kurset hjelper elever å bli eksperter i HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume og Sqoop ved å bruke sanntidsbruk på Retail, Social Media, Aviation, Tourism, Finance.

Har du spørsmål til oss? Vennligst nevn det i kommentarfeltet, så kommer vi tilbake til deg.