Теорија и пракса коришћења ХБасе-а

Добар дан Моје име је Данил Липовои, наш тим у Сбертецх-у је почео да користи ХБасе као складиште за оперативне податке. Током проучавања нагомилало се искуство које сам желео да систематизујем и опишем (надамо се да ће многима бити корисно). Сви експерименти у наставку су изведени са ХБасе верзијама 1.2.0-цдх5.14.2 и 2.0.0-цдх6.0.0-бета1.

1. Општа архитектура
2. Уписивање података у ХБАСЕ
3. Читање података са ХБАСЕ-а
4. Кеширање података
5. Пакетна обрада података МултиГет/МултиПут
6. Стратегија за поделу табела на регионе (подела)
7. Толеранција грешака, компактификација и локација података
8. Подешавања и перформансе
9. Тестирање на стрес
10. Налази

1. Општа архитектура

Бацкуп Мастер слуша откуцаје срца активног на ЗооКеепер чвору и, у случају нестанка, преузима функције мастера.

2. Упишите податке у ХБАСЕ

Прво, погледајмо најједноставнији случај - писање објекта кључ/вредност у табелу помоћу пут(ровкеи). Клијент прво мора да сазна где се налази сервер коренског региона (РРС), који чува табелу хбасе:мета. Ову информацију добија од ЗооКеепер-а. Након тога приступа РРС-у и чита хбасе:мета табелу, из које издваја информације о томе који је РегионСервер (РС) одговоран за чување података за дати кључ у табели од интереса. За будућу употребу, мета табелу кешира клијент и стога наредни позиви иду брже, директно у РС.

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

Након постављања уноса у МемСторе, клијенту се враћа одговор да је унос успешно сачуван. Међутим, у стварности се чува само у баферу и долази на диск тек након одређеног временског периода или када се напуни новим подацима.

Када се изврши операција „Делете“, подаци се физички не бришу. Они су једноставно означени као избрисани, а само уништавање се дешава у тренутку позивања главне компактне функције, што је детаљније описано у параграфу 7.

Датотеке у ХФиле формату се акумулирају у ХДФС и с времена на време се покреће мањи компактни процес, који једноставно спаја мале датотеке у веће без брисања било чега. Временом се ово претвара у проблем који се појављује само при читању података (на ово ћемо се вратити мало касније).

Поред горе описаног процеса учитавања, постоји много ефикаснија процедура, која је можда и најјача страна ове базе података – БулкЛоад. Лежи у чињеници да самостално формирамо ХФилес и стављамо их на диск, што нам омогућава да савршено скалирамо и постигнемо веома пристојне брзине. У ствари, ограничење овде није ХБасе, већ могућности хардвера. Испод су резултати покретања на кластеру који се састоји од 16 РегионСервера и 16 НодеМанагер ИАРН (ЦПУ Ксеон Е5-2680 в4 @ 2.40ГХз * 64 нити), ХБасе верзија 1.2.0-цдх5.14.2.

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

Такође можете почети да учитавате у две табеле истовремено и да добијете дуплу брзину. Испод можете видети да се уписивање блокова од 10 КБ у две табеле одједном одвија брзином од око 600 МБ/сец у свакој (укупно 1275 МБ/сец), што се поклапа са брзином уписивања у једну табелу од 623 МБ/сец (види бр. 11 изнад)

Али друга серија са записима од 50 КБ показује да брзина преузимања благо расте, што указује да се приближава граничним вредностима. Истовремено, морате имати на уму да се на самом ХБАСЕ-у практично не ствара никакво оптерећење, све што се од њега тражи је да прво да податке са хбасе:мета, а након облагања ХФилес-а, ресетујете БлоцкЦацхе податке и сачувате МемСторе бафер на диск, ако није празан.

3. Читање података са ХБАСЕ-а

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

Добивши податке из ова три извора, РС генерише одговор. Конкретно, може пренети неколико пронађених верзија објекта одједном ако је клијент захтевао верзионисање.

4. Кеширање података

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

Постоји један БлоцкЦацхе за цео РС и један МемСторе за сваку табелу (по један за сваку фамилију колона).

Као opisano у теорији, приликом писања, подаци не иду у кеш меморију и заиста, такви параметри ЦАЦХЕ_ДАТА_ОН_ВРИТЕ за табелу и „Цацхе ДАТА он Врите“ за РС су постављени на фалсе. Међутим, у пракси, ако запишемо податке у МемСторе, затим их избацимо на диск (на тај начин избришемо), а затим избришемо резултујућу датотеку, онда ћемо извршавањем захтева за добијање успешно примити податке. Штавише, чак и ако потпуно онемогућите БлоцкЦацхе и попуните табелу новим подацима, а затим ресетујете МемСторе на диск, избришете их и затражите их из друге сесије, они ће и даље бити однекуд преузети. Дакле, ХБасе чува не само податке, већ и мистериозне мистерије.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

