Архитектура ХБасе: Модел података ХБасе и механизам читања / писања ХБасе



Овај блог о ХБасе архитектури објашњава ХБасе модел података и даје увид у ХБасе архитектуру. Такође објашњава различите механизме у ХБасе.

ХБасе Арцхитецтуре

У мом претходном блогу на ХБасе Туториал , Објаснио сам шта је ХБасе и његове карактеристике. Такође сам поменуо студију случаја Фацебоок мессенгер-а да би вам помогао да се боље повежете. Сада даље напредујемо у нашем , Објаснићу вам модел података ХБасе и ХБасе Арцхитецтуре.Пре него што наставите, такође треба да знате да је ХБасе важан концепт који чини саставни део за сертификацију Хадооп за велике податке.

Важне теме кроз које ћу вас провести на овом блогу о ХБасе архитектури су:





Прво да разумемо модел података ХБасе. Помаже ХБасе-у у бржем читању / писању и претраживању.



Архитектура ХБасе: Модел података ХБасе

Као што знамо, ХБасе је НоСКЛ база података оријентисана на колоне. Иако изгледа слично релационој бази података која садржи редове и колоне, али није релациона база података. Релационе базе података су оријентисане на редове, док је ХБасе оријентисана на колоне. Дакле, прво да схватимо разлику између база података оријентисаних на колоне и редове:

Базе података оријентисане према редовима или колонама:

  • Базе података оријентисане на ред чувају записе табеле у низу редова. Док базе података оријентисане на колонечувају записе табеле у низу колона, тј. уноси у колони се чувају на суседним локацијама на дисковима.

Да бисмо га боље разумели, узмимо пример и размотримо доњу табелу.



Табела - Архитектура ХБасе - Едурека

Ако је ова табела смештена у базу података оријентисану на редове. Чуваће записе као што је приказано доле:

један,Пол Вокер,САД,231,Галантно,

2, Вин Диесел,Бразил,520,Мустанг

У базама података оријентисаним на редове подаци се чувају на основу редова или корпица, као што видите горе.

Док базе података оријентисане на колоне чувају ове податке као:

један,2, Пол Вокер,Вин Диесел, САД,Бразил, 231,520, Галантно,Мустанг

У базама података оријентисаним на колоне, све вредности колона се чувају заједно, као што ће се вредности првог ступца чувати заједно, затим ће се вредности другог ступца чувати заједно, а подаци у другим колонама се чувају на сличан начин.

  • Када је количина података веома велика, попут петабајта или ексабајта, користимо приступ оријентисан на колону, јер се подаци једне колоне чувају заједно и може им се брже приступити.
  • Иако приступ оријентисан на редове упоредно ефикасно рукује мањим бројем редова и колона, јер база података оријентисана на редове чува податке у структурираном формату.
  • Када треба да обрадимо и анализирамо велики скуп полуструктурираних или неструктурираних података, користимо приступ оријентисан на колоне. Као што су апликације које се баве Интернет аналитичка обрада попут претраживања података, складиштења података, апликација укључујући аналитику итд.
  • Док, Трансакциона обрада на мрежи као што су банкарски и финансијски домени који рукују структурираним подацима и захтевају трансакциона својства (АЦИД својства) користе приступ оријентисан на редове.

Табеле ХБасе имају следеће компоненте, приказане на доњој слици:

  • Столови : Подаци се чувају у формату табеле у ХБасеу. Али овде су табеле у формату оријентисаном на колоне.
  • Ред Кључ : Редни тастери се користе за претрагу записа који убрзавају претрагу. Били бисте радознали да знате како? Објаснићу то у делу о архитектури који се креће напред на овом блогу.
  • Колона Породице : Разни ступци су комбиновани у породици колона. Ове породице колона се чувају заједно, што убрзава процес претраживања, јер се подацима који припадају истој породици колона може приступити заједно у једном тражењу.
  • Колона Квалификације : Име сваке колоне познато је као квалификатор колоне.
  • Ћелија : Подаци се чувају у ћелијама. Подаци се избацују у ћелије које су посебно идентификоване помоћу квалификатора кључева редова и колона.
  • Временска ознака : Временска ознака је комбинација датума и времена. Кад год се подаци чувају, они се чувају са временском ознаком. Ово олакшава тражење одређене верзије података.

