Vodič za košnice - Arhitektura košnica i NASA-ina studija slučaja



Ovaj tutorial blog Hive daje vam detaljno znanje o arhitekturi košnica i modelu podataka o košnici. Također objašnjava NASA-inu studiju slučaja Apache Hive.

Vodič za Apache Hive: Uvod

Hive je rigorozno korišten alat za Big Data Analytics i sjajan alat za pokretanje vašeg s. U ovom blogu s uputama o Hiveu detaljno ćemo raspravljati o Apache Hiveu. Apache Hive je alat za skladištenje podataka u , koji pruža jezik poput SQL-a za upite i analizu velikih podataka. Motivacija za razvoj Hivea je put učenja bez ikakvih trenja za SQL programere i analitičare. Košnica nije spasitelj samo ljudima koji nisu iz programskog porijekla, već također smanjuje rad programera koji provode duge sate pišući MapReduce programe. U ovom blogu Apache Hive Tutorial govorit ću o:





Vodič za Apache Hive: Što je košnica?

Apache Hive sustav je skladišta podataka izgrađen na vrhu Hadoopa i koristi se za analizu strukturiranih i polustrukturiranih podataka.Hive apstrahira složenost Hadoop MapReducea. U osnovi, pruža mehanizam za projektiranje strukture na podatke i izvršavanje upita napisanih u HQL (Hive Query Language) koji su slični SQL izrazima. Interno, ovi upiti ili HQL prevodilac Hive pretvara u mapu kako bi smanjio poslove. Stoga ne trebate brinuti o pisanju složenih programa MapReduce za obradu podataka pomoću Hadoop-a. Ciljana je na korisnike koji vole SQL. Apache Hive podržava jezik za definiranje podataka (DDL), jezik za manipulaciju podacima (DML) i funkcije definirane od korisnika (UDF).

kada koristiti ovo u javi

Vodič za košnice za početnike | Razumijevanje košnice u dubini | Edureka



SQL + Hadoop MapReduce = HiveQL

Vodič za košnice Apache: Priča o košnici - od Facebooka do Apachea

Slučaj upotrebe Facebooka - Vodič za košnice - EdurekaSl : Hive Tutorial - slučaj upotrebe Facebooka

Izazovi na Facebooku: Eksponencijalni rast podataka

Prije 2008. godine, sva infrastruktura za obradu podataka na Facebooku izgrađena je oko skladišta podataka zasnovanog na komercijalnom RDBMS-u. Te su infrastrukture bile dovoljno sposobne da u to vrijeme zadovolje potrebe Facebooka. No, kako su podaci počeli vrlo brzo rasti, postao je veliki izazov za upravljanje i obradu ovog velikog skupa podataka. Prema članku na Facebooku, podaci su skalirani sa 15 TB podataka u 2007. na 2 PB u 2009. Također, mnogi Facebook proizvodi uključuju analizu podataka poput Audience Insights, Facebook Lexicon, Facebook Ads, itd. Dakle, oni trebalo je prilagodljivo i ekonomično rješenje za suočavanje s ovim problemom te je stoga počeo koristiti Hadoop okvir.



Demokratiziranje Hadoop - MapReduce

No, kako su podaci rasli, složenost Map-Reduce kodova proporcionalno je rasla. Dakle, postalo je teško osposobiti ljude s neprogramskim porijeklom za pisanje programa MapReduce. Također, za obavljanje jednostavne analize treba napisati stotinu redaka MapReduce koda. Budući da su SQL inženjeri i analitičari, uključujući Facebook, naširoko koristili, postavljanje SQL-a na vrh Hadoopa činilo se logičnim načinom da se Hadoop učini dostupnim korisnicima sa SQL pozadinom.

Stoga je sposobnost SQL-a dovoljna za većinu analitičkih zahtjeva i skalabilnost Hadoopa rodila Apache košnica koji omogućuje izvršavanje SQL sličnih upita na podacima prisutnim u HDFS-u. Kasnije je Facebook otvorio projekt Hive u kolovozu 2008. godine i danas je slobodno dostupan kao Apache Hive.

