Arhitektura HBase: Model podataka HBase i mehanizam čitanja / pisanja HBase

Arhitektura HBase

U mom prethodnom blogu na Vodič za HBase , Objasnio sam što je HBase i njegove značajke. Također sam spomenuo studiju slučaja Facebook messenger-a da bi vam pomogao da se bolje povežete. Sada dalje idemo naprijed u našem , Objasnit ću vam podatkovni model HBase i HBase Architecture.Prije nego što krenete dalje, trebali biste znati i da je HBase važan koncept koji čini sastavni dio za certificiranje Hadoop velikih podataka.

Važne teme kroz koje ću vas provesti na ovom blogu o HBase arhitekturi su:

• HBase model podataka
• Arhitektura HBase i njezine komponente
• Mehanizam upisa HBase
• Mehanizam očitavanja HBase
• Mehanizmi optimizacije izvedbe HBase

Prvo da shvatimo model podataka HBase. Pomaže HBaseu u bržem čitanju / pisanju i pretraživanju.

Arhitektura HBase: model podataka HBase

Kao što znamo, HBase je baza podataka usmjerena na stupce NoSQL. Iako izgleda slično relacijskoj bazi podataka koja sadrži retke i stupce, ali nije relacijska baza podataka. Relacijske baze podataka orijentirane su na redove, dok je HBase orijentirana na stupce. Dakle, prvo shvatimo razliku između baza podataka orijentiranih na stup i redova:

Baze podataka orijentirane na redove ili na stupce:

• Baze podataka orijentirane na red pohranjuju zapise tablice u nizu redaka. Dok baze podataka orijentirane na stupcepohranjuju zapise tablice u nizu stupaca, tj. unosi u stupcu pohranjuju se na susjedna mjesta na diskovima.

Da bismo ga bolje razumjeli, uzmimo primjer i razmotrimo donju tablicu.

Ako je ova tablica pohranjena u bazu podataka orijentiranu na redove. Pohranit će zapise kao što je prikazano dolje:

jedan,Paul Walker,NAS,231,Galantno,

2, Vin Diesel,Brazil,520,Mustang

U bazama podataka orijentiranim na redove podaci se pohranjuju na temelju redaka ili korpica, kao što vidite gore.

Dok baze podataka orijentirane na stupac te podatke pohranjuju kao:

jedan,2, Paul Walker,Vin Diesel, NAS,Brazil, 231,520, Galantno,Mustang

U bazama podataka orijentiranim na stupac, sve vrijednosti stupaca pohranjuju se zajedno kao što se zajedno čuvaju vrijednosti prvog stupca, zatim vrijednosti drugog stupca zajedno, a podaci u ostalim stupcima pohranjuju se na sličan način.

• Kada je količina podataka vrlo velika, poput petabajta ili eksabajta, koristimo pristup usmjeren prema stupcu, jer se podaci jednog stupca pohranjuju zajedno i može im se brže pristupiti.
• Iako pristup usmjeren na redove usporedno rješava manji broj redaka i stupaca, jer baza podataka orijentirana na redove pohranjuje podatke u strukturiranom formatu.
• Kada trebamo obraditi i analizirati velik skup polustrukturiranih ili nestrukturiranih podataka, koristimo pristup usmjeren na stupce. Kao što su aplikacije koje se bave Mrežna analitička obrada poput pretraživanja podataka, skladištenja podataka, aplikacija uključujući analitiku itd.
• Dok, Internetska transakcijska obrada kao što su bankarske i financijske domene koje obrađuju strukturirane podatke i zahtijevaju transakcijska svojstva (ACID svojstva) koriste pristup usmjeren na redove.

HBase tablice imaju sljedeće komponente, prikazane na donjoj slici:

