{"id":55302,"date":"2020-01-17T00:00:00","date_gmt":"2020-01-16T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/teoriya-i-praktika-ispolzovaniya-hbase"},"modified":"2020-02-18T14:03:24","modified_gmt":"2020-02-18T11:03:24","slug":"teoriya-i-praktika-ispolzovaniya-hbase","status":"publish","type":"post","link":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Teorie a praxe pou\u017e\u00edv\u00e1n\u00ed HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dobr\u00fd den! Jmenuji se Danil Lipovoj, n\u00e1\u0161 t\u00fdm ve Sbertechu za\u010dal pou\u017e\u00edvat HBase jako \u00falo\u017ei\u0161t\u011b provozn\u00edch dat. B\u011bhem jeho studia jsme nashrom\u00e1\u017edili zku\u0161enosti, kter\u00e9 jsme cht\u011bli systematizovat a popsat (douf\u00e1me, \u017ee to bude pro mnoh\u00e9 u\u017eite\u010dn\u00e9). V\u0161echny n\u00ed\u017ee uveden\u00e9 experimenty byly prov\u00e1d\u011bny s verzemi HBase 1.2.0-cdh5.14.2 a 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. Obecn\u00e1 architektura <\/li>\n
  2. Z\u00e1pis dat do HBASE<\/li>\n
  3. \u010cten\u00ed dat z HBASE<\/li>\n
  4. Mezipam\u011b\u0165 dat<\/li>\n
  5. Hromadn\u00e9 zpracov\u00e1n\u00ed dat MultiGet\/MultiPut<\/li>\n
  6. Strategie rozd\u011blen\u00ed tabulek na oblasti (splittov\u00e1n\u00ed)<\/li>\n
  7. Odolnost v\u016f\u010di chyb\u00e1m, kompakce a lokalita dat<\/li>\n
  8. Nastaven\u00ed a v\u00fdkon<\/li>\n
  9. Z\u00e1t\u011b\u017eov\u00e9 testov\u00e1n\u00ed<\/li>\n
  10. Z\u00e1v\u011bry<\/li>\n<\/ol>\n

    <\/a><\/noindex><\/p>\n

    1. Obecn\u00e1 architektura<\/h2>\n

    \n\"Teorie
    \nZ\u00e1lo\u017en\u00ed Master monitoruje heartbeat aktivn\u00edho na uzlu ZooKeeper a v p\u0159\u00edpad\u011b jeho v\u00fdpadku p\u0159eb\u00edr\u00e1 funkce Mistra. <\/p>\n

    2. Z\u00e1pis dat do HBASE<\/h2>\n

    \nNejprve se pod\u00edv\u00e1me na nejjednodu\u0161\u0161\u00ed p\u0159\u00edpad \u2013 z\u00e1pis objektu kl\u00ed\u010d-hodnota do ur\u010dit\u00e9 tabulky pomoc\u00ed put(rowkey). Klient nejprve mus\u00ed zjistit, kde se nach\u00e1z\u00ed ko\u0159enov\u00fd region server (Root Region Server \u2014 RRS), kter\u00fd uchov\u00e1v\u00e1 tabulku hbase:meta. Tyto informace z\u00edsk\u00e1v\u00e1 od ZooKeeper. Pot\u00e9 se obrac\u00ed na RRS a \u010dte tabulku hbase:meta, ze kter\u00e9 z\u00edsk\u00e1v\u00e1 informace o tom, kter\u00fd RegionServer (RS) odpov\u00edd\u00e1 za uchov\u00e1v\u00e1n\u00ed dat pro zadan\u00fd kl\u00ed\u010d rowkey v zaj\u00edmav\u00e9 tabulce. Za \u00fa\u010delem dal\u0161\u00edho pou\u017eit\u00ed je meta-tabulka cachov\u00e1na klientem, a tak jsou n\u00e1sleduj\u00edc\u00ed dotazy rychlej\u0161\u00ed, p\u0159\u00edmo k RS.<\/p>\n

    Pot\u00e9 RS, po p\u0159ijet\u00ed po\u017eadavku, nejprve zap\u00ed\u0161e jeho do WriteAheadLog (WAL), co\u017e je nutn\u00e9 pro obnoven\u00ed v p\u0159\u00edpad\u011b p\u00e1du. Pot\u00e9 ukl\u00e1d\u00e1 data do MemStore. To je buffer v pam\u011bti, kter\u00fd obsahuje se\u0159azenou sadu kl\u00ed\u010d\u016f z tohoto regionu. Tabulka m\u016f\u017ee b\u00fdt rozd\u011blena na oblasti (partice), z nich\u017e ka\u017ed\u00e1 obsahuje nep\u0159ekr\u00fdvaj\u00edc\u00ed se sadu kl\u00ed\u010d\u016f. To umo\u017e\u0148uje um\u00edstit oblasti na r\u016fzn\u00e9 servery a dos\u00e1hnout tak vy\u0161\u0161\u00ed v\u00fdkonnosti. I kdy\u017e je tento v\u00fdrok z\u0159ejm\u00fd, pozd\u011bji uvid\u00edme, \u017ee to nefunguje ve v\u0161ech p\u0159\u00edpadech.<\/p>\n

    Po um\u00edst\u011bn\u00ed z\u00e1znamu do MemStore obdr\u017e\u00ed klient odpov\u011b\u010f, \u017ee z\u00e1znam byl \u00fasp\u011b\u0161n\u011b ulo\u017een. Ve skute\u010dnosti se v\u0161ak ukl\u00e1d\u00e1 pouze v bufferu a na disk se dostane teprve po uplynut\u00ed ur\u010dit\u00e9ho \u010dasov\u00e9ho intervalu nebo p\u0159i napln\u011bn\u00ed nov\u00fdmi daty. <\/p>\n

    \"Teorie
    \nP\u0159i prov\u00e1d\u011bn\u00ed operace \u201eSmazat\u201c nedoch\u00e1z\u00ed k fyzick\u00e9mu odstran\u011bn\u00ed dat. Ta jsou pouze ozna\u010dena jako smazan\u00e1 a samotn\u00e9 zni\u010den\u00ed nast\u00e1v\u00e1 v okam\u017eiku zavol\u00e1n\u00ed funkce major compact, o kter\u00e9 je podrobn\u011bji pojedn\u00e1no v bodu 7.<\/p>\n

    Soubory ve form\u00e1tu HFile se hromad\u00ed v HDFS a \u010das od \u010dasu se spou\u0161t\u00ed proces minor compact, kter\u00fd jednodu\u0161e spojuje mal\u00e9 soubory do v\u011bt\u0161\u00edch, ani\u017e by n\u011bco odstra\u0148oval. V pr\u016fb\u011bhu \u010dasu to p\u0159er\u016fst\u00e1 v probl\u00e9m, kter\u00fd se projevuje pouze p\u0159i \u010dten\u00ed dat (k tomu se vr\u00e1t\u00edme pozd\u011bji). <\/p>\n

    Krom\u011b v\u00fd\u0161e uveden\u00e9ho procesu na\u010d\u00edt\u00e1n\u00ed existuje mnohem efektivn\u011bj\u0161\u00ed procedura, kter\u00e1 p\u0159edstavuje asi nejsiln\u011bj\u0161\u00ed str\u00e1nku t\u00e9to datab\u00e1ze \u2013 BulkLoad. Ta spo\u010d\u00edv\u00e1 v tom, \u017ee si sami vytv\u00e1\u0159\u00edme HFiles a ukl\u00e1d\u00e1me je na disk, co\u017e n\u00e1m umo\u017e\u0148uje vynikaj\u00edc\u00ed \u0161k\u00e1lovatelnost a dosahovat velmi slu\u0161n\u00fdch rychlost\u00ed. V podstat\u011b je zde omezen\u00edm nikoliv HBase, ale mo\u017enosti hardwaru. N\u00ed\u017ee jsou uvedeny v\u00fdsledky na\u010d\u00edt\u00e1n\u00ed na clusteru slo\u017een\u00e9m z 16 RegionServers a 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 vl\u00e1ken), verze HBase 1.2.0-cdh5.14.2. <\/p>\n

    \"Teorie
    \n
    \nZde je vid\u011bt, \u017ee zvy\u0161ov\u00e1n\u00edm po\u010dtu parti\u00ed (region\u016f) v tabulce, stejn\u011b jako executor\u016f Spark, z\u00edsk\u00e1v\u00e1me n\u00e1r\u016fst rychlosti na\u010d\u00edt\u00e1n\u00ed. Tak\u00e9 rychlost z\u00e1vis\u00ed na objemu z\u00e1pisu. Velk\u00e9 bloky p\u0159in\u00e1\u0161ej\u00ed n\u00e1r\u016fst v m\u011b\u0159en\u00ed MB\/s, mal\u00e9 v po\u010dtu vlo\u017een\u00fdch z\u00e1znam\u016f za jednotku \u010dasu, p\u0159i jinak stejn\u00fdch podm\u00ednk\u00e1ch. <\/p>\n

    Tak\u00e9 m\u016f\u017eeme spustit na\u010d\u00edt\u00e1n\u00ed do dvou tabulek sou\u010dasn\u011b a z\u00edskat zdvojen\u00ed rychlosti. N\u00ed\u017ee lze vid\u011bt, \u017ee z\u00e1pis blok\u016f 10 KB najednou do dvou tabulek prob\u00edh\u00e1 rychlost\u00ed kolem 600 MB\/s do ka\u017ed\u00e9 (celkem 1275 MB\/s), co\u017e odpov\u00edd\u00e1 rychlosti z\u00e1pisu do jedn\u00e9 tabulky 623 MB\/s (viz \u010d. 11 v\u00fd\u0161e).<\/p>\n

    \"Teorie
    \nDruh\u00e1 relace se z\u00e1pisy o velikosti 50 KB ukazuje, \u017ee rychlost na\u010d\u00edt\u00e1n\u00ed ji\u017e neroste v\u00fdrazn\u011b, co\u017e nazna\u010duje bl\u00ed\u017e\u00edc\u00ed se k limitn\u00edm hodnot\u00e1m. Je t\u0159eba m\u00edt na pam\u011bti, \u017ee na samotn\u00e9m HBASE zde prakticky nevznik\u00e1 z\u00e1t\u011b\u017e, v\u0161e, co od n\u011bj vy\u017eaduje, je nejprve vr\u00e1tit data z hbase:meta, a pot\u00e9 po vlo\u017een\u00ed HFiles vypr\u00e1zdnit data BlockCache a ulo\u017eit buffer MemStore na disk, pokud nen\u00ed pr\u00e1zdn\u00fd.<\/p>\n

    3. \u010cten\u00ed dat z HBASE<\/h2>\n

    \nPokud p\u0159edpokl\u00e1d\u00e1me, \u017ee v\u0161echny informace z hbase:meta m\u00e1 klient ji\u017e k dispozici (viz bod 2), pak dotaz ihned zam\u00ed\u0159\u00ed na ten RS, kde je ulo\u017een\u00fd po\u017eadovan\u00fd kl\u00ed\u010d. Nejprve se prov\u00e1d\u00ed hled\u00e1n\u00ed v MemCache. Bez ohledu na to, zda tam data jsou \u010di nikoliv, je hled\u00e1n\u00ed tak\u00e9 prov\u00e1d\u011bno v bloku BlockCache a v p\u0159\u00edpad\u011b pot\u0159eby v HFiles. Pokud jsou data nalezena v souboru, jsou ulo\u017eena do BlockCache a p\u0159i dal\u0161\u00edm dotazu budou vr\u00e1cena rychleji. Hled\u00e1n\u00ed v HFile prob\u00edh\u00e1 d\u00edky pou\u017eit\u00ed Bloomova filtru relativn\u011b rychle, tzn. po na\u010dten\u00ed mal\u00e9ho mno\u017estv\u00ed dat okam\u017eit\u011b ur\u010d\u00ed, zda tento soubor obsahuje po\u017eadovan\u00fd kl\u00ed\u010d, a pokud ne, p\u0159ech\u00e1z\u00ed na dal\u0161\u00ed.<\/p>\n

    \"Teorie
    \nPo z\u00edsk\u00e1n\u00ed dat z t\u011bchto t\u0159\u00ed zdroj\u016f RS vytv\u00e1\u0159\u00ed odpov\u011b\u010f. M\u016f\u017ee nap\u0159\u00edklad okam\u017eit\u011b p\u0159edat n\u011bkolik nalezen\u00fdch verz\u00ed objektu, pokud klient po\u017eadoval verze.<\/p>\n

    4. Ke\u0161ov\u00e1n\u00ed dat<\/h2>\n

    \nPam\u011b\u0165ov\u00e9 buffery MemStore a BlockCache zab\u00edraj\u00ed a\u017e 80 % vyhrazen\u00e9 on-heap pam\u011bti RS (zbytek je rezervov\u00e1n pro servisn\u00ed \u00fakoly RS). Pokud je typick\u00e9 pou\u017eit\u00ed takov\u00e9, \u017ee procesy zapisuj\u00ed a okam\u017eit\u011b \u010dtou tato stejn\u00e1 data, m\u00e1 smysl sn\u00ed\u017eit BlockCache a zv\u00fd\u0161it MemStore, proto\u017ee p\u0159i z\u00e1pisu data do cache na \u010dten\u00ed nepadaj\u00ed, tak\u017ee pou\u017e\u00edv\u00e1n\u00ed BlockCache bude m\u00e9n\u011b \u010dast\u00e9. Buffer BlockCache se skl\u00e1d\u00e1 ze dvou \u010d\u00e1st\u00ed: LruBlockCache (v\u017edy on-heap) a BucketCache (obvykle off-heap nebo na SSD). BucketCache by m\u011bl b\u00fdt pou\u017eit, kdy\u017e je velmi vysok\u00fd po\u010det dotaz\u016f na \u010dten\u00ed a ta se nevejdou do LruBlockCache, co\u017e vede k aktivn\u00edmu provozu Garbage Collector. Z\u00e1rove\u0148 nen\u00ed re\u00e1ln\u011b mo\u017en\u00e9 o\u010dek\u00e1vat radik\u00e1ln\u00ed n\u00e1r\u016fst v\u00fdkonu z pou\u017e\u00edv\u00e1n\u00ed cache na \u010dten\u00ed, nicm\u00e9n\u011b k tomu se je\u0161t\u011b vr\u00e1t\u00edme v bod\u011b 8.<\/p>\n

    \"Teorie
    \nBlockCache je jeden pro cel\u00fd RS, zat\u00edmco MemStore je pro ka\u017edou tabulku zvl\u00e1\u0161tn\u00ed (po jednom na ka\u017ed\u00fd Column Family).<\/p>\n

    Jak je pops\u00e1no<\/a><\/noindex> Teoreticky, p\u0159i z\u00e1pisu data do cache nepadaj\u00ed a skute\u010dn\u011b jsou takov\u00e9 parametry CACHE_DATA_ON_WRITE pro tabulku a \u201eCache DATA on Write\u201c pro RS nastaveny na false. Nicm\u00e9n\u011b v praxi, pokud zap\u00ed\u0161eme data do MemStore, pot\u00e9 je vypr\u00e1zdn\u00edme na disk (t\u00edmto zp\u016fsobem), n\u00e1sledn\u011b odstran\u00edme vznikl\u00fd soubor, p\u0159i vykon\u00e1v\u00e1n\u00ed dotazu get \u00fasp\u011b\u0161n\u011b z\u00edsk\u00e1me data. Nav\u00edc, i kdy\u017e zcela vypneme BlockCache a napln\u00edme tabulku nov\u00fdmi daty, pak dos\u00e1hneme vypr\u00e1zdn\u011bn\u00ed MemStore na disk, pokud je odstran\u00edme a po\u017e\u00e1d\u00e1me z jin\u00e9 relace, data se stejn\u011b n\u011bjak\u00fdm zp\u016fsobem z\u00edskaj\u00ed. Tak\u017ee HBase uchov\u00e1v\u00e1 nejen data, ale tak\u00e9 tajemn\u00e9 z\u00e1hady.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nCreated table ns:magic\nTook 1.1533 seconds\nhbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'\nTook 0.2610 seconds\nhbase(main):003:0> flush 'ns:magic'\nTook 0.6161 seconds\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> get 'ns:magic', 'key1'\n cf:c      timestamp=1534440690218, value=try_to_delete_me\n<\/code><\/pre>\n
    \nParametr \u201eCache DATA on Read\u201c je nastaven na false. Pokud m\u00e1te n\u011bjak\u00e9 n\u00e1pady, v\u00edt\u00e1me va\u0161e koment\u00e1\u0159e.<\/p>\n
    5. Hromadn\u00e9 zpracov\u00e1n\u00ed dat MultiGet\/MultiPut<\/h2>\n
    \nZpracov\u00e1n\u00ed jednotliv\u00fdch po\u017eadavk\u016f (Get\/Put\/Delete) je pom\u011brn\u011b n\u00e1kladn\u00e1 operace, proto byste je m\u011bli co nejv\u00edce sdru\u017eovat do seznamu, co\u017e umo\u017e\u0148uje dos\u00e1hnout zna\u010dn\u00e9ho zv\u00fd\u0161en\u00ed v\u00fdkonu. To plat\u00ed zejm\u00e9na pro z\u00e1pis, ale p\u0159i \u010dten\u00ed existuje n\u00e1sleduj\u00edc\u00ed \u00faskal\u00ed. Na grafu n\u00ed\u017ee je uveden \u010das \u010dten\u00ed 50 000 z\u00e1znam\u016f z MemStore. \u010cten\u00ed prob\u00edhalo v jednom vl\u00e1knu a na vodorovn\u00e9 ose je uveden po\u010det kl\u00ed\u010d\u016f v po\u017eadavku. Zde je vid\u011bt, \u017ee p\u0159i zv\u00fd\u0161en\u00ed na tis\u00edc kl\u00ed\u010d\u016f v jednom po\u017eadavku kles\u00e1 doba vykon\u00e1n\u00ed, tj. rychlost se zvy\u0161uje. Ov\u0161em p\u0159i zapnut\u00e9m v\u00fdchoz\u00edm re\u017eimu MSLAB po tomto prahu za\u010d\u00edn\u00e1 radik\u00e1ln\u00ed pokles v\u00fdkonu, p\u0159i\u010dem\u017e \u010d\u00edm v\u011bt\u0161\u00ed je objem dat v z\u00e1znamu, t\u00edm v\u00edce roste doba zpracov\u00e1n\u00ed. <\/p>\n
    \"Teorie
    \n
    \nTesty byly prov\u00e1d\u011bny na virtu\u00e1ln\u00edm stroji, 8 jader, verze HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    Re\u017eim MSLAB slou\u017e\u00ed ke sn\u00ed\u017een\u00ed fragmentace haldy, kter\u00e1 vznik\u00e1 m\u00edsen\u00edm dat nov\u00fdch a star\u00fdch generac\u00ed. Jako \u0159e\u0161en\u00ed probl\u00e9mu p\u0159i aktivaci MSLAB se data umis\u0165uj\u00ed do relativn\u011b mal\u00fdch bun\u011bk (chunk) a zpracov\u00e1vaj\u00ed se po d\u00e1vk\u00e1ch. V d\u016fsledku toho, kdy\u017e objem po\u017eadovan\u00e9ho bal\u00ed\u010dku dat p\u0159ekro\u010d\u00ed vyhrazenou velikost, dojde k radik\u00e1ln\u00edmu poklesu v\u00fdkonu. Na druhou stranu, vypnut\u00ed tohoto re\u017eimu je tak\u00e9 ne\u017e\u00e1douc\u00ed, proto\u017ee to povede k z\u00e1stav\u00e1m kv\u016fli GC v obdob\u00edch intenzivn\u00ed pr\u00e1ce s daty. Dobr\u00e9 \u0159e\u0161en\u00ed je zv\u00fd\u0161en\u00ed objem\u016f bun\u011bk, kdy\u017e doch\u00e1z\u00ed k aktivn\u00edmu z\u00e1pisu p\u0159es put sou\u010dasn\u011b s \u010dten\u00edm. Je t\u0159eba poznamenat, \u017ee probl\u00e9m nevznik\u00e1, pokud po z\u00e1pisu provedete p\u0159\u00edkaz flush, kter\u00fd ukl\u00e1d\u00e1 MemStore na disk, nebo pokud provedete na\u010dten\u00ed pomoc\u00ed BulkLoad. V tabulce n\u00ed\u017ee je uvedeno, \u017ee dotazy z MemStore s v\u011bt\u0161\u00edm objemem dat (a stejn\u00fdm mno\u017estv\u00edm) vedou k zpomalen\u00ed. Nicm\u00e9n\u011b zv\u00fd\u0161en\u00edm velikosti chunksize se doba zpracov\u00e1n\u00ed vrac\u00ed na normu.<\/p>\n
    \"Teorie
    \nKrom\u011b zv\u00fd\u0161en\u00ed chunksize pom\u00e1h\u00e1 d\u011blen\u00ed dat podle region\u016f, tedy rozd\u011blen\u00ed tabulek. To zp\u016fsobuje, \u017ee na ka\u017ed\u00fd region p\u0159ich\u00e1z\u00ed men\u0161\u00ed po\u010det dotaz\u016f a pokud jsou um\u00edst\u011bny do bun\u011bk, odezva z\u016fst\u00e1v\u00e1 dobr\u00e1.<\/p>\n
    6. Strategie rozd\u011blen\u00ed tabulek na regiony (splitting)<\/h2>\n
    \nJeliko\u017e HBase je \u00falo\u017ei\u0161t\u011b kl\u00ed\u010d-hodnota a partitioning se prov\u00e1d\u00ed podle kl\u00ed\u010de, je velmi d\u016fle\u017eit\u00e9 rozd\u011blovat data rovnom\u011brn\u011b mezi v\u0161echny regiony. Nap\u0159\u00edklad rozd\u011blen\u00ed takov\u00e9 tabulky na t\u0159i \u010d\u00e1sti povede k tomu, \u017ee data budou rozd\u011blena do t\u0159\u00ed region\u016f:<\/p>\n
    \"Teorie
    \nN\u011bkdy to vede k v\u00fdrazn\u00e9mu zpomalen\u00ed, pokud budou pozd\u011bji na\u010d\u00edtan\u00e9 data v\u011bt\u0161inou obsahovat long hodnoty, kter\u00e9 za\u010d\u00ednaj\u00ed stejnou \u010d\u00edslic\u00ed, nap\u0159\u00edklad:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Jeliko\u017e jsou kl\u00ed\u010de ukl\u00e1d\u00e1ny jako pole byt\u016f, v\u0161echna budou za\u010d\u00ednat stejn\u011b a vztahovat se k regionu #1 ukl\u00e1daj\u00edc\u00edmu tuto oblast kl\u00ed\u010d\u016f. Existuje n\u011bkolik strategi\u00ed rozd\u011blen\u00ed:<\/p>\n
    HexStringSplit \u2013 P\u0159ev\u00e1d\u00ed kl\u00ed\u010d na \u0159et\u011bzec s hexadecim\u00e1ln\u00edm k\u00f3dov\u00e1n\u00edm v rozsahu \u201e00000000\u201c => \u201eFFFFFFFF\u201c a vypl\u0148uje zleva nulami.<\/p>\n
    UniformSplit \u2013 P\u0159ev\u00e1d\u00ed kl\u00ed\u010d na pole byt\u016f s hexadecim\u00e1ln\u00edm k\u00f3dov\u00e1n\u00edm v rozsahu \u201e00\u201c => \u201eFF\u201c a vypl\u0148uje zprava nulami.<\/p>\n
    Krom\u011b toho lze specifikovat libovoln\u00fd rozsah nebo sadu kl\u00ed\u010d\u016f pro rozd\u011blen\u00ed a nastavit automatick\u00e9 d\u011blen\u00ed. Av\u0161ak jedn\u00edm z nejjednodu\u0161\u0161\u00edch a nej\u00fa\u010dinn\u011bj\u0161\u00edch p\u0159\u00edstup\u016f je UniformSplit a pou\u017eit\u00ed koncatenace hashe, nap\u0159\u00edklad nejvy\u0161\u0161\u00ed dvojice byt\u016f od spu\u0161t\u011bn\u00ed kl\u00ed\u010de pomoc\u00ed funkce CRC32(rowkey) a vlastn\u011b rowkey:<\/p>\n
    hash + rowkey<\/p>\n
    V\u0161echny data budou rovnom\u011brn\u011b rozlo\u017eena mezi regiony. P\u0159i \u010dten\u00ed se prvn\u00edch dva byty jednodu\u0161e zahod\u00ed a z\u016fstane p\u016fvodn\u00ed kl\u00ed\u010d. Tak\u00e9 RS kontroluje mno\u017estv\u00ed dat a kl\u00ed\u010d\u016f v regionu a p\u0159i p\u0159ekro\u010den\u00ed limit\u016f je automaticky rozd\u011bl\u00ed na \u010d\u00e1sti. <\/p>\n
    7. Odolnost v\u016f\u010di poruch\u00e1m a lokalita dat<\/h2>\n
    \nJeliko\u017e ka\u017ed\u00fd soubor kl\u00ed\u010d\u016f odpov\u00edd\u00e1 pouze jednomu regionu, \u0159e\u0161en\u00edm probl\u00e9m\u016f spojen\u00fdch s p\u00e1dy RS nebo jejich vy\u0159azov\u00e1n\u00edm z provozu je ukl\u00e1d\u00e1n\u00ed v\u0161ech pot\u0159ebn\u00fdch dat do HDFS. P\u0159i p\u00e1du RS to master zjist\u00ed prost\u0159ednictv\u00edm nedostatku heartbeat na uzlu ZooKeeper. Pot\u00e9 p\u0159i\u0159ad\u00ed obsluhovan\u00fd region jin\u00e9mu RS a proto\u017ee HFiles jsou ulo\u017eeny v distribuovan\u00e9m souborov\u00e9m syst\u00e9mu, nov\u00fd majitel je vy\u010dte a pokra\u010duje v obsluze dat. Nicm\u00e9n\u011b, proto\u017ee \u010d\u00e1st dat m\u016f\u017ee b\u00fdt v MemStore a nestihla se dostat do HFiles, pro obnoven\u00ed historie operac\u00ed se pou\u017e\u00edv\u00e1 WAL, kter\u00fd je tak\u00e9 ulo\u017een v HDFS. Po aplikaci zm\u011bn je RS schopen odpov\u00eddat na dotazy, nicm\u00e9n\u011b p\u0159est\u011bhov\u00e1n\u00ed vede k tomu, \u017ee \u010d\u00e1st dat a procesy, kter\u00e9 je obsluhuj\u00ed, se nach\u00e1zej\u00ed na r\u016fzn\u00fdch uzlech, co\u017e znamen\u00e1, \u017ee se sni\u017euje lokalita. <\/p>\n
    \u0158e\u0161en\u00edm probl\u00e9mu je major compaction \u2013 tento proces p\u0159esouv\u00e1 soubory na ty uzly, kter\u00e9 jsou za n\u011b zodpov\u011bdn\u00e9 (tam, kde se nach\u00e1zej\u00ed jejich regiony), co\u017e m\u00e1 za n\u00e1sledek prudk\u00fd n\u00e1r\u016fst zat\u00ed\u017een\u00ed s\u00edt\u011b a disk\u016f b\u011bhem t\u00e9to procedury. V budoucnu v\u0161ak bude p\u0159\u00edstup k dat\u016fm znateln\u011b urychlen. Krom\u011b toho major_compaction prov\u00e1d\u00ed slou\u010den\u00ed v\u0161ech HFiles do jednoho souboru v r\u00e1mci regionu a tak\u00e9 \u010dist\u00ed data podle nastaven\u00ed tabulky. Nap\u0159\u00edklad lze ur\u010dit po\u010det verz\u00ed objektu, kter\u00e9 je t\u0159eba uchov\u00e1vat, nebo jeho \u017eivotnost, po jej\u00edm\u017e uplynut\u00ed je objekt fyzicky smaz\u00e1n.<\/p>\n
    Tento proces m\u016f\u017ee m\u00edt velmi pozitivn\u00ed vliv na v\u00fdkon HBase. Na obr\u00e1zku n\u00ed\u017ee je vid\u011bt, jak se zhor\u0161ila v\u00fdkonnost v d\u016fsledku aktivn\u00edho z\u00e1pisu dat. M\u016f\u017eeme vid\u011bt, jak do jedn\u00e9 tabulky zapisovalo 40 vl\u00e1ken a 40 vl\u00e1ken sou\u010dasn\u011b \u010detlo data. P\u00ed\u0161\u00edc\u00ed vl\u00e1kna generuj\u00ed st\u00e1le v\u00edce a v\u00edce HFiles, kter\u00e9 jsou \u010dteny jin\u00fdmi vl\u00e1kny. V d\u016fsledku toho je t\u0159eba st\u00e1le v\u00edce dat smazat z pam\u011bti a nakonec za\u010dne fungovat GC, kter\u00fd t\u00e9m\u011b\u0159 paralyzuje celou pr\u00e1ci. Spu\u0161t\u011bn\u00ed major compaction vedlo k vy\u010di\u0161t\u011bn\u00ed nahromad\u011bn\u00fdch dat a obnoven\u00ed v\u00fdkonu.<\/p>\n
    \"Teorie
    \nTest byl proveden na 3 DataNode a 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 vl\u00e1ken). Verze HBase 1.2.0-cdh5.14.2<\/p>\n
    Je t\u0159eba poznamenat, \u017ee major compaction byla provedena na '\u017eiv\u00e9' tabulce, do kter\u00e9 se aktivn\u011b zapisovala a \u010detla data. V s\u00edti se objevovalo tvrzen\u00ed, \u017ee to m\u016f\u017ee v\u00e9st k nespr\u00e1vn\u00fdm odpov\u011bd\u00edm p\u0159i \u010dten\u00ed dat. Pro ov\u011b\u0159en\u00ed byl spu\u0161t\u011bn proces, kter\u00fd generoval nov\u00e1 data a zapisoval je do tabulky. Po \u010dem\u017e se okam\u017eit\u011b \u010detlo a porovn\u00e1valo, zda z\u00edskan\u00e1 hodnota souhlas\u00ed s t\u00edm, co bylo zaps\u00e1no. B\u011bhem pr\u00e1ce tohoto procesu se major compaction spustil asi 200kr\u00e1t a nebyla zaznamen\u00e1na \u017e\u00e1dn\u00e1 selh\u00e1n\u00ed. Problematika se pravd\u011bpodobn\u011b projevuje vz\u00e1cn\u011b a pouze b\u011bhem vysok\u00e9ho zat\u00ed\u017een\u00ed, proto je v\u00edce bezpe\u010dn\u00e9 pl\u00e1novan\u011b zastavit procesy z\u00e1pisu a \u010dten\u00ed a prov\u00e9st vy\u010di\u0161t\u011bn\u00ed, aby se p\u0159ede\u0161lo takov\u00fdm v\u00fdpadk\u016fm GC.<\/p>\n
    Tak\u00e9 major compaction neovliv\u0148uje stav MemStore, pro jeho vypr\u00e1zdn\u011bn\u00ed na disk a kompakci je pot\u0159eba pou\u017e\u00edt flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Nastaven\u00ed a v\u00fdkon<\/h2>\n
    \nJak ji\u017e bylo \u0159e\u010deno, nejv\u011bt\u0161\u00ed \u00fasp\u011bch HBase dosahuje tam, kde nemus\u00ed nic d\u011blat, p\u0159i prov\u00e1d\u011bn\u00ed BulkLoad. Nicm\u00e9n\u011b to plat\u00ed pro v\u011bt\u0161inu syst\u00e9m\u016f a lid\u00ed. Tento n\u00e1stroj je sp\u00ed\u0161e ur\u010den pro hromadn\u00e9 ukl\u00e1d\u00e1n\u00ed dat ve velk\u00fdch bloc\u00edch, zat\u00edmco pokud proces vy\u017eaduje prov\u00e1d\u011bn\u00ed mnoha konkuren\u010dn\u00edch \u010dtec\u00edch a zapisovac\u00edch po\u017eadavk\u016f, pou\u017e\u00edvaj\u00ed se v\u00fd\u0161e popsan\u00e9 p\u0159\u00edkazy Get a Put. Pro stanoven\u00ed optim\u00e1ln\u00edch parametr\u016f byly provedeny spu\u0161t\u011bn\u00ed p\u0159i r\u016fzn\u00fdch kombinac\u00edch parametr\u016f tabulek a nastaven\u00ed:<\/p>\n