На једноставнији и разумљивији начин можемо рећи да се ХБасе састоји од:

  • Сет столова
  • Свака табела са породицама колона и редовима
  • Редни кључ делује као примарни кључ у ХБасеу.
  • Сваки приступ таблицама ХБасе користи овај Примарни кључ
  • Сваки квалификатор колоне присутан у ХБасе означава атрибут који одговара објекту који се налази у ћелији.

Сада када знате за ХБасе модел података, погледајмо како се овај модел података подудара са ХБасе Арцхитецтуре и чини га погодним за велико складиштење и бржу обраду.

Архитектура ХБасе: Компоненте архитектуре ХБасе

ХБасе има три главне компоненте, тј. ХМастер Сервер , ХБасе Регион Сервер, Региони и Чувар зоолошког врта .

Слика испод објашњава хијерархију архитектуре ХБасе. Разговараћемо о сваком од њих појединачно.

надјачавање у односу на преоптерећење ц ++


Сада ћемо пре одласка у ХМастер разумети Регионе јер су сви ови сервери (ХМастер, Регион Сервер, Зоокеепер) постављени да координирају и управљају регионима и извршавају разне операције унутар Региона. Па би вас занимало шта су региони и зашто су толико важни?

ХБасе архитектура: Регион

Регија садржи све редове између почетног и завршног кључа додељеног тој регији. Табеле ХБасе могу се поделити у више региона на такав начин да су сви ступци породице колона ускладиштени у једном региону. Свака регија садржи редове у сортираном редоследу.

Многи региони су додељени а Регион Сервер , који је одговоран за руковање, управљање, извршавање операција читања и писања на том скупу регија.

Дакле, закључујући на једноставнији начин:

шта је демон демон
  • Табела се може поделити на више региона. Регија је сортирани опсег редова који чувају податке између почетног и завршног кључа.
  • Регија има подразумевану величину од 256 МБ, која се може конфигурисати према потреби.
  • Групу регија клијентима сервира Регионални Сервер.
  • Регијски сервер може клијенту опслужити приближно 1000 регија.

Полазећи од врха хијерархије, прво бих желео да вам објасним о ХМастер серверу који слично делује као НамеНоде у ХДФС . Затим, померајући се у хијерархији, водићу вас кроз ЗооКеепер и Регион Сервер.

ХБасе архитектура: ХМастер

Као на доњој слици, можете видети како ХМастер обрађује колекцију регионалног сервера који се налази на ДатаНоде. Хајде да разумемо како ХМастер то ради.

  • ХБасе ХМастер изводи ДДЛ операције (креира и брише табеле) и додељује регионе серверима региона као што видите на горњој слици.
  • Координира и управља регионалним сервером (слично као што НамеНоде управља ДатаНодеом у ХДФС-у).
  • Регионалним серверима додељује регионе приликом покретања и поново додељује регионе регионалним серверима током опоравка и балансирања оптерећења.
  • Надгледа све инстанце Регионалног сервера у кластеру (уз помоћ Зоокеепер-а) и обавља активности опоравка кад год било који регионални сервер падне.
  • Пружа интерфејс за креирање, брисање и ажурирање табела.

ХБасе има дистрибуирано и огромно окружење где само ХМастер није довољан да управља свиме. Дакле, запитали бисте се шта помаже ХМастеру да управља овим огромним окружењем? Ту ЗооКеепер долази на сцену. Након што смо схватили како ХМастер управља ХБасе околином, схватићемо како Зоокеепер помаже ХМастеру у управљању околином.

ХБасе архитектура: ЗооКеепер - Координатор