• Stolovi : Podaci su pohranjeni u formatu tablice u HBaseu. Ali ovdje su tablice u formatu orijentiranom na stupce.
• Red Ključ : Redne tipke koriste se za pretraživanje zapisa koji ubrzavaju pretraživanje. Bilo bi vas znatiželjno znati kako? Objasnit ću to u dijelu arhitekture koji ide dalje na ovom blogu.
• Stupac Obitelji : Razni stupci kombinirani su u obitelji stupaca. Te se obitelji stupaca pohranjuju zajedno, što ubrzava proces pretraživanja jer se podacima koji pripadaju istoj obitelji stupaca može pristupiti zajedno u jednom traženju.
• Stupac Kvalifikacije : Naziv svakog stupca poznat je kao kvalifikator stupca.
• Ćelija : Podaci se pohranjuju u ćelije. Podaci se izbacuju u ćelije koje su posebno identificirane kvalifikatorima tipki retka i stupaca.
• Vremenska oznaka : Vremenska oznaka kombinacija je datuma i vremena. Kad god se podaci pohrane, pohranjuju se s vremenskom oznakom. To olakšava traženje određene verzije podataka.

Na jednostavniji i razumljiviji način možemo reći da se HBase sastoji od:

• Set stolova
• Svaka tablica s obiteljima stupaca i redovima
• Redni ključ djeluje kao primarni ključ u HBaseu.
• Svaki pristup tablicama HBase koristi ovaj Primarni ključ
• Svaki kvalifikator stupca prisutan u HBase označava atribut koji odgovara objektu koji se nalazi u ćeliji.

Sad kad znate za HBase Data Model, pokazimo kako se ovaj podatkovni model podudara s HBase Architecture i čini ga prikladnim za veliku pohranu i bržu obradu.

Arhitektura HBase: Komponente arhitekture HBase

HBase ima tri glavne komponente, tj. HMaster poslužitelj , HBase regija poslužitelj, regije i Čuvar zoo vrta .

Sljedeća slika objašnjava hijerarhiju arhitekture HBase. Razgovarat ćemo o svakom od njih pojedinačno.

Sada ćemo prije odlaska na HMaster shvatiti Regije jer su svi ovi poslužitelji (HMaster, Regijski poslužitelj, Zookeeper) postavljeni da koordiniraju i upravljaju regijama i obavljaju razne operacije unutar Regiona. Pa bi vas zanimalo što su regije i zašto su tako važne?

Arhitektura HBase: Regija

Regija sadrži sve retke između početne i završne tipke dodijeljene toj regiji. Tablice HBase mogu se podijeliti u veći broj regija na takav način da su svi stupci porodice stupaca pohranjeni u jednoj regiji. Svaka regija sadrži retke poredanim poredkom.

Mnoga su područja dodijeljena a Regijski poslužitelj , koji je odgovoran za rukovanje, upravljanje, izvršavanje operacija čitanja i pisanja na tom skupu regija.

Dakle, zaključujući na jednostavniji način:

• Tablica se može podijeliti u niz regija. Regija je razvrstani raspon redaka koji pohranjuju podatke između početnog i završnog ključa.
• Regija ima zadanu veličinu od 256 MB koja se može konfigurirati prema potrebi.
• Grupu regija klijentima poslužuje regionalni poslužitelj.
• Regijski poslužitelj klijentu može poslužiti približno 1000 regija.

Polazeći od vrha hijerarhije, prvo bih vam želio objasniti o HMaster poslužitelju koji djeluje slično kao NameNode u HDFS . Zatim, krećući se prema dolje u hijerarhiji, provest ću vas kroz ZooKeeper i Region Server.

Arhitektura HBase: HMaster

Kao na donjoj slici, možete vidjeti kako HMaster obrađuje kolekciju Regijskog poslužitelja koji se nalazi na DataNodeu. Razumijemo kako HMaster to radi.

