Architektura HBase: HBase Data Model & HBase Read / Write Mechanism

Architektura HBase

V mém předchozím blogu na Výukový program HBase , Vysvětlil jsem, co je HBase a jeho vlastnosti. Zmínil jsem také případovou studii Facebook Messenger, která vám pomůže lépe se spojit. Nyní dále postupujeme vpřed v našem , Vysvětlím vám datový model HBase a HBase Architecture.Než budete pokračovat, měli byste také vědět, že HBase je důležitý koncept, který tvoří nedílnou součást pro certifikaci Big Data Hadoop.

Důležitá témata, kterými vás provedu v tomto blogu architektury HBase, jsou:

• Datový model HBase
• Architektura HBase a její komponenty
• Mechanismus zápisu HBase
• Mechanismus čtení HBase
• Mechanismy optimalizace výkonu HBase

Nejprve pochopíme datový model HBase. Pomáhá HBase při rychlejším čtení / zápisu a vyhledávání.

Architektura HBase: Datový model HBase

Jak víme, HBase je sloupcově orientovaná databáze NoSQL. I když to vypadá podobně jako relační databáze, která obsahuje řádky a sloupce, ale nejde o relační databázi. Relační databáze jsou orientovány na řádky, zatímco HBase je orientován na sloupce. Pojďme tedy nejprve porozumět rozdílu mezi sloupcově a řádkově orientovanými databázemi:

Řádkově vs sloupcově orientované databáze:

• Řádkově orientované databáze ukládají záznamy tabulky v řadě řádků. Zatímco sloupově orientované databázeukládat záznamy tabulky v posloupnosti sloupců, tj. položky ve sloupci se ukládají na sousedních místech na discích.

Abychom tomu lépe porozuměli, vezměme si příklad a zvažte následující tabulku.

Pokud je tato tabulka uložena v řádkově orientované databázi. Uloží záznamy, jak je uvedeno níže:

jeden,Paul Walker,NÁS,231,Galantní,

2, VIN Diesel,Brazílie,520,Mustang

V řádkově orientovaných databázích jsou data ukládána na základě řádků nebo n-tic, jak vidíte výše.

Zatímco sloupcově orientované databáze ukládají tato data jako:

jeden,2, Paul Walker,VIN Diesel, NÁS,Brazílie, 231,520, Galantní,Mustang

Ve sloupcově orientovaných databázích jsou všechny hodnoty sloupců uloženy společně, jako budou hodnoty prvního sloupce uloženy společně, poté budou hodnoty druhého sloupce uloženy společně a data v ostatních sloupcích budou uložena podobným způsobem.

jak převést double na int

• Když je množství dat velmi velké, jako v případě petabajtů nebo exabajtů, používáme přístup orientovaný na sloupce, protože data jednoho sloupce jsou uložena společně a lze k nim přistupovat rychleji.
• Zatímco přístup orientovaný na řádky srovnává efektivně menší počet řádků a sloupců, protože řádkově orientovaná databáze ukládá data ve strukturovaném formátu.
• Když potřebujeme zpracovat a analyzovat velkou sadu polostrukturovaných nebo nestrukturovaných dat, použijeme přístup orientovaný na sloupce. Například aplikace zabývající se Online analytické zpracování jako je dolování dat, skladování dat, aplikace včetně analytiky atd.
• Zatímco, Online transakční zpracování jako jsou bankovní a finanční domény, které zpracovávají strukturovaná data a vyžadují transakční vlastnosti (vlastnosti ACID), používají přístup zaměřený na řádky.

Tabulky HBase mají následující komponenty zobrazené na obrázku níže:

• Tabulky : Data jsou uložena ve formátu tabulky v HBase. Ale tady jsou tabulky ve sloupcově orientovaném formátu.
• Řádek Klíč : Klávesy řádků se používají k vyhledávání záznamů, díky nimž je vyhledávání rychlé. Zajímalo by vás, jak? V tomto blogu to vysvětlím v další části architektury.
• Sloupec Rodiny : Různé sloupce jsou sloučeny do rodiny sloupců. Tyto rodiny sloupců jsou uloženy společně, což zrychluje proces vyhledávání, protože k datům patřícím do stejné rodiny sloupců lze přistupovat společně při jediném hledání.
• Sloupec Kvalifikace : Název každého sloupce je znám jako jeho kvalifikátor.
• Buňka : Data jsou uložena v buňkách. Data jsou vypsána do buněk, které jsou specificky identifikovány kvalifikátory řádků a sloupců.
• Časové razítko : Časové razítko je kombinací data a času. Kdykoli jsou data uložena, jsou uložena s časovým razítkem. To usnadňuje vyhledávání konkrétní verze dat.

