Arhitectura HBase: Modelul de date HBase și mecanismul de citire / scriere HBase

HBase Architecture

În blogul meu anterior de pe Tutorial HBase , Am explicat ce este HBase și caracteristicile sale. De asemenea, am menționat studiul de caz Facebook Messenger pentru a vă ajuta să vă conectați mai bine. Acum mergem mai departe în , Vă voi explica modelul de date al HBase și HBase Architecture.Înainte de a trece mai departe, ar trebui să știți, de asemenea, că HBase este un concept important care constituie o parte integrantă a pentru certificarea Big Data Hadoop.

Subiectele importante pe care le voi aborda în acest blog de arhitectură HBase sunt:

• Modelul de date HBase
• HBase Architecture și componentele sale
• Mecanismul de scriere HBase
• Mecanismul de citire HBase
• Mecanisme de optimizare a performanței HBase

Să înțelegem mai întâi modelul de date al HBase. Ajută HBase la citire / scriere și căutări mai rapide.

Arhitectura HBase: Modelul de date HBase

După cum știm, HBase este o bază de date NoSQL orientată pe coloane. Deși arată similar cu o bază de date relațională care conține rânduri și coloane, dar nu este o bază de date relațională. Bazele de date relaționale sunt orientate pe rând, în timp ce HBase este orientat pe coloane. Deci, să înțelegem mai întâi diferența dintre bazele de date orientate pe coloane și bazele de date orientate pe rând:

Baze de date orientate pe rânduri vs. bazate pe coloane:

• Bazele de date orientate pe rând stochează înregistrările tabelelor într-o succesiune de rânduri. În timp ce bazele de date orientate pe coloanestocați înregistrările tabelelor într-o succesiune de coloane, adică intrările dintr-o coloană sunt stocate în locații contigue pe discuri.

Pentru a o înțelege mai bine, să luăm un exemplu și să luăm în considerare tabelul de mai jos.

Dacă acest tabel este stocat într-o bază de date orientată pe rând. Va stoca înregistrările așa cum se arată mai jos:

unu,Paul Walker,S.U.A.,231,Galant,

2, Vin Diesel,Brazilia,520,Mustang

În bazele de date orientate pe rând, datele sunt stocate pe baza de rânduri sau tupluri, după cum puteți vedea mai sus.

În timp ce bazele de date orientate pe coloane stochează aceste date ca:

unu,2, Paul Walker,Vin Diesel, S.U.A.,Brazilia, 231,520, Galant,Mustang

Într-o bază de date orientată pe coloane, toate valorile coloanei sunt stocate împreună, așa cum valorile primei coloane vor fi stocate împreună, apoi valorile celei de-a doua coloane vor fi stocate împreună, iar datele din alte coloane sunt stocate în mod similar.

• Când cantitatea de date este foarte mare, cum ar fi în termeni de petabytes sau exabytes, folosim abordarea orientată pe coloane, deoarece datele unei singure coloane sunt stocate împreună și pot fi accesate mai repede.
• În timp ce abordarea orientată pe rânduri gestionează în mod eficient un număr mai mic de rânduri și coloane, întrucât baza de date orientată pe rând stochează datele este un format structurat.
• Când trebuie să procesăm și să analizăm un set mare de date semi-structurate sau nestructurate, folosim abordarea orientată pe coloane. Cum ar fi aplicațiile care se ocupă Procesare analitică online cum ar fi extragerea datelor, depozitarea datelor, aplicații, inclusiv analize etc.
• Întrucât, Prelucrare tranzacțională online precum domeniile bancare și financiare care gestionează date structurate și necesită proprietăți tranzacționale (proprietăți ACID) utilizează abordarea orientată pe rând.

Tabelele HBase au următoarele componente, prezentate în imaginea de mai jos:

• Mese : Datele sunt stocate într-un format de tabel în HBase. Dar aici tabelele sunt în format orientat pe coloane.
• Rând Cheie : Tastele rând sunt folosite pentru căutarea înregistrărilor care fac căutările rapide. Ai fi curios să știi cum? O voi explica în partea de arhitectură care merge mai departe în acest blog.
• Coloană Familii : Diverse coloane sunt combinate într-o familie de coloane. Aceste familii de coloane sunt stocate împreună, ceea ce face procesul de căutare mai rapid, deoarece datele aparținând aceleiași familii de coloane pot fi accesate împreună într-o singură căutare.
• Coloană Calificări : Numele fiecărei coloane este cunoscut ca calificativul său de coloană.
• Celula : Datele sunt stocate în celule. Datele sunt aruncate în celule care sunt identificate în mod specific prin calificarea rândurilor și coloanelor.
• Timestamp-ul : Timestamp este o combinație de dată și oră. Ori de câte ori datele sunt stocate, acestea sunt stocate cu marcajul de timp. Acest lucru facilitează căutarea unei anumite versiuni de date.

