Теорија и практика на користење на HBase

Добар ден Моето име е Данил Липовој, нашиот тим во Сбертех почна да користи HBase како складиште за оперативни податоци. Во текот на неговото проучување, се акумулираше искуство кое сакав да го систематизирам и опишам (се надеваме дека ќе им биде од корист на многумина). Сите експерименти подолу беа изведени со верзии на HBase 1.2.0-cdh5.14.2 и 2.0.0-cdh6.0.0-beta1.

1. Општа архитектура
2. Запишување податоци во HBASE
3. Читање податоци од HBASE
4. Кеширање на податоци
5. Сериска обработка на податоци MultiGet/MultiPut
6. Стратегија за поделба на табелите во региони (поделба)
7. Толеранција на грешки, компактификација и локалитет на податоци
8. Поставки и перформанси
9. Тестирање на стрес
10. Наоди

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

Резервниот Master го слуша чукањето на срцето на активниот на ZooKeeper јазолот и, во случај на исчезнување, ги презема функциите на господарот.

2. Напишете податоци во HBASE

Прво, да го погледнеме наједноставниот случај - пишување објект со клучна вредност во табела користејќи put(rowkey). Клиентот мора прво да открие каде се наоѓа Root Region Server (RRS), кој ја складира табелата hbase:meta. Оваа информација ја добива од ZooKeeper. После тоа, тој пристапува до RRS и ја чита табелата hbase:meta, од која извлекува информации за тоа кој RegionServer (RS) е одговорен за складирање на податоци за даден редослед во табелата за интерес. За идна употреба, мета-табелата е кеширана од клиентот и затоа следните повици одат побрзо, директно до RS.

Следно, РС, откако доби барање, прво го пишува во WriteAheadLog (WAL), што е неопходно за обновување во случај на пад. Потоа ги зачувува податоците во MemStore. Ова е бафер во меморијата што содржи сортиран сет на клучеви за даден регион. Табелата може да се подели на региони (партиции), од кои секоја содржи разделен сет на клучеви. Ова ви овозможува да поставите региони на различни сервери за да постигнете повисоки перформанси. Сепак, и покрај очигледноста на оваа изјава, подоцна ќе видиме дека тоа не функционира во сите случаи.

По поставувањето запис во MemStore, на клиентот се враќа одговор дека записот е успешно зачуван. Меѓутоа, во реалноста тој се чува само во бафер и доаѓа до дискот само откако ќе помине одреден временски период или кога ќе се пополни со нови податоци.

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

Датотеките во формат HFile се акумулираат во HDFS и од време на време се стартува помалиот компактен процес, кој едноставно ги спојува малите датотеки во поголеми без да брише ништо. Со текот на времето, ова се претвора во проблем што се појавува само при читање податоци (на ова ќе се вратиме малку подоцна).

Во прилог на процесот на вчитување опишан погоре, постои многу поефикасна процедура, која е можеби најсилната страна на оваа база на податоци - BulkLoad. Тоа лежи во фактот дека ние самостојно формираме HFiles и ги ставаме на дискот, што ни овозможува совршено да скалираме и да постигнеме многу пристојни брзини. Всушност, ограничувањето овде не е HBase, туку можностите на хардверот. Подолу се резултатите од подигањето на кластерот составен од 16 RegionServers и 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 нишки), HBase верзија 1.2.0-cdh5.14.2.

Овде можете да видите дека со зголемување на бројот на партиции (региони) во табелата, како и извршителите на Spark, добиваме зголемување на брзината на преземање. Исто така, брзината зависи од јачината на звукот на снимањето. Големите блокови даваат зголемување на МБ/сек, малите блокови во бројот на вметнати записи по единица време, а сите други работи се еднакви.

Можете исто така да започнете со вчитување во две табели во исто време и да добиете двојно поголема брзина. Подолу можете да видите дека пишувањето блокови од 10 KB на две табели одеднаш се случува со брзина од околу 600 MB/сек во секоја (вкупно 1275 MB/sec), што се совпаѓа со брзината на запишување на една табела 623 MB/sec (види бр. 11 погоре)

