Výukový program Úľov - Úlová architektúra a prípadová štúdia NASA



Tento blog s príručkou o úli vám poskytuje podrobné informácie o architektúre úľov a dátovom modeli úľa. Vysvetľuje to aj prípadovú štúdiu NASA o úli Apache.

Výukový program Apache Hive: Úvod

Hive je dôsledne používaný priemyselný nástroj pre analýzu veľkých dát a skvelý nástroj na začatie práce s. V tomto výučbovom blogu Hive budeme podrobne diskutovať o Apache Hive. Apache Hive je nástroj na ukladanie údajov v systéme Windows , ktorý poskytuje jazyk podobný SQL na dopytovanie a analýzu veľkých dát. Motiváciou vývoja Hive je cesta učenia sa bez trenia pre vývojárov a analytikov SQL. Úľ je nielen záchrancom pre ľudí z neprogramátorského prostredia, ale tiež znižuje prácu programátorov, ktorí trávia dlhé hodiny písaním programov MapReduce. V tomto blogu Apache Hive Tutorial budem hovoriť o:





Výukový program Apache Hive: Čo je to Hive?

Apache Hive je systém dátových skladov postavený na platforme Hadoop a používa sa na analýzu štruktúrovaných a pološtruktúrovaných údajov.Úľ abstrahuje od komplexnosti Hadoop MapReduce. V zásade poskytuje mechanizmus na premietnutie štruktúry do dát a vykonávanie dotazov napísaných v jazyku HQL (Hive Query Language), ktoré sú podobné príkazom SQL. Interne sa tieto dotazy alebo HQL prevedú na úlohy zmenšujúce mapu pomocou kompilátora Hive. Preto sa nemusíte starať o písanie zložitých programov MapReduce na spracovanie vašich údajov pomocou Hadoop. Je zameraný na používateľov, ktorým vyhovuje SQL. Apache Hive podporuje Data Definition Language (DDL), Data Manipulation Language (DML) a User Defined Functions (UDF).

Výukový program pre úle pre začiatočníkov Pochopenie Hive In Depth Edureka



SQL + Hadoop MapReduce = HiveQL

Výukový program Apache Hive: Story of Hive - od Facebooku po Apache

Prípad použitia na Facebooku - Výučba úľov - EdurekaObr : Hive Tutorial - Prípad použitia Facebooku

Výzvy na Facebooku: Exponenciálny rast dát

Pred rokom 2008 bola všetka infraštruktúra na spracovanie údajov na Facebooku postavená na dátovom sklade založenom na komerčných RDBMS. Tieto infraštruktúry boli v tom čase dostatočne schopné uspokojiť potreby Facebooku. Ale keďže dáta začali veľmi rýchlo rásť, stalo sa obrovskou výzvou spravovať a spracovávať tento obrovský súbor údajov. Podľa článku na Facebooku sa údaje škálovali z 15 TB dátovej sady v roku 2007 na 2 PB dáta v roku 2009. Mnoho produktov Facebooku tiež zahrnuje analýzu údajov, ako sú Audience Insights, Facebook Lexicon, Facebook Ads atď. Aby sme sa vyrovnali s týmto problémom, potrebovali sme škálovateľné a ekonomické riešenie, a preto som začal používať rámec Hadoop.



Demokratizujúce Hadoop - MapReduce

Ako však rástli údaje, proporcionálne narastala aj zložitosť kódov Map-Reduce. Takže školenie ľudí s neprogramovacím zázemím na písanie programov MapReduce bolo ťažké. Pre vykonanie jednoduchej analýzy je tiež potrebné napísať sto riadkov kódu MapReduce. Pretože SQL bolo inžiniermi a analytikmi, vrátane Facebooku, hojne využívané, javilo sa uvedenie SQL na vrch Hadoop logickým spôsobom, ako Hadoop sprístupniť používateľom s pozadím SQL.

Preto schopnosť SQL postačovať na väčšinu analytických požiadaviek a škálovateľnosť Hadoopu zrodila Apache Hive , ktorý umožňuje vykonávať dotazy typu SQL na dáta prítomné v HDFS. Neskôr bol projekt Hive otvorený v auguste 2008 spoločnosťou Facebook a dnes je voľne dostupný ako Apache Hive.

