Hive Tutorial - Hive Architecture și NASA Case Study

Acest blog tutorial Hive vă oferă cunoștințe aprofundate despre Hive Architecture și Hive Data Model. De asemenea, explică studiul de caz al NASA despre Apache Hive.

Tutorial Apache Hive: Introducere

Hive este un instrument riguros utilizat la nivel de industrie pentru Big Data Analytics și un instrument excelent pentru a vă începe cu. În acest blog tutorial Hive, vom discuta în profunzime despre Apache Hive. Apache Hive este un instrument de stocare a datelor din , care oferă limbaj de tip SQL pentru interogarea și analiza Big Data. Motivația din spatele dezvoltării Hive este calea de învățare fără frecare pentru dezvoltatorii și analistii SQL. Hive nu este doar un salvator pentru persoanele care nu provin din programare, ci reduce și munca programatorilor care petrec ore lungi scriind programe MapReduce. În acest blog Tutorial Apache Hive, voi vorbi despre:





Tutorial Apache Hive: Ce este Hive?

Apache Hive este un sistem de depozitare a datelor construit deasupra Hadoop și este utilizat pentru analiza datelor structurate și semi-structurate.Hive abstractizează complexitatea Hadoop MapReduce. Practic, oferă un mecanism pentru proiectarea structurii pe date și efectuarea de interogări scrise în HQL (Hive Query Language) care sunt similare cu instrucțiunile SQL. Pe plan intern, aceste interogări sau HQL sunt convertite în hartă pentru reducerea locurilor de muncă de către compilatorul Hive. Prin urmare, nu trebuie să vă faceți griji cu privire la scrierea de programe complexe MapReduce pentru a vă procesa datele folosind Hadoop. Este destinat utilizatorilor care se simt confortabil cu SQL. Apache Hive acceptă limbajul de definire a datelor (DDL), limbajul de manipulare a datelor (DML) și funcțiile definite de utilizator (UDF).

Tutorial Hive pentru începători | Înțelegerea stupului în adâncime | Edureka



SQL + Hadoop MapReduce = HiveQL

Tutorial Apache Hive: Story of Hive - de la Facebook la Apache

Facebook Use Case - Hive Tutorial - EdurekaSmochin : Tutorial Hive - caz de utilizare Facebook

Provocări pe Facebook: Creșterea exponențială a datelor

Înainte de 2008, toată infrastructura de procesare a datelor din Facebook a fost construită în jurul unui depozit de date bazat pe RDBMS comercial. Aceste infrastructuri erau suficient de capabile să satisfacă nevoile Facebook de atunci. Dar, pe măsură ce datele au început să crească foarte repede, a devenit o provocare uriașă gestionarea și procesarea acestui set de date imens. Potrivit unui articol de pe Facebook, datele au crescut de la un set de date de 15 TB în 2007 la un număr de 2 PB în 2009. De asemenea, multe produse Facebook implică analiza datelor precum Audience Insights, Facebook Lexicon, Facebook Ads etc. a avut nevoie de o soluție scalabilă și economică pentru a face față acestei probleme și, prin urmare, a început să utilizeze cadrul Hadoop.



Democratizând Hadoop - MapReduce

Dar, pe măsură ce datele au crescut, complexitatea codurilor Map-Reduce a crescut proporțional. Așadar, instruirea persoanelor cu un background care nu este programator să scrie programe MapReduce a devenit dificilă. De asemenea, pentru efectuarea unei analize simple, trebuie să scrieți o sută de linii de cod MapReduce. Întrucât SQL a fost utilizat pe scară largă de ingineri și analiști, inclusiv de Facebook, prin urmare, punerea SQL pe partea de sus a Hadoop părea o modalitate logică de a face Hadoop accesibil utilizatorilor cu background SQL.

Prin urmare, abilitatea SQL de a fi suficientă pentru majoritatea cerințelor analitice și scalabilitatea Hadoop au dat naștere Apache Hive care permite efectuarea de interogări de tip SQL pe datele prezente în HDFS. Mai târziu, proiectul Hive a fost deschis în august 2008 de către Facebook și este disponibil gratuit ca Apache Hive astăzi.

