Architektúra HBase: dátový model HBase a mechanizmus čítania a zápisu HBase

Architektúra HBase

V mojom predchádzajúcom blogu na Výukový program HBase , Vysvetlil som, čo je HBase a jeho vlastnosti. Spomenul som tiež prípadovú štúdiu Facebook Messenger, ktorá vám pomôže lepšie sa spojiť. Teraz ďalej napredujeme v našej , Vysvetlím vám dátový model HBase a HBase Architecture.Než začnete, mali by ste tiež vedieť, že HBase je dôležitý koncept, ktorý tvorí neoddeliteľnú súčasť pre certifikáciu Big Data Hadoop.

Dôležitými témami, ktoré vás prevediem v tomto blogu o architektúre HBase, sú:

• Dátový model HBase
• Architektúra HBase a jej súčasti
• Mechanizmus zápisu HBase
• Mechanizmus čítania HBase
• Mechanizmy optimalizácie výkonu HBase

Najprv pochopíme dátový model HBase. Pomáha HBase pri rýchlejšom čítaní / zápise a vyhľadávaní.

Architektúra HBase: dátový model HBase

Ako vieme, HBase je stĺpcovo orientovaná databáza NoSQL. Aj keď to vyzerá podobne ako relačná databáza, ktorá obsahuje riadky a stĺpce, nejde o relačnú databázu. Relačné databázy sú orientované na riadky, zatiaľ čo HBase je orientovaná na stĺpce. Poďme si teda najskôr uvedomiť rozdiel medzi stĺpcovými a riadkovými databázami:

Riadkovo a stĺpcovo orientované databázy:

• Riadkovo orientované databázy ukladajú záznamy tabuľky v rade riadkov. Zatiaľ čo stĺpcovo orientované databázyukladať záznamy tabuľky do postupnosti stĺpcov, to znamená, že záznamy v stĺpci sú uložené na susedných miestach na diskoch.

Aby sme tomu lepšie porozumeli, vezmime si príklad a zvážme nasledujúcu tabuľku.

Ak je táto tabuľka uložená v riadkovej databáze. Uloží záznamy, ako je uvedené nižšie:

jeden,Paul Walker,USA,231,Galantný,

2, Vin Diesel,Brazília,520,Mustang

V databázach zameraných na riadky sa údaje ukladajú na základe riadkov alebo n-tic, ako vidíte vyššie.

Zatiaľ čo stĺpcovo orientované databázy ukladajú tieto údaje ako:

jeden,2, Paul Walker,Vin Diesel, USA,Brazília, 231,520, Galantný,Mustang

V stĺpcovo orientovaných databázach sú všetky hodnoty stĺpcov uložené spoločne, pretože hodnoty prvého stĺpca budú uložené spoločne, potom budú hodnoty druhého stĺpca uložené spoločne a údaje v ostatných stĺpcoch budú uložené podobným spôsobom.

príklady programov java applet s výstupom

• Keď je množstvo dát veľmi obrovské, napríklad pokiaľ ide o petabajty alebo exabajty, používame prístup zameraný na stĺpce, pretože údaje jedného stĺpca sú uložené spoločne a je k nim rýchlejší prístup.
• Zatiaľ čo prístup zameraný na riadky porovnateľne efektívne spracováva menší počet riadkov a stĺpcov, keďže databáza zameraná na riadky ukladá údaje, je to štruktúrovaný formát.
• Ak potrebujeme spracovať a analyzovať veľkú množinu pološtruktúrovaných alebo neštruktúrovaných údajov, použijeme stĺpcovo orientovaný prístup. Ako sú napríklad aplikácie zaoberajúce sa Online analytické spracovanie ako dolovanie dát, skladovanie dát, aplikácie vrátane analytiky atď.
• Keďže Online transakčné spracovanie ako sú bankové a finančné domény, ktoré spracúvajú štruktúrované údaje a vyžadujú transakčné vlastnosti (vlastnosti ACID), používajú riadkový prístup.

Tabuľky HBase majú nasledujúce komponenty zobrazené na obrázku nižšie:

• Tabuľky : Údaje sú uložené v tabuľkovom formáte v HBase. Ale tu sú tabuľky v stĺpcovo orientovanom formáte.
• Riadok Kľúč : Klávesy riadkov sa používajú na vyhľadávanie záznamov, ktoré umožňujú rýchle vyhľadávanie. Boli by ste zvedaví, ako na to? Vysvetlím to v časti venovanej architektúre v tomto blogu.
• Stĺpec Rodiny : Rôzne stĺpce sú kombinované do rodiny stĺpcov. Tieto rodiny stĺpcov sú uložené spoločne, čo urýchľuje proces vyhľadávania, pretože k údajom patriacim do rovnakej rodiny stĺpcov je možné pristupovať spoločne pri jednom vyhľadávaní.
• Stĺpec Kvalifikácie : Názov každého stĺpca je známy ako jeho kvalifikátor.
• Bunka : Údaje sú uložené v bunkách. Údaje sa ukladajú do buniek, ktoré sú špecificky identifikované kvalifikátormi riadkov a stĺpcov.
• Časová značka : Časová pečiatka je kombináciou dátumu a času. Kedykoľvek sú dáta uložené, sú uložené s ich časovou značkou. Takto je ľahké vyhľadať konkrétnu verziu údajov.

Jednoduchším a pochopiteľnejším spôsobom môžeme povedať, že HBase pozostáva z:

• Sada tabuliek
• Každá tabuľka s rodinami stĺpcov a riadkami
• Kľúč riadku funguje ako primárny kľúč v HBase.
• Akýkoľvek prístup k tabuľkám HBase používa tento primárny kľúč
• Každý kvalifikátor stĺpca prítomný v HBase označuje atribút zodpovedajúci objektu, ktorý sa nachádza v bunke.

Teraz, keď viete o dátovom modeli HBase, pozrime sa, ako tento dátový model zapadá do architektúry HBase Architecture a je vhodný pre veľké úložisko a rýchlejšie spracovanie.

Architektúra HBase: Komponenty architektúry HBase

HBase má tri hlavné zložky, tj. HMaster Server , Server regiónu HBase, regióny a Ošetrovateľ v zoo .

Nasledujúci obrázok vysvetľuje hierarchiu architektúry HBase. O každom z nich si povieme niečo individuálne.

Teraz pred prechodom na HMaster pochopíme Regióny, pretože všetky tieto servery (HMaster, Region Server, Zookeeper) sú umiestnené tak, aby koordinovali a spravovali Regióny a vykonávali rôzne operácie vo vnútri Regiónov. Takže by vás zaujímalo, čo sú to regióny a prečo sú také dôležité?

Architektúra HBase: Región

Oblasť obsahuje všetky riadky medzi počiatočným a koncovým kľúčom priradeným k tejto oblasti. Tabuľky HBase možno rozdeliť do niekoľkých oblastí takým spôsobom, že všetky stĺpce rodiny stĺpcov sú uložené v jednej oblasti. Každá oblasť obsahuje riadky v zoradenom poradí.

Mnoho regiónov je priradených k a Server regiónu , ktorý je zodpovedný za spracovanie, správu, vykonávanie operácií čítania a zápisu na tejto množine oblastí.

Takže záver jednoduchším spôsobom:

• Tabuľku je možné rozdeliť do niekoľkých regiónov. Región je zoradený rozsah riadkov, v ktorých sú uložené údaje medzi kľúčom začiatku a koncom.
• Región má predvolenú veľkosť 256 MB, ktorú je možné nakonfigurovať podľa potreby.
• Skupina regiónov je poskytovaná klientom prostredníctvom Regionálneho servera.
• Regionálny server môže klientovi obslúžiť približne 1 000 regiónov.

Teraz, počnúc najvyššou úrovňou hierarchie, by som najskôr chcel vysvetliť server HMaster Server, ktorý funguje podobne ako HDFS . Potom sa v hierarchii presuniem nadol, prevediem vás cez ZooKeeper a Region Server.

Architektúra HBase: HMaster

Rovnako ako na nasledujúcom obrázku môžete vidieť, že server HMaster spracováva kolekciu servera Region Server, ktorý sa nachádza na serveri DataNode. Poďme pochopiť, ako to HMaster robí.