Pogledajmo sada značajke ili prednosti Hive-a zbog kojih je toliko popularan.

Vodič za Apache košnice: Prednosti košnice

  • Korisno za ljude koji nisu iz programskog porijekla jer uklanja potrebu za pisanjem složenog programa MapReduce.
  • Proširivo i skalabilno nositi se sa sve većim volumenom i raznolikošću podataka, bez utjecaja na performanse sustava.
  • To je učinkovit ETL (Extract, Transform, Load) alat.
  • Hive podržava bilo koju klijentsku aplikaciju napisanu na Java, PHP, Python, C ++ ili Ruby izlažući je Štedljivi poslužitelj . (Ove jezike na strani klijenta ugrađene u SQL možete koristiti za pristup bazi podataka kao što je DB2, itd.).
  • Kako su podaci o metapodacima Hivea pohranjeni u RDBMS, to značajno smanjuje vrijeme za obavljanje semantičkih provjera tijekom izvršavanja upita.

Vodič za Apache Hive: Gdje koristiti Apache Hive?

Apache Hive iskorištava oba svijeta, tj. SQL sistem baza podataka i okvir. Stoga ga koristi veliko mnoštvo tvrtki. Uglavnom se koristi za skladištenje podataka gdje možete obavljati analitiku i rudarenje podataka koje ne zahtijevaju obradu u stvarnom vremenu. Neka od polja u kojima možete koristiti Apache Hive su sljedeća:

  • Skladištenje podataka
  • Ad-hoc analiza

Kao što je rečeno, ne možete pljeskati samo jednom rukom, tj. Ne možete riješiti svaki problem jednim alatom. Stoga možete povezati Hive s drugim alatima kako biste ga koristili u mnogim drugim domenama. Na primjer, Tableau se zajedno s Apache Hive može koristiti za vizualizaciju podataka, integracija Apache Tez s Hive pružit će vam mogućnosti obrade u stvarnom vremenu, itd.
Krećući se naprijed na ovom blogu Apache Hive Tutorial, pogledajmo studiju slučaja NASA-e gdje ćete upoznati kako je Hive riješio problem s kojim su se NASA-ini znanstvenici suočavali tijekom vršenja evaluacije klimatskih modela.

Vodič za košnice: NASA-ina studija slučaja

Klimatski model je matematički prikaz klimatskih sustava zasnovan na raznim čimbenicima koji utječu na klimu Zemlje. U osnovi, opisuje interakciju različitih pokretača klime kao što su ocean, sunce, atmosfera itdpružaju uvid u dinamiku klimatskog sustava. Koristi se za projektiranje klimatskih uvjeta simuliranjem klimatskih promjena na temelju čimbenika koji utječu na klimu. NASA-in laboratorij za mlazni pogon razvio je Regionalni sustav za ocjenu klimatskog modela (RCMES) za analizu i ocjenu modela klimatskih rezultata prema podacima daljinskog istraživanja koji su prisutni u raznim vanjskim spremištima.

RCMES (Regionalni sustav za ocjenu klimatskih modela) ima dvije komponente:

  • RCMED (Baza podataka za procjenu regionalnog klimatskog modela):

To je skalabilna baza podataka u oblaku koja učitava podatke daljinskog istraživanja i podatke o ponovnoj analizi koji su povezani s klimom pomoću ekstraktora kao što su Apache OODT ekstraktori, Apache Tika itd. Konačno, podatke transformira kao model točke podataka koji je oblika (zemljopisna širina , dužina, vrijeme, vrijednost, visina) i sprema je u Moju SQL bazu podataka. Klijent može dohvatiti podatke prisutne u RCMED-u izvođenjem prostorno-vremenskih upita. Opis takvih upita za nas sada nije relevantan.

  • RCMET (Regionalni priručnik za procjenu klimatskih modela):

Pruža korisniku mogućnost usporedbe referentnih podataka prisutnih u RCMED-u s izlaznim podacima klimatskog modela dobivenim iz nekih drugih izvora za obavljanje različitih vrsta analiza i procjene. Možete se pozvati na donju sliku kako biste razumjeli arhitekturu RCMES-a.