Acum, să ne uităm la caracteristicile sau avantajele Hive care îl fac atât de popular.

Tutorial Apache Hive: Avantajele Hive

  • Util pentru persoanele care nu provin din mediul de programare, deoarece elimină necesitatea de a scrie un program complex MapReduce.
  • Extensibil și scalabil pentru a face față volumului și varietății de date în creștere, fără a afecta performanțele sistemului.
  • Este ca un instrument ETL eficient (Extract, Transform, Load).
  • Hive acceptă orice aplicație client scrisă în Java, PHP, Python, C ++ sau Ruby prin expunerea acesteia Thrift server . (Puteți utiliza aceste limbaje din partea clientului încorporate în SQL pentru accesarea unei baze de date precum DB2 etc.).
  • Deoarece informațiile despre metadatele Hive sunt stocate într-un RDBMS, reduce semnificativ timpul pentru efectuarea verificărilor semantice în timpul executării interogării.

Tutorial Apache Hive: Unde se folosește Apache Hive?

Apache Hive profită de ambele lumi, adică Sistemul de baze de date SQL și cadru. Prin urmare, este folosit de o mare multitudine de companii. Este utilizat în principal pentru depozitarea datelor, unde puteți efectua analize și extrageri de date care nu necesită procesare în timp real. Unele dintre câmpurile în care puteți utiliza Apache Hive sunt următoarele:

  • Depozitarea datelor
  • Analiză ad-hoc

După cum se spune, nu puteți bate din palme cu o singură mână, adică nu puteți rezolva fiecare problemă cu un singur instrument. Prin urmare, puteți cupla Hive cu alte instrumente pentru al utiliza în multe alte domenii. De exemplu, Tableau împreună cu Apache Hive pot fi utilizate pentru vizualizarea datelor, integrarea Apache Tez cu Hive vă va oferi capacități de procesare în timp real etc.
Mergând mai departe în acest blog Apache Hive Tutorial, permiteți-ne să aruncăm o privire la un studiu de caz al NASA în care veți afla cum Hive a rezolvat problema cu care oamenii de știință NASA se confruntau în timp ce efectuau evaluarea modelelor climatice.

Tutorial Hive: Studiu de caz NASA

Un model climatic este o reprezentare matematică a sistemelor climatice bazată pe diverși factori care au impact asupra climatului Pământului. Practic, descrie interacțiunea diferiților factori climatici precum oceanul, soarele, atmosfera etc.oferă o perspectivă asupra dinamicii sistemului climatic. Este folosit pentru a proiecta condițiile climatice prin simularea schimbărilor climatice pe baza factorilor care afectează clima. Laboratorul de propulsie cu jet al NASA a dezvoltat un sistem regional de evaluare a modelului climatic (RCMES) pentru analiza și evaluarea modelului de producție climatică în raport cu datele de teledetecție prezente în diferite depozite externe.

RCMES (Sistemul regional de evaluare a modelului climatic) are două componente:

  • RCMED (Baza de date de evaluare a modelului climatic regional):

Este o bază de date cloud scalabilă care încarcă datele de teledetecție și datele de reanaliză care sunt legate de climă folosind extractoare precum extractoare Apache OODT, Apache Tika etc. În cele din urmă, transformă datele ca model de punct de date care este de formă (latitudine , longitudine, timp, valoare, înălțime) și o stochează în baza de date My SQL. Clientul poate prelua datele prezente în RCMED efectuând interogări Spațiu / Timp. Descrierea unor astfel de interogări nu este relevantă pentru noi acum.

  • RCMET (set de instrumente de evaluare a modelului climatic regional):

Acesta oferă utilizatorului posibilitatea de a compara datele de referință prezente în RCMED cu datele de ieșire ale modelului climatic preluate din alte surse pentru a efectua diferite tipuri de analiză și evaluare. Puteți consulta imaginea dată mai jos pentru a înțelege arhitectura RCMES.