Teraz sa pozrime na funkcie alebo výhody Hive, vďaka ktorým je taký populárny.

Výukový program Apache Hive: Výhody úľa

  • Je to užitočné pre ľudí, ktorí nepochádzajú z programovacieho prostredia, pretože eliminuje potrebu písať zložitý program MapReduce.
  • Rozšíriteľné a škálovateľný vyrovnať sa s rastúcim objemom a rozmanitosťou údajov bez toho, aby to malo vplyv na výkon systému.
  • Je to ako efektívny nástroj ETL (Extract, Transform, Load).
  • Hive podporuje všetky klientske aplikácie napísané v jazykoch Java, PHP, Python, C ++ alebo Ruby tým, že ich vystavuje Šetrný server . (Tieto jazyky na strane klienta vložené do jazyka SQL môžete použiť na prístup k databáze, ako je DB2, atď.).
  • Pretože sú metaúdajové informácie Hive uložené v RDBMS, výrazne to skracuje čas potrebný na vykonávanie sémantických kontrol počas vykonávania dotazu.

Výukový program Apache Hive: Kde používať Apache Hive?

Apache Hive využíva výhody oboch svetov, t. J. SQL Database System a rámec. Preto ho využíva obrovské množstvo spoločností. Väčšinou sa používa na dátové sklady, kde môžete vykonávať analýzy a ťažbu dát, ktoré nevyžadujú spracovanie v reálnom čase. Niektoré z polí, kde môžete použiť Apache Hive, sú nasledujúce:

  • Skladovanie údajov
  • Ad-hoc analýza

Ako sa hovorí, tlieskať nemôžete iba jednou rukou, t. J. Každý problém nevyriešite pomocou jedného nástroja. Preto môžete Hive spárovať s inými nástrojmi a použiť ho v mnohých ďalších doménach. Napríklad Tableau spolu s Apache Hive možno použiť na vizualizáciu údajov, integrácia Apache Tez s Hive vám poskytne možnosti spracovania v reálnom čase atď.
Ďalej v tomto blogu Apache Hive Tutorial sa pozrime na prípadovú štúdiu NASA, kde sa dozviete, ako Hive vyriešil problém, ktorému čelili vedci NASA pri hodnotení klimatických modelov.

Výukový program Hive: Prípadová štúdia NASA

Klimatický model je matematické znázornenie klimatických systémov založené na rôznych faktoroch, ktoré majú vplyv na podnebie Zeme. V zásade popisuje interakciu rôznych činiteľov podnebia ako oceán, slnko, atmosféra atď. Sposkytujú pohľad na dynamiku klimatického systému. Používa sa na projektovanie klimatických podmienok simuláciou klimatických zmien na základe faktorov, ktoré ovplyvňujú podnebie. Laboratórium Jet Propulsion Laboratory NASA vyvinulo Regionálny systém hodnotenia podnebia (RCMES) na analýzu a hodnotenie modelu výstupu podnebia oproti údajom diaľkového prieskumu terénu, ktoré sa nachádzajú v rôznych externých úložiskách.

RCMES (Regional Climate Model Evaluation System) má dve zložky:

  • RCMED (regionálna hodnotiaca databáza klimatických modelov):

Jedná sa o škálovateľnú cloudovú databázu, ktorá načítava údaje vzdialeného snímania a údaje o opätovnej analýze súvisiace s podnebím pomocou extraktorov, ako sú extraktory Apache OODT, Apache Tika atď. Nakoniec tieto údaje transformuje ako model dátového bodu, ktorý je vo forme (zemepisná šírka zemepisná dĺžka, čas, hodnota, výška) a uloží sa do databázy My SQL. Klient môže načítať údaje prítomné v RCMED vykonaním dotazov časopriestoru. Popis takýchto dotazov pre nás v súčasnosti nie je relevantný.

radič zobrazenia modelu v jave
  • RCMET (sada nástrojov na hodnotenie regionálnych klimatických modelov):