Но, второто возење со записи од 50 KB покажува дека брзината на преземање малку расте, што покажува дека се приближува до граничните вредности. Во исто време, треба да имате на ум дека практично нема креирано оптоварување на самиот HBASE, сè што се бара од него е прво да се дадат податоци од hbase:meta, а откако ќе се постават HFiles, да се ресетираат податоците на BlockCache и да се зачува MemStore бафер на дискот, ако не е празен.

3. Читање податоци од HBASE

Ако претпоставиме дека клиентот веќе ги има сите информации од hbase:meta (види точка 2), тогаш барањето оди директно во RS каде што е зачуван бараниот клуч. Прво, пребарувањето се врши во MemCache. Без оглед на тоа дали има податоци таму или не, пребарувањето се врши и во баферот BlockCache и, доколку е потребно, во HFiles. Доколку се пронајдени податоци во датотеката, тие се ставаат во BlockCache и ќе бидат вратени побрзо на следното барање. Пребарувањето во HFile е релативно брзо благодарение на употребата на филтерот Bloom, т.е. откако прочитал мала количина на податоци, веднаш одредува дали оваа датотека го содржи потребниот клуч и ако не, тогаш се префрла на следната.

Откако доби податоци од овие три извори, RS генерира одговор. Конкретно, може да пренесе неколку пронајдени верзии на објект одеднаш ако клиентот побарал верзија.

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

Баферите MemStore и BlockCache зафаќаат до 80% од доделената RS меморија на купот (остатокот е резервиран за задачи за услуги на RS). Ако типичниот режим на користење е таков што процесите ги пишуваат и веднаш ги читаат истите податоци, тогаш има смисла да се намали BlockCache и да се зголеми MemStore, бидејќи Кога пишувањето податоци не влегува во кешот за читање, BlockCache ќе се користи поретко. Баферот BlockCache се состои од два дела: LruBlockCache (секогаш вклучен) и BucketCache (обично off-heap или на SSD). BucketCache треба да се користи кога има многу барања за читање и тие не се вклопуваат во LruBlockCache, што доведува до активна работа на Garbage Collector. Во исто време, не треба да очекувате радикално зголемување на перформансите од користењето на кешот за читање, но ние ќе се вратиме на ова во став 8

Има еден BlockCache за целиот RS и има по еден MemStore за секоја табела (по еден за секое семејство на колони).

Како опишано во теорија, кога се пишува, податоците не влегуваат во кешот и навистина, таквите параметри CACHE_DATA_ON_WRITE за табелата и „Cache DATA on Write“ за RS се поставени на неточни. Меѓутоа, во пракса, ако напишеме податоци во MemStore, потоа ги фрлиме на дискот (со тоа ќе го исчистиме), потоа ја избришеме добиената датотека, а потоа со извршување на барање за добивање успешно ќе ги добиеме податоците. Покрај тоа, дури и ако целосно го оневозможите BlockCache и ја наполните табелата со нови податоци, потоа го ресетирате MemStore на дискот, ги избришете и побарате од друга сесија, тие сепак ќе бидат преземени од некаде. Така, HBase складира не само податоци, туку и мистериозни мистерии.

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

Параметарот „Cache DATA on Read“ е поставен на неточно. Ако имате какви било идеи, добредојдени да разговарате за тоа во коментарите.

5. Сериска обработка на податоци MultiGet/MultiPut

Обработката на поединечни барања (Земи/Стави/Избриши) е прилично скапа операција, па ако е можно, треба да ги комбинирате во Листа или Список, што ви овозможува да добиете значително зголемување на перформансите. Ова е особено точно за операцијата за пишување, но при читањето постои следнава замка. Графиконот подолу го покажува времето за читање 50 записи од MemStore. Читањето беше извршено во една нишка и хоризонталната оска го покажува бројот на копчиња во барањето. Овде можете да видите дека при зголемување на илјада клучеви во едно барање, времето на извршување паѓа, т.е. брзината се зголемува. Меѓутоа, со стандардно овозможен режим MSLAB, по овој праг започнува радикален пад на перформансите и колку е поголема количината на податоци во записот, толку е подолго времето на работа.