Datele de referință din RCMED provin de la teledetecție prin satelit, conform diferiților parametri necesari pentru evaluarea modelului climatic. De exemplu - AIRS (Sonda Infraroșie Atmosferică) oferă parametri precum temperatura aerului de suprafață, temperatura și Geopotențial, TRMM (Misiunea de măsurare a precipitațiilor tropicale) oferă precipitații lunare etc.

Probleme cu care se confruntă NASA folosind sistemul de baze de date MySQL:

  • După încărcarea bazei de date MySQL cu 6 miliarde de tupluri ale formularului (latitudine, longitudine, timp, valoarea punctului de date, înălțime), sistemul s-a blocat așa cum se arată în imaginea de mai sus.
  • Chiar și după împărțirea întregului tabel în subseturi mai mici, sistemul a generat o cheltuială imensă în timpul procesării datelor.

Deci, aveau nevoie de o soluție scalabilă care poate stoca și procesa această cantitate uriașă de date cu SQL, cum ar fi capacitatea de interogare. În cele din urmă, au decis să folosească Apache Hive pentru a depăși problemele menționate mai sus.

Cum Apache Hive poate rezolva problema?

Acum, să vedem, care sunt acele caracteristici care au convins echipa JPL a NASA să includă Apache Hive ca parte integrantă în strategia lor de soluții:

  • Întrucât Apache Hive rulează pe Hadoop, este scalabil și poate prelucra date într-un mod distribuit și paralel.
  • Oferă Hive Query Language, care este similar cu SQL și, prin urmare, ușor de învățat.

Implementarea stupului:

Următoarea imagine explică arhitectul RCMES cu integrare Apache Hive:

care sunt filtrele de context în tablou

Smochin : Tutorial Hive - Arhitectură RCMES cu Apache Hive

Imaginea de mai sus arată desfășurarea stupului apache în RCMES. Următorii pași au fost luați de echipa NASA în timpul implementării Apache Hive:

  • Au instalat Hive folosind Cloudera și Apache Hadoop așa cum se arată în imaginea de mai sus.
  • Au folosit Apache Sqoop pentru a ingera date în Hive din baza de date MySQL.
  • Apache OODT wrapper a fost implementat pentru a efectua interogări pe Hive și pentru a recupera datele înapoi la RCMET.

Observații inițiale de comparare cu Hive:

  • Inițial, au încărcat 2,5 miliarde de puncte de date într-un singur tabel și au efectuat o interogare de numărare. De exemplu, Stup> selectați număr (datapoint_id) din dataPoint. Au fost necesare 5-6 minute pentru a număra toate înregistrările (15-17 minute pentru 6,8 miliarde de înregistrări complete).
  • Faza de reducere a fost rapidă, dar faza de hartă a durat 95% din timpul total de procesare. Foloseau șase ( 4x quad-core ) sisteme cu 24 GB RAM (aprox.) în fiecare dintre sisteme.
  • Chiar și după adăugarea mai multor mașini, modificarea dimensiunii blocului HDFS (64 MB, 128 MB, 256 MB) și modificarea multor alte variabile de configurare (io.fel.factor, i.fel.mb), nu au obținut prea mult succes în reducerea timpului pentru finalizarea numărării.

Contribuții de la membrii comunității Hive:

În cele din urmă, membrii comunității Hive au venit în salvare și au oferit diverse informații pentru a rezolva problemele cu implementările lor curente Hive:

  • Au menționat că viteza de citire HDFS este de aproximativ 60 MB / s în comparație cu 1 GB / s în cazul unui disc local, în funcție de capacitatea rețelei și de volumul de lucru de pe NameNode.
  • Membrii au sugerat că 16 cartografi vor fi necesare în sistemul lor actual pentru a se potrivi cu performanța I / O a unei sarcini locale non-Hadoop.
  • De asemenea, au sugerat reducerea divizat pentru ca fiecare cartograf să crească număruldecartografilor și, prin urmare, oferind mai mult paralelism.
  • În cele din urmă, membrii comunității le-au spus număr de utilizări (1) în loc să se refere la numara ( date_punct_id) . Acest lucru se datorează faptului că, în cazul numărării (1), nu există o coloană de referință și, prin urmare, nu are loc decompresie și deserializare în timpul efectuării numărării.