Referentni podaci u RCMED-u potječu od satelitskog daljinskog istraživanja, prema različitim parametrima potrebnim za procjenu klimatskog modela. Na primjer - AIRS (Atmospheric Infrared Sounder) pruža parametre poput temperature površinskog zraka, temperature i Geopotencijala, TRMM (Tropical Rainfall Measurement Mission) pruža mjesečne oborine itd.

Problemi s kojima se susreće NASA koristeći MySQL sustav baza podataka:

  • Nakon učitavanja MySQL baze podataka sa 6 milijardi tupi obrazaca (zemljopisna širina, dužina, vrijeme, vrijednost podatkovne točke, visina), sustav se srušio kao što je prikazano na gornjoj slici.
  • Čak i nakon što je cijelu tablicu podijelio na manje podskupove, sustav je generirao ogromne troškove tijekom obrade podataka.

Dakle, bilo im je potrebno prilagodljivo rješenje koje može pohraniti i obraditi ovu ogromnu količinu podataka s SQL-om poput mogućnosti postavljanja upita. Napokon su odlučili koristiti Apache Hive kako bi prevladali gore navedene probleme.

Kako Apache Hive može riješiti problem?

Sad, da vidimo, koje su to značajke koje su uvjerile NASA-in tim JPL da Apache Hive uključi kao sastavni dio u svoju strategiju rješenja:

  • Budući da Apache Hive radi na vrhu Hadoopa, prilagodljiv je i može obrađivati ​​podatke distribuirano i paralelno.
  • Pruža jezik upita za košnice koji je sličan SQL-u i stoga ga je lako naučiti.

Uvođenje košnice:

Sljedeća slika objašnjava RCMES Architect s integracijom Apache Hive:

Sl : Vodič za košnice - RCMES arhitektura s Apache košnicom

Gornja slika prikazuje postavljanje apache košnice u RCMES. NASA-in je tim poduzeo sljedeće korake prilikom raspoređivanja Apache Hive:

__init__ python 3
  • Instalirali su Hive koristeći Cloudera i Apache Hadoop kako je prikazano na gornjoj slici.
  • Koristili su Apache Sqoop za unos podataka u košnicu iz MySQL baze podataka.
  • Omotač Apache OODT implementiran je za izvođenje upita na Hive i vraćanje podataka natrag u RCMET.

Početna opažanja s košnicom:

  • U početku su učitali 2,5 milijarde točaka podataka u jednu tablicu i izvršili upit za brojanje. Na primjer, Košnica> odaberite count (datapoint_id) iz dataPointa. Za brojanje svih zapisa trebalo je 5-6 minuta (15-17 minuta za punih 6,8 milijardi zapisa).
  • Faza smanjenja bila je brza, ali faza karte trajala je 95% ukupnog vremena obrade. Koristili su šest ( 4x četverojezgreni ) sustavi s 24 GB RAM-a (približno) u svakom od sustava.
  • Čak i nakon dodavanja dodatnih strojeva, promjene veličine HDFS bloka (64 MB, 128 MB, 256 MB) i izmjene mnogih drugih konfiguracijskih varijabli (io.vrsta.faktor, t.j..vrsta.mb), nisu postigli puno uspjeha u smanjenju vremena za dovršavanje brojanja.

Unosi članova zajednice košnica:

Konačno, članovi zajednice Hive priskočili su u pomoć i pružili razne uvide kako bi riješili probleme svojim trenutnim primjenama u košnici:

  • Spomenuli su da je brzina čitanja HDFS-a približno 60 MB / s u usporedbi s 1 GB / s u slučaju lokalnog diska, ovisno o mrežnom kapacitetu i radnom opterećenju na NameNode.
  • Članovi su to predložili 16 mapera će se u njihovom trenutnom sustavu podudarati s I / O izvedbom lokalnog zadatka koji nije Hadoop.
  • Također su predložili da se smanji podijeljena veličina za svako mapiranje da poveća brojodmape i, pružajući više paralelizma.
  • Konačno, članovi zajednice su im rekli broj upotrebe (1) umjesto pozivanja na računati ( datapoint_id) . To je zato što u slučaju brojanja (1) ne postoji referentni stupac i stoga se ne vrši dekompresija i deserializacija tijekom izvođenja brojanja.