Poskytuje používateľovi možnosť porovnávať referenčné údaje nachádzajúce sa v RCMED s výstupnými údajmi o klimatickom modeli získanými z niektorých iných zdrojov s cieľom vykonať rôzne druhy analýz a vyhodnotení. Na pochopenie architektúry RCMES môžete odkazovať na nasledujúcom obrázku.

Referenčné údaje v RCMED pochádzajú zo satelitného diaľkového snímania podľa rôznych parametrov požadovaných pre hodnotenie klimatického modelu. Napríklad - AIRS (Atmosférický infračervený sirén) poskytuje parametre, ako je teplota povrchového vzduchu, teplota a geopotenciál, TRMM (misia na meranie tropických zrážok) poskytuje mesačné zrážky atď.

Problémy, ktorým čelí NASA pri využívaní databázového systému MySQL:

  • Po načítaní databázy MySQL so 6 miliardami n-tíc formy (zemepisná šírka, dĺžka, čas, hodnota dátových bodov, výška) došlo k zlyhaniu systému, ako je to znázornené na obrázku vyššie.
  • Aj po rozdelení celej tabuľky na menšie podmnožiny systém vygeneroval pri spracovaní údajov obrovskú réžiu.

Potrebovali teda škálovateľné riešenie, ktoré by dokázalo ukladať a spracovávať toto obrovské množstvo údajov pomocou technológie SQL, ako je napríklad dopytovanie. Nakoniec sa rozhodli použiť Apache Hive na prekonanie vyššie uvedených problémov.

Ako môže Apache Hive vyriešiť problém?

Teraz sa pozrime, aké sú funkcie, ktoré presvedčili tím JPL NASA, aby zahrnul Apache Hive ako neoddeliteľnú súčasť svojej stratégie riešenia:

  • Pretože Apache Hive beží nad Hadoopom, je škálovateľný a dokáže spracovávať dáta distribuovaným a paralelným spôsobom.
  • Poskytuje jazyk Hive Query Language, ktorý je podobný jazyku SQL, a preto sa dá ľahko naučiť.

Nasadenie úľa:

Nasledujúci obrázok vysvetľuje RCMES Architect s integráciou Apache Hive:

Obr : Hive Tutorial - RCMES Architecture with Apache Hive

ako používať tostring v jave -

Vyššie uvedený obrázok ukazuje nasadenie úľa Apache v RCMES. Tím NASA pri nasadení Apache Hive urobil nasledujúce kroky:

  • Nainštalovali si Úľ pomocou služieb Cloudera a Apache Hadoop, ako je to znázornené na obrázku vyššie.
  • Použili Apache Sqoop na príjem údajov do úľa z databázy MySQL.
  • Na vykonávanie dotazov v úli a na načítanie údajov späť do RCMET bol implementovaný obal Apache OODT.

Počiatočné pozorovania pri porovnávaní s úľom:

  • Spočiatku načítali 2,5 miliardy dátových bodov do jednej tabuľky a vykonali dotaz na počet. Napríklad, Úľ> vyberte počet (datapoint_id) z dataPoint. Spočítanie všetkých záznamov trvalo 5-6 minút (15–17 minút pre celých 6,8 miliárd záznamov).
  • Fáza redukcie bola rýchla, ale fáza mapy trvala 95% z celkového času spracovania. Používali šesť ( 4x štvorjadrový ) systémy s 24 GB RAM (približne) v každom zo systémov.
  • Aj po pridaní ďalších strojov, zmene veľkosti bloku HDFS (64 MB, 128 MB, 256 MB) a zmene mnohých ďalších konfiguračných premenných (io.triediť.faktor, t.j..triediť.mb), nezískali veľa úspechov v skrátení času na dokončenie počítania.

Príspevky od členov komunity Hive:

Na záver prišli na pomoc členovia komunity Hive a poskytli rôzne pohľady na riešenie problémov s ich aktuálnymi implementáciami Hive:

  • Uviedli, že rýchlosť čítania HDFS je približne 60 MB / s v porovnaní s 1 GB / s v prípade lokálneho disku v závislosti od kapacity siete a pracovného zaťaženia v NameNode.
  • Členovia to navrhli 16 mapovačov sa v ich súčasnom systéme bude vyžadovať zhoda s I / O výkonom miestnej úlohy, ktorá nie je Hadoop.
  • Navrhli tiež znížiť rozdelená veľkosť pre každého mapovača zvýšiť početzmapovače, a preto poskytujú viac paralelizmu.
  • Nakoniec im to členovia komunity povedali počet použití (1) namiesto odkazovania na počítať ( datapoint_id) . Je to tak preto, lebo v prípade count (1) neexistuje referenčný stĺpec, a preto počas vykonávania count nedôjde k žiadnej dekompresii a deserializácii.

Nakoniec bola NASA schopná vyladiť svoj klaster Úľov podľa svojich očakávaní tak, že zohľadnila všetky návrhy poskytnuté členmi komunity Hive. A preto pomocou systémových konfigurácií uvedených vyššie dokázali dopytovať miliardy riadkov za pouhých 15 sekúnd.

Výukový program Apache Hive: Architektúra úľov a jej súčasti

Nasledujúci obrázok popisuje architektúru úľov a tok, do ktorého sa zadáva dotazÚľa nakoniec spracované pomocou rámca MapReduce:

Obr : Hive Tutorial - Hive Architecture

Ako je znázornené na obrázku vyššie, architektúru Hive možno rozdeliť do nasledujúcich komponentov:

  • Klienti úľov: Úľ podporuje aplikácie napísané v mnohých jazykoch ako Java, C ++, Python atď. Pomocou ovládačov JDBC, Thrift a ODBC. Preto je možné kedykoľvek napísať klientsku aplikáciu v úli napísanú v jazyku podľa vlastného výberu.
  • Úľové služby: Apache Hive poskytuje rôzne služby ako CLI, webové rozhranie atď. Na vykonávanie dotazov. Každú z nich krátko preskúmame v tomto blogu s návodmi na Úle.
  • Rámec spracovania a správa zdrojov: Interne,Úľ používa ako nástroj na vykonávanie dotazov rámec Hadoop MapReduce. je samostatná téma sama o sebe, a preto sa tu nehovorí.
  • Distribuované úložisko: Pretože je Hive nainštalovaný na vrchu Hadoop, používa pre distribuované úložisko podkladový HDFS. Môžete sa obrátiť na Blog HDFS dozvedieť sa o tom viac.

Teraz sa pozrime na prvé dva hlavné komponenty architektúry Hive:

1. Klienti úľov:

Apache Hive podporuje rôzne typy klientskych aplikácií na vykonávanie dotazov v Hive. Týchto klientov možno rozdeliť do troch typov:

  • Thrift klienti: Pretože server Hive je založený na serveri Apache Thrift, môže vyhovieť požiadavkám zo všetkých programovacích jazykov, ktoré Thrift podporujú.
  • Klienti JDBC: Hive umožňuje Java aplikáciám pripojiť sa k nim pomocou ovládača JDBC, ktorý je definovaný v triede org.apache.hadoop.úľ.jdbc.HiveDriver.
  • Klienti ODBC: Ovládač Hive ODBC umožňuje aplikáciám, ktoré podporujú protokol ODBC, pripojiť sa k Hive. (Rovnako ako ovládač JDBC, aj ovládač ODBC používa Thrift na komunikáciu so serverom Hive.)

2. Úľové služby:

Úľ poskytuje mnoho služieb, ako je znázornené na obrázku vyššie. Pozrime sa na každú z nich:

  • Hive CLI (rozhranie príkazového riadku): Toto je predvolený shell poskytovaný Hive, kde môžete priamo vykonávať dotazy a príkazy Hive.
  • Webové rozhrania Apache Hive: Okrem rozhrania príkazového riadku poskytuje Hive aj webové GUI na vykonávanie dotazov a príkazov Hive.
  • Server úľa: Server Hive je postavený na serveri Apache Thrift, a preto sa označuje aj ako server Thrift, ktorý umožňuje rôznym klientom odosielať žiadosti do Hive a získať konečný výsledok.
  • Ovládač úľa Apache: Je zodpovedný za prijímanie otázok zadaných klientom prostredníctvom rozhraní CLI, webového používateľského rozhrania, rozhrania Thrift, ODBC alebo JDBC. Ovládač potom odovzdá dotaz kompilátoru, kde prebieha analýza, kontrola typu a sémantická analýza pomocou schémy v metastore. V ďalšom kroku sa vygeneruje optimalizovaný logický plán vo forme DAG (Directed Acyclic Graph) úloh zameraných na zníženie mapy a úloh HDFS. Nakoniec vykonávací modul vykoná tieto úlohy v poradí podľa ich závislostí pomocou Hadoop.
  • Metastore: Môžete myslieť metastoreako centrálne úložisko na ukladanie všetkých metaúdajov úľa. Metadáta podregistra zahŕňajú rôzne typy informácií, ako napríklad štruktúru tabuliek a oddielovspolu so stĺpcom, typom stĺpca, serializátorom a deserializátorom, ktorý je potrebný na operáciu čítania a zápisu na dátach prítomných v HDFS. Metastoresa skladá z dvoch základných jednotiek:
    • Služba, ktorá poskytuje metastoreprístup k ostatnýmrÚľové služby.
    • Diskové úložisko pre metadáta, ktoré je oddelené od úložiska HDFS.

Poďme teraz pochopiť rôzne spôsoby implementácie úľového metastorev nasledujúcej časti tohto Návodu na úle.

Výukový program Apache Hive: Konfigurácia úložiska Metastore

Metastore ukladá informácie o metaúdajoch pomocou RDBMS a vrstvy ORM (Object Relational Model) s otvoreným zdrojom nazývanej Data Nucleus, ktorá prevádza reprezentáciu objektov do relačnej schémy a naopak. Dôvodom výberu RDBMS namiesto HDFS je dosiahnutie nízkej latencie. Metastore môžeme implementovať v nasledujúcich troch konfiguráciách:

1. Vložené úložisko:

Služba metastore aj služba Hive štandardne bežia v rovnakom JVM pomocou vloženej inštancie Derby Database, kde sú metadáta uložené na lokálnom disku. Toto sa nazýva vložená konfigurácia metastore. V takom prípade sa môže k databáze metastore pripojiť naraz iba jeden používateľ. Ak spustíte druhú inštanciu ovládača Hive, zobrazí sa chyba. To je dobré pre testovanie jednotiek, ale nie pre praktické riešenia.

2. Miestne úložisko:

Táto konfigurácia nám umožňuje mať viac relácií Hive, t.j. databázu metastore môže súčasne používať viac používateľov. To sa dosiahne použitím ľubovoľnej databázy vyhovujúcej JDBC, ako je MySQL, ktorá beží v samostatnom JVM alebo na inom počítači ako je služba Hive a služba metastore, ktoré bežia v rovnakom JVM, ako je uvedené vyššie. Všeobecne je najpopulárnejšou voľbou implementácia servera MySQL ako databázy metastore.

3. Vzdialený ukladací priestor:

V vzdialenej konfigurácii metastore služba metastore beží na vlastnom samostatnom JVM a nie v JVM služby Hive. Ostatné procesy komunikujú so serverom metastore pomocou rozhraní Thrift Network API. V tomto prípade môžete mať jeden alebo viac serverov metastore, aby ste zaistili väčšiu dostupnosť.Hlavnou výhodou použitia vzdialeného metastore je, že na prístup do databázy metastore nemusíte zdieľať prihlasovacie údaje JDBC s každým používateľom Hive.

Výukový program Apache Hive: Dátový model

Údaje v úli možno na granulárnej úrovni rozdeliť do troch typov:

  • Tabuľka
  • Priečka
  • Vedro

Tabuľky:

Tabuľky v úli sú rovnaké ako tabuľky nachádzajúce sa v relačnej databáze. Môžete na nich vykonávať operácie filtrovania, projektovania, spájania a spájania. V úli sú dva typy tabuliek:

1. Spravovaná tabuľka:

Príkaz:

CREATE TABLE (stĺpec1 typ_údajov, stĺpec2 typ_údajov)

LOAD DATA INPATH INTO table managed_table