Jednodušším a srozumitelnějším způsobem můžeme říci, že HBase se skládá z:

• Sada stolů
• Každá tabulka s rodinami sloupců a řádky
• Klíč řádku funguje jako primární klíč v HBase.
• Jakýkoli přístup k tabulkám HBase používá tento primární klíč
• Každý kvalifikátor sloupce přítomný v HBase označuje atribut odpovídající objektu, který se nachází v buňce.

Nyní, když víte o HBase Data Model, podívejme se, jak tento datový model spadá do souladu s HBase Architecture a je vhodný pro velké úložiště a rychlejší zpracování.

Architektura HBase: Součásti architektury HBase

HBase má tři hlavní složky, tj. HMaster Server , Server regionu HBase, regiony a Zookeeper .

Níže uvedený obrázek vysvětluje hierarchii architektury HBase. O každém z nich budeme mluvit individuálně.

Nyní, než půjdeme na HMaster, pochopíme regiony, protože všechny tyto servery (HMaster, Region Server, Zookeeper) jsou umístěny ke koordinaci a správě regionů a provádění různých operací uvnitř regionů. Zajímalo by vás, co jsou regiony a proč jsou tak důležité?

Architektura HBase: Kraj

Oblast obsahuje všechny řádky mezi počátečním klíčem a koncovým klíčem přiřazeným k této oblasti. Tabulky HBase lze rozdělit do několika oblastí takovým způsobem, že všechny sloupce rodiny sloupců jsou uloženy v jedné oblasti. Každá oblast obsahuje řádky v seřazeném pořadí.

Mnoho regionů je přiřazeno k Regionální server , který je zodpovědný za zpracování, správu, provádění operací čtení a zápisu v této sadě oblastí.

Závěr tedy jednodušší:

• Tabulka může být rozdělena do několika oblastí. Region je seřazený rozsah řádků ukládajících data mezi počátečním a koncovým klíčem.
• Region má výchozí velikost 256 MB, kterou lze nakonfigurovat podle potřeby.
• Skupina regionů je klientům poskytována serverem regionu.
• Regionální server může klientovi obsluhovat přibližně 1000 regionů.

Nyní počínaje od vrcholu hierarchie bych vám nejprve chtěl vysvětlit server HMaster, který funguje podobně jako NameNode v HDFS . Poté v hierarchii přejdu dolů přes ZooKeeper a Region Server.

Architektura HBase: HMaster

Stejně jako na následujícím obrázku můžete vidět, že HMaster zpracovává kolekci Region Server, která se nachází na DataNode. Pojďme pochopit, jak to HMaster dělá.

• HBase HMaster provádí operace DDL (vytváření a mazání tabulek) a přiřazuje oblasti serverům Region, jak vidíte na obrázku výše.
• Koordinuje a spravuje Region Server (podobně jako NameNode spravuje DataNode v HDFS).
• Při spuštění přiřadí regiony regionálním serverům a během obnovy a vyrovnávání zatížení znovu přiřadí regiony regionálním serverům.
• Sleduje všechny instance Region Serveru v klastru (pomocí Zookeeper) a provádí činnosti obnovy, kdykoli je některý Region Server vypnutý.
• Poskytuje rozhraní pro vytváření, mazání a aktualizaci tabulek.

HBase má distribuované a obrovské prostředí, kde samotný HMaster nestačí ke správě všeho. Zajímalo by vás, co HMaster pomáhá spravovat toto obrovské prostředí? To je místo, kde ZooKeeper přichází do obrazu. Poté, co jsme pochopili, jak HMaster spravuje prostředí HBase, pochopíme, jak Zookeeper pomáhá HMaster při správě prostředí.

Architektura HBase: ZooKeeper - koordinátor

Tento obrázek níže vysvětluje koordinační mechanismus ZooKeeper.