Napokon, NASA je uspjela prilagoditi njihov klaster košnica prema njihovim očekivanjima uzimajući u obzir sve prijedloge članova zajednice Hive. Stoga su uspjeli ispitati milijarde redaka u samo 15 sekundi pomoću gore spomenutih konfiguracija sustava.

Vodič za Apache Hive: Arhitektura košnica i njezine komponente

Sljedeća slika opisuje Arhitekturu košnica i tijek u koji se podnosi upitKošnicai konačno obrađena pomoću MapReduce okvira:

Sl : Vodič za košnice - Arhitektura košnica

Kao što je prikazano na gornjoj slici, Arhitektura košnica može se kategorizirati u sljedeće komponente:

  • Klijenti košnica: Hive podržava aplikaciju napisanu na mnogim jezicima kao što su Java, C ++, Python itd. Pomoću JDBC, Thrift i ODBC upravljačkih programa. Stoga se uvijek može napisati klijentska aplikacija košnice napisana na jeziku po njihovom izboru.
  • Usluge košnica: Apache Hive pruža razne usluge poput CLI-a, web sučelja itd. Za obavljanje upita. Uskoro ćemo istražiti svakog od njih u ovom blogu s uputama o Hiveu.
  • Okvir obrade i upravljanje resursima: Interno,Hive koristi okvir Hadoop MapReduce kao faktički pokretač za izvršavanje upita. je zasebna tema za sebe i stoga se ovdje ne raspravlja.
  • Distribuirana pohrana: Kako je Hive instaliran na vrhu Hadoopa, za distribuiranu pohranu koristi temeljni HDFS. Možete se pozvati na HDFS blog da biste saznali više o tome.

Sada, istražimo prve dvije glavne komponente u Arhitekturi košnica:

1. Klijenti košnica:

Apache Hive podržava različite vrste klijentskih aplikacija za izvršavanje upita na košnici. Ti se klijenti mogu podijeliti u tri vrste:

  • Štedljivi klijenti: Kako se poslužitelj Hive temelji na Apache Thrift, on može poslužiti zahtjev iz svih onih programskih jezika koji podržavaju Thrift.
  • JDBC klijenti: Hive omogućuje Java programima da se na njega povežu pomoću upravljačkog programa JDBC koji je definiran u klasi org.apache.hadoop.košnica.jdbc.HiveDriver.
  • ODBC klijenti: ODBC pogonitelj Hive omogućuje aplikacijama koje podržavaju ODBC protokol povezivanje s Hiveom. (Kao i JDBC pogonitelj, ODBC pokretač koristi Thrift za komunikaciju s Hive poslužiteljem.)

2. Usluge košnica:

Košnica pruža mnoge usluge kao što je prikazano na gornjoj slici. Pogledajmo svakog od njih:

  • CLI košnice (sučelje naredbenog retka): Ovo je zadana ljuska koju pruža Hive gdje možete izravno izvršavati svoje upite i naredbe u Hiveu.
  • Web sučelja Apache Hive: Osim sučelja naredbenog retka, Hive također nudi internetski GUI za izvršavanje upita i naredbi Hivea.
  • Poslužnik košnica: Hive poslužitelj izgrađen je na Apache Thrift i stoga se naziva i Thrift Server koji omogućava različitim klijentima da predaju zahtjeve Hiveu i dohvaćaju konačni rezultat.
  • Apache pogonitelj košnice: Odgovorna je za primanje upita koje klijent podnosi putem CLI-a, web korisničkog sučelja, Thrift-a, ODBC-a ili JDBC-a. Zatim vozač prosljeđuje upit kompajleru gdje se vrši raščlamba, provjera tipa i semantička analiza uz pomoć sheme prisutne u metastoreu. U sljedećem koraku generira se optimizirani logički plan u obliku DAG-a (Directed Acyclic Graph) zadataka za smanjenje karte i HDFS zadataka. Konačno, izvršni mehanizam izvršava ove zadatke po redoslijedu njihovih ovisnosti, koristeći Hadoop.
  • Metastore: Možete misliti u metastorekao središnje spremište za pohranu svih podataka o metapodacima Hivea. Metapodaci o košnici uključuju razne vrste informacija poput strukture tablica i particijazajedno sa stupcem, vrstom stupaca, serializatorom i deserijalizatorom koji su potrebni za operaciju čitanja / pisanja podataka prisutnih u HDFS-u. Metastoresastoji se od dvije temeljne cjeline:
    • Usluga koja pruža metastorepristup drugimrUsluge košnica.
    • Diskovna pohrana za metapodatke koja je odvojena od HDFS pohrane.