Într-un mod mai simplu și mai înțelegător, putem spune că HBase constă din:

• Set de mese
• Fiecare tabel cu familii de coloane și rânduri
• Tasta rând acționează ca o cheie primară în HBase.
• Orice acces la tabelele HBase utilizează această cheie primară
• Fiecare calificativ de coloană prezent în HBase denotă atribut corespunzător obiectului care se află în celulă.

Acum, că știți despre modelul de date HBase, permiteți-ne să vedem cum acest model de date se încadrează în arhitectura HBase și îl face potrivit pentru stocare mare și procesare mai rapidă.

HBase Architecture: Componente ale HBase Architecture

HBase are trei componente majore, adică Server HMaster , Server regiune HBase, Regiuni și Ingrijitor zoo .

Figura de mai jos explică ierarhia arhitecturii HBase. Vom vorbi despre fiecare dintre ele în mod individual.

Acum, înainte de a merge la HMaster, vom înțelege regiunile, deoarece toate aceste servere (HMaster, Region Server, Zookeeper) sunt plasate pentru a coordona și gestiona regiunile și pentru a efectua diferite operațiuni în interiorul regiunilor. Așadar, ați fi curios să știți ce sunt regiunile și de ce sunt atât de importante?

Arhitectura HBase: Regiune

O regiune conține toate rândurile dintre tasta de pornire și tasta de final atribuită regiunii respective. Tabelele HBase pot fi împărțite în mai multe regiuni în așa fel încât toate coloanele unei familii de coloane să fie stocate într-o singură regiune. Fiecare regiune conține rândurile într-o ordine sortată.

Multe regiuni sunt alocate unei Server regiune , care este responsabil pentru manipularea, gestionarea, executarea operațiilor de citire și scriere pe acel set de regiuni.

Deci, concluzionând într-un mod mai simplu:

• Un tabel poate fi împărțit în mai multe regiuni. O regiune este o gamă sortată de rânduri care stochează date între o cheie de pornire și o cheie de sfârșit.
• O regiune are o dimensiune implicită de 256 MB, care poate fi configurată în funcție de necesitate.
• Un grup de regiuni este deservit clienților de către un server de regiune.
• Un server de regiune poate deservi aproximativ 1000 de regiuni către client.

Acum, începând din partea de sus a ierarhiei, aș dori mai întâi să vă explic despre HMaster Server care acționează în mod similar ca un NameNode în HDFS . Apoi, trecând în jos în ierarhie, vă voi duce prin ZooKeeper și Region Server.

Arhitectura HBase: HMaster

Ca și în imaginea de mai jos, puteți vedea HMaster gestionează o colecție de Region Server care se află pe DataNode. Să înțelegem cum face acest lucru HMaster.

• HBase HMaster efectuează operații DDL (creează și șterge tabele) și atribuie regiuni serverelor Region așa cum puteți vedea în imaginea de mai sus.
• Acesta coordonează și gestionează serverul de regiune (similar cu NameNode care gestionează DataNode în HDFS).
• Atribuie regiuni la serverele de regiune la pornire și reatribuie regiuni la servere de regiune în timpul recuperării și echilibrării încărcării.
• Monitorizează toate instanțele Region Server din cluster (cu ajutorul Zookeeper) și efectuează activități de recuperare ori de câte ori un server de regiune este defect.
• Oferă o interfață pentru crearea, ștergerea și actualizarea tabelelor.

HBase are un mediu distribuit și imens în care HMaster singur nu este suficient pentru a gestiona totul. Deci, te-ai întreba ce ajută HMaster să gestioneze acest mediu imens? Acolo apare ZooKeeper. După ce am înțeles modul în care HMaster gestionează mediul HBase, vom înțelege modul în care Zookeeper îl ajută pe HMaster în gestionarea mediului.

Arhitectura HBase: ZooKeeper - Coordonatorul

Această imagine de mai jos explică mecanismul de coordonare al ZooKeeper.