• HBase HMaster izvodi DDL operacije (stvaranje i brisanje tablica) i dodjeljuje regije poslužiteljima regije kao što možete vidjeti na gornjoj slici.
• Koordinira i upravlja Regijskim poslužiteljem (slično kao što NameNode upravlja DataNodeom u HDFS-u).
• Dodijeljuje regije regionalnim poslužiteljima prilikom pokretanja i ponovno dodjeljuje regije regionalnim poslužiteljima tijekom oporavka i uravnoteženja opterećenja.
• Nadgleda sve instance Regijskog poslužitelja u klasteru (uz pomoć Zookeeper) i izvodi aktivnosti oporavka kad god je bilo koji Regijski poslužitelj u kvaru.
• Pruža sučelje za stvaranje, brisanje i ažuriranje tablica.

HBase ima distribuirano i ogromno okruženje u kojem samo HMaster nije dovoljan da upravlja svime. Dakle, zapitali biste se što pomaže HMasteru u upravljanju ovim ogromnim okruženjem? Tu ZooKeeper dolazi na scenu. Nakon što smo shvatili kako HMaster upravlja HBase okolinom, shvatit ćemo kako Zookeeper pomaže HMasteru u upravljanju okolišem.

Arhitektura HBase: ZooKeeper - Koordinator

Ova slika ispod objašnjava mehanizam koordinacije ZooKeepera.

• Čuvar zoološkog vrta ponaša se kao koordinator unutar HBase distribuiranog okruženja. Pomaže u održavanju stanja poslužitelja unutar klastera komunicirajući kroz sesije.
• Svaki regionalni poslužitelj, zajedno s HMaster poslužiteljem, šalje redovite otkucaje srca u redovitim intervalima Zookeeperu i on provjerava koji je poslužitelj živ i dostupan kao što je spomenuto na gornjoj slici. Također pruža obavijesti o neuspjehu poslužitelja, tako da se mogu izvršiti mjere oporavka.
• Pozivajući se na gornju sliku koju vidite, postoji neaktivni poslužitelj koji djeluje kao sigurnosna kopija aktivnog poslužitelja. Ako aktivni poslužitelj ne uspije, dolazi po spas.
• Aktivni HMaster šalje otkucaje srca čuvaru zoološkog vrta, dok neaktivni HMaster osluškuje obavijest koju šalje aktivni HMaster. Ako aktivni HMaster ne uspije poslati otkucaj srca, sesija se briše i neaktivni HMaster postaje aktivan.
• Iako ako regionalni poslužitelj ne uspije poslati otkucaj srca, sesija je istekla i svi slušatelji su o tome obaviješteni. Tada HMaster izvodi odgovarajuće akcije oporavka o kojima ćemo kasnije razgovarati na ovom blogu.
• Zookeeper također održava put .META poslužitelja, koji pomaže bilo kojem klijentu u potrazi za bilo kojom regijom. Klijent prvo mora provjeriti s .META poslužiteljem u kojem regijskom poslužitelju pripada regija i dobiva put tog regionalnog poslužitelja.

Dok sam govorio o .META poslužitelju, dopustite mi da vam prvo objasnim što je .META poslužitelj? Dakle, lako možete povezati rad ZooKeeper-a i .META poslužitelja. Kasnije, kada ću vam na ovom blogu objasniti mehanizam pretraživanja HBase, objasnit ću kako ovo dvoje funkcioniraju u suradnji.

Arhitektura HBase: Meta tablica

• META tablica je posebna HBase kataloška tablica. Održava popis svih Regions poslužitelja u sustavu za pohranu HBase, kao što možete vidjeti na gornjoj slici.
• Gledajući lik koji možete vidjeti, .META datoteka održava tablicu u obliku ključeva i vrijednosti. Ključ predstavlja početni ključ regije i njezin id dok vrijednost sadrži put poslužitelja regije.

Kao što sam već raspravljao, Region Server i njegove funkcije dok sam vam objašnjavao Regije, sada se pomičemo hijerarhijom i usredotočit ću se na komponentu Regional Server i njihove funkcije. Kasnije ću razgovarati o mehanizmu pretraživanja, čitanja, pisanja i razumjeti kako sve ove komponente djeluju zajedno.