În cele din urmă, NASA a reușit să își adapteze grupul Hive la nivelul așteptărilor lor, luând în considerare toate sugestiile date de membrii comunității Hive. Prin urmare, au putut interoga miliarde de rânduri în doar 15 secunde folosind configurațiile de sistem menționate mai sus.

Tutorial Apache Hive: Arhitectura stupului și componentele sale

Următoarea imagine descrie Arhitectura Hive și fluxul în care este trimisă o interogareStupși în cele din urmă procesate folosind cadrul MapReduce:

Smochin : Tutorial Hive - Arhitectura stupului

Așa cum se arată în imaginea de mai sus, Arhitectura stupului poate fi clasificată în următoarele componente:

  • Clienți Hive: Hive acceptă aplicații scrise în multe limbi cum ar fi Java, C ++, Python etc. folosind driverele JDBC, Thrift și ODBC. Prin urmare, se poate scrie oricând aplicația client de tip stup scris într-o limbă la alegere.
  • Servicii de stup: Apache Hive oferă diverse servicii precum CLI, interfață web etc. pentru a efectua interogări. Le vom explora pe fiecare în scurt timp în acest blog tutorial Hive.
  • Cadrul de procesare și gestionarea resurselor: Intern,Hive folosește cadrul Hadoop MapReduce ca motor de facto pentru a executa interogările. este un subiect separat în sine și, prin urmare, nu este discutat aici.
  • Stocare distribuită: Deoarece Hive este instalat deasupra Hadoop, folosește HDFS-ul de bază pentru stocarea distribuită. Puteți face referire la Blog HDFS pentru a afla mai multe despre asta.

Acum, haideți să explorăm primele două componente majore din Arhitectura Hive:

1. Clienți Hive:

Apache Hive acceptă diferite tipuri de aplicații client pentru efectuarea de interogări pe Hive. Acești clienți pot fi clasificați în trei tipuri:

  • Clienți Thrift: Deoarece serverul Hive se bazează pe Apache Thrift, acesta poate servi cererea de la toate acele limbaje de programare care acceptă Thrift.
  • Clienți JDBC: Hive permite aplicațiilor Java să se conecteze la acesta utilizând driverul JDBC care este definit în clasa org.apache.hadoop.stup.jdbc.HiveDriver.
  • Clienți ODBC: Driverul HBC ODBC permite aplicațiilor care acceptă protocolul ODBC să se conecteze la Hive. (La fel ca driverul JDBC, driverul ODBC folosește Thrift pentru a comunica cu serverul Hive.)

2. Servicii de stup:

Hive oferă multe servicii, așa cum se arată în imaginea de mai sus. Să ne uităm la fiecare dintre ele:

  • Hive CLI (Command Line Interface): Acesta este shell-ul implicit furnizat de Hive, unde puteți executa direct interogările și comenzile Hive.
  • Interfețe web Apache Hive: În afară de interfața liniei de comandă, Hive oferă, de asemenea, o interfață grafică web pentru executarea interogărilor și comenzilor Hive.
  • Server Hive: Serverul Hive este construit pe Apache Thrift și, prin urmare, este denumit și Thrift Server, care permite clienților diferiți să trimită cereri către Hive și să recupereze rezultatul final.
  • Driver Apache Hive: Este responsabil pentru primirea interogărilor trimise prin CLI, UI web, Thrift, ODBC sau interfețele JDBC de către un client. Apoi, driverul transmite interogarea către compilator unde are loc analiza, verificarea tipului și analiza semantică cu ajutorul schemei prezente în metastore.. În pasul următor, se generează un plan logic optimizat sub forma unui DAG (grafic aciclic direcționat) de sarcini de reducere a hărții și sarcini HDFS. În cele din urmă, motorul de execuție execută aceste sarcini în ordinea dependențelor lor, utilizând Hadoop.
  • Metastore: Puteți gândi metastoreca un depozit central pentru stocarea tuturor informațiilor despre metadatele Hive. Metadatele Hive includ diverse tipuri de informații, cum ar fi structura tabelelor și partițiileîmpreună cu coloana, tipul coloanei, serializatorul și deserializatorul care sunt necesare pentru operația de citire / scriere a datelor prezente în HDFS. Metastorecuprinde două unități fundamentale:
    • Un serviciu care oferă metastoreacces la altelerServicii stup.
    • Stocare pe disc pentru metadatele care sunt separate de stocarea HDFS.

