{"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\/et\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"HBase'i teooria ja praktika","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere p\u00e4evast! Mina olen Danil Lipovoy, meie meeskond Sbertechi's on hakanud HBase'i kasutama operatiivandmete salvestamiseks. Selle uurimise k\u00e4igus on kogunenud kogemusi, mida soovisime s\u00fcsteematisteerida ja kirjeldada (loodame, et sellest on paljudele abi). K\u00f5ik allpool toodud eksperimendid viidi l\u00e4bi versioonidega HBase 1.2.0-cdh5.14.2 ja 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. \u00dcldine arhitektuur <\/li>\n
  2. Andmete salvestamine HBASE-s<\/li>\n
  3. Andmete lugemine HBASE-st<\/li>\n
  4. Andmete vahem\u00e4lu<\/li>\n
  5. Andmete partii t\u00f6\u00f6tlemine MultiGet\/MultiPut<\/li>\n
  6. Tabelite jagamise strateegia piirkondadeks (sharding)<\/li>\n
  7. Veakindlus, kompakteerimine ja andmete kohalikkus<\/li>\n
  8. Seaded ja j\u00f5udlus<\/li>\n
  9. Koormuse testimine<\/li>\n
  10. J\u00e4reldused<\/li>\n<\/ol>\n

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

    1. \u00dcldine arhitektuur<\/h2>\n

    \n\"HBase'i
    \nVaru Master kuulab aktiivse s\u00f5lme ZooKeeper'is heartbeat'i ja kaotamise korral v\u00f5tab Master'i funktsioonid enda kanda. <\/p>\n

    2. Andmete salvestamine HBASE-s<\/h2>\n

    \nAlustame k\u00f5ige lihtsama juhtumiga \u2013 v\u00f5tme-v\u00e4\u00e4rtuse objekti salvestamine tabelisse kasutades put(rowkey). Klient peab esmalt kindlaks tegema, kus asub juure piirkonna server (Root Region Server \u2014 RRS), mis salvestab tabelit hbase:meta. Selle teabe saab ta ZooKeeper'ist. Seej\u00e4rel p\u00f6\u00f6rdub ta RRS-i poole ja loeb tabelit hbase:meta, millest ta t\u00f5mbab v\u00e4lja teabe, milline RegionServer (RS) vastutab antud v\u00f5tme rowkey seotud andmete salvestamise eest huvipakkuvas tabelis. J\u00e4tkuva kasutamise eesm\u00e4rgil vahem\u00e4lu tabelit kliendile ja seega l\u00e4hevad edasised p\u00e4ringud kiiremini, otseselt RS-i.<\/p>\n

    Seej\u00e4rel kirjutab RS, saades p\u00e4ringu, esmalt selle WriteAheadLog'i (WAL), mis on vajalik taastumiseks, kui midagi l\u00e4heb valesti. Seej\u00e4rel salvestab ta andmed MemStore'i. See on m\u00e4lu puhver, mis sisaldab antud piirkonna sorteeritud v\u00f5tmete kogumit. Tabel v\u00f5ib jagada piirkondadeks (partitsioonideks), millest iga\u00fcks sisaldab \u00fcksteisega mitte \u00fchtivat v\u00f5tmete kogumit. See v\u00f5imaldab piirkondi erinevates serverites paigutades saavutada k\u00f5rgemat j\u00f5udlust. Siiski, hoolimata selle v\u00e4ite ilmsusest, n\u00e4eme hiljem, et see ei toimi k\u00f5ikides olukordades.<\/p>\n

    P\u00e4rast salvestuse paigutamist MemStore'i saab klient vastuse, et salvestus on edukalt tehtud. Samas hoitakse seda tegelikult ainult puhvers ja j\u00f5uab kettale alles p\u00e4rast teatud aja m\u00f6\u00f6dumist v\u00f5i selle t\u00e4itumisel uutega. <\/p>\n

    \"HBase'i
    \nTehtava \"Delete\" k\u00e4igus ei toimu f\u00fc\u00fcsilist andmete kustutamist. Need m\u00e4rgitakse lihtsalt kui kustutatud ja tegelik h\u00e4vitamine toimub major compact funktsiooni k\u00e4ivitamise hetkel, millest on rohkem juttu punktis 7.<\/p>\n

    HFile formaadis failid kogunevad HDFS-s ja aeg-ajalt k\u00e4ivitatakse minor compact protsess, mis lihtsalt liidab v\u00e4ikesed failid suuremateks, midagi kustutamata. Aja jooksul muutub see probleemiks, mis avaldub ainult andmete lugemisel (sellest r\u00e4\u00e4gime natuke hiljem). <\/p>\n

    Lisaks \u00fclaltoodud andmete laadimise protsessile on olemas palju t\u00f5husam protseduur, mille keskmes on br\u00e4ndi k\u00f5ige tugevam k\u00fclg \u2013 BulkLoad. See seisneb selles, et me ise vormistame HFiles ja paneme need kettale, mis v\u00f5imaldab suurep\u00e4rast skaleerimist ning saavutada \u00fcsna korralikke kiirusnumbreid. Sisuliselt on piiranguks mitte HBase, vaid riistvara v\u00f5imalused. Allpool on toodud laadimistulemused klastrilt, mis koosneb 16 RegionServerist ja 16 NodeManager YARN-ist (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niidid), HBase versioon 1.2.0-cdh5.14.2. <\/p>\n

    \"HBase'i
    \n
    \nSiit on n\u00e4ha, et partitsioonide (regioonide) arvu ning Spark'i eksekutorite suurendamisega saame laadimiskiiruse suurenemise. Samuti s\u00f5ltub kiirus kirjutamise mahust. Suured plokid annavad t\u00f5usu MB\/sek m\u00f5\u00f5tmisel, v\u00e4iksemad aga sisse kirjutatud kirjade arvu ajas, kui k\u00f5ik muud tingimused on v\u00f5rdsed. <\/p>\n

    Samuti saab k\u00e4ivitada laadimise kahes tabelis samaaegselt ning saavutada kiiruskahekordistumine. Allpool on n\u00e4htav, et 10 KB plokkide kirjutamine kahte tabelisse toimub kiirusel umbes 600 Mb\/sek igasse (kokku 1275 Mb\/sek), mis vastab \u00fchte tabelisse kirjutamise kiirusel 623 MB\/sek (vt punkt 11 \u00fclevale).<\/p>\n

    \"HBase'i
    \nKuid teine k\u00e4ivitamine 50 KB kirjete kirjutamisega n\u00e4itab, et laadimiskiirus t\u00f5useb juba minimaalsetes m\u00e4\u00e4rades, mis viitab sellele, et l\u00e4hme piirv\u00e4\u00e4rtuste suunas. Pealegi tuleb arvestada, et HBASE-le endale ei tekkida praktiliselt mingit koormust; k\u00f5ik, mis sellest n\u00f5utakse, on esmalt andmete andmine hbase:meta-st ja seej\u00e4rel HFiles'i lisamisel BlockCache'i t\u00fchjendamine ning MemStore'i buffri salvestamine kettale, kui see pole t\u00fchi.<\/p>\n

    3. Andmete lugemine HBASE-st<\/h2>\n

    \nKui eeldada, et kogu teave hbase:meta on juba kliendil olemas (vt p.2), siis l\u00e4heb p\u00e4ring kohe sellele RS-ile, kus vajalik v\u00f5ti asub. Esiteks toimub otsing MemCache'is. S\u00f5ltumata sellest, kas seal on andmeid v\u00f5i mitte, toimub otsing ka BlockCache'i puhveres ja vajadusel HFiles'is. Kui andmed leiti failist, salvestatakse need BlockCache'i ja j\u00e4rgmise p\u00e4ringu korral tagastatakse need kiiremini. Otsing HFiles'is toimub suhteliselt kiiresti, kasutades Bloomi filtrit, mis t\u00e4hendab, et lugedes v\u00e4ikest andmehulka, m\u00e4\u00e4rab ta kohe, kas see fail sisaldab vajalikku v\u00f5tit ja kui ei, siis liikuda j\u00e4rgmise juurde.<\/p>\n

    \"HBase'i
    \nSaades andmed neist kolmest allikast, vormib RS vastuse. Eriti v\u00f5ib ta edastada mitu leitud objekti versiooni, kui klient k\u00fcsis versioonisust.<\/p>\n

    4. Andmete vahem\u00e4lu<\/h2>\n

    \nMemStore'i ja BlockCache'i puhvrit\u00e4iendus moodustab kuni 80% eraldatud on-heap m\u00e4lu RS jaoks (\u00fclej\u00e4\u00e4nud on reserveeritud RS teenuste jaoks). Kui t\u00fc\u00fcpiline kasutusre\u017eiim on selline, et protsessid kirjutavad ja loevad kohe neid samu andmeid, siis on m\u00f5istlik v\u00e4hendada BlockCache'i ja suurendada MemStore'i, kuna kirjutades ei p\u00e4\u00e4se andmed lugemiseks puhvri, seega toimub BlockCache'i kasutamine harvem. BlockCache puhver koosneb kahest osast: LruBlockCache (alati on-heap) ja BucketCache (tavaliselt off-heap v\u00f5i SSD-l). BucketCache'i tuleks kasutada, kui on v\u00e4ga palju lugemisep\u00e4ringuid ja need ei mahu LruBlockCache'i, mis toob kaasa aktiivse Garbage Collectori t\u00f6\u00f6. Samas ei tasu oodata radikaalset j\u00f5udluse kasvu lugemisvahem\u00e4lu kasutamiselt, kuid sellest r\u00e4\u00e4gime veel p. 8.<\/p>\n

    \"HBase'i
    \nBlockCache on kogu RS-i kaupa, samas on iga tabeli jaoks oma MemStore (iga Column Family jaoks \u00fcks).<\/p>\n

    Kuidas kirjeldatud<\/a><\/noindex> teoorias, kui andmed kirjutatakse vahem\u00e4llu, siis need ei j\u00f5ua sinna ja t\u00f5epoolest, sellised parameetrid CACHE_DATA_ON_WRITE tabeli jaoks ja \"Cache DATA on Write\" RS-i jaoks on seatud v\u00e4\u00e4rtusele false. Kuid praktikast, kui kirjutada andmed MemStore'i, seej\u00e4rel kustutada see kettale (puhastades selguse m\u00f5ttes), seej\u00e4rel eemaldada saadud fail, siis tehes get p\u00e4ringu saame andmed edukalt. Lisaks, isegi kui t\u00e4ielikult blokeerida BlockCache ja t\u00e4ita tabel uute andmetega, siis saavutades MemStore'i v\u00e4ljal\u00fclitamise kettale, kustutades need ja k\u00fcsides teises sessioonis, need ikka kuskilt saadakse. Seega HBase hoiab endas mitte ainult andmeid, vaid ka salap\u00e4raseid m\u00f5istatusi.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nLoodud tabel ns:magic\nKestis 1.1533 sekundit\nhbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'\nKestis 0.2610 sekundit\nhbase(main):003:0> flush 'ns:magic'\nKestis 0.6161 sekundit\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
    \nParameeter \u201eCache DATA on Read\u201d on seadistatud vale. Kui teil on ideid, siis teretulnud arutama seda kommentaarides.<\/p>\n
    5. Andmete paketiline t\u00f6\u00f6tlemine MultiGet\/MultiPut<\/h2>\n
    \n\u00dcksikute p\u00e4ringute (Get\/Put\/Delete) t\u00f6\u00f6tlemine on \u00fcsna kallis operatsioon, seet\u00f5ttu tuleks neid v\u00f5imalusel \u00fchendatud Listi v\u00f5i Listide alla koondada, mis toob kaasa m\u00e4rkimisv\u00e4\u00e4rse j\u00f5udluse kasvu. Eriti kehtib see kirjutamise operatsioonide jaoks, kuid lugemise puhul on j\u00e4rgmine peidetud karikas. Alloleval graafikul on n\u00e4idatud 50 000 m\u00e4rkme lugemise aega MemStores. Lugemine toimus \u00fches olles ja horisontaalsel teljel on n\u00e4idatud p\u00e4ringu v\u00f5tmete arv. Siit on n\u00e4ha, et kui v\u00f5tmete arv \u00fches p\u00e4ringus suureneb kuni tuhandeni, siis t\u00e4itmisaja kestus langeb, st kiirus suureneb. Kuid vaike- MSLABi re\u017eiimi aktiveerimisel hakkab p\u00e4rast seda piiri j\u00f5udluse j\u00e4rsult langema, kusjuures andmete maht kirje sisse m\u00f5jutab kestust. <\/p>\n
    \"HBase'i
    \n
    \nTestid viidi l\u00e4bi virtuaalkeskkonnas, 8 tuuma, HBase versioon 2.0.0-cdh6.0.0-beta1.<\/p>\n
    MSLAB re\u017eiim on loodud v\u00e4hendama heap'i fragmentatsiooni, mis tuleneb uue ja vana p\u00f5lvkonna andmete segunemisest. Probleemi lahendusena andmed MSLAB re\u017eiimi aktiveerimisel paigutatakse suhteliselt v\u00e4ikestesse rakkudesse (chunk) ja t\u00f6\u00f6deldakse portsjonitena. Tulemuseks on see, et kui k\u00fcsitud andmepaketi maht \u00fcletab reserveeritud suuruse, siis j\u00f5udlus langeb j\u00e4rsult. Teiselt poolt ei ole antud re\u017eiimi v\u00e4ljal\u00fclitamine soovitatav, kuna see v\u00f5ib p\u00f5hjustada peatuseid GC t\u00f5ttu intensiivse andmet\u00f6\u00f6tluse hetkedel. Hea lahendus on suurendada rakuga mahte, kui kirjutamist teostatakse put'i kaudu samal ajal lugemisega. Tuleb m\u00e4rkida, et see probleem ei esine, kui p\u00e4rast kirjutamist antakse k\u00e4sk flush, mis kirjutab MemStore'i kettale, v\u00f5i kui laadimist teostatakse BulkLoad abil. Allolevas tabelis on n\u00e4idatud, et p\u00e4ringud MemStore'ist suuremate (ja sama arvu) andmete puhul p\u00f5hjustavad aeglustumist. Kuid suurendades chunksize'i, toob oleme t\u00f6\u00f6tluse aega normaali juurde.<\/p>\n
    \"HBase'i
    \nLisaks chunksize'i suurendamisele aitab andmete jagamine regioonide kaupa, st tabelite jagamine. See v\u00e4hendab igale regioonile j\u00f5udvate p\u00e4ringute arvu ning kui need on lahtris, siis j\u00e4\u00e4b vastus hea.<\/p>\n
    6. Tabelite jagamise strateegia regioonide vahel (jagamine)<\/h2>\n
    \nKuna HBase on v\u00f5tme-v\u00e4\u00e4rtuse salvestus ja jaotamine toimub v\u00f5tme j\u00e4rgi, on v\u00e4ga oluline jagada andmed \u00fchtlaselt k\u00f5ikide regioonide vahel. N\u00e4iteks teeb kolme ossa jagamine, et andmed jagatakse kolme regiooniks:<\/p>\n
    \"HBase'i
    \nM\u00f5nikord toob see kaasa j\u00e4rsu aeglustumise, kui hiljem laaditavad andmed on n\u00e4iteks long v\u00e4\u00e4rtustes, mis enamikul juhtudel algavad sama numbriga, n\u00e4iteks:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Kuna v\u00f5tmed salvestatakse baitide massiivina, hakkavad k\u00f5ik nad samamoodi ja kuuluvad \u00fchte regioon #1, mis salvestab selle v\u00f5tme vahemiku. On mitmeid jagamise strateegiaid:<\/p>\n
    HexStringSplit \u2013 Muunib v\u00f5tme stringiks, kasutades kuues\u00fcsteemi kodeeringut vahemikus \"00000000\" => \"FFFFFFFF\", t\u00e4iendades vasakule nullidega.<\/p>\n
    UniformSplit \u2013 Muunib v\u00f5tme baitide massiiviks, kasutades kuues\u00fcsteemi kodeeringut vahemikus \"00\" => \"FF\", t\u00e4iendades paremale nullidega.<\/p>\n
    Lisaks saab m\u00e4\u00e4rata igasuguseid vahemikke v\u00f5i v\u00f5tmete kogumeid jagamiseks ja seadistada automaatse jagamise. Siiski on \u00fcks lihtsamaid ja t\u00f5husamaid l\u00e4henemisviise UniformSplit ja hash'i kleepimise kasutamine, n\u00e4iteks vanema paari baitidest, kus v\u00f5tme jooksutatakse l\u00e4bi CRC32(rowkey) funktsiooni ja t\u00f5elise rowkey:<\/p>\n
    hash + rowkey<\/p>\n
    Siis jagatakse k\u00f5ik andmed \u00fchtlaselt regioonide vahel. Lugemise k\u00e4igus lihtsalt visatakse esimesed kaks baitit \u00e4ra ja j\u00e4\u00e4b algne v\u00f5ti. Samuti kontrollib RS regioonis andmete ja v\u00f5tmete arvu ning \u00fcletades piirangud jagab selle automaatselt osadeks. <\/p>\n
    7. T\u00f5rketaluvus ja andmete lokaalsus<\/h2>\n
    \nKuna iga v\u00f5tme komplekti haldab ainult \u00fcks piirkond, on RS-i v\u00e4ljalangemise v\u00f5i v\u00e4ljalaskmise probleemide lahenduseks k\u00f5igi vajalike andmete salvestamine HDFS-i. Kui RS laguneb, tuvastab master selle ZooKeeperis s\u00fcdamepeatu kaudu. Siis m\u00e4\u00e4rab ta hooldatava piirkonna teisele RS-ile ja kuna HFiles on salvestatud jaotatud failis\u00fcsteemi, loeb uus omanik need v\u00e4lja ja j\u00e4tkab andmete teenindamist. Kuid kuna osa andmetest v\u00f5ib olla MemStores ja ei ole j\u00f5udnud HFilesse, kasutatakse operatsioonide ajaloo taastamiseks WAL-i, mis on samuti salvestatud HDFS-i. P\u00e4rast muudatuste pealekandmist suudab RS vastata p\u00e4ringutele, kuid \u00fcmberpaiknemine p\u00f5hjustab, et osa andmeid ja neid teenindavad protsessid paiknevad erinevates s\u00f5lmedes, st lokaalsus v\u00e4heneb. <\/p>\n
    Probleemi lahenduseks on major compaction \u2013 see protseduur liigutab faile nendele s\u00f5lmedele, mis nende eest vastutavad (seal, kus nende piirkonnad asuvad), mist\u00f5ttu suureneb selle protseduuri k\u00e4igus oluliselt v\u00f5rgu- ja kettakoormus. Siiski kiireneb hiljem juurdep\u00e4\u00e4s andmetele. Lisaks viib major_compaction k\u00f5ik HFiles kokku \u00fcheks failiks piirkonna piiresse ning puhastab andmed vastavalt tabeli seadistustele. N\u00e4iteks saab m\u00e4\u00e4rata objekti versioonide arvu, mida tuleb s\u00e4ilitada, v\u00f5i eluaega, p\u00e4rast mille m\u00f6\u00f6dumist objekt f\u00fc\u00fcsiliselt kustutatakse.<\/p>\n
    See protseduur v\u00f5ib avaldada v\u00e4ga positiivset m\u00f5ju HBase t\u00f6\u00f6le. Alloleval pildil on n\u00e4htav, kuidas j\u00f5udlus on degradeerunud aktiivse andmete kirjutamise t\u00f5ttu. N\u00e4ha on, kuidas \u00fchte tabelisse kirjutas 40 voogu ja 40 voogu luges andmeid samaaegselt. Kirjutamisvood vormivad \u00fcha rohkem ja rohkem HFiles, mida teised vood v\u00e4lja loevad. Tulemuseks on, et \u00fcha rohkem andmeid tuleb m\u00e4lust eemaldada ja l\u00f5puks hakkab t\u00f6\u00f6tama GC, mis praktiliselt halvab kogu t\u00f6\u00f6. Major compactioni k\u00e4ivitamine viis tekkinud ummikute puhastamiseni ja j\u00f5udluse taastamiseni.<\/p>\n
    \"HBase'i
    \nTest viidi l\u00e4bi 3 DataNode'i ja 4 RS-i (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 l\u00f5ime). HBase versioon 1.2.0-cdh5.14.2<\/p>\n
    Tuleb m\u00e4rkida, et major compactioni k\u00e4ivitamine toimus \u201eelavas\u201c tabelis, kuhu kirjutati ja loeti andmeid aktiivselt. Internetis kohtas v\u00e4idet, et see v\u00f5ib tuua kaasa eba\u00f5ige vastuse andmete lugemisel. Kontrollimiseks k\u00e4ivitati protsess, mis genereeris uusi andmeid ja kirjutas need tabelisse, millele j\u00e4rgnes kohene lugemine ja kontrollimine, kas saadud v\u00e4\u00e4rtus vastab sellele, mis oli kirjutatud. Selle protsessi k\u00e4igus k\u00e4ivitati umbes 200 korda major compaction ja \u00fchtegi viga ei registreeritud. V\u00f5ib-olla probleem avaldub harva ja ainult k\u00f5rge koormuse ajal, seega on ohutum siiski planeeritult peatada kirjutamis- ja lugemisprotsessid ning teostada puhastus, v\u00e4ltides selliseid GC kukkumisi.<\/p>\n
    Samuti ei m\u00f5juta major compaction MemStore'i olekut, selle kettale kirjutamiseks ja kompaktimiseks tuleb kasutada flush'i (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Seaded ja j\u00f5udlus<\/h2>\n
    \nNagu juba mainitud, saavutab HBase k\u00f5ige suurema edusammuga seal, kus tal ei ole vaja midagi teha, BulkLoad'i teostamisel. Siiski kehtib see enamikus s\u00fcsteemides ja inimeste jaoks. Kuid see t\u00f6\u00f6riist sobib pigem suurte andmepakettide massiliseks paigutamiseks, samas kui kui protsess n\u00f5uab paljude samaaegsete lugemis- ja kirjutamis\u00fclesannete t\u00e4itmist, kasutatakse \u00fclaltoodud Get ja Put k\u00e4ske. Optimaalsete parameetrite m\u00e4\u00e4ramiseks viidi l\u00e4bi katseid erinevate tabelite parameetrite ja seadistuste kombinatsioonidega:<\/p>\n