Arhitektura HBase: Komponente regionalnog poslužitelja

Ova slika ispod prikazuje komponente regionalnog poslužitelja. Sad ću o njima posebno razgovarati.

Regijski poslužitelj održava razne regije koje se izvode na vrhu . Komponente regionalnog poslužitelja su:

• WAL: Kao što možete zaključiti iz gornje slike, Write Ahead Log (WAL) datoteka je koja je priložena svakom regionalnom poslužitelju unutar distribuiranog okruženja. WAL pohranjuje nove podatke koji se nisu zadržali niti su predani trajnoj pohrani. Koristi se u slučaju neuspjeha oporavka skupova podataka.
• Blokiraj predmemoriju: Iz gornje slike jasno je vidljivo da se Block Cache nalazi na vrhu poslužitelja regije. U memoriju pohranjuje često pročitane podatke. Ako se podaci u BlockCacheu najmanje koriste, tada se ti podaci uklanjaju iz BlockCachea.
• MemStore: To je predmemorija pisanja. Pohranjuje sve dolazne podatke prije nego što ih preda na disk ili u trajnu memoriju. Postoji jedan MemStore za svaku obitelj kolona u regiji. Kao što možete vidjeti na slici, postoji više MemStores za regiju, jer svaka regija sadrži više porodica stupaca. Podaci se razvrstavaju u leksikografskom redoslijedu prije nego što se predaju na disk.
• HFile: Iz gornje slike možete vidjeti da je HFile pohranjen na HDFS. Tako pohranjuje stvarne stanice na disk. MemStore predaje podatke u HFile kada veličina MemStorea premaši.

Sad kad znamo glavne i sporedne komponente HBase arhitekture, objasnit ću mehanizam i njihov zajednički napor u tome. Bilo da se radi o čitanju ili pisanju, prvo moramo pretražiti odakle čitati ili kamo napisati datoteku. Dakle, shvatimo ovaj postupak pretraživanja, jer je ovo jedan od mehanizama koji čini HBase vrlo popularnom.

Arhitektura HBase: Kako se pretraživanje inicijalizira u HBaseu?

Kao što znate, Zookeeper pohranjuje mjesto META tablice. Kad god klijent pristupi sa zahtjevima za čitanje ili upis u HBase, dogodi se sljedeća operacija:

1. Klijent dohvaća mjesto META tablice iz ZooKeeper-a.
2. Klijent zatim traži mjesto za Regijski poslužitelj odgovarajućeg ključa retka iz META tablice da bi mu pristupio. Klijent kešira ove podatke s mjestom META tablice.
3. Tada će mjesto retka dobiti zahtjevom od odgovarajućeg Regijskog poslužitelja.

Za buduće reference, klijent koristi svoju predmemoriju kako bi dohvatio mjesto META tablice i prethodno pročitao Regijski poslužitelj ključa retka. Tada se klijent neće pozivati ​​na META tablicu sve dok i ako ne dođe do propusta jer je regija pomaknuta ili pomaknuta. Zatim će ponovno zatražiti META poslužitelj i ažurirati predmemoriju.

Kao i svaki put, klijenti ne troše vrijeme na dohvaćanje lokacije Regijskog poslužitelja s META poslužitelja, što na taj način štedi vrijeme i ubrzava postupak pretraživanja. Sada ću vam reći kako se pisanje odvija u HBaseu. Koje su komponente uključene u to i kako su uključene?

Arhitektura HBase: HBase Write Mehanizam

Ova slika ispod objašnjava mehanizam pisanja u HBaseu.

Mehanizam pisanja prolazi kroz sljedeći postupak uzastopno (pogledajte gornju sliku):

Korak 1: Kad god klijent ima zahtjev za upis, klijent zapisuje podatke u WAL (Write Ahead Log).

• Uređivanja se zatim dodaju na kraju WAL datoteke.
• Ova se WAL datoteka održava na svakom poslužitelju regije i poslužitelj regije koristi je za oporavak podataka koji nisu dodijeljeni disku.