Razumijemo sada različite načine primjene Hive metastoreu sljedećem odjeljku ovog Vodiča za košnice.

Vodič za Apache Hive: Konfiguracija metastore

Metastore pohranjuje podatke o meta podacima koristeći RDBMS i sloj otvorenog koda ORM (objektni relacijski model) nazvan Data Nucleus koji pretvara prikaz objekta u relacijsku shemu i obrnuto. Razlog odabira RDBMS-a umjesto HDFS-a je postizanje niske latencije. Metastore možemo implementirati u sljedeće tri konfiguracije:

1. Ugrađena metastora:

I usluga metastore i usluga Hive po defaultu se izvode u istom JVM-u, koristeći ugrađenu instancu Derby Database gdje su metapodaci pohranjeni na lokalnom disku. To se naziva konfiguracija ugrađene metateke. U ovom se slučaju samo jedan korisnik može istodobno povezati s metastore bazom podataka. Ako pokrenete drugu instancu upravljačkog programa Hive, dobit ćete pogrešku. Ovo je dobro za jedinstveno testiranje, ali ne i za praktična rješenja.

2. Lokalna metastora:

Ova konfiguracija omogućuje nam da imamo više sesija Hive, tj. Više korisnika može istovremeno koristiti bazu podataka metastore. To se postiže korištenjem bilo koje JDBC kompatibilne baze podataka poput MySQL-a koja se izvodi u zasebnom JVM-u ili na drugom stroju od onog usluge Hive i metastore usluge koji rade u istom JVM-u kao što je gore prikazano. Općenito, najpopularniji je izbor implementirati MySQL poslužitelj kao metastore bazu podataka.

3. Udaljena metastora:

U konfiguraciji udaljene metastore, usluga metastore radi na svom zasebnom JVM-u, a ne na JVM usluge Hive. Ostali procesi komuniciraju s metastore poslužiteljem pomoću Thrift Network API-ja. U ovom slučaju možete imati jedan ili više poslužitelja metastore radi pružanja veće dostupnosti.Glavna prednost korištenja udaljene metastore je da ne morate dijeliti JDBC vjerodajnice za prijavu sa svakim korisnikom Hive za pristup bazi podataka metastore.

Vodič za Apache Hive: Model podataka

Podaci u košnici mogu se razvrstati u tri vrste na granularnoj razini:

  • Stol
  • Pregrada
  • Kanta

Tablice:

Tablice u košnici iste su kao i tablice prisutne u relacijskoj bazi podataka. Na njima možete izvoditi operacije filtriranja, projektiranja, pridruživanja i spajanja. U košnici postoje dvije vrste tablica:

1. Upravljana tablica:

Naredba:

STVORI TABELU (stupac1 vrsta podataka, stupac2 vrsta podataka)

Učitaj podatke u ulaz u tablicu managed_table

Kao što i samo ime govori (upravljana tablica), Hive je odgovoran za upravljanje podacima upravljane tablice. Drugim riječima, ono što sam mislio rekavši, „Košnica upravlja podacima“, jest da ako podatke iz datoteke prisutne u HDFS učitate u košnicu Upravljani stol i na njemu izdajte naredbu DROP, tablica s metapodacima bit će izbrisana. Dakle, podaci koji pripadaju ispuštenima upravljana_tablica više ne postoje nigdje u HDFS-u i ne možete ga dohvatiti ni na koji način. U osnovi premještate podatke kada izdate naredbu LOAD s mjesta HDFS datoteke u direktorij skladišta Hive.