• Zookeeper acționează ca un coordonator în mediul distribuit HBase. Ajută la menținerea stării serverului în interiorul clusterului prin comunicarea prin sesiuni.
• Fiecare server de regiune împreună cu serverul HMaster trimit în mod regulat ritmul cardiac către Zookeeper și verifică ce server este viu și disponibil așa cum se menționează în imaginea de mai sus. De asemenea, oferă notificări de eșec ale serverului, astfel încât să poată fi executate măsuri de recuperare.
• Referindu-ne la imaginea de mai sus pe care o puteți vedea, există un server inactiv, care acționează ca o copie de rezervă pentru serverul activ. Dacă serverul activ eșuează, vine pentru salvare.
• HMaster-ul activ trimite bătăile inimii către Zookeeper în timp ce HMaster-ul inactiv ascultă notificările trimise de HMaster-ul activ. Dacă HMaster-ul activ nu reușește să trimită bătăile inimii, sesiunea este ștearsă și HMaster-ul inactiv devine activ.
• În timp ce, dacă un server de regiune nu reușește să trimită bătăile inimii, sesiunea este expirată și toți ascultătorii sunt informați despre aceasta. Apoi HMaster efectuează acțiuni de recuperare adecvate pe care le vom discuta mai târziu în acest blog.
• Zookeeper menține, de asemenea, calea .META Server, care ajută orice client în căutarea oricărei regiuni. Clientul trebuie mai întâi să verifice cu serverul .META de care server de regiune aparține o regiune și obține calea acelui server de regiune.

În timp ce vorbeam despre serverul .META, permiteți-mi să vă explic mai întâi ce este serverul .META? Deci, puteți raporta cu ușurință munca ZooKeeper și a serverului .META împreună. Mai târziu, când vă voi explica mecanismul de căutare HBase în acest blog, voi explica cum funcționează aceste două în colaborare.

Arhitectura HBase: Tabelul Meta

• Tabelul META este un tabel special de catalog HBase. Păstrează o listă cu toate serverele din regiune în sistemul de stocare HBase, după cum puteți vedea în imaginea de mai sus.
• Privind figura pe care o puteți vedea, .META fișierul menține tabelul sub formă de chei și valori. Cheia reprezintă cheia de pornire a regiunii și id-ul acesteia, în timp ce valoarea conține calea serverului de regiune.

Așa cum am discutat deja, Region Server și funcțiile sale, în timp ce vă explicam Regiunile, prin urmare, acum ne deplasăm în ierarhie și mă voi concentra asupra componentei Serverului Region și a funcțiilor acestora. Mai târziu voi discuta despre mecanismul de căutare, citire, scriere și înțelegerea modului în care toate aceste componente funcționează împreună.

Arhitectura HBase: Componentele serverului de regiune

Această imagine de mai jos prezintă componentele unui server de regiune. Acum, le voi discuta separat.

Un server de regiune menține diferite regiuni care rulează în partea de sus a . Componentele unui server de regiune sunt:

supraîncărcare metodă și suprascriere în java

• WAL: După cum puteți concluziona din imaginea de mai sus, Write Ahead Log (WAL) este un fișier atașat fiecărui server de regiune din mediul distribuit. WAL stochează noile date care nu au fost persistente sau angajate pentru stocarea permanentă. Se utilizează în caz de eșec la recuperarea seturilor de date.
• Blocați memoria cache: Din imaginea de mai sus, este clar vizibil faptul că Block Cache se află în partea de sus a Region Server. Stochează datele citite frecvent în memorie. Dacă datele din BlockCache sunt utilizate cel mai recent, atunci aceste date sunt eliminate din BlockCache.
• MemStore: Este memoria cache de scriere. Stochează toate datele primite înainte de a le trimite pe disc sau în memoria permanentă. Există câte un MemStore pentru fiecare familie de coloane dintr-o regiune. După cum puteți vedea în imagine, există mai multe MemStores pentru o regiune, deoarece fiecare regiune conține mai multe familii de coloane. Datele sunt sortate în ordine lexicografică înainte de a le trimite pe disc.
• HFile: Din figura de mai sus puteți vedea HFile este stocat pe HDFS. Astfel, stochează celulele reale pe disc. MemStore trimite datele la HFile când dimensiunea MemStore depășește.

Acum, că cunoaștem componentele majore și minore ale Arhitecturii HBase, voi explica mecanismul și efortul lor de colaborare în acest sens. Fie că este vorba de citire sau scriere, mai întâi trebuie să căutăm de unde să citim sau unde să scriem un fișier. Deci, să înțelegem acest proces de căutare, deoarece acesta este unul dintre mecanismele care fac HBase foarte popular.

Arhitectura HBase: Cum se inițializează căutarea în HBase?

După cum știți, Zookeeper stochează locația tabelului META. Ori de câte ori un client se apropie cu o citire sau scrie solicitări către HBase are loc următoarea operație:

1. Clientul recuperează locația tabelului META din ZooKeeper.
2. Clientul solicită apoi locația serverului de regiune al cheii de rând corespunzătoare din tabelul META pentru a-l accesa. Clientul cache aceste informații cu locația Tabelului META.
3. Apoi va obține locația rândului solicitând de la serverul de regiune corespunzător.

Pentru referințele viitoare, clientul își folosește memoria cache pentru a prelua locația tabelului META și a citit anterior Region Server cheie de rând. Apoi, clientul nu se va referi la tabelul META, până și cu excepția cazului în care există o lipsă, deoarece regiunea este mutată sau mutată. Apoi va solicita din nou serverului META și va actualiza memoria cache.

Ca de fiecare dată, clienții nu pierd timp în recuperarea locației serverului de regiune de pe serverul META, astfel, acest lucru economisește timp și face procesul de căutare mai rapid. Acum, permiteți-mi să vă spun cum are loc scrierea în HBase. Care sunt componentele implicate în acesta și cum sunt acestea implicate?

Arhitectura HBase: Scrie HBase Mecanism

Această imagine de mai jos explică mecanismul de scriere din HBase.

Mecanismul de scriere parcurge succesiv următorul proces (consultați imaginea de mai sus):

Pasul 1: Ori de câte ori clientul are o cerere de scriere, acesta scrie datele în WAL (Write Ahead Log).

• Modificările sunt apoi anexate la sfârșitul fișierului WAL.
• Acest fișier WAL este menținut în fiecare server de regiune și server de regiune îl folosește pentru a recupera datele care nu sunt angajate pe disc.

Pasul 2: Odată ce datele sunt scrise în WAL, atunci acestea sunt copiate în MemStore.

Pasul 3: Odată ce datele sunt plasate în MemStore, atunci clientul primește confirmarea.

Pasul 4: Când MemStore atinge pragul, acesta aruncă sau transferă datele într-un fișier HFile.

Acum, să facem o scufundare profundă și să înțelegem modul în care MemStore contribuie la procesul de scriere și care sunt funcțiile sale?

Scrie HBase Mecanism- MemStore

• MemStore actualizează întotdeauna datele stocate în acesta, într-o ordine lexicografică (secvențial într-un mod dicționar) ca valori KeyValues ​​sortate. Există un MemStore pentru fiecare familie de coloane și astfel actualizările sunt stocate într-un mod sortat pentru fiecare familie de coloane.
• Când MemStore atinge pragul, aruncă toate datele într-un nou fișier H într-o manieră sortată. Acest fișier HF este stocat în HDFS. HBase conține mai multe fișiere H pentru fiecare familie de coloane.
• În timp, numărul HFile crește pe măsură ce MemStore renunță la date.
• MemStore salvează, de asemenea, ultimul număr al secvenței scrise, astfel încât Master Server și MemStore știu amândouă ce este angajat până acum și de unde să pornim. Când regiunea pornește, se citește ultimul număr de secvență și, din acel număr, încep modificările noi.

După cum am discutat de mai multe ori, acel HFile este principalul stocare persistentă într-o arhitectură HBase. În cele din urmă, toate datele sunt dedicate HFile, care este stocarea permanentă a HBase. Prin urmare, să ne uităm la proprietățile HFile, care îl fac mai rapid pentru căutare în timp ce citește și scrie.

Arhitectura HBase: Scrie HBase Mecanism- HFile

• Scrierile sunt plasate secvențial pe disc. Prin urmare, mișcarea capului de citire-scriere a discului este foarte redusă. Acest lucru face ca mecanismul de scriere și căutare să fie foarte rapid.
• Indicii HFile sunt încărcați în memorie ori de câte ori este deschis un fișier HFile. Acest lucru ajută la găsirea unei înregistrări într-o singură căutare.
• Trailerul este un indicator care indică meta-blocul HFile. Este scris la sfârșitul fișierului angajat. Acesta conține informații despre timestamp și filtre de înflorire.
• Bloom Filter ajută la căutarea perechilor de valori cheie, omite fișierul care nu conține cheia de rând necesară. Timestamp ajută, de asemenea, la căutarea unei versiuni a fișierului, ajută la omiterea datelor.

După cunoașterea mecanismului de scriere și a rolului diferitelor componente în scrierea și căutarea mai rapidă. Vă voi explica cum funcționează mecanismul de citire într-o arhitectură HBase? Apoi vom trece la mecanismele care cresc performanța HBase, cum ar fi compactarea, împărțirea regiunii și recuperarea.

Arhitectura HBase: Citiți Mecanism

Așa cum s-a discutat în mecanismul nostru de căutare, clientul primește mai întâi locația serverului de regiune de pe serverul .META dacă clientul nu îl are în memoria cache. Apoi parcurge etapele secvențiale după cum urmează:

• Pentru citirea datelor, scanerul caută mai întâi celula Row în memoria cache. Aici sunt stocate toate perechile de valori cheie citite recent.
• Dacă scanerul nu reușește să găsească rezultatul necesar, acesta se mută în MemStore, deoarece știm că aceasta este memoria cache de scriere. Acolo, caută cele mai recente fișiere scrise, care nu au fost încă aruncate în HFile.
• În cele din urmă, va utiliza filtre Bloom și va bloca memoria cache pentru a încărca datele din HFile.

Până acum, am discutat despre mecanismul de căutare, citire și scriere a HBase. Acum ne vom uita la mecanismul HBase care face căutarea, citirea și scrierea rapidă în HBase. În primul rând, vom înțelege Compactarea , care este unul dintre aceste mecanisme.

Arhitectura HBase: Compactarea

HBase combină HFiles pentru a reduce spațiul de stocare și a reduce numărul de căutări de disc necesare pentru o citire. Acest proces se numește compactare . Compactarea alege unele HFiles dintr-o regiune și le combină. Există două tipuri de compactare așa cum puteți vedea în imaginea de mai sus.

1. Compactare minoră : HBase alege automat fișiere HF mai mici și le recomandă în fișiere HF mai mari, așa cum se arată în imaginea de mai sus. Aceasta se numește compactare minoră. Realizează sortare de îmbinare pentru comiterea HFiles mai mici la HFiles mai mari. Acest lucru ajută la optimizarea spațiului de stocare.
2. Compactare majoră: Așa cum este ilustrat în imaginea de mai sus, în compactare majoră, HBase fuzionează și recomandă fișierele HF mai mici ale unei regiuni într-un fișier HF nou. În acest proces, aceleași familii de coloane sunt plasate împreună în noul HFile. Eliberează celula ștearsă și expirată în acest proces. Crește performanța citirii.

Dar în timpul acestui proces, discurile de intrare-ieșire și traficul de rețea ar putea fi aglomerate. Acest lucru este cunoscut sub numele de scrie amplificare . Deci, este, în general, programată în timpul cronometrelor de vârf scăzute.

Acum, un alt proces de optimizare a performanței despre care voi discuta este Regiunea Split . Acest lucru este foarte important pentru echilibrarea sarcinii.

Arhitectura HBase: Regiunea Split

Figura de mai jos ilustrează mecanismul de împărțire a regiunii.

Ori de câte ori o regiune devine mare, aceasta este împărțită în două regiuni copil, așa cum se arată în figura de mai sus. Fiecare regiune reprezintă exact jumătate din regiunea părinte. Apoi această divizare este raportată către HMaster. Acest lucru este gestionat de același server de regiune până când HMaster le alocă unui nou server de regiune pentru echilibrarea încărcării.

Mergând în jos pe linie, nu în ultimul rând, vă voi explica cum recuperează datele HBase după un eșec. După cum știm asta Recuperarea eșecului este o caracteristică foarte importantă a HBase, deci anunțați-ne cum recuperează datele HBase după un eșec.

Arhitectura HBase: HBase Crash și recuperarea datelor

• Ori de câte ori un server de regiune eșuează, ZooKeeper notifică HMaster-ului despre eșec.
• Apoi HMaster distribuie și alocă regiunile serverului de regiune blocat la mai multe servere de regiuni active. Pentru a recupera datele MemStore ale serverului de regiune eșuat, HMaster distribuie WAL către toate serverele de regiune.
• Fiecare server de regiune execută din nou WAL pentru a construi MemStore pentru familia de coloane a regiunii care nu a reușit.
• Datele sunt scrise în ordine cronologică (în timp util) în WAL. Prin urmare, reexecutarea acelui WAL înseamnă efectuarea tuturor modificărilor care au fost făcute și stocate în fișierul MemStore.
• Deci, după ce toate serverele de regiune execută WAL, datele MemStore pentru toată familia de coloane sunt recuperate.

Sper că acest blog v-ar fi ajutat la subevaluarea modelului de date HBase și a arhitecturii HBase. Sper ca ti-a placut. Acum vă puteți raporta la caracteristicile HBase (pe care le-am explicat în versiunea anterioară Tutorial HBase blog) cu HBase Architecture și înțelegeți cum funcționează intern. Acum că cunoașteți partea teoretică a HBase, ar trebui să treceți la partea practică. Ținând cont de acest lucru, următorul nostru blog de va explica un eșantion HBase POC .

Acum că ați înțeles Arhitectura HBase, verificaț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.