Korak 2: Jednom kad se podaci upišu u WAL, oni se kopiraju u MemStore.

Korak 3: Nakon što se podaci stave u MemStore, klijent dobiva potvrdu.

Korak 4: Kad MemStore dosegne prag, izbacuje ili predaje podatke u HFile.

Sada duboko zaronimo i shvatimo kako MemStore doprinosi procesu pisanja i koje su njegove funkcije?

HBase Write Mehanizam- MemStore

• MemStore uvijek ažurira podatke pohranjene u njemu, leksikografskim redoslijedom (u slijedu u rječniku) kao sortirane KeyValues. Za svaku obitelj stupaca postoji jedan MemStore, pa se stoga ažuriranja pohranjuju na sortirani način za svaku obitelj stupaca.
• Kad MemStore dosegne prag, sortira sve podatke u novi HFile. Ovaj HFile pohranjen je u HDFS. HBase sadrži više HFi datoteka za svaku obitelj stupaca.
• S vremenom, broj HFile raste kako MemStore izbacuje podatke.
• MemStore također sprema posljednji upisani sekvencijski broj, tako da i Master Server i MemStore znaju što je do sada počinjeno i od čega početi. Kada se regija pokrene, čita se posljednji sekvencijski broj i s tog broja započinju nova uređivanja.

Kao što sam nekoliko puta raspravljao, HFile je glavno trajno spremište u HBase arhitekturi. Napokon su svi podaci predani HFile-u koji je trajna pohrana HBase. Stoga, pogledajmo svojstva HFile-a što ga čini bržim za pretraživanje tijekom čitanja i pisanja.

Arhitektura HBase: HBase Write Mehanizam- HFile

• Zapisi se postavljaju sekvencijalno na disk. Stoga je kretanje glave za čitanje i pisanje diska vrlo manje. To čini mehanizam pisanja i pretraživanja vrlo brzim.
• Indeksi HFile učitavaju se u memoriju kad god se otvori HFile. To pomaže u pronalaženju zapisa u jednom traženju.
• Najava je pokazivač koji pokazuje na meta blok HFile-a. Napisano je na kraju predane datoteke. Sadrži informacije o vremenskim oznakama i filtrima cvjetanja.
• Bloom Filter pomaže u pretraživanju parova vrijednosti ključeva, preskače datoteku koja ne sadrži potreban ključ retka. Timestamp također pomaže u pretraživanju verzije datoteke, pomaže u preskakanju podataka.

Nakon poznavanja mehanizma pisanja i uloge različitih komponenata u bržem pisanju i pretraživanju. Objasnit ću vam kako funkcionira mehanizam čitanja unutar HBase arhitekture? Tada ćemo prijeći na mehanizme koji povećavaju performanse HBase poput sabijanja, razdvajanja regije i oporavka.

Arhitektura HBase: Čitaj Mehanizam

Kao što je raspravljeno u našem mehanizmu pretraživanja, prvo klijent dohvaća lokaciju Regijskog poslužitelja s .META poslužitelja ako ga klijent nema u svojoj predmemoriji. Zatim prolazi slijedeće korake kako slijedi:

• Za čitanje podataka, skener prvo traži ćeliju reda u predmemoriji blokova. Ovdje su pohranjeni svi nedavno pročitani parovi vrijednosti ključa.
• Ako Scanner ne uspije pronaći traženi rezultat, premješta se u MemStore, jer znamo da je ovo predmemorija pisanja. Tamo traži najnovije napisane datoteke, koje još nisu bačene u HFile.
• Napokon će upotrijebiti bloom filtre i blok predmemoriju za učitavanje podataka iz HFile.

Do sada sam razgovarao o mehanizmu pretraživanja, čitanja i pisanja HBase. Sada ćemo razmotriti mehanizam HBase koji omogućuje brzo pretraživanje, čitanje i pisanje u HBaseu. Prvo, shvatit ćemo Sabijanje , koji je jedan od tih mehanizama.