• Zookeeper funguje jako koordinátor uvnitř distribuovaného prostředí HBase. Pomáhá udržovat stav serveru uvnitř klastru tím, že komunikuje prostřednictvím relací.
• Každý server Region spolu se serverem HMaster Server odesílá nepřetržitý prezenční signál v pravidelných intervalech do Zookeeper a kontroluje, který server je aktivní a dostupný, jak je uvedeno výše. Poskytuje také upozornění na selhání serveru, aby bylo možné provést opatření pro obnovení.
• Z výše uvedeného obrázku můžete vidět, že existuje neaktivní server, který funguje jako záloha pro aktivní server. Pokud aktivní server selže, přijde na záchranu.
• Aktivní HMaster odesílá prezenční signály Zookeeperu, zatímco neaktivní HMaster poslouchá oznámení zasílaná aktivním HMasterem. Pokud aktivní HMaster nedokáže odeslat prezenční signál, relace je odstraněna a neaktivní HMaster se stane aktivním.
• I když regionální server nedokáže odeslat prezenční signál, relace vypršela a všichni posluchači jsou o ní informováni. Poté HMaster provede vhodné akce obnovy, o kterých budeme diskutovat dále v tomto blogu.
• Zookeeper také udržuje cestu serveru .META, která pomáhá každému klientovi při hledání jakékoli oblasti. Klient musí nejprve zkontrolovat u serveru .META Server, do kterého Region Servera region patří, a získá cestu k tomuto Region Serveru.

Když jsem mluvil o .META Serveru, dovolte mi nejprve vám vysvětlit, co je .META server? Takže můžete snadno spojit práci ZooKeeper a .META Server dohromady. Později, když vám v tomto blogu vysvětlím vyhledávací mechanismus HBase, vysvětlím, jak tito dva spolupracují.

Architektura HBase: Meta tabulka

• Tabulka META je speciální tabulka katalogu HBase. Udržuje seznam všech serverů regionů v úložném systému HBase, jak vidíte na obrázku výše.
• Při pohledu na postavu, kterou vidíte, .META soubor udržuje tabulku ve formě klíčů a hodnot. Klíč představuje počáteční klíč regionu a jeho ID, zatímco hodnota obsahuje cestu k Region Serveru.

Jak jsem již zmínil, Region Server a jeho funkce, zatímco jsem vám vysvětloval Regiony, nyní se pohybujeme dolů v hierarchii a já se zaměřím na komponentu Region Server a jejich funkce. Později budu diskutovat o mechanismu vyhledávání, čtení, psaní a pochopit, jak všechny tyto komponenty spolupracují.

Architektura HBase: Součásti regionálního serveru

Tento obrázek níže zobrazuje komponenty regionálního serveru. Nyní o nich budu diskutovat zvlášť.

Regionální server udržuje různé oblasti spuštěné nad . Součásti regionálního serveru jsou:

• WAL: Jak můžete uzavřít z výše uvedeného obrázku, Write Ahead Log (WAL) je soubor připojený ke každému Region Serveru uvnitř distribuovaného prostředí. WAL ukládá nová data, která nebyla přetrvávána nebo potvrzena pro trvalé úložiště. Používá se v případě selhání při obnovení datových sad.
• Blokovat mezipaměť: Z výše uvedeného obrázku je jasně vidět, že Block Cache se nachází v horní části Region Server. Ukládá často načtená data do paměti. Pokud jsou data v BlockCache použita naposledy, pak jsou tato data z BlockCache odstraněna.
• MemStore: Je to mezipaměť pro zápis. Ukládá všechna příchozí data před jejich potvrzením na disk nebo do trvalé paměti. Pro každou rodinu sloupců v oblasti existuje jeden MemStore. Jak vidíte na obrázku, existuje několik MemStores pro oblast, protože každá oblast obsahuje více rodin sloupců. Před potvrzením na disk jsou data tříděna v lexikografickém pořadí.
• HFile: Z výše uvedeného obrázku můžete vidět, že soubor HFile je uložen na HDFS. Ukládá tedy skutečné buňky na disku. MemStore zaváže data do souboru HFile, když velikost MemStore přesáhne.

Nyní, když známe hlavní a vedlejší součásti HBase Architecture, vysvětlím mechanismus a jejich společné úsilí v tomto. Ať už jde o čtení nebo psaní, nejprve musíme hledat, odkud číst nebo kam zapisovat soubor. Pojďme tedy pochopit tento proces vyhledávání, protože toto je jeden z mechanismů, díky nimž je HBase velmi populární.

Architektura HBase: Jak se inicializuje vyhledávání v HBase?

Jak víte, Zookeeper ukládá umístění tabulky META. Kdykoli se klient přiblíží s požadavky na čtení nebo zápis do HBase, dojde k následující operaci:

1. Klient načte umístění tabulky META ze ZooKeeper.
2. Klient poté požádá o umístění regionálního serveru odpovídajícího klíče řádku z tabulky META, aby k němu měl přístup. Klient ukládá tyto informace do mezipaměti s umístěním tabulky META.
3. Pak získá umístění řádku vyžádáním od příslušného Region Serveru.