Ako naznačuje názov (riadená tabuľka), Hive je zodpovedný za správu údajov spravovanej tabuľky. Inými slovami, to, čo som chcel povedať tým, že „Úľ spravuje údaje“, je, že ak načítate údaje zo súboru prítomného v HDFS do úľa Spravovaná tabuľka a vydáme na ňu príkaz DROP, tabuľka spolu s jej metadátami sa vymaže. Takže, dáta patriace k poklesla Managed_table už v HDFS nikde neexistujú a nemôžete ich nijakým spôsobom načítať. V zásade presúvate údaje, keď vydáte príkaz LOAD z umiestnenia súboru HDFS do adresára skladu Hive.

k sile v jave

Poznámka: Predvolená cesta k adresáru skladu je nastavená na / user / hive / warehouse. Údaje tabuľky úľov sa nachádzajú v priečinku warehouse_directory / nazov_tabulky (HDFS). Môžete tiež určiť cestu k adresáru skladu v konfiguračnom parametri hive.metastore.warehouse.dir, ktorý sa nachádza v úli-site.xml.

2. Externá tabuľka:

Príkaz:

VYTVORIŤ EXTERNÚ TABUĽKU (stĺpec 1 typ_údajov, stĺpec2 typ_údajov) LOCATION „“

VLOŽTE ÚDAJE DO TABUĽKY „“

Pre externý stôl „Úľ nie je zodpovedný za správu údajov. V takom prípade, keď vydáte príkaz LOAD, Hive presunie údaje do svojho adresára skladu. Potom Hive vytvorí informácie o metadátach pre externú tabuľku. Teraz, ak vydáte príkaz DROP na serveri externý stôl , budú vymazané iba informácie o metaúdajoch týkajúcich sa externej tabuľky. Preto môžete stále načítať údaje tejto veľmi externej tabuľky z adresára skladu pomocou príkazov HDFS.

Priečky:

Príkaz:

CREATE TABLE table_name (column1 data_type, column2 data_type) PARTITIONED BY (partition1 data_type, partition2 data_type, & hellip.)

Hive organizuje tabuľky do oddielov na zoskupovanie podobných typov údajov na základe kľúča stĺpca alebo oddielu. Každá tabuľka môže mať jeden alebo viac kľúčov oddielov na identifikáciu konkrétneho oddielu. To nám umožňuje mať rýchlejší dopyt po výrezoch údajov.

Poznámka: Pamätajte, že najčastejšou chybou pri vytváraní oddielov je zadanie názvu existujúceho stĺpca ako stĺpca oddielu. Pritom sa zobrazí chyba - „Chyba v sémantickej analýze: Stĺpec sa opakuje v rozdelení stĺpcov“.

Poďme to pochopiť ako oddiel, vezmime si príklad, kde mám tabuľku student_details obsahujúcu informácie o študentoch nejakej technickej školy ako student_id, name, department, year, etc. patriace konkrétnemu oddeleniu, budú uložené spolu práve v tomto oddiele. Fyzicky oddiel nie je nič iné ako podadresár v adresári tabuľky.

Povedzme, že v našej tabuľke student_details máme údaje za tri oddelenia - CSE, ECE a Civil. Preto budeme mať celkovo tri oddiely pre každé z oddelení, ako je to znázornené na obrázku nižšie. A pre každé oddelenie budeme mať všetky údaje týkajúce sa daného oddelenia, ktoré sa nachádzajú v samostatnom podadresári v adresári tabuľky Úľ. Napríklad všetky údaje študentov týkajúce sa oddelení VVN budú uložené v priečinku user / hive / warehouse / student_details / dept. = CSE. Dotazy týkajúce sa študentov CSE by teda museli prehľadávať iba údaje prítomné v oddiele CSE. Toto robí rozdelenie oddielov veľmi užitočným, pretože znižuje latenciu dotazu iba pri skenovaní relevantné rozdelené údaje namiesto celého súboru údajov. V skutočnosti sa pri implementáciách v reálnom svete budete zaoberať stovkami TB dát. Predstavte si teda, že skenujete toto obrovské množstvo údajov a hľadáte kde 95% údaje, ktoré ste naskenovali, boli pre váš dopyt irelevantné.