Arhitektura HBase: Sabijanje

HBase kombinira HFiles kako bi smanjio pohranu i smanjio broj traženja diska potrebnih za čitanje. Taj se proces naziva zbijanje . Zbijanje odabire neke HFilove iz regije i kombinira ih. Postoje dvije vrste zbijanja kao što možete vidjeti na gornjoj slici.

1. Manje sabijanje : HBase automatski odabire manje datoteke HFi i vraća ih na veće datoteke HFi, kao što je prikazano na gornjoj slici. To se naziva Manje zbijanje. Izvršava sortiranje spajanja za uređivanje manjih HFilesa za veće HFiles. To pomaže u optimizaciji prostora za pohranu.
2. Glavno sabijanje: Kao što je prikazano na gornjoj slici, u Velikom zbijanju, HBase spaja i ponovo predaje male HFilove regije u novu HFile. U tom su procesu iste obitelji stupaca smještene zajedno u novi HFile. U ovom se postupku ispuštaju izbrisane i istekle ćelije. Povećava izvedbu čitanja.

No tijekom ovog postupka ulazno-izlazni diskovi i mrežni promet mogu postati zagušeni. Ovo je poznato kao pisanje pojačanja . Dakle, obično se planira za vrijeme vršnih opterećenja.

Sada je još jedan postupak optimizacije izvedbe o kojem ću razgovarati Regija Split . To je vrlo važno za uravnoteženje opterećenja.

što je * u sql

Arhitektura HBase: Regija Split

Sljedeća slika ilustrira mehanizam Region Split.

Kad god regija postane velika, podijeljena je u dvije podređene regije, kao što je prikazano na gornjoj slici. Svaka regija predstavlja točno polovicu matične regije. Tada se taj podjela prijavljuje HMasteru. To obrađuje isti regionalni poslužitelj dok ih HMaster ne dodijeli novom regionalnom poslužitelju za uravnoteženje opterećenja.

Krećući se niz liniju, posljednje, ali ne najmanje važno, objasnit ću vam kako HBase obnavlja podatke nakon kvara. Kao što to znamo Oporavak neuspjeha je vrlo važna značajka HBase, pa nam recite kako HBase obnavlja podatke nakon kvara.

Arhitektura HBase: HBase pad i oporavak podataka

• Kad god regionalni poslužitelj zakaže, ZooKeeper obavijesti HMaster o kvaru.
• Tada HMaster distribuira i dodjeljuje regije srušenog Regijskog poslužitelja mnogim aktivnim Regijskim poslužiteljima. Da bi oporavio podatke MemStorea neuspjelog regionalnog poslužitelja, HMaster distribuira WAL svim regionalnim poslužiteljima.
• Svaki poslužitelj regije ponovno izvršava WAL za izgradnju MemStorea za obitelj stupaca te neuspjele regije.
• Podaci su zapisani kronološkim redoslijedom (pravovremeno) WAL-om. Prema tome, ponovno izvršavanje tog WAL-a znači uvođenje svih promjena koje su napravljene i pohranjene u datoteci MemStore.
• Dakle, nakon što svi regionalni poslužitelji izvrše WAL, obnavljaju se podaci MemStore za svu obitelj stupaca.

Nadam se da bi vam ovaj blog pomogao u razumijevanju modela podataka HBase i arhitekture HBase. Nadam se da ste uživali. Sada se možete povezati sa značajkama HBase (što sam objasnio u svom prethodnom Vodič za HBase blog) s HBase Architecture i shvatite kako to interno djeluje. Sad kad znate teorijski dio HBase, trebali biste prijeći na praktični dio. Imajući ovo na umu, naš sljedeći blog objasnit će uzorak HBase POC .

Sad kad ste razumjeli arhitekturu HBase, pogledajte Edureka, pouzdana tvrtka 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 korištenja 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.