Acum, să înțelegem diferitele moduri de implementare a metastorei Hiveîn următoarea secțiune a acestui tutorial Hive.

Tutorial Apache Hive: Configurare Metastore

Metastore stochează informațiile meta date folosind RDBMS și un strat open source ORM (Object Relational Model) numit Data Nucleus care convertește reprezentarea obiectului în schemă relațională și invers. Motivul alegerii RDBMS în loc de HDFS este pentru a obține o latență scăzută. Putem implementa metastore în următoarele trei configurații:

1. Metastore încorporat:

Atât serviciul metastore, cât și serviciul Hive rulează în același JVM în mod implicit, utilizând o instanță încorporată Derby Database în care metadatele sunt stocate pe discul local. Aceasta se numește configurație metastore încorporată. În acest caz, un singur utilizator se poate conecta la baza de date metastore la un moment dat. Dacă porniți o a doua instanță a driverului Hive, veți primi o eroare. Acest lucru este bun pentru testarea unității, dar nu și pentru soluțiile practice.

2. Metastore local:

Această configurație ne permite să avem mai multe sesiuni Hive, adică mai mulți utilizatori pot utiliza baza de date metastore în același timp. Acest lucru se realizează prin utilizarea oricărei baze de date conforme JDBC, cum ar fi MySQL, care rulează într-o JVM separată sau într-o altă mașină decât cea a serviciului Hive și a serviciului metastore care rulează în aceeași JVM așa cum se arată mai sus. În general, cea mai populară alegere este de a implementa un server MySQL ca bază de date metastore.

3. Metastore la distanță:

În configurația metastore la distanță, serviciul metastore rulează pe propriul JVM separat și nu în serviciul Hive JVM. Alte procese comunică cu serverul metastore folosind API-urile Thrift Network. Puteți avea unul sau mai multe servere de metastore în acest caz pentru a oferi mai multă disponibilitate.Principalul avantaj al utilizării metastore-ului la distanță este că nu trebuie să partajați datele de conectare JDBC cu fiecare utilizator Hive pentru a accesa baza de date metastore.

Tutorial Apache Hive: Model de date

Datele din Hive pot fi clasificate în trei tipuri la nivel granular:

  • Masa
  • Partiție
  • Găleată

Mese:

Tabelele din Hive sunt aceleași cu tabelele prezente într-o bază de date relațională. Puteți efectua operații de filtrare, proiectare, alăturare și unire asupra acestora. Există două tipuri de tabele în Hive:

1. Tabel gestionat:

Comanda:

Întrebări despre interviul Google Data Scientist

CREARE TABEL (coloana1 tip_date, coloană2 tip_date)

ÎNCĂRCAȚI INPATHUL DE DATE ÎN tabelul administrat_tabel