Ова слика испод објашњава механизам координације ЗооКеепер-а.

  • Чувар зоолошког врта понаша се као координатор унутар ХБасе дистрибуираног окружења. Помаже у одржавању стања сервера унутар кластера комуницирајући кроз сесије.
  • Сваки регион сервер, заједно са ХМастер сервером, шаље редовне откуцаје срца у редовним интервалима Зоокеепер-у и он проверава који је сервер жив и доступан како је поменуто на горњој слици. Такође пружа обавештења о неуспеху сервера, тако да се могу извршити мере опоравка.
  • Позивајући се на горњу слику коју видите, постоји неактиван сервер који делује као резервна копија активног сервера. Ако активни сервер закаже, долази за спас.
  • Активни ХМастер шаље откуцаје срца чувару зоолошког врта, док неактивни ХМастер ослушкује обавештење које шаље активни ХМастер. Ако активни ХМастер не успе да пошаље откуцаје срца, сесија се брише и неактивни ХМастер постаје активан.
  • Иако ако регионални сервер не успе да пошаље откуцаје срца, сесија је истекла и сви слушаоци су о томе обавештени. Тада ХМастер изводи одговарајуће акције опоравка о којима ћемо касније разговарати на овом блогу.
  • Зоокеепер такође одржава путању .МЕТА сервера, која помаже било ком клијенту у потрази за било којим регионом. Клијент прво мора да провери код .МЕТА сервера у који регион Сервер припада регион и добија путању до тог регионалног сервера.

Док сам говорио о .МЕТА серверу, прво ћу вам објаснити шта је .МЕТА сервер? Дакле, лако можете повезати рад ЗооКеепер-а и .МЕТА сервера заједно. Касније, када ћу вам објаснити механизам претраживања ХБасе на овом блогу, објаснићу како ово двоје функционишу у сарадњи.

ХБасе архитектура: Мета табела

  • МЕТА табела је посебна ХБасе каталошка табела. Одржава листу свих Регионс сервера у систему за складиштење ХБасе, као што видите на горњој слици.
  • Гледајући фигуру коју можете видети, .МЕТА датотека одржава табелу у облику кључева и вредности. Кључ представља стартни кључ региона и његов ид док вредност садржи путању регионалног сервера.

Као што сам већ разговарао, Регион Сервер и његове функције док сам вам објашњавао Регионе, стога се сада крећемо низ хијерархију и фокусираћу се на компоненту Регионал Сервер и њихове функције. Касније ћу разговарати о механизму претраживања, читања, писања и разумети како све ове компоненте функционишу заједно.

ХБасе архитектура: Компоненте регионалног сервера

Ова слика испод приказује компоненте регионалног сервера. Сада ћу о њима разговарати одвојено.

Регијски сервер одржава различите регионе који се изводе на врху . Компоненте регионалног сервера су:

  • ВАЛ: Као што можете закључити из горње слике, Врите Ахеад Лог (ВАЛ) је датотека која је приложена сваком регионалном серверу унутар дистрибуираног окружења. ВАЛ чува нове податке који нису сачувани или су посвећени трајном складишту. Користи се у случају неуспешног опоравка скупова података.
  • Блоцк Цацхе: Из горње слике је јасно видљиво да се Блоцк Цацхе налази на врху Регионалног сервера. У меморију чува често прочитане податке. Ако се подаци из БлоцкЦацхе најмање користе недавно, ти подаци се уклањају из БлоцкЦацхе-а.
  • МемСторе: То је кеш меморија. Похрањује све долазне податке пре него што их упише на диск или у трајну меморију. Постоји један МемСторе за сваку породицу колона у региону. Као што видите на слици, постоји више МемСторес-а за регион, јер сваки регион садржи више породица колона. Подаци се сортирају у лексикографском редоследу пре него што се унесу на диск.
  • ХФиле: Са горње слике можете видети да је ХФиле ускладиштен на ХДФС-у. Тако он складишти стварне ћелије на диску. МемСторе предаје податке у ХФиле када величина МемСторе пређе.

Сад кад знамо главне и споредне компоненте ХБасе архитектуре, објаснићу механизам и њихов заједнички напор у томе. Било да се ради о читању или писању, прво морамо да претражимо одакле да читамо или где да напишемо датотеку. Дакле, хајде да разумемо овај процес претраживања, јер је ово један од механизама који чини ХБасе веома популарном.

ХБасе архитектура: Како се претрага иницијализује у ХБасе?

Као што знате, Зоокеепер чува локацију МЕТА табеле. Кад год клијент приступи са захтевима за читање или упис у ХБасе, догоди се следећа операција:

  1. Клијент преузима локацију МЕТА табеле из ЗооКеепер-а.
  2. Клијент затим тражи локацију Регијског сервера одговарајућег кључа реда из МЕТА табеле да би му приступио. Клијент кешира ове податке са локацијом МЕТА табеле.
  3. Тада ће добити локацију реда захтевањем од одговарајућег Регионалног сервера.