Pro budoucí reference klient pomocí své mezipaměti načte umístění tabulky META a dříve přečetl Region Server klíče řádku. Potom klient nebude odkazovat na tabulku META, dokud a pokud nedojde k chybě, protože oblast je posunuta nebo přesunuta. Poté znovu požádá server META a aktualizuje mezipaměť.

co je charat v javě

Jako vždy, klienti neztrácejí čas načítáním umístění Region Serveru z META Serveru, takže to šetří čas a zrychluje proces hledání. Nyní vám řeknu, jak probíhá psaní v HBase. O jaké komponenty se jedná a jak jsou zapojeny?

Architektura HBase: HBase zápis Mechanismus

Tento obrázek níže vysvětluje mechanismus zápisu v HBase.

Mechanismus zápisu prochází následujícím procesem postupně (viz obrázek výše):

Krok 1: Kdykoli má klient požadavek na zápis, zapíše data do WAL (Write Ahead Log).

• Úpravy se poté připojí na konec souboru WAL.
• Tento soubor WAL je udržován na každém Region Serveru a Region Server jej používá k obnovení dat, která nejsou potvrzena na disku.

Krok 2: Jakmile jsou data zapsána do WAL, jsou zkopírována do MemStore.

Krok 3: Jakmile jsou data umístěna do MemStore, klient obdrží potvrzení.

Krok 4: Když MemStore dosáhne prahové hodnoty, vypíše nebo potvrdí data do souboru HFile.

Nyní se důkladně ponoříme a pochopíme, jak MemStore přispívá k procesu psaní a jaké jsou jeho funkce?

HBase zápis Mechanismus- MemStore

• MemStore vždy aktualizuje data v něm uložená, v lexikografickém pořadí (postupně slovníkovým způsobem) jako seřazené KeyValues. Pro každou rodinu sloupců existuje jeden MemStore, a proto se aktualizace ukládají tříděným způsobem pro každou rodinu sloupců.
• Když MemStore dosáhne prahové hodnoty, vypíše všechna data do nového souboru HF seřazeným způsobem. Tento soubor HF je uložen v HDFS. HBase obsahuje více souborů HF pro každou rodinu sloupců.
• Postupem času počet souborů HFile roste, protože MemStore ukládá data.
• MemStore také ukládá poslední zapsané pořadové číslo, takže Master Server i MemStore vědí, co je dosud potvrzeno a odkud začít. Když se region spustí, přečte se poslední pořadové číslo a od tohoto čísla se spustí nové úpravy.

Jak jsem několikrát diskutoval, tento HFile je hlavní trvalé úložiště v architektuře HBase. Nakonec jsou všechna data vyhrazena pro HFile, což je trvalé úložiště HBase. Podívejme se tedy na vlastnosti HFile, které zrychlují vyhledávání při čtení a psaní.

Architektura HBase: HBase zápis Mechanismus- HSoubor

• Zápisy se umisťují postupně na disk. Proto je pohyb čtecí a zapisovací hlavy disku mnohem menší. Díky tomu je mechanismus zápisu a vyhledávání velmi rychlý.
• Indexy HFile jsou načteny do paměti při každém otevření souboru HFile. To pomáhá při hledání záznamu v jediném hledání.
• Trailer je ukazatel, který ukazuje na metablok HFile. Je zapsán na konec potvrzeného souboru. Obsahuje informace o časových značkách a filtrech květů.
• Blokový filtr pomáhá při hledání párů klíčových hodnot, přeskočí soubor, který neobsahuje požadovaný řádek. Timestamp také pomáhá při hledání verze souboru, pomáhá při přeskakování dat.

Poté, co znáte mechanismus zápisu a roli různých komponent při rychlejším zápisu a vyhledávání. Vysvětlím vám, jak funguje mechanismus čtení uvnitř architektury HBase? Poté přejdeme k mechanismům, které zvyšují výkon HBase, jako je zhutnění, rozdělení oblastí a zotavení.

Architektura HBase: Mechanismus čtení

Jak je popsáno v našem vyhledávacím mechanismu, klient nejprve načte umístění serveru Region ze serveru .META, pokud jej klient nemá ve své mezipaměti. Poté projde následujícími kroky:

• Pro čtení dat skener nejprve hledá buňku Row v mezipaměti bloku. Zde jsou uloženy všechny nedávno načtené páry klíč – hodnota.
• Pokud se skeneru nepodaří najít požadovaný výsledek, přesune se do MemStore, protože víme, že se jedná o mezipaměť pro zápis. Tam vyhledává naposledy napsané soubory, které dosud nebyly uloženy v souboru HFile.
• Nakonec použije načtení dat z HFile Bloom filtry a zablokování mezipaměti.