Тестовите беа извршени на виртуелна машина, 8 јадра, верзија HBase 2.0.0-cdh6.0.0-beta1.

Режимот MSLAB е дизајниран да ја намали фрагментацијата на купиштата, што се јавува поради мешање на податоците од новата и старата генерација. Како решение, кога е овозможено MSLAB, податоците се ставаат во релативно мали ќелии (парчиња) и се обработуваат во парчиња. Како резултат на тоа, кога волуменот во бараниот пакет со податоци ја надминува доделената големина, перформансите нагло паѓаат. Од друга страна, исклучувањето на овој режим исто така не е препорачливо, бидејќи тоа ќе доведе до прекини поради GC во моменти на интензивна обработка на податоците. Добро решение е да се зголеми волуменот на ќелијата во случај на активно пишување преку ставање во исто време со читањето. Вреди да се напомене дека проблемот не се јавува ако, по снимањето, ја извршите командата flush, која го ресетира MemStore на дискот или ако вчитате користејќи BulkLoad. Табелата подолу покажува дека барањата од MemStore за поголеми (и иста количина) податоци резултираат со забавување. Меѓутоа, со зголемување на големината, времето на обработка го враќаме во нормала.

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

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

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

Се случува ова да доведе до нагло забавување ако податоците вчитани подоцна изгледаат како, на пример, долги вредности, повеќето од нив почнуваат со иста цифра, на пример:

1000001
1000002
...
1100003

Бидејќи копчињата се зачувани како низа бајти, сите тие ќе започнат исто и ќе припаѓаат на истиот регион #1 што го складира овој опсег на клучеви. Постојат неколку стратегии за партиционирање:

HexStringSplit – Го претвора клучот во хексадецимална кодирана низа во опсегот „00000000“ => „FFFFFFFF“ и лево го пополнува со нули.

UniformSplit – Го претвора клучот во низа од бајти со хексадецимално кодирање во опсегот „00“ => „FF“ и пополнување на десната страна со нули.

Покрај тоа, можете да наведете кој било опсег или збир на копчиња за разделување и да го конфигурирате автоматското разделување. Сепак, еден од наједноставните и најефикасните пристапи е UniformSplit и употребата на хаш конкатенација, на пример, најзначајниот пар бајти од извршувањето на клучот преку функцијата CRC32 (rowkey) и самиот клуч:

хаш + редица

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

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

Бидејќи само еден регион е одговорен за секој сет на клучеви, решението за проблемите поврзани со падовите или деактивирањето на RS е да се складираат сите потребни податоци во HDFS. Кога РС паѓа, мајсторот го открива ова преку отсуство на отчукување на срцето на јазолот ZooKeeper. Потоа го доделува опслужениот регион на друг RS и бидејќи HFiles се зачувани во дистрибуиран датотечен систем, новиот сопственик ги чита и продолжува да ги опслужува податоците. Меѓутоа, бидејќи некои од податоците можеби се во MemStore и немале време да влезат во HFiles, WAL, кој исто така е зачуван во HDFS, се користи за враќање на историјата на операциите. Откако ќе се применат промените, RS може да одговори на барањата, но потегот води до фактот дека некои од податоците и процесите што ги сервисираат завршуваат на различни јазли, т.е. локалитетот се намалува.

Решението за проблемот е големо набивање - оваа постапка ги преместува датотеките во оние јазли кои се одговорни за нив (каде што се наоѓаат нивните региони), како резултат на што во текот на оваа постапка оптоварувањето на мрежата и дисковите нагло се зголемува. Меѓутоа, во иднина, пристапот до податоците е значително забрзан. Покрај тоа, major_compaction врши спојување на сите HFiles во една датотека во рамките на регионот, а исто така ги чисти податоците во зависност од поставките на табелата. На пример, можете да го одредите бројот на верзии на објектот што мора да се задржи или животниот век после кој објектот физички се брише.