За будуће референце, клијент користи своју кеш меморију да би пронашао локацију МЕТА табеле и претходно прочитао Регион Сервер кључа реда. Тада се клијент неће позивати на МЕТА табелу док и уколико не дође до пропуста јер је регион померен или премештен. Затим ће поново затражити МЕТА сервер и ажурирати кеш меморију.

Као и сваки пут, клијенти не троше време на проналажење локације Регијског сервера са МЕТА сервера, па ово штеди време и убрзава процес претраживања. Сада ћу вам рећи како се писање одвија у ХБасе-у. Које су компоненте укључене у то и како су укључене?

ХБасе архитектура: ХБасе Врите Механизам

Ова слика испод објашњава механизам писања у ХБасе.

Механизам писања пролази кроз следећи поступак узастопно (погледајте горњу слику):

Корак 1: Кад год клијент има захтев за упис, клијент записује податке у ВАЛ (Врите Ахеад Лог).

  • Измене се затим додају на крају ВАЛ датотеке.
  • Ова ВАЛ датотека се одржава на сваком регионалном серверу и регионални сервер је користи за опоравак података који нису додељени диску.

Корак 2: Једном када се подаци упишу у ВАЛ, они се копирају у МемСторе.

Корак 3: Једном када се подаци ставе у МемСторе, клијент добија потврду.

Корак 4: Када МемСторе достигне праг, одбацује или урезује податке у ХФиле.

Сада дубоко заронимо и схватимо како МемСторе доприноси процесу писања и које су његове функције?

ХБасе Врите Механизам- МемСторе

  • МемСторе увек ажурира податке ускладиштене у њему, лексикографским редоследом (секвенцијално у речнику) као сортиране КеиВалуес. Постоји једна МемСторе за сваку породицу колона, па се стога ажурирања складиште на сортирани начин за сваку породицу колона.
  • Када МемСторе достигне праг, сортира све податке у нови ХФиле. Овај ХФиле се чува у ХДФС-у. ХБасе садржи више ХФи датотека за сваку породицу колона.
  • Временом, број ХФиле расте како МемСторе баца податке.
  • МемСторе такође чува последњи уписани секвенцијални број, тако да и Мастер Сервер и МемСторе знају шта је до сада почињено и одакле почети. Када се регија покрене, чита се последњи секвенцијски број и од тог броја започињу нове измене.

Као што сам неколико пута разговарао, тај ХФиле је главно трајно складиште у ХБасе архитектури. Напокон, сви подаци су предани ХФиле-у који је трајно складиште ХБасе. Стога, погледајмо својства ХФиле-а која га чине бржим за претрагу током читања и писања.

ХБасе архитектура: ХБасе Врите Механизам- ХФиле

  • Записи се постављају секвенцијално на диск. Због тога је кретање главе за читање и писање на диску веома мање. То чини механизам писања и претраживања врло брзим.
  • ХФиле индекси се учитавају у меморију кад год се отвори ХФиле. Ово помаже у проналажењу записа у једном тражењу.
  • Најава је показивач који показује на мета блок ХФиле-а. Написано је на крају урезане датотеке. Садржи информације о временским ознакама и филтерима цветања.
  • Блоом Филтер помаже у претраживању парова вредности кључева, прескаче датотеку која не садржи потребан кључ реда. Тиместамп такође помаже у претраживању верзије датотеке, помаже и прескакању података.

Након познавања механизма писања и улоге различитих компонената у бржем писању и претраживању. Објаснићу вам како механизам за читање функционише унутар ХБасе архитектуре? Затим ћемо прећи на механизме који повећавају перформансе ХБасе попут сабијања, поделе региона и опоравка.

ХБасе архитектура: Читај механизам

Као што је објашњено у нашем механизму претраживања, прво клијент преузима локацију Регионалног сервера са .МЕТА сервера ако га клијент нема у кеш меморији. Затим пролази кроз секвенцијалне кораке на следећи начин:

  • За читање података, скенер прво тражи ћелију реда у кешу блокова. Овде се чувају сви недавно прочитани парови вредности кључа.
  • Ако Сцаннер не успе да пронађе тражени резултат, премешта се у МемСторе, јер знамо да је ово кеш меморија писања. Тамо тражи најновије написане датотеке, које још нису депоноване у ХФиле.
  • Напокон ће користити блоом филтере и блок предмеморију за учитавање података из ХФиле.