Navrhoval by som vám prejsť blogom na Príkazy úľa kde nájdete rôzne spôsoby implementácie oddielov s príkladom.

Vedrá:

Príkazy:

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],…)] INTO num_buckets BUCKETS

Teraz môžete rozdeliť každý oddiel alebo nerozdelenú tabuľku na segmenty na základe hashovacej funkcie stĺpca v tabuľke. V skutočnosti je každý segment iba súborom v adresári oddielu alebo v adresári tabuľky (nerozdelená tabuľka). Preto, ak ste sa rozhodli rozdeliť oddiely na n segmentov, budete mať v každom adresári oddielov n súborov. Napríklad môžete vidieť vyššie uvedený obrázok, kde sme každý oddiel vložili do dvoch segmentov. Takže každý oddiel, povedzme VVN, bude mať dva súbory, kde každý z nich bude ukladať údaje študentov VVN.

Ako Hive distribuuje riadky do vedier?

Úľ určuje číslo vedra pre riadok pomocou vzorca: hash_function (bucketing_column) modulo (num_of_buckets) . Tu, hash_function závisí od dátového typu stĺpca. Napríklad, ak tabuľku vykladáte na základe nejakého stĺpca, povedzme user_id, z dátového typu INT, bude hash_function - hash_function (user_id ) = celočíselná hodnota user_id . A predpokladajme, že ste vytvorili dva segmenty, potom Hive určí riadky idúce do segmentu 1 v každom oddiele výpočtom: (hodnota user_id) modulo (2). Preto v tomto prípade budú riadky, ktoré majú user_id končiace párnou celočíselnou číslicou, umiestnené v rovnakom segmente zodpovedajúcom každému oddielu. Funkcia hash_funkce pro jiné datové typy je výpočet trochu složitější a pro řetězec to není v podstatě ani lidsky rozpoznatelná.

Poznámka: Ak používate Apache Hive 0.x alebo 1.x, musíte pred vykonaním bucketingu vydať príkaz - set hive.enforce.bucketing = true z terminálu Hive. To vám umožní mať správny počet reduktorov pri použití klauzuly cluster by bucketing na stĺpci. Ak ste to neurobili, môžete zistiť, že počet súborov vygenerovaných v adresári tabuľky sa nerovná počtu segmentov. Alternatívne môžete tiež nastaviť počet reduktorov na počet vedier pomocou sady mapred.reduce.task = num_bucket.

Prečo potrebujeme vedrá?

Existujú dva hlavné dôvody uskutočnenia segmentu oddielu:

  • TO pripojiť sa na strane mapy vyžaduje, aby údaje patriace k jedinečnému spojovaciemu kľúču boli prítomné v rovnakom oddieli. Ale čo s prípadmi, keď sa kľúč vášho oddielu líši od spojenia? Preto v týchto prípadoch môžete vykonať spojenie na strane mapy tak, že tabuľku vykrojíte pomocou klávesu join.
  • Bucketing zefektívňuje proces vzorkovania, a preto nám umožňuje skrátiť čas dotazu.

Rád by som tu uzavrel tento blog s návodom na Úle. Som si istý, že po absolvovaní tohto výukového blogu Hive by ste si uvedomili jednoduchosť Apache Hive. Od tej doby ste sa chlapci naučili všetky základy Úľa, je najvyšší čas vyskúšať si s Apache Hive skúsenosti. Takže si pozrite nasledujúci blog v tejto sérii blogov Hive Tutorial, ktorý je v inštalácii Hive, a začnite pracovať na Apache Hive.

Teraz, keď ste pochopili Apache Hive a jeho vlastnosti, pozrite sa na autor: Edureka, dôveryhodná online vzdelávacia spoločnosť so sieťou viac ako 250 000 spokojných študentov rozmiestnených po celom svete. Kurz certifikácie Edadoka Big Data Hadoop Certification Training pomáha študentom stať sa odborníkmi v oblasti HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume a Sqoop pomocou prípadov použitia v reálnom čase v oblasti maloobchodu, sociálnych médií, letectva, cestovného ruchu, financií.

Máte na nás otázku? Uveďte to prosím v sekcii komentárov a my sa vám ozveme.