Zatím jsem diskutoval o mechanismu vyhledávání, čtení a zápisu HBase. Nyní se podíváme na mechanismus HBase, který umožňuje rychlé vyhledávání, čtení a zápis v HBase. Nejprve to pochopíme Zhutnění , což je jeden z těchto mechanismů.

Architektura HBase: Zhutnění

vytvořit řadu objektů

HBase kombinuje soubory HF, aby se snížilo úložiště a snížil počet hledání disků potřebných pro čtení. Tento proces se nazývá zhutnění . Zhutnění vybere některé soubory HF z oblasti a spojí je. Jak vidíte na obrázku výše, existují dva typy zhutnění.

1. Drobné zhutnění : HBase automaticky vybírá menší soubory HF a doporučuje je pro větší soubory HF, jak je znázorněno na obrázku výše. Tomu se říká drobné zhutnění. Provádí sloučení pro potvrzení menších souborů HF do větších souborů HF. To pomáhá při optimalizaci úložného prostoru.
2. Hlavní zhutnění: Jak je znázorněno na výše uvedeném obrázku, v Major Compaction HBase sloučí a doporučuje menší HFiles oblasti do nového HFile. V tomto procesu jsou stejné rodiny sloupců umístěny společně do nového souboru HFile. V tomto procesu upustí odstraněnou a vypršelou buňku. Zvyšuje výkon čtení.

Během tohoto procesu však mohou být přetíženy vstupně-výstupní disky a síťový provoz. Toto je známé jako Zesílení zápisu . Obvykle je tedy naplánováno během časování nízkého špičkového zatížení.

Nyní je další proces optimalizace výkonu, o kterém budu diskutovat Region Split . To je velmi důležité pro vyvažování zátěže.

Architektura HBase: Region Split

Níže uvedený obrázek ilustruje mechanismus rozdělení regionu.

Kdykoli se oblast zvětší, rozdělí se na dvě podřízené oblasti, jak ukazuje obrázek výše. Každá oblast představuje přesně polovinu nadřazené oblasti. Poté je toto rozdělení nahlášeno HMasterovi. Toto zpracovává stejný Region Server, dokud je HMaster nepřidělí na nový Region Server pro vyvažování zátěže.

V neposlední řadě vám vysvětlím, jak HBase obnovuje data po selhání. Jak to víme Obnova selhání je velmi důležitou vlastností HBase, takže nám dejte vědět, jak HBase obnovuje data po selhání.

Architektura HBase: Havárie HBase a obnova dat

• Kdykoli selže Region Server, ZooKeeper upozorní HMaster na selhání.
• Poté HMaster distribuuje a přiděluje oblasti havarovaného Region Serveru na mnoho aktivních Regionových serverů. Chcete-li obnovit data MemStore neúspěšného Region Serveru, HMaster distribuuje WAL na všechny Region servery.
• Každý Region Server znovu provede WAL, aby vytvořil MemStore pro rodinu sloupců této neúspěšné oblasti.
• Data se zapisují v chronologickém pořadí (v aktuálním pořadí) ve formátu WAL. Proto opětovné provedení tohoto WAL znamená provedení všech změn, které byly provedeny a uloženy v souboru MemStore.
• Takže poté, co všechny servery Region provedou WAL, budou obnovena data MemStore pro celou rodinu sloupců.

Doufám, že vám tento blog pomohl porozumět datovým modelům a architektuře HBase. Doufám, že se vám to líbilo. Nyní můžete souviset s funkcemi HBase (které jsem vysvětlil v mém předchozím Výukový program HBase blog) s HBase Architecture a pochopit, jak to funguje interně. Nyní, když znáte teoretickou část HBase, měli byste přejít k praktické části. Mějte to na paměti, náš další blog o bude vysvětlovat vzorek HBase POC .

Nyní, když jste porozuměli architektuře HBase, podívejte se na Edureka, důvěryhodná online vzdělávací společnost se sítí více než 250 000 spokojených studentů po celém světě. Kurz certifikace Edureka Big Data Hadoop Certification Training pomáhá studentům stát se odborníky na HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume a Sqoop pomocí případů použití v reálném čase v oblasti maloobchodu, sociálních médií, letectví, cestovního ruchu, financí.

Máte na nás dotaz? Uveďte to prosím v sekci komentáře a my se vám ozveme.