До сада сам разговарао о механизму претраживања, читања и писања ХБасе. Сада ћемо размотрити механизам ХБасе који омогућава брзо претраживање, читање и писање у ХБасе-и. Прво ћемо разумети Сабијање , који је један од тих механизама.

ХБасе архитектура: Сабијање

ХБасе комбинује ХФилес како би смањио складиште и смањио број захтева за читање диска. Овај процес се назива збијање . Сабијање бира неке ХФилове из региона и комбинује их. Постоје две врсте збијања као што видите на горњој слици.

  1. Мање сабијање : ХБасе аутоматски бира мање датотеке ХФи и враћа их на веће датотеке ХФи, као што је приказано на горњој слици. Ово се назива Мање сабијање. Извршава сортирање спајања за додељивање мањих ХФилес већим ХФилес. Ово помаже у оптимизацији простора за складиштење.
  2. Главно сабијање: Као што је приказано на горњој слици, у Великом збијању, ХБасе спаја и поново предаје мале ХФилове регије у нову ХФиле. У овом процесу, исте породице колона стављају се заједно у нови ХФиле. У овом процесу се испуштају избрисане и истекле ћелије. Повећава перформансе читања.

Али током овог процеса улазно-излазни дискови и мрежни саобраћај могу бити загушени. Ово је познато као писање појачања . Дакле, то је генерално заказано за време вршних оптерећења.

Сада је још један процес оптимизације перформанси о којем ћу разговарати Регија Сплит . Ово је веома важно за уравнотежење оптерећења.

ХБасе архитектура: Регија Сплит

Доња слика илуструје механизам Регион Сплит.

моји СКЛ водичи за почетнике

Кад год регија постане велика, она се дели на две подређене регије, као што је приказано на горњој слици. Свака регија представља тачно половину матичне регије. Тада се овај подељак пријављује ХМастеру. Ово обрађује исти регионални сервер док их ХМастер не додели новом регионалном серверу за уравнотежење оптерећења.

Померањем ниже, последње, али не најмање важно, објаснићу вам како ХБасе обнавља податке након неуспеха. Као што то знамо Опоравак неуспеха је врло важна карактеристика ХБасе, па нам реците како ХБасе обнавља податке након квара.

ХБасе архитектура: ХБасе пад и опоравак података

  • Кад год регионални сервер закаже, ЗооКеепер обавести ХМастер о квару.
  • Тада ХМастер дистрибуира и додељује регије срушеног Регионалног сервера многим активним Регионалним серверима. Да би опоравио податке МемСторе-а неуспелог регионалног сервера, ХМастер дистрибуира ВАЛ свим регионалним серверима.
  • Сваки регион регион поново извршава ВАЛ за изградњу МемСторе-а за породицу колона тог неуспелог региона.
  • Подаци су записани хронолошким редом (благовремено) у ВАЛ-у. Према томе, поновно извршавање тог ВАЛ-а значи уношење свих промена које су направљене и ускладиштене у МемСторе датотеци.
  • Дакле, након што сви регионални сервери изврше ВАЛ, обнављају се подаци МемСторе за сву породицу колона.

Надам се да би вам овај блог помогао да разумете модел података ХБасе и архитектуру ХБасе. Надам се да сте уживали. Сада се можете повезати са карактеристикама ХБасе (што сам објаснио у свом претходном ХБасе Туториал блог) са ХБасе Арцхитецтуре и схватите како то интерно функционише. Сада када знате теоријски део ХБасе, требало би да пређете на практични део. Имајући ово на уму, наш следећи блог објасниће узорак ХБасе ПОЦ .

Сад кад сте разумели архитектуру ХБасе, погледајте Едурека, поуздана компанија за учење на мрежи са мрежом од више од 250.000 задовољних ученика раширених широм света. Едурека курс обуке за сертификацију великих података помаже ученицима да постану стручњаци за ХДФС, предиво, МапРедуце, ​​свињу, кошницу, ХБасе, Оозие, Флуме и Скооп користећи случајеве коришћења у реалном времену на малопродаји, друштвеним медијима, ваздухопловству, туризму, финансијском домену.

Имате питање за нас? Молимо вас да то споменете у одељку за коментаре и јавићемо вам се.