Bilješka: Zadana putanja direktorija skladišta postavljena je na / user / hive / warehouse. Podaci tablice košnice nalaze se u warehouse_directory / ime_tabele (HDFS). Također možete odrediti put direktorija skladišta u konfiguracijskom parametru hive.metastore.warehouse.dir prisutan u hive-site.xml.

2. Vanjska tablica:

Naredba:

IZRADI VANJSKU TABLICU (vrsta podataka_stupac1, tip_ podataka stupac2) LOKACIJA ‘’

UČITAJ PUT DO PODATAKA ‘’ U STOL

c ++ idite na

Za vanjski stol , Hive nije odgovoran za upravljanje podacima. U ovom slučaju, kada izdate naredbu LOAD, Hive premješta podatke u svoj direktorij skladišta. Zatim, Hive stvara podatke o metapodacima za vanjsku tablicu. Ako izdate naredbu DROP na vanjski stol , izbrisat će se samo podaci o metapodacima u vezi s vanjskom tablicom. Stoga i dalje možete dohvatiti podatke te vrlo vanjske tablice iz direktorija skladišta pomoću naredbi HDFS.

Pregrade:

Naredba:

STVORI TABELU ime_tablice (vrsta_podatka1, vrsta_podatka2 stupac) RAZDJELJENO (tip podataka_podijela1, tip_podjele2, tip_ & hellip.)

Hive organizira tablice u particije za grupiranje sličnih vrsta podataka na temelju stupca ili particijskog ključa. Svaka tablica može imati jedan ili više particijskih ključeva za identifikaciju određene particije. To nam omogućuje brži upit o kriškama podataka.

Bilješka: Imajte na umu da je najčešća pogreška tijekom stvaranja particija to što ste kao particijski stupac naveli postojeći naziv stupca. Pritom ćete primiti pogrešku - 'Pogreška u semantičkoj analizi: Stupac ponovljen u stupcima za particioniranje'.

Dopustite nam da razumijemo particiju uzevši primjer na kojem imam tablicu student_details koja sadrži podatke o studentima nekog inženjerskog fakulteta kao što su student_id, ime, odjel, godina itd. Sada, ako izvodim particiju na temelju stupca odjela, podaci svih učenika koji pripadaju određenom odjelu bit će pohranjeni zajedno na toj particiji. Fizički, particija nije ništa drugo do poddirektorij u direktoriju tablice.

Recimo da u našoj tablici studentski_detalji imamo podatke za tri odjela - CSE, ECE i Civil. Stoga ćemo imati ukupno tri particije za svaki odjel kako je prikazano na donjoj slici. I za svaki odjel imat ćemo sve podatke koji se tiču ​​tog odjela koji borave u posebnom poddirektorijumu pod imenikom tablice košnica. Na primjer, svi podaci o studentima koji se odnose na Odjele za CSE bit će pohranjeni u user / hive / warehouse / student_details / dept. = CSE. Dakle, upiti u vezi sa studentima CSE morali bi samo pregledati podatke prisutne u particiji CSE-a. To particioniranje čini vrlo korisnim jer smanjuje kašnjenje upita samo skeniranjem relevantne particionirani podaci umjesto cijelog skupa podataka. Zapravo, u stvarnim implementacijama imat ćete posla sa stotinama TB podataka. Dakle, zamislite da skenirate ovu ogromnu količinu podataka za neki upit gdje 95% podaci koje ste skenirali nisu bili relevantni za vaš upit.

Predložio bih vam da prođete kroz blog na Naredbe košnice gdje ćete pronaći različite načine implementacije particija s primjerom.

Kante:

Naredbe:

STVORI TABLICU ime_tablice PODJELJENO (vrsta podataka_ particija1, tip podataka_ particije2 i hellip.) KLASTERIRANO PO (ime_stupaca1, ime_stupca2, ...) RAZREDJENO PO (naziv stupca [ASC | DESC], ...)] U BROJSKE kante