Параметар „Цацхе ДАТА он Реад“ је подешен на нетачно. Ако имате било какву идеју, добродошли да о томе разговарате у коментарима.

5. Пакетна обрада података МултиГет/МултиПут

Обрада појединачних захтева (Гет/Пут/Делете) је прилично скупа операција, па ако је могуће, требало би да их комбинујете у Листу или Листу, што вам омогућава да добијете значајно повећање перформанси. Ово посебно важи за операцију писања, али при читању постоји следећа замка. Графикон испод показује време за читање 50 записа из МемСторе-а. Очитавање је обављено у једној нити и хоризонтална оса приказује број кључева у захтеву. Овде можете видети да при повећању на хиљаду кључева у једном захтеву време извршења опада, тј. брзина се повећава. Међутим, када је МСЛАБ режим подразумевано омогућен, након овог прага почиње радикалан пад перформанси, а што је већа количина података у запису, то је време рада дуже.

Тестови су обављени на виртуелној машини, 8 језгара, верзија ХБасе 2.0.0-цдх6.0.0-бета1.

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

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

6. Стратегија поделе табела на регионе (подела)

Пошто је ХБасе складиште кључ-вредност и партиционисање се врши по кључу, изузетно је важно равномерно поделити податке на све регионе. На пример, партиционисање такве табеле на три дела ће довести до тога да подаци буду подељени у три региона:

Дешава се да то доводи до наглог успоравања ако касније учитани подаци изгледају као, на пример, дугачке вредности, од којих већина почиње истом цифром, на пример:

1000001
1000002
...
1100003

Пошто се кључеви чувају као низ бајтова, сви ће почети исто и припадати истом региону #1 који чува овај опсег кључева. Постоји неколико стратегија поделе:

ХекСтрингСплит – Претвара кључ у хексадецимални кодирани стринг у опсегу "00000000" => "ФФФФФФФФ" и допуна са леве стране нулама.

УниформСплит – Претвара кључ у низ бајтова са хексадецималним кодирањем у опсегу "00" => "ФФ" и допуном на десној страни нулама.

Поред тога, можете одредити било који опсег или скуп тастера за раздвајање и конфигурисати аутоматско раздвајање. Међутим, један од најједноставнијих и најефикаснијих приступа је УниформСплит и употреба хеш конкатенације, на пример најзначајнији пар бајтова од покретања кључа преко функције ЦРЦ32(ровкеи) и самог ровкеи:

хасх + ровкеи

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

7. Толеранција грешака и локација података

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

Решење проблема је велико збијање - ова процедура премешта датотеке на оне чворове који су за њих одговорни (где се налазе њихови региони), услед чега се током ове процедуре оптерећење мреже и дискова нагло повећава. Међутим, у будућности се приметно убрзава приступ подацима. Поред тога, мајор_цомпацтион врши спајање свих ХФилес у једну датотеку унутар региона, а такође чисти податке у зависности од подешавања табеле. На пример, можете одредити број верзија објекта који се морају задржати или животни век након којег се објекат физички брише.

Ова процедура може имати веома позитиван ефекат на рад ХБасе-а. Слика испод показује како су перформансе смањене као резултат активног снимања података. Овде можете видети како 40 нити пише у једну табелу и 40 нити истовремено чита податке. Нити писања генеришу све више и више ХФилес, које читају друге нити. Као резултат тога, све више и више података мора бити уклоњено из меморије и на крају ГЦ почиње да ради, што практично паралише сав рад. Покретање великог сабијања довело је до рашчишћавања насталог отпада и обнављања продуктивности.

Тест је обављен на 3 ДатаНоде и 4 РС (ЦПУ Ксеон Е5-2680 в4 @ 2.40ГХз * 64 нити). ХБасе верзија 1.2.0-цдх5.14.2

Вреди напоменути да је велико збијање покренуто на „живој“ табели, у коју су подаци активно уписани и читани. Постојала је изјава на мрежи да би то могло довести до нетачног одговора при читању података. За проверу је покренут процес који је генерисао нове податке и записао их у табелу. Након чега сам одмах прочитао и проверио да ли се добијена вредност поклапа са записаним. Док је овај процес текао, велико збијање је изведено око 200 пута и није забележен ниједан квар. Можда се проблем појављује ретко и само при великом оптерећењу, тако да је сигурније зауставити процесе писања и читања како је планирано и извршити чишћење како би се спречила таква ГЦ повлачења.