Оваа постапка може да има многу позитивно влијание врз работата на HBase. Сликата подолу покажува како перформансите се деградирани како резултат на активното снимање на податоци. Овде можете да видите како 40 нишки пишуваат на една табела и 40 нишки истовремено читаат податоци. Нишките за пишување генерираат сè повеќе HFiles, кои се читаат од други нишки. Како резултат на тоа, се повеќе и повеќе податоци треба да се отстранат од меморијата и на крајот GC почнува да работи, што практично ја парализира целата работа. Лансирањето на големото набивање доведе до расчистување на добиените остатоци и враќање на продуктивноста.

Тестот беше извршен на 3 DataNodes и 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 нишки). HBase верзија 1.2.0-cdh5.14.2

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

Исто така, големото набивање не влијае на состојбата на MemStore; за да го ставите на дискот и да го набиете, треба да користите flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Поставки и перформанси

Како што веќе споменавме, HBase го покажува својот најголем успех таму каде што не треба ништо да прави, при извршување на BulkLoad. Сепак, ова се однесува на повеќето системи и луѓе. Сепак, оваа алатка е посоодветна за складирање на податоци на големо во големи блокови, додека ако процесот бара повеќе конкурентни барања за читање и запишување, се користат командите Get и Put опишани погоре. За да се утврдат оптималните параметри, лансирањето беше извршено со различни комбинации на параметри и поставки на табелата:

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

- Стави
— Земи
— Земи + Стави

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

— BlockCache = вклучен или исклучен
— BlockSize = 65 KB или 16 KB
- Партиции = 1, 5 или 30
— MSLAB = овозможено или оневозможено

Значи, блокот изгледа вака:

а. Режимот MSLAB беше вклучен/исклучен.
б. Создадена е табела за која беа поставени следните параметри: BlockCache = точно/нема, BlockSize = 65/16 Kb, Поделба = 1/5/30.
в. Компресијата беше поставена на GZ.
г. Беа лансирани 10 нишки истовремено правејќи операции 1/10 put/get/get+put во оваа табела со записи од 100/1000/10000 бајти, изведувајќи 50 прашања по ред (случајни копчиња).
д. Точката г се повторува три пати.
ѓ. Времето на работа на сите нишки беше просечно.

Сите можни комбинации беа тестирани. Предвидливо е дека брзината ќе се намали како што се зголемува големината на рекордот или дека оневозможувањето на кеширањето ќе предизвика забавување. Сепак, целта беше да се разбере степенот и значајноста на влијанието на секој параметар, така што собраните податоци беа внесени во влезот на линеарна регресивна функција, што овозможува да се процени значајноста со помош на t-статистички податоци. Подолу се прикажани резултатите од блоковите кои извршуваат операции Put. Целосен сет на комбинации 2*2*3*2*3 = 144 опции + 72 tk. некои беа направени двапати. Според тоа, има вкупно 216 трки:

Тестирањето беше спроведено на мини-кластер составен од 3 DataNodes и 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 нишки). HBase верзија 1.2.0-cdh5.14.2.

Највисоката брзина на вметнување од 3.7 секунди е добиена со исклучен режим MSLAB, на маса со една партиција, со вклучен BlockCache, BlockSize = 16, записи од 100 бајти, 10 парчиња по пакет.
Најниската брзина на вметнување од 82.8 секунди е добиена со овозможен режим MSLAB, на табела со една партиција, со вклучен BlockCache, BlockSize = 16, записи од 10000 бајти, по 1.

Сега да го погледнеме моделот. Го гледаме добриот квалитет на моделот базиран на R2, но апсолутно е јасно дека екстраполацијата е контраиндицирана овде. Вистинското однесување на системот кога се менуваат параметрите нема да биде линеарно; овој модел не е потребен за предвидувања, туку за разбирање што се случило во дадените параметри. На пример, овде гледаме од студентскиот критериум дека параметрите BlockSize и BlockCache не се важни за операцијата Put (која е генерално сосема предвидлива):

Но, фактот дека зголемувањето на бројот на партиции доведува до намалување на перформансите е нешто неочекувано (веќе го видовме позитивното влијание од зголемувањето на бројот на партиции со BulkLoad), иако разбирливо. Прво, за обработка, треба да генерирате барања до 30 региони наместо еден, а обемот на податоци не е таков што тоа ќе донесе добивка. Второ, вкупното време на работа се одредува од најбавниот RS, и бидејќи бројот на DataNodes е помал од бројот на RS, некои региони имаат нула локалитет. Па, да ги погледнеме првите пет:

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

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

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

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