Sada možete podijeliti svaku particiju ili neparticioniranu tablicu u segmente na temelju hash funkcije stupca u tablici. Zapravo, svaki je segment samo datoteka u direktoriju particija ili direktoriju tablice (neparticionirana tablica). Stoga, ako ste odlučili podijeliti particije u n segmenata, imat ćete n datoteka u svakoj od vaših direktorija particija. Na primjer, možete vidjeti gornju sliku gdje smo svaku particiju podijelili u 2 segmenta. Dakle, svaka će particija, recimo CSE, imati dvije datoteke u koje će svaka od njih pohraniti podatke učenika CSE-a.

Kako Hive raspoređuje redove u segmente?

Pa, Hive određuje broj segmenta za red pomoću formule: hash_function (bucketing_column) modulo (num_of_buckets) . Evo, hfunkcija pepela ovisi o tipu podataka stupca. Na primjer, ako tablicu grupirate na temelju nekog stupca, recimo da je user_id, tipa podataka INT, hash_funkcija će biti - hash_function (user_id ) = cijela vrijednost user_id . I, pretpostavimo da ste stvorili dva segmenta, tada će Hive izračunati redove koji idu u segment 1 na svakoj particiji: (vrijednost user_id) modulo (2). Prema tome, u ovom će se slučaju retci koji imaju user_id koji završavaju parom cijelom znamenkom nalaziti u istom segmentu koji odgovara svakoj particiji. Funkcija hash_ za druge tipove podataka pomalo je složena za izračunavanje, a zapravo za niz čak nije ni ljudski prepoznatljiva.

Bilješka: Ako koristite Apache Hive 0.x ili 1.x, morate izdati naredbu - postavite hive.enforce.bucketing = true s vašeg Hive terminala prije izvođenja segmentiranja. To će vam omogućiti da imate točan broj reduktora dok koristite klaster po klauzuli za skupljanje stupaca. U slučaju da to niste učinili, možda ćete utvrditi da broj datoteka koje su generirane u direktoriju vaše tablice nije jednak broju segmenata. Kao alternativu, također možete postaviti broj reduktora jednak broju segmenata koristeći set mapred.reduce.task = num_bucket.

Zašto su nam potrebne kante?

Dva su glavna razloga za izvođenje segmentiranja na particiji:

  • DO map side join zahtijeva da podaci koji pripadaju jedinstvenom ključu za pridruživanje budu prisutni na istoj particiji. Ali što je s onim slučajevima u kojima se vaš particijski ključ razlikuje od pridruživanja? Stoga u tim slučajevima možete izvesti bočno spajanje mapom dodavanjem tablice u ključeve pridruživanjem.
  • Skupljanje čini postupak uzorkovanja učinkovitijim i stoga nam omogućuje da smanjimo vrijeme upita.

Želio bih zaključiti ovaj blog s udžbenicima o košnicama ovdje. Prilično sam siguran da biste nakon prolaska kroz ovaj tutorial blog Hive shvatili jednostavnost Apache Hivea. Od tada ste naučili sve osnove košnice, krajnje je vrijeme da se upoznate s Apache Hive-om. Dakle, pogledajte sljedeći blog u ovoj blogovskoj seriji Hive Tutorial koji je o instalaciji Hive i započnite raditi na Apache Hiveu.

Sad kad ste razumjeli Apache Hive i njegove značajke, pogledajte Edureka, pouzdane tvrtke za internetsko učenje s mrežom od više od 250 000 zadovoljnih učenika raširenih širom svijeta. Edureka tečaj obuke za certificiranje velikih podataka Hadoop pomaže učenicima da postanu stručnjaci za HDFS, pređu, MapReduce, svinju, košnicu, HBase, Oozie, Flume i Sqoop koristeći slučajeve upotrebe u stvarnom vremenu na maloprodaji, društvenim mrežama, zrakoplovstvu, turizmu i financijama.

Imate pitanje za nas? Molimo spomenite to u odjeljku za komentare i javit ćemo vam se.