Ieskats HBase arhitektūrā



Šajā ziņojumā ir apspriesti HBase un ieskati par HBase arhitektūru. Tajā tiek apspriesti arī Hbase komponenti, piemēram, Master, Region serveris un Zoo turētājs, kā arī to izmantošana.

Šodienas ierakstā apspriedīsim HBase arhitektūru. Padziļināsim mūsu HBase pamatus, pirms iedziļināsimies HBase arhitektūrā.





kā iziet no Java programmas

HBase - pamati:

HBase ir atvērtā koda NoSQL izplatīts, ar relāciju nesaistīts, versijots, daudzdimensionāls, uz kolonnām orientēts veikals, kas ir modelēts pēc Google BigTable, kas darbojas virs HDFS. '' NoSQL 'ir plašs termins, kas nozīmē, ka datu bāze nav RDBMS, kas atbalsta SQL kā galveno piekļuves valodu. Bet NoSQL datu bāzēm ir daudz veidu, un Berkeley DB ir labs vietējās NoSQL datu bāzes piemērs, savukārt HBase ir ļoti izplatīta datu bāze.

HBase nodrošina visas Google BigTable funkcijas. Tas sākās kā Powerset projekts, lai apstrādātu lielu daudzumu datu dabiskās valodas meklēšanai. Tas tika izstrādāts kā daļa no Apache’s Hadoop projekta un darbojas virs HDFS (Hadoop Distributed File System). Tas nodrošina kļūdu izturīgus veidus, kā uzglabāt lielu daudzumu retu datu. HBase patiešām vairāk ir “Datu krātuve”, nevis “Datu bāze”, jo tai trūkst daudzu RDBMS pieejamo funkciju, piemēram, drukātas kolonnas, sekundārie indeksi, aktivizētāji un uzlabotas vaicājumu valodas utt.



Uz kolonnām orientētās datu bāzēs datu tabula tiek glabāta kā datu kolonnu sadaļas, nevis kā datu rindas. Kolonnu orientētas datu bāzes datu modeli veido tabulas nosaukums, rindas atslēga, kolonnu saime, kolonnas, laika zīmogs. Veidojot tabulas HBase, rindas tiks unikāli identificētas, izmantojot rindu taustiņus un laika zīmogu. Šajā datu modelī kolonnu saime ir statiska, savukārt kolonnas ir dinamiskas. Tagad ieskatīsimies HBase arhitektūrā.

Kad doties uz HBase?

HBase ir laba iespēja tikai tad, ja ir simtiem miljonu vai miljardu rindu. HBase var izmantot arī vietās, apsverot iespēju pāriet no RDBMS uz HBase kā pilnīgu pārveidojumu, nevis portu. Citiem vārdiem sakot, HBase nav optimizēts klasiskām darījumu lietojumprogrammām vai pat relāciju analītikai. Veicot lielu MapReduce partiju, tas arī nav pilnīgs HDFS aizstājējs. Tad kāpēc jums vajadzētu doties uz HBase ?? Ja jūsu lietojumprogrammai ir mainīga shēma, kur katra rinda ir nedaudz atšķirīga, jums vajadzētu apskatīt HBase.

HBase arhitektūra:

Šis attēls skaidri izskaidro HBase arhitektūru.



Ieskats HBase arhitektūrā

HBase ir trīs galvenie komponenti: Meistars, reģiona serveris un zoodārza turētājs . Pārējie komponenti ir Memstore, HFile un WAL.

Tā kā HBase darbojas virs HDFS, tā izmanto galveno-vergu arhitektūru, kurā HMaster būs galvenais mezgls un reģiona serveri ir vergu mezgli. Kad klients nosūta rakstīšanas pieprasījumu, HMaster saņem šo pieprasījumu un pārsūta to attiecīgajam reģiona serverim.

Reģiona serveris:

Tā ir sistēma, kas darbojas līdzīgi kā datu mezgls. Kad reģiona serveris (RS) saņem rakstīšanas pieprasījumu, tas novirza pieprasījumu uz konkrētu reģionu. Katrs reģions glabā rindu kopu. Rindu datus var atdalīt vairākās kolonnu grupās (CF). Konkrēta CF dati tiek glabāti HStore veikalā, kas sastāv no Memstore un HFile kopas.

kā padarīt jframe java

Ko dara Memstore?