După cum sugerează și numele (tabelul gestionat), Hive este responsabil pentru gestionarea datelor unui tabel gestionat. Cu alte cuvinte, ceea ce am vrut să spun prin „Hive gestionează datele”, este că dacă încărcați datele dintr-un fișier prezent în HDFS într-un Hive Tabel gestionat și emiteți o comandă DROP pe acesta, tabelul împreună cu metadatele sale vor fi șterse. Deci, datele aparținând celor scăpați administrat_tabel nu mai există nicăieri în HDFS și nu îl puteți recupera în niciun fel. Practic, mutați datele când lansați comanda LOAD din locația fișierului HDFS în directorul depozitului Hive.

Notă: Calea implicită a directorului depozitului este setată la / user / hive / warehouse. Datele unui tabel Hive se află în directorul_depozit / nume_tabel (HDFS). De asemenea, puteți specifica calea directorului depozitului în parametrul de configurare hive.metastore.warehouse.dir prezent în hive-site.xml.

2. Tabel extern:

Comanda:

CREAȚI TABEL EXTERN (coloana1 tip_date, coloană2 tip_date) LOCAȚIE „”

ÎNCĂRCAȚI INPATHUL DE DATE ‘’ ÎN TABEL

Pentru masa externa , Hive nu este responsabil pentru gestionarea datelor. În acest caz, când lansați comanda LOAD, Hive mută datele în directorul său de depozit. Apoi, Hive creează informațiile de metadate pentru tabelul extern. Acum, dacă lansați o comandă DROP pe masa externa , vor fi șterse numai informațiile despre metadate referitoare la tabelul extern. Prin urmare, puteți retrage în continuare datele din acel tabel foarte extern din directorul depozitului utilizând comenzi HDFS.

Partiții:

Comanda:

CREATE TABLE nume_tabel (coloană1 tip_date, coloană2 tip_date) PARTIȚIONAT DE (partiție1 tip_date, partiție2 tip_date și hellip.)

Hive organizează tabele în partiții pentru a grupa tipuri similare de date împreună pe baza unei coloane sau a unei chei de partiție. Fiecare tabel poate avea una sau mai multe chei de partiție pentru a identifica o anumită partiție. Acest lucru ne permite să avem o interogare mai rapidă pe felii de date.

Notă: Amintiți-vă, cea mai frecventă greșeală făcută la crearea partițiilor este să specificați un nume de coloană existent ca coloană de partiție. În acest timp, veți primi o eroare - „Eroare în analiza semantică: Coloană repetată în coloanele de partiționare”.

Să înțelegem partiția luând un exemplu în care am un tabel student_details care conține informațiile despre studenți ale unor facultăți de inginerie precum student_id, nume, departament, an etc. Acum, dacă fac partiționare pe baza coloanei departamentului, informațiile tuturor studenților apartenența la un anumit departament va fi stocată împreună chiar în acea partiție. Fizic, o partiție nu este altceva decât un subdirector din directorul tabelului.

Să presupunem că avem date pentru trei departamente în tabelul nostru student_details - CSE, ECE și Civil. Prin urmare, vom avea trei partiții în total pentru fiecare departament așa cum se arată în imaginea de mai jos. Și, pentru fiecare departament, vom avea toate datele referitoare la acel departament care se află într-un subdirector separat sub directorul tabelului Hive. De exemplu, toate datele studenților referitoare la departamentele CSE vor fi stocate în user / hive / warehouse / student_details / dept. = CSE. Deci, interogările cu privire la studenții CSE ar trebui să analizeze doar datele prezente în partiția CSE. Acest lucru face ca partiționarea să fie foarte utilă, deoarece reduce latența interogării doar prin scanare relevante partiționat date în loc de întregul set de date. De fapt, în implementările din lumea reală, veți avea de-a face cu sute de TB de date. Deci, imaginați-vă scanarea acestei cantități uriașe de date pentru o întrebare unde 95% datele scanate de dvs. nu au fost relevante pentru interogarea dvs.

V-aș sugera să treceți prin blog pe Comenzi Hive unde veți găsi diferite moduri de implementare a partițiilor cu un exemplu.

Cupe:

Comenzi:

CREATE TABLE table_name PARTITIONED BY (partition1 data_type, partition2 data_type, & hellip.) CLUSTERED BY (column_name1, column_name2, ...) SORTED BY (column_name [ASC | DESC], ...)] IN num_buckets BUCKETS

Acum, puteți împărți fiecare partiție sau tabela nepartitionată în găleți pe baza funcției hash a unei coloane din tabel. De fapt, fiecare bucket este doar un fișier din directorul partiției sau directorul tabelului (tabel nepartitionat). Prin urmare, dacă ați ales să împărțiți partițiile în n cupe, veți avea n fișiere în fiecare din directorul de partiție. De exemplu, puteți vedea imaginea de mai sus în care am compartimentat fiecare partiție în 2 găleți. Deci, fiecare partiție, spune CSE, va avea două fișiere în care fiecare dintre ele va stoca datele elevului CSE.

funcția de sortare c ++

Cum distribuie Hive rândurile în găleți?

Ei bine, Hive determină numărul cupei pentru un rând folosind formula: hash_function (bucketing_column) modulo (num_of_buckets) . Aici, hfuncția_cenușă depinde de tipul de date al coloanei. De exemplu, dacă colectați tabelul pe baza unei coloane, să presupunem user_id, din tipul de date INT, funcția hash_ va fi - funcție_hash (user_id ) = valoarea întregului user_id . Și, să presupunem că ați creat două găleți, atunci Hive va determina rândurile care merg la cupa 1 în fiecare partiție, calculând: (valoarea user_id) modulo (2). Prin urmare, în acest caz, rândurile care au user_id care se termină cu o cifră întreagă pare vor locui într-un același compartiment corespunzător fiecărei partiții. Funcția hash_ pentru alte tipuri de date este puțin complexă de calculat și, de fapt, pentru un șir nici măcar nu este recunoscută uman.

Notă: Dacă utilizați Apache Hive 0.x sau 1.x, trebuie să lansați comanda - set hive.enforce.bucketing = true de la terminalul Hive înainte de a efectua bucketing. Acest lucru vă va permite să aveți numărul corect de reductor în timp ce utilizați clauza cluster prin clauză pentru colectarea unei coloane. În cazul în care nu ați făcut-o, este posibil să găsiți că numărul de fișiere care a fost generat în directorul tabelelor dvs. nu este egal cu numărul de cupe. Ca alternativă, puteți seta, de asemenea, numărul reductorului egal cu numărul de găleți utilizând set mapred.reduce.task = num_bucket.

De ce avem nevoie de găleți?

Există două motive principale pentru efectuarea bucketingului către o partiție:

  • LA harta laterală se alătură necesită ca datele care aparțin unei chei de unire unice să fie prezente în aceeași partiție. Dar cum rămâne cu acele cazuri în care cheia de partiție diferă de unire? Prin urmare, în aceste cazuri puteți efectua o asociere laterală a hărții buclând tabelul folosind cheia de asociere.
  • Bucketing face procesul de eșantionare mai eficient și, prin urmare, ne permite să reducem timpul de interogare.

Aș dori să închei aici acest blog tutorial Hive. Sunt destul de sigur că, după ce ați parcurs acest blog tutorial Hive, ați fi realizat simplitatea Apache Hive. De atunci, voi ați învățat toate fundamentele Hive, este timpul să aveți experiență practică cu Apache Hive. Așadar, verificați următorul blog din această serie de bloguri Hive Tutorial care se află în instalarea Hive și începeți să lucrați la Apache Hive.

Acum că ați înțeles Apache Hive și caracteristicile sale, consultați de Edureka, o companie de învățare online de încredere, cu o rețea de peste 250.000 de elevi mulțumiți răspândiți pe tot globul. Cursul Edureka Big Data Hadoop Certification Training îi ajută pe cursanți să devină experți în HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume și Sqoop folosind cazuri de utilizare în timp real în domeniul Retail, Social Media, Aviație, Turism, Finanțe.

Ai o întrebare pentru noi? Vă rugăm să o menționați în secțiunea de comentarii și vă vom răspunde.