• HBase HMaster vykonáva operácie DDL (vytvára a odstraňuje tabuľky) a priraďuje oblasti serverom Region, ako vidíte na obrázku vyššie.
• Koordinuje a spravuje regionálny server (podobne ako NameNode spravuje DataNode v HDFS).
• Priraďuje regióny oblastným serverom pri štarte a opätovne priraďuje regióny regionálnym serverom počas obnovy a vyrovnávania zaťaženia.
• Monitoruje všetky inštancie servera Region Server v klastri (pomocou aplikácie Zookeeper) a vykonáva činnosti obnovy, kedykoľvek je akýkoľvek server Region Server nefunkčný.
• Poskytuje rozhranie na vytváranie, mazanie a aktualizáciu tabuliek.

HBase má distribuované a obrovské prostredie, kde samotný HMaster nestačí na správu všetkého. Zaujímalo by vás, čo pomáha HMaster spravovať toto obrovské prostredie? Tam prichádza na scénu ZooKeeper. Keď pochopíme, ako HMaster spravuje prostredie HBase, pochopíme, ako Zookeeper pomáha HMaster pri správe prostredia.

Architektúra HBase: ZooKeeper - koordinátor

Tento obrázok nižšie vysvetľuje koordinačný mechanizmus ZooKeeper.

• Zookeeper funguje ako koordinátor v distribuovanom prostredí HBase. Pomáha udržiavať stav servera v klastri komunikáciou prostredníctvom relácií.
• Každý regionálny server spolu so serverom HMaster odosiela nepretržitý srdcový rytmus v pravidelných intervaloch aplikácii Zookeeper a kontroluje, ktorý server je aktívny a dostupný, ako je uvedené na obrázku vyššie. Poskytuje tiež oznámenia o zlyhaní servera, aby bolo možné vykonať opatrenia na obnovenie.
• Z vyššie uvedeného obrázka môžete vidieť, že existuje neaktívny server, ktorý slúži ako záloha aktívneho servera. Ak aktívny server zlyhá, prichádza na pomoc.
• Aktívny HMaster odosiela tepy Zookeeperovi, zatiaľ čo neaktívny HMaster počúva oznámenie odoslané aktívnym HMasterom. Ak aktívny HMaster nedokáže odoslať tep, relácia sa vymaže a neaktívny HMaster sa stane aktívnym.
• Aj keď regionálny server nedokáže odoslať tep, relácii vypršala platnosť a všetci poslucháči sú o nej informovaní. Potom HMaster vykoná vhodné akcie obnovy, o ktorých budeme diskutovať ďalej v tomto blogu.
• Zookeeper tiež udržuje cestu servera .META, ktorá pomáha každému klientovi pri hľadaní ľubovoľného regiónu. Klient si musí najskôr overiť na serveri .META Server, do ktorého regionálneho servera región patrí, a získa cestu k tomuto regionálnemu serveru.

Keď som hovoril o serveri .META, dovoľte mi, aby som vám najskôr vysvetlil, čo je server .META? Môžete teda ľahko prepojiť prácu serverov ZooKeeper a .META Server. Neskôr, keď vám v tomto blogu vysvetlím mechanizmus vyhľadávania HBase, vysvetlím, ako tieto dva spolupracujú.

Architektúra HBase: Meta tabuľka

• Tabuľka META je špeciálna katalógová tabuľka HBase. Vedie zoznam všetkých serverov regiónov v úložnom systéme HBase, ako vidíte na obrázku vyššie.
• Pri pohľade na postavu, ktorú vidíte, .META súbor udržiava tabuľku vo forme kľúčov a hodnôt. Kľúč predstavuje štartovací kľúč regiónu a jeho ID, zatiaľ čo hodnota obsahuje cestu servera regiónu.

Ako som už hovoril o serveri Region a jeho funkciách, zatiaľ čo som vám vysvetľoval regióny, teraz sa posúvame v hierarchii nižšie a zameriam sa na komponenty servera Region a ich funkcie. Neskôr budem diskutovať o mechanizme vyhľadávania, čítania, písania a porozumení toho, ako všetky tieto komponenty spolupracujú.

