{"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 kasutamise teooria ja praktika","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere! Minu nimi on Danil Lipovoy, meie meeskond Sbertechiis on hakanud kasutama HBase'i operatiivsete andmete salvestamiseks. Selle uurimise k\u00e4igus on kogunenud teadmisi, mille tahtsime s\u00fcsteematiseerida ja kirja panna (loodame, et see on paljudele kasulik). Allpool esitatud eksperimentid viidi l\u00e4bi HBase'i versioonidega 1.2.0-cdh5.14.2 ja 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. \u00dcldine arhitektuur <\/li>\n
  2. Andmete kirjutamine HBASE'sse<\/li>\n
  3. Andmete lugemine HBASE'st<\/li>\n
  4. Andmete vahem\u00e4lu<\/li>\n
  5. Partii t\u00f6\u00f6tlemine MultiGet\/MultiPut<\/li>\n
  6. Tabelite v\u00e4ljajagamise strateegia (splitting)<\/li>\n
  7. Talitlush\u00e4ired, tihendamine ja andmete kohalikkus<\/li>\n
  8. Seaded ja j\u00f5udlus<\/li>\n
  9. Koormustestimine<\/li>\n
  10. J\u00e4reldused<\/li>\n<\/ol>\n

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

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

    \n\"HBase'i
    \nReserv Master j\u00e4lgib aktiivse s\u00f5lme ZooKeeperi heartbeat'i ja kaotuse korral v\u00f5tab meisterfunktsioonid enda kanda. <\/p>\n

    2. Andmete kirjutamine HBASE'sse<\/h2>\n

    \nAlustame k\u00f5ige lihtsamast juhtumist \u2013 v\u00f5tme-v\u00e4\u00e4rtuse objekti kirjutamine mingisse tabelisse funktsiooniga put(rowkey). Klient peab k\u00f5igepealt v\u00e4lja selgitama, kus asub juureregionaalserver (Root Region Server \u2013 RRS), mis salvestab tabeli hbase:meta. Selle teabe saab ta ZooKeeperilt. Seej\u00e4rel p\u00f6\u00f6rdub ta RRS-i poole ja loeb tabeli hbase:meta, millest ta tuvastab, milline RegionServer (RS) vastutab antud rowkey v\u00f5tme andmete salvestamise eest huvipakkuvas tabelis. Edasi, et meta-tabelit kasutada, vahem\u00e4lestab klient selle ja seega j\u00e4rgnevate p\u00e4ringute vastuv\u00f5tt toimub kiiremini, otse RS-iga.<\/p>\n

    Seej\u00e4rel kirjutab RS, saades p\u00e4ringu, k\u00f5igepealt selle WriteAheadLog'i (WAL), mis on vajalik taastamiseks, kui s\u00fcsteem peaks kokku kukkuma. Seej\u00e4rel salvestab andmed MemStore'i. See on m\u00e4lu vahem\u00e4lu, mis sisaldab antud regiooni j\u00e4rjestatud v\u00f5tmete kogumit. Tabel v\u00f5ib olla jagatud regioonideks (partitsioonideks), millest iga\u00fcks sisaldab omavahel mitte\u00fchtivaid v\u00f5tmete komplekte. See v\u00f5imaldab regioonide jagamist erinevatele serveritele, et saavutada paremat j\u00f5udlust. Kuid hoolimata selle v\u00e4ite ilmsetest eeliseid, n\u00e4eme hiljem, et see ei toimi k\u00f5igis olukordades.<\/p>\n

    P\u00e4rast salvestuse paigutamist MemStore'i naaseb kliendile vastus, et salvestus on edukalt tehtud. Sellegipoolest salvestatakse see t\u00f5eliselt ainult vahem\u00e4llu ja j\u00f5uab ketta peale alles p\u00e4rast teatud ajavahemiku m\u00f6\u00f6dumist v\u00f5i uute andmete t\u00e4itmise korral. <\/p>\n

    \"HBase'i
    \nKustutamisoperatsiooni (Delete) sooritamisel ei toimu andmete f\u00fc\u00fcsilist kustutamist. Need lihtsalt m\u00e4rgitakse kustutatuks, samas kui tegelik h\u00e4vitamine toimub major compact'i funktsiooni k\u00e4ivitamisel, millest l\u00e4hemalt r\u00e4\u00e4gitakse punktis 7.<\/p>\n

    HFile formaadis failid kogunevad HDFS-is ja aeg-ajalt k\u00e4ivitatakse minor compact'i protsess, mis lihtsalt liidab v\u00e4iksed failid suuremateks, midagi kustutamata. Aja jooksul muutub see probleemiks, mis avaldub andmete lugemisel (kust me r\u00e4\u00e4gime hiljem). <\/p>\n

    Peale eespool kirjeldatud laadimisprotsessi on olemas palju t\u00f5husam protseduur, milles seisneb t\u00f5eliselt selle andmebaasi \u00fcks tugevamaid k\u00fclgi \u2013 BulkLoad. See seisneb selles, et me ise valmistame HFiles'd ja paigutame need kettale, mis v\u00f5imaldab suurep\u00e4rast skaleerimist ja saavutada \u00fcsna h\u00e4id kiirus. Sisuliselt on piiranguks mitte HBase, vaid riistvara v\u00f5imalused. Allpool on toodud laadimistulemused klastris, mis koosneb 16 RegionServerist ja 16 NodeManager YARNist (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niiti), HBase'i versioon 1.2.0-cdh5.14.2. <\/p>\n

    \"HBase'i
    \n
    \nSiit on n\u00e4ha, et suurendades tabeli partitsioonide (regioonide) arvu, samuti Spark'i executoreid, saame laadimiskiirusel lisanduse. Samuti s\u00f5ltub kiirus kirjutamise mahust. Suured plokid annavad t\u00f5usu MB\/sekundis, v\u00e4iksed aga lisatud kirjete arvu ajas, kui k\u00f5ik muud tingimused on v\u00f5rdsed. <\/p>\n

    Samuti on v\u00f5imalik laadimist k\u00e4ivitada kahes tabelis samaaegselt ja saavutada kiirus kahekordistumine. Allpool on n\u00e4ha, et 10 KB plokkide kirjutamine kahes tabelis toimub kiirusel umbes 600 MB\/sek iga\u00fche kohta (kokku 1275 MB\/sek), mis vastab \u00fche tabeli kirjutamise kiirusel 623 MB\/sek (vt punkt 11 \u00fclal).<\/p>\n

    \"HBase'i
    \nSiiski n\u00e4itab teine k\u00e4ivitus 50 KB kirjetega, et laadimiskiirus kasvab enam-v\u00e4hem mitteolemasolevalt, mis viitab piirv\u00e4\u00e4rtuste l\u00e4henemisele. Samas tuleb arvestada, et HBASEle ei tekitata peaaegu mingeid koormusi, k\u00f5ik, mida temalt n\u00f5utakse, on k\u00f5igepealt andmete edastamine hbase:meta-st, ja p\u00e4rast HFiles'i paigaldamist andmete BlockCache'i t\u00fchjendamine ning MemStore'i vahem\u00e4lu salvestamine kettale, kui see pole t\u00fchi.<\/p>\n

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

    \nKui arvata, et kogu teave hbase:meta on klient juba olemas (vt p.2), siis saadetakse p\u00e4ring kohe sellele RS-ile, kus vajalik v\u00f5ti asub. Esmalt otsitakse MemCache'is. S\u00f5ltumata sellest, kas seal on andmeid v\u00f5i mitte, otsitakse ka BlockCache'i puhvris ja vajadusel HFailes. Kui andmed leitakse failist, paigutatakse need BlockCache'i ja j\u00e4rgmise p\u00e4ringu korral tagastatakse need kiiremini. Otsing HFailes toimub suhteliselt kiiresti, kasutades Bloom'i filtrit, mis t\u00e4hendab, et v\u00e4ikese andmemahtude lugemise korral m\u00e4\u00e4rab see kohe, kas fail sisaldab vajalikku v\u00f5tit; kui ei, siis minnakse j\u00e4rgmise juurde.<\/p>\n

    \"HBase'i
    \nSaades andmed neist kolmest allikast, koostab RS vastuse. Konkreetsemalt v\u00f5ib ta vajadusel edastada mitu leitud objekti versiooni, kui klient on n\u00f5udnud versioonide ajalugu.<\/p>\n

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

    \nMemStore ja BlockCache puhvrite maht v\u00f5ib ulatuda kuni 80% RS-i m\u00e4\u00e4ratud on-heap m\u00e4lust (\u00fclej\u00e4\u00e4nud on reserveeritud RS-i teenindavateks \u00fclesanneteks). Kui t\u00fc\u00fcpiline kasutusre\u017eiim on selline, et protsessid kirjutavad ja kohe loevad neid andmeid, siis on m\u00f5ttekas v\u00e4hendada BlockCache'i ja suurendada MemStore'i, kuna kirjutamisel ei satu andmed lugemiseks puhvri, mist\u00f5ttu BlockCache'i kasutamine toimub harvem. BlockCache'i puhver koosneb kahest osast: LruBlockCache (alati on-heap) ja BucketCache (enamasti off-heap v\u00f5i SSD-l). BucketCache'i kasutamine on otstarbekas, kui lugemisep\u00e4ringute arv on v\u00e4ga suur ja need ei mahu LruBlockCache'i, mis toob kaasa aktiivse Garbage Collector'i t\u00f6\u00f6. Siiski ei maksa oodata kiiruset\u00f5usu lugemisekahe kasutamisel, kuid selle juurde naaseme veel p. 8.<\/p>\n

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

    Kuidas detailsemalt<\/a><\/noindex> Teoorias, andmeid kirjutades ei satu need puhvri, ja t\u00f5epoolest on selle tabeli ja RS-i jaoks parameetrid CACHE_DATA_ON_WRITE seadistatud valele. Kuid praktikas, kui kirjutada andmed MemStore'i, siis seej\u00e4rel see kettale t\u00fchjendada (sellega puhastades), p\u00e4rast seda fail kustutada, saame get p\u00e4ringuga edukalt andmed. Ja isegi kui t\u00e4ielikult BlockCache keelata ja tabel uute andmetega t\u00e4ita, ning saavutada MemStore'i kirjutamine kettale, need kustutada ja teises sessioonis k\u00fcsida, t\u00f5mmatakse need ikkagi kuskilt v\u00e4lja. Nii et HBase hoiab endas mitte ainult andmeid, vaid ka salap\u00e4raseid m\u00f5istatusi.<\/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
    \nParameeter \u201eCache DATA on Read\u201c on seadistatud valele. Kui teil on ideid, on oodatud arutamiseks kommentaarides.<\/p>\n
    5. Andmete grupi t\u00f6\u00f6tlemine MultiGet\/MultiPut<\/h2>\n
    \nAinulaadsete p\u00e4ringute (Get\/Put\/Delete) t\u00f6\u00f6tlemine on \u00fcsna kulukas operatsioon, seet\u00f5ttu tuleks neid v\u00f5imaluse korral \u00fchendada Listi v\u00f5i Listiga, mis v\u00f5imaldab saavutada m\u00e4rkimisv\u00e4\u00e4rset j\u00f5udluse t\u00f5usu. Eriti puudutab see kirjutamisoperatsiooni, kuid lugemisel on j\u00e4rgmine peidul k\u00f5rvaline probleem. Alloleval graafikul on n\u00e4idatud 50 000 kirje lugemise aega MemStore'ist. Lugemine toimus \u00fches l\u00f5imes ning horisontaalsel teljel on n\u00e4idatud p\u00e4ringu v\u00f5tmete arvu. Siit on n\u00e4ha, et kui v\u00f5tmete arv \u00fche p\u00e4ringu korral suureneb tuhandeni, siis t\u00e4itmisaja v\u00e4henemine toimub, s.t. kiirus suureneb. Kuid kui vaikimisi MSLAB-re\u017eiim on sisse l\u00fclitatud, algab p\u00e4rast seda piiri \u00e4kiline j\u00f5udluse langemine, ja see tuleneb sellest, et mis rohkem andmeid salvestatakse, seda pikem on t\u00f6\u00f6tlemisaeg. <\/p>\n
    \"HBase'i
    \n
    \nTestid viidi l\u00e4bi virtuaalses masinas, 8 tuuma, HBase versioon 2.0.0-cdh6.0.0-beta1.<\/p>\n
    MSLAB re\u017eiim on m\u00f5eldud heap-i fragmenteeringute v\u00e4hendamiseks, mis tekivad uute ja vanade andmete segunemise t\u00f5ttu. Lahenduseks, kui MSLAB on sisse l\u00fclitatud, paigutatakse andmed suhteliselt v\u00e4ikestesse rakkudesse (chunk) ja t\u00f6\u00f6deldakse partii kaupa. Selle tulemusena, kui n\u00f5utud andmepaketi maht \u00fcletab m\u00e4\u00e4ratud suuruse, siis j\u00f5udlus langeb j\u00e4rsult. Teiselt poolt ei ole soovitatav selle re\u017eiimi v\u00e4ljal\u00fclitamine, kuna see toob kaasa peatuste tekkimise GC t\u00f5ttu andmeid intensiivselt t\u00f6\u00f6deldes. Heaks lahenduseks on rakendusmahu suurendamine, kui samal ajal toimub kirjutamine put-i kaudu koos lugemisega. Tasub m\u00e4rkida, et probleemi ei teki, kui p\u00e4rast kirjutamist t\u00e4ita flush k\u00e4sk, mis t\u00fchjendab MemStore kettale, v\u00f5i kui laetakse andmeid BulkLoad'i kaudu. Allolevas tabelis on n\u00e4idatud, et p\u00e4ringud suuremate andmete MemStore'ist (ja sama koguse) toovad kaasa aeglustumise. Kuid suurendades chunksize'i, saame t\u00f6\u00f6tlemise aega normaliseerida.<\/p>\n
    \"HBase'i
    \nLisaks chunksize'i suurendamisele aitab andmete jagamine piirkondade kaupa, st tabelite jagamine. See toob kaasa, et iga piirkonna jaoks tuleb v\u00e4hem p\u00e4ringuid ja kui need mahtusid rakku, j\u00e4\u00e4b vastus heaks.<\/p>\n
    6. Tabelite jagamise strateegia piirkondade kaupa (splittimine)<\/h2>\n
    \nKuna HBase on key-value salvestus ja partitsioneerimine toimub v\u00f5tme j\u00e4rgi, on \u00e4\u00e4rmiselt oluline andmeid \u00fchtlaselt k\u00f5igi piirkondade vahel jagada. N\u00e4iteks sellise tabeli partitsioneerimine kolme osaks toob kaasa, et andmed jagatakse kolme piirkonna vahel:<\/p>\n
    \"HBase'i
    \nM\u00f5nikord p\u00f5hjustab see j\u00e4rske aeglustumisi, kui edaspidi laaditavad andmed on n\u00e4iteks long v\u00e4\u00e4rtustes, mis enamasti algavad sama numbriga, n\u00e4iteks:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Kuna v\u00f5tmed salvestatakse baitide massiivina, siis k\u00f5ik nad alustavad \u00fchtmoodi ja kuuluvad \u00fchte piirkonda #1, mis hoiab seda v\u00f5tme vahemikku. On mitu jagamise strateegiat:<\/p>\n
    HexStringSplit \u2013 Muudab v\u00f5tmeks k\u00fcmnends\u00fcsteemis koodi vahemikus \"00000000\" => \"FFFFFFFF\" ja t\u00e4idab vasakult nullidega.<\/p>\n
    UniformSplit \u2013 Muudab v\u00f5tmeks baitide massiivi, mis on k\u00fcmnends\u00fcsteemis kood vahemikus \"00\" => \"FF\" ja t\u00e4idab parelt nullidega.<\/p>\n
    Samuti saab m\u00e4\u00e4rata mis tahes vahemiku v\u00f5i v\u00f5tmete kogumi jagamiseks ja seadistada autot\u00f6\u00f6stust. Siiski on \u00fcks lihtsamaid ja t\u00f5husamaid l\u00e4henemisviise UniformSplit ja hash'i \u00fchendamise kasutamine, n\u00e4iteks esimesed kaks baiti v\u00f5tme t\u00f6\u00f6tlemisel funktsiooni CRC32(rowkey) kaudu ja tegelik rowkey:<\/p>\n
    hash + rowkey<\/p>\n
    Siis jaotatakse k\u00f5ik andmed \u00fchtlaselt piirkondade vahel. Lugemisel visatakse esimesed kaks baiti lihtsalt k\u00f5rvale ja j\u00e4etakse alles algne v\u00f5ti. Samuti kontrollib RS andmete ja v\u00f5tmete arvu piirkonnas ja kui limiidid \u00fcletatakse, jagab selle automaatselt osadeks. <\/p>\n
    7. Vigade taluvus ja andmete kohalolek<\/h2>\n
    \nKuna iga v\u00f5tme seeria eest vastutab ainult \u00fcks piirkond, on RS-i v\u00f5i selle v\u00e4ljal\u00fclitamisega seotud probleemide lahenduseks k\u00f5ik vajalikud andmed hoida HDFS-is. RS-i rikke korral avastab master selle ZooKeeperis s\u00fcdametuksis oleva s\u00f5lme kaudu. Siis m\u00e4\u00e4rab ta hallatava piirkonna teisele RS-ile ja kuna HFiles salvestatakse jaotatud failis\u00fcsteemi, loeb uus peremees need v\u00e4lja ja j\u00e4tkab andmete teenindamist. Kuid kuna osa andmeid v\u00f5ib olla MemStore'is ja pole veel HFilesisse j\u00f5udnud, kasutatakse toimingute ajaloos WAL-i, mis samuti hoitakse HDFS-is. P\u00e4rast muudatuste elluviimist suudab RS p\u00e4ringutele vastata, kuid liikumine viib selleni, et osa andmeid ja nende teenindamise protsessid asuvad erinevates s\u00f5lmedes, st lokaliteed v\u00e4hendatakse. <\/p>\n
    Probleemi lahenduseks on major compaction \u2013 see protseduur viib failid nende s\u00f5lmedesse, mis nende eest vastutavad (seal, kus nende piirkonnad asuvad), mille tulemusena suureneb selle protseduuri ajal j\u00e4rsult koormus v\u00f5rku ja kettale. Kuid edaspidi kiireneb juurdep\u00e4\u00e4s andmetele oluliselt. Lisaks teostab major_compaction k\u00f5igi HFiles'ide \u00fchendamist \u00fcheks failiks piirkonna raames ja puhastab andmeid tabeli seadistuste j\u00e4rgi. N\u00e4iteks v\u00f5ib m\u00e4\u00e4rata objekti versioonide arvu, mida tuleb s\u00e4ilitada, v\u00f5i selle eluiga, p\u00e4rast mille m\u00f6\u00f6dumist objekt f\u00fc\u00fcsiliselt eemaldatakse.<\/p>\n
    See protseduur v\u00f5ib positiivselt m\u00f5jutada HBase'i toimimist. Allolev pilt n\u00e4itab, kuidas j\u00f5udlus halvenes aktiivsete andmete kirjutamise t\u00f5ttu. N\u00e4ha on, kuidas \u00fchte tabelisse kirjutas 40 haru ja 40 haru luges andmeid samal ajal. Kirjutavad harud genereerisid \u00fcha rohkem HFiles'e, mida lugesid teised harud. tulemuseks on see, et j\u00e4rjest rohkem andmeid on vajalik m\u00e4lust eemaldada ja l\u00f5puks hakkab t\u00f6\u00f6le GC, mis praktiliselt halvab kogu t\u00f6\u00f6. Major compactioni k\u00e4ivitamine viis kogunenud segaduse puhastamiseni ja j\u00f5udluse taastamiseni.<\/p>\n
    \"HBase'i
    \nTest viidi l\u00e4bi 3 DataNode'i ja 4 RS-i peal (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 haru). HBase'i versioon 1.2.0-cdh5.14.2<\/p>\n
    On oluline m\u00e4rkida, et major compaction viidi l\u00e4bi \"elava\" tabeli peal, kuhu kirjutati ja loeti aktiivselt andmeid. V\u00f5rgus esines v\u00e4iteid, et see v\u00f5ib p\u00f5hjustada vale vastust andmete lugemise ajal. Kontrollimiseks k\u00e4ivitati protsess, mis genereeris uusi andmeid ja kirjutas need tabelisse. Seej\u00e4rel loeti kohe ja v\u00f5rreldi, kas saadud v\u00e4\u00e4rtus kattus salvestatuga. Selle protsessi k\u00e4igus k\u00e4ivitati umbes 200 korda major compaction ja mitte \u00fchtegi riket ei registreeritud. Probleem v\u00f5ib ilmneda harva ja ainult k\u00f5rgete koormuste korral, seega on siiski turvalisem plaane teha, peatades kirjutamise ja lugemise protsessid ning teostada puhastust, v\u00e4ltides nii GC languseid.<\/p>\n
    Samuti ei m\u00f5juta major compaction MemStore'i seisukorda, et selle andmeid kettale kirjutada ja kompaktida, tuleb kasutada flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Seaded ja j\u00f5udlus<\/h2>\n
    \nNagu juba mainitud, on HBase k\u00f5ige edukam seal, kus tal pole vaja midagi teha, BulkLoad'i teostamisel. Kuid see kehtib enamiku s\u00fcsteemide ja inimeste kohta. Siiski sobib see t\u00f6\u00f6riist pigem andmete massiliseks salvestamiseks suurtel blokkidel, samas kui, kui protsess n\u00f5uab paljude konkurentsiv\u00f5imeliste lugemise ja kirjutamise p\u00e4ringute t\u00e4itmist, kasutatakse \u00fclalnimetatud Get ja Put k\u00e4ske. Optimaalsete parameetrite m\u00e4\u00e4ramiseks viidi l\u00e4bi katseid erinevate tabeli parameetrite ja seadistuste kombinatsioonide korral:<\/p>\n