Такође, велико збијање не утиче на стање МемСторе-а; да бисте га избацили на диск и збили га, потребно је да користите флусх (цоннецтион.гетАдмин().флусх(ТаблеНаме.валуеОф(тблНаме))).

8. Подешавања и перформансе

Као што је већ поменуто, ХБасе показује свој највећи успех тамо где не треба ништа да ради, када извршава БулкЛоад. Међутим, ово се односи на већину система и људи. Међутим, ова алатка је погоднија за масовно складиштење података у великим блоковима, док ако процес захтева више конкурентних захтева за читање и писање, користе се горе описане команде Гет и Пут. Да би се одредили оптимални параметри, лансирања су извршена са различитим комбинацијама параметара и подешавања табеле:

• 10 нити је покренуто истовремено 3 пута заредом (назовимо ово блок нити).
• Време рада свих нити у блоку је усредњено и представљало је коначни резултат рада блока.
• Све теме су радиле са истом табелом.
• Пре сваког покретања блока навоја, извршено је велико сабијање.
• Сваки блок је извршио само једну од следећих операција:

-Ставити
-Добити
—Гет+Пут

• Сваки блок је извршио 50 итерација своје операције.
• Величина блока записа је 100 бајтова, 1000 бајтова или 10000 бајтова (насумично).
• Блокови су покренути са различитим бројем тражених кључева (или једним кључем или 10).
• Блокови су вођени под различитим поставкама табеле. Промењени параметри:

— БлоцкЦацхе = укључено или искључено
— Величина блока = 65 КБ или 16 КБ
— Партиције = 1, 5 или 30
— МСЛАБ = омогућено или онемогућено

Дакле, блок изгледа овако:

а. МСЛАБ режим је укључен/искључен.
б. Направљена је табела за коју су подешени следећи параметри: БлоцкЦацхе = труе/ноне, БлоцкСизе = 65/16 Кб, Партитион = 1/5/30.
ц. Компресија је подешена на ГЗ.
д. Покренуто је 10 нити истовремено радећи 1/10 пут/гет/гет+пут операција у овој табели са записима од 100/1000/10000 бајтова, обављајући 50 упита у низу (случајни кључеви).
е. Тачка д је поновљена три пута.
ф. Време рада свих нити је усредњено.

Тестиране су све могуће комбинације. Предвидљиво је да ће брзина пасти како се величина записа повећава, или да ће онемогућавање кеширања узроковати успоравање. Међутим, циљ је био да се разуме степен и значај утицаја сваког параметра, па су прикупљени подаци унети у улаз функције линеарне регресије, што омогућава процену значаја помоћу т-статистике. Испод су резултати блокова који изводе Пут операције. Комплетан сет комбинација 2*2*3*2*3 = 144 опције + 72 тк. неки су рађени два пута. Дакле, има укупно 216 трчања:

Тестирање је обављено на мини-кластеру који се састоји од 3 ДатаНоде-а и 4 РС (ЦПУ Ксеон Е5-2680 в4 @ 2.40ГХз * 64 нити). ХБасе верзија 1.2.0-цдх5.14.2.

Највећа брзина уметања од 3.7 секунди је добијена са искљученим МСЛАБ режимом, на табели са једном партицијом, са укљученим БлоцкЦацхе-ом, БлоцкСизе = 16, записи од 100 бајтова, 10 комада по паковању.
Најнижа брзина уметања од 82.8 сек је добијена са омогућеним МСЛАБ режимом, на табели са једном партицијом, са укљученим БлоцкЦацхе-ом, БлоцкСизе = 16, записима од 10000 бајтова, по 1.

Сада погледајмо модел. Видимо добар квалитет модела заснованог на Р2, али је апсолутно јасно да је екстраполација овде контраиндикована. Стварно понашање система при промени параметара неће бити линеарно, овај модел није потребан за предвиђања, већ за разумевање шта се дешавало у оквиру датих параметара. На пример, овде видимо из студентовог критеријума да параметри БлоцкСизе и БлоцкЦацхе нису битни за операцију Пут (која је генерално прилично предвидљива):

Али чињеница да повећање броја партиција доводи до смањења перформанси је донекле неочекивана (већ смо видели позитиван утицај повећања броја партиција са БулкЛоад-ом), иако је разумљива. Прво, за обраду морате да генеришете захтеве за 30 региона уместо за један, а обим података није такав да би то донело добит. Друго, укупно време рада је одређено најспоријим РС, а пошто је број ДатаНодес мањи од броја РС-ова, неки региони имају нулти локалитет. Па, погледајмо првих пет:

Сада хајде да проценимо резултате извршавања блокова Гет:

Број партиција је изгубио на значају, што се вероватно објашњава чињеницом да се подаци добро кешују и да је кеш за читање најзначајнији (статистички) параметар. Наравно, повећање броја порука у захтеву је такође веома корисно за перформансе. Најбољи резултати:

Па, коначно, погледајмо модел блока који је прво извео гет а затим стави:

Овде су сви параметри значајни. И резултати лидера:

9. Испитивање оптерећења

Па, коначно ћемо покренути мање-више пристојно оптерећење, али увек је занимљивије када имате са чиме да упоредите. На веб локацији компаније ДатаСтак, кључног програмера Цассандре, налази се налази НТ бројних НоСКЛ складишта, укључујући ХБасе верзију 0.98.6-1. Учитавање је извршено са 40 нити, величина података 100 бајтова, ССД дискови. Резултат тестирања операција Реад-Модифи-Врите показао је следеће резултате.

Колико сам разумео, читање је обављено у блоковима од 100 записа и за 16 ХБасе чворова, ДатаСтак тест је показао перформансе од 10 хиљада операција у секунди.

Срећа је што и наш кластер има 16 чворова, али није баш „срећа“ што сваки има по 64 језгра (тхреад-а), док их у ДатаСтак тесту има само 4. С друге стране, они имају ССД дискове, док ми имамо ХДД или више нова верзија ХБасе-а и искоришћеност ЦПУ-а током оптерећења се практично није значајно повећала (визуелно за 5-10 процената). Међутим, хајде да покушамо да почнемо да користимо ову конфигурацију. Подразумевана подешавања табеле, читање се врши у опсегу кључева од 0 до 50 милиона насумично (тј. сваки пут у суштини ново). Табела садржи 50 милиона записа, подељених у 64 партиције. Кључеви се хеширају помоћу црц32. Подешавања табеле су подразумевана, МСЛАБ је омогућен. Покретањем 40 нити, свака нит чита скуп од 100 насумичних кључева и одмах уписује генерисаних 100 бајтова назад у ове кључеве.

Постоље: 16 ДатаНоде и 16 РС (ЦПУ Ксеон Е5-2680 в4 @ 2.40 ГХз * 64 нити). ХБасе верзија 1.2.0-цдх5.14.2.

Просечан резултат је ближи 40 хиљада операција у секунди, што је знатно боље него на ДатаСтак тесту. Међутим, у експерименталне сврхе, можете мало променити услове. Мало је вероватно да ће се сав посао обављати искључиво на једном столу, а такође и само на јединственим кључевима. Претпоставимо да постоји одређени „врући“ скуп тастера који генерише главно оптерећење. Стога, хајде да покушамо да направимо оптерећење са већим записима (10 КБ), такође у групама од 100, у 4 различите табеле и ограничавајући опсег тражених кључева на 50 хиљада. Графикон испод приказује покретање 40 нити, свака нит гласи сет од 100 кључева и одмах уписује насумично 10 КБ на ове кључеве назад.

Постоље: 16 ДатаНоде и 16 РС (ЦПУ Ксеон Е5-2680 в4 @ 2.40 ГХз * 64 нити). ХБасе верзија 1.2.0-цдх5.14.2.

Током оптерећења, велико сабијање је покренуто неколико пута, као што је горе приказано, без ове процедуре, перформансе ће постепено деградирати, међутим, додатно оптерећење се такође јавља током извођења. Повлачења су узрокована различитим разлозима. Понекад су нити завршиле са радом и дошло је до паузе док су поново покренуте, понекад су апликације трећих страна створиле оптерећење на кластеру.

Читање и непосредно писање је један од најтежих радних сценарија за ХБасе. Ако направите само мале пут захтеве, на пример 100 бајтова, комбинујући их у пакете од 10-50 хиљада комада, можете добити стотине хиљада операција у секунди, а слична је ситуација и са захтевима само за читање. Вреди напоменути да су резултати радикално бољи од оних које добија ДатаСтак, пре свега због захтева у блоковима од 50 хиљада.

Постоље: 16 ДатаНоде и 16 РС (ЦПУ Ксеон Е5-2680 в4 @ 2.40 ГХз * 64 нити). ХБасе верзија 1.2.0-цдх5.14.2.

10. Закључци

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

Ако постоји нешто по вашем мишљењу што није довољно обелодањено, спреман сам да вам кажем детаљније. Позивамо вас да поделите своје искуство или дискутујете ако се са нечим не слажете.

Извор: ввв.хабр.цом