Architektúra HBase: Komponenty regionálneho servera

Tento obrázok nižšie zobrazuje komponenty servera regiónu. Teraz ich rozoberiem osobitne.

Regionálny server udržiava rôzne regióny bežiace nad . Komponenty regionálneho servera sú:

• WAL: Ako môžete vyvodiť z vyššie uvedeného obrázka, Write Ahead Log (WAL) je súbor pripojený ku každému serveru Region vo vnútri distribuovaného prostredia. WAL ukladá nové údaje, ktoré neboli trvalé alebo určené pre trvalé úložisko. Používa sa v prípade zlyhania obnovy súborov údajov.
• Blokovať medzipamäť: Z vyššie uvedeného obrázka je jasne viditeľné, že Block Cache sa nachádza v hornej časti servera Region. Ukladá často načítané údaje do pamäte. Pokiaľ sú dáta v BlockCache použité naposledy, potom sú z BlockCache odstránené.
• MemStore: Je to medzipamäť na zápis. Ukladá všetky prichádzajúce dáta pred ich odovzdaním na disk alebo do permanentnej pamäte. Pre každú rodinu stĺpcov v regióne existuje jeden MemStore. Ako vidíte na obrázku, pre oblasť existuje viac MemStores, pretože každý región obsahuje viac skupín stĺpcov. Údaje sú zoradené v lexikografickom poradí skôr, ako ich potvrdíte na disku.
• HFile: Z vyššie uvedeného obrázku vidíte, že súbor HF je uložený na HDFS. Takto ukladá skutočné bunky na disk. MemStore zaviaže údaje do súboru HFile, keď veľkosť MemStore presiahne.

Teraz, keď poznáme hlavné a vedľajšie súčasti architektúry HBase, vysvetlím v tejto súvislosti mechanizmus a ich spoločné úsilie. Či už ide o čítanie alebo písanie, najskôr musíme vyhľadať, odkiaľ čítať alebo kam zapisovať súbor. Poďme teda pochopiť tento proces vyhľadávania, pretože toto je jeden z mechanizmov, vďaka ktorým je HBase veľmi populárny.

Architektúra HBase: Ako sa inicializuje vyhľadávanie v HBase?

Ako viete, Zookeeper ukladá umiestnenie tabuľky META. Kedykoľvek sa klient priblíži s požiadavkami na čítanie alebo zápis do HBase, dôjde k nasledujúcej operácii:

1. Klient získa zo servera ZooKeeper umiestnenie tabuľky META.
2. Klient potom požiada o umiestnenie regionálneho servera zodpovedajúceho kľúča riadku z tabuľky META, aby k nej získal prístup. Klient tieto informácie uloží do pamäte s umiestnením tabuľky META.
3. Potom získa umiestnenie riadku vyžiadaním z príslušného servera oblastí.

Pre budúce referencie použije klient pomocou svojej medzipamäte umiestnenie tabuľky META a predtým prečítaný Region Server servera kľúča riadku. Potom klient nebude odkazovať na tabuľku META, pokiaľ a pokiaľ nepríde o miss, pretože región je posunutý alebo presunutý. Potom znova požiada server META a aktualizuje vyrovnávaciu pamäť.

maximálna halda implementácia v jave

Ako vždy, klienti nestrácajú čas načítaním polohy servera Region zo servera META, čo šetrí čas a urýchľuje proces vyhľadávania. Teraz vám poviem, ako prebieha písanie v HBase. Čo sú jej zložky a ako sú zapojené?

Architektúra HBase: HBase Write Mechanizmus

Tento obrázok nižšie vysvetľuje mechanizmus zápisu v HBase.

Mechanizmus zápisu prechádza nasledujúcim procesom postupne (pozri obrázok vyššie):

Krok 1: Kedykoľvek má klient požiadavku na zápis, zapíše údaje do WAL (Write Ahead Log).

• Úpravy sa potom pripoja na koniec súboru WAL.
• Tento súbor WAL sa uchováva na každom serveri Region Server a server Region Server ho používa na obnovu údajov, ktoré nie sú vyhradené pre disk.