Memstore uzskaita visus žurnālus par lasīšanas un rakstīšanas operācijām, kas veiktas konkrētajā reģiona serverī. No tā mēs varam teikt, ka tā darbojas līdzīgi nosaukuma mezglam Hadoopā. Memstore ir atmiņas atmiņa, tāpēc Memstore žurnālu glabāšanai izmanto katra datu mezgla atmiņā esošo atmiņu. Kad tiek sasniegti noteikti sliekšņi, Memstore dati tiek iekļauti HFile.

Memstore izmantošanas galvenais mērķis ir nepieciešamība uzglabāt datus DFS, kas sakārtoti pēc rindas atslēgas. Tā kā HDFS ir paredzēts secīgai lasīšanai / rakstīšanai un nav atļautas failu modifikācijas, HBase nevar efektīvi ierakstīt datus diskā, jo tie tiek saņemti: rakstītie dati netiks kārtoti (kad ievade netiks kārtota), kas nozīmē, ka tie nav optimizēti nākotnei izgūšana. Lai atrisinātu šo problēmu, HBase bufera atmiņā (Memstore) pēdējoreiz saņēma datus, pirms izskalošanas tos 'sašķiro' un pēc tam raksta HDFS, izmantojot ātrus secīgus ierakstus. Tādējādi HFile satur sakārtoto rindu sarakstu.

Katru reizi, kad Memstore flush notiek viens HFile, kas izveidots katram CF, un bieža skalošana var radīt daudz HFile. Tā kā lasīšanas laikā HBase būs jāaplūko daudzi HF faili, lasīšanas ātrums var ciest. Lai novērstu pārāk daudz HFile atvēršanu un lasīšanas veiktspējas pasliktināšanos, tiek izmantots HFiles blīvēšanas process. HBase periodiski (kad tiks izpildīti noteikti konfigurējami sliekšņi) vairākus mazākus HF failus sablīvēs lielos. Acīmredzot, jo vairāk Memstore izveidoto failu tiek izskalots, jo vairāk darba (papildu slodze) sistēmai. Papildus tam, kamēr blīvēšanas process parasti tiek veikts paralēli citu pieprasījumu apkalpošanai un kad HBase nespēj sekot līdzi HF failu blīvēšanai (jā, arī tam ir konfigurēti sliekšņi), tas atkal bloķēs rakstīšanu RS. Tāpat kā mēs iepriekš apspriedām, tas ir ļoti nevēlami.

Mēs nevaram būt pārliecināti, ka Memstore dati būs noturīgi. Pieņemsim, ka konkrēts datanode ir uz leju. Tad dati, kas atrodas šī datu mezgla atmiņā, tiks zaudēti.

Lai pārvarētu šo problēmu, kad pieprasījums nāk no kapteiņa, tas tiek uzrakstīts arī WAL. WAL nav nekas cits kā Rakstiet uz priekšu žurnālus kas atrodas HDFS, pastāvīgā krātuvē. Tagad mēs varam pārliecināties, ka pat tad, ja datu mezgls atrodas uz leju, dati netiks zaudēti, t.i. mums ir visu to darbību kopijas, kuras jums vajadzētu veikt WAL. Kad datu mezgls ir augšā, tas atkal veiks visas darbības. Kad darbība ir pabeigta, viss tiek izdzēsts no Memstore un WAL un tiek ierakstīts HFile, lai pārliecinātos, ka mums nepietrūkst atmiņas.

Ņemsim vienkāršu piemēru, ka es vēlos pievienot 10. rindu, pēc tam, kad ienāk rakstīšanas pieprasījums, teikts, ka tas visus metadatus nodod Memstore un WAL. Kad šī konkrētā rinda ir ierakstīta HFile, viss Memstore un WAL tiek izdzēsts.

Zooloģiskā dārza turētājs:

HBase ir integrēta ar zooloģiskā dārza turētāju. Kad es startēju HBase, tiek startēta arī zooloģiskā dārza turētāja instance. Iemesls ir tāds, ka zooloģiskā dārza turētājs palīdz mums izsekot visiem reģiona serveriem, kas ir HBase. Zooloģiskā dārza turētājs seko līdzi tam, cik ir reģiona serveru, kuru reģiona serveri tur no kura datu mezgla un kura datu mezgla. Tas seko līdzi mazākām datu kopām, kur Hadoop trūkst. Tas samazina papildu izmaksas virs Hadoop, kas seko lielākajai daļai jūsu metadatu. Tādējādi HMaster iegūst informāciju par reģiona serveriem, faktiski sazinoties ar Zoo turētāju.

Vai mums ir jautājums? Pieminiet tos komentāru sadaļā, un mēs ar jums sazināsimies.

kas ir datu zinātnes kurss

Saistītās ziņas:

Noderīgas stropa komandas