9. Тестирање на оптоварување

Па, конечно, ќе лансираме повеќе или помалку пристојно оптоварување, но секогаш е поинтересно кога имате со што да се споредите. На веб-страницата на DataStax, клучниот развивач на Cassandra, постои Наодите NT на голем број складишта NoSQL, вклучувајќи ја верзијата HBase 0.98.6-1. Вчитувањето беше извршено од 40 нишки, големина на податоци 100 бајти, SSD дискови. Резултатот од тестирањето на операциите Read-Modify-Write ги покажа следните резултати.

Колку што разбрав, читањето беше извршено во блокови од 100 записи и за 16 HBase јазли, тестот DataStax покажа изведба од 10 илјади операции во секунда.

Среќа што нашиот кластер има и 16 јазли, но не е многу „среќа“ што секое има 64 јадра (нишки), додека во тестот DataStax има само 4. Од друга страна, тие имаат SSD дискови, додека ние имаме HDD или повеќе, новата верзија на HBase и користењето на процесорот при оптоварување практично не се зголеми значително (визуелно за 5-10 проценти). Сепак, да се обидеме да започнеме да ја користиме оваа конфигурација. Стандардните поставки на табелата, читањето се врши во опсегот на клучеви од 0 до 50 милиони по случаен избор (т.е., во суштина ново секој пат). Табелата содржи 50 милиони записи, поделени на 64 партиции. Копчињата се хашираат со помош на crc32. Поставките за табелата се стандардни, MSLAB е овозможен. Стартувајќи 40 нишки, секоја нишка чита сет од 100 случајни клучеви и веднаш ги запишува генерираните 100 бајти назад на овие клучеви.

Стенд: 16 DataNode и 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 нишки). HBase верзија 1.2.0-cdh5.14.2.

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

Стенд: 16 DataNode и 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 нишки). HBase верзија 1.2.0-cdh5.14.2.

За време на оптоварувањето, неколку пати се активираше големо набивање, како што е прикажано погоре, без оваа постапка, перформансите постепено ќе се намалуваат, но дополнително оптоварување се јавува и за време на извршувањето. Повлекувањата се предизвикани од различни причини. Понекогаш нишките завршуваа со работа и имаше пауза додека се рестартираа, понекогаш апликациите од трети страни создаваа оптоварување на кластерот.

Читањето и веднаш пишувањето е едно од најтешките работни сценарија за HBase. Ако правите само мали барања за ставање, на пример 100 бајти, комбинирајќи ги во пакувања од 10-50 илјади парчиња, можете да добиете стотици илјади операции во секунда, а ситуацијата е слична со барањата само за читање. Вреди да се напомене дека резултатите се радикално подобри од оние добиени од DataStax, најмногу поради барањата во блокови од 50 илјади.

Стенд: 16 DataNode и 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 нишки). HBase верзија 1.2.0-cdh5.14.2.

10. Заклучоци

Овој систем е прилично флексибилно конфигуриран, но влијанието на голем број параметри сè уште останува непознато. Некои од нив беа тестирани, но не беа вклучени во добиениот тест сет. На пример, прелиминарните експерименти покажаа незначително значење на таков параметар како DATA_BLOCK_ENCODING, кој ги кодира информациите користејќи вредности од соседните ќелии, што е разбирливо за случајно генерирани податоци. Ако користите голем број дупликати објекти, добивката може да биде значителна. Генерално, можеме да кажеме дека HBase дава впечаток на прилично сериозна и добро осмислена база на податоци, која може да биде доста продуктивна при извршување на операции со големи блокови на податоци. Особено ако е можно навреме да се разделат процесите на читање и пишување.

Доколку има нешто според вашето мислење што не е доволно обелоденето, подготвен сум да ви кажам подетално. Ве покануваме да го споделите вашето искуство или да разговарате доколку не се согласувате со нешто.

Извор: www.habr.com