Krok 2: Akonáhle sú dáta zapísané do WAL, potom sa skopírujú do MemStore.

Krok 3: Po uložení údajov do MemStore dostane klient potvrdenie.

Krok 4: Keď MemStore dosiahne prahovú hodnotu, vypíše alebo zaviaže údaje do súboru HFile.

Teraz sa hlboko ponoríme a pochopíme, ako MemStore prispieva k procesu písania a aké sú jeho funkcie?

HBase Write Mechanizmus- MemStore

• MemStore vždy aktualizuje údaje, ktoré sú v ňom uložené, v lexikografickom poradí (postupne v slovníku) ako zoradené KeyValues. Pre každú rodinu stĺpcov existuje jeden MemStore, a preto sa aktualizácie ukladajú triedeným spôsobom pre každú rodinu stĺpcov.
• Keď MemStore dosiahne prahovú hodnotu, triedi všetky údaje do nového súboru HFile. Tento súbor HF je uložený v HDFS. HBase obsahuje viac súborov HF pre každú rodinu stĺpcov.
• Postupom času počet súborov HFile rastie, keď MemStore ukladá údaje.
• MemStore tiež uloží posledné napísané poradové číslo, takže Master Server aj MemStore vedia, že čo je doteraz spáchané a odkiaľ začať. Po spustení regiónu sa načíta posledné poradové číslo a od tohto čísla sa začnú nové úpravy.

Ako som už niekoľkokrát hovoril, tento HFile je hlavným perzistentným úložiskom v architektúre HBase. Nakoniec sú všetky údaje vyhradené pre HFile, čo je trvalé úložisko HBase. Pozrime sa teda na vlastnosti súboru HFile, ktorý umožňuje rýchlejšie vyhľadávanie počas čítania a zápisu.

Architektúra HBase: HBase Write Mechanizmus- HSúbor

• Zápisy sa umiestňujú postupne na disk. Preto je pohyb čítacej a zapisovacej hlavy disku veľmi malý. Vďaka tomu je mechanizmus zápisu a vyhľadávania veľmi rýchly.
• Indexy HFile sa načítajú do pamäte vždy, keď sa otvorí HFile. To pomáha pri hľadaní záznamu v jednom hľadaní.
• Trailer je ukazovateľ, ktorý ukazuje na metablok súboru HFile. Je napísaný na konci potvrdeného súboru. Obsahuje informácie o časových značkách a filtroch kvitnutia.
• Blokový filter pomáha pri hľadaní párov kľúč - hodnota, preskočí súbor, ktorý neobsahuje požadovaný riadok. Časová pečiatka tiež pomáha pri vyhľadávaní verzie súboru a pomáha pri preskakovaní údajov.

Po poznaní mechanizmu zápisu a úlohe rôznych komponentov pri rýchlejšom zápise a vyhľadávaní. Vysvetlím vám, ako čítací mechanizmus funguje vo vnútri architektúry HBase? Potom prejdeme k mechanizmom, ktoré zvyšujú výkon HBase, ako je zhutňovanie, rozdelenie oblastí a obnova.

Architektúra HBase: Mechanizmus čítania

Ako je popísané v našom mechanizme vyhľadávania, najskôr klient načíta umiestnenie servera regiónu zo servera .META Server, ak ho nemá vo svojej pamäti cache. Potom prejde nasledujúcimi krokmi nasledovne:

• Pri načítaní údajov skener najskôr vyhľadá bunku Row v medzipamäti bloku. Tu sa ukladajú všetky nedávno načítané páry kľúč - hodnota.
• Ak sa skeneru nepodarí nájsť požadovaný výsledok, presunie sa do MemStore, pretože vieme, že sa jedná o pamäť medzipamäte na zápis. Tam vyhľadáva naposledy napísané súbory, ktoré zatiaľ neboli v HFile uložené.
• Nakoniec na načítanie údajov z HFile použije Bloom filtre a zablokuje medzipamäť.

Doteraz som diskutoval o mechanizme vyhľadávania, čítania a zápisu HBase. Teraz sa pozrieme na mechanizmus HBase, ktorý umožňuje rýchle vyhľadávanie, čítanie a písanie v HBase. Najprv to pochopíme Zhutnenie , ktorý je jedným z týchto mechanizmov.

Architektúra HBase: Zhutnenie

štruktúra java programu

HBase kombinuje súbory HF na zníženie úložného priestoru a zníženie počtu vyhľadávaní diskov potrebných na čítanie. Tento proces sa nazýva zhutnenie . Zhutnenie vyberie niektoré súbory HF z regiónu a skombinuje ich. Existujú dva typy zhutnenia, ktoré vidíte na obrázku vyššie.

1. Drobné zhutnenie : HBase automaticky vyberie menšie súbory HF a odporučí ich k väčším súborom HF, ako je to znázornené na obrázku vyššie. Toto sa nazýva menšie zhutnenie. Vykonáva zlučovanie na potvrdenie menších súborov HF do väčších súborov HF. To pomáha pri optimalizácii úložného priestoru.
2. Hlavné zhutnenie: Ako je znázornené na vyššie uvedenom obrázku, pri hlavnom zhutňovaní sa HBase zlúči a odporučí menšie súbory HF v oblasti do nového súboru HFile. V tomto procese sú do nového súboru HF umiestnené rovnaké rodiny stĺpcov. V tomto procese zahodí odstránenú a vypršanú bunku. Zvyšuje výkon čítania.

Ale počas tohto procesu môžu byť preťažené vstupno-výstupné disky a sieťová prevádzka. Toto je známe ako napísať zosilnenie . Spravidla je to teda naplánované počas nízkych časov špičkového zaťaženia.

Teraz bude ďalší proces optimalizácie výkonu, o ktorom budem diskutovať Splitský región . To je veľmi dôležité pre vyváženie záťaže.

Architektúra HBase: Splitský región

Na nasledujúcom obrázku je znázornený mechanizmus rozdelenia regiónov.

Kedykoľvek sa región zväčší, rozdelí sa na dva podradené oblasti, ako je to znázornené na obrázku vyššie. Každý región predstavuje presne polovicu nadradeného regiónu. Potom sa toto rozdelenie nahlási HMaster. Toto spracúva ten istý Region Server, kým ich HMaster nepridelí na nový Region Server na vyváženie záťaže.

Ak sa posuniem o riadok nižšie, v neposlednom rade vám vysvetlím, ako HBase obnovuje údaje po zlyhaní. Ako to vieme Obnova zlyhania je veľmi dôležitá vlastnosť HBase, dajte nám teda vedieť, ako HBase obnovuje údaje po zlyhaní.

Architektúra HBase: Havária HBase a obnova dát

• Kedykoľvek zlyhá regionálny server, ZooKeeper upozorní HMaster na zlyhanie.
• Potom HMaster distribuuje a prideľuje oblasti havarovaného servera Region mnohým aktívnym serverom oblastí. Na zotavenie údajov z MemStore servera Region, kde server zlyhal, HMaster distribuuje WAL na všetky servery Region.
• Každý regionálny server opätovne vykoná WAL, aby vytvoril MemStore pre rodinu stĺpcov tohto zlyhaného regiónu.
• Údaje sa zapisujú v chronologickom poradí (v správnom poradí) do formátu WAL. Preto opätovné vykonanie tohto WAL znamená vykonať všetky zmeny, ktoré boli vykonané a uložené v súbore MemStore.
• Takže potom, čo všetky regionálne servery vykonajú WAL, sa obnovia údaje MemStore pre celú rodinu stĺpcov.

Dúfam, že vám tento blog pomohol porozumieť údajovým modelom HBase a architektúre HBase. Dúfam, že sa vám páčilo. Teraz sa môžete týkať funkcií HBase (ktoré som vysvetlil v mojom predchádzajúcom Výukový program HBase blog) s HBase Architecture a pochopte, ako to funguje interne. Teraz, keď poznáte teoretickú časť HBase, mali by ste prejsť na praktickú časť. Majte to na pamäti, náš ďalší blog o vysvetlí vzorku HBase POC .

Teraz, keď ste pochopili architektúru HBase, 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.