{"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\/hr\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Teorija i praksa kori\u0161tenja HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dobar dan! Zovem se Danil Lipovoy, na\u0161 tim u Sbertechu po\u010deo je koristiti HBase kao skladi\u0161te operativnih podataka. Tijekom njegovog istra\u017eivanja stekli smo iskustvo koje \u017eelimo sistematizirati i opisati (nadamo se da \u0107e mnogima biti korisno). Svi eksperimenta navedeni u nastavku provedeni su s verzijama HBase 1.2.0-cdh5.14.2 i 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. Sveobuhvatna arhitektura <\/li>\n
  2. Upis podataka u HBASE<\/li>\n
  3. \u010citanje podataka iz HBASE<\/li>\n
  4. Ke\u0161iranje podataka<\/li>\n
  5. Batch obrada podataka MultiGet\/MultiPut<\/li>\n
  6. Strategija dijeljenja tablica na regije (splitting)<\/li>\n
  7. Otpornost na gre\u0161ke, kompaktiranje i lokalnost podataka<\/li>\n
  8. Postavke i performanse<\/li>\n
  9. Testiranje optere\u0107enja<\/li>\n
  10. Zaklju\u010dci<\/li>\n<\/ol>\n

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

    1. Sveobuhvatna arhitektura<\/h2>\n

    \n\"Teorija
    \nRezervni Master slu\u0161a heartbeat aktivnog na \u010dvoru ZooKeeper i u slu\u010daju nestanka preuzima funkcije mastera. <\/p>\n

    2. Upis podataka u HBASE<\/h2>\n

    \nPrvo razmotrite najjednostavniji slu\u010daj \u2013 upis objekta klju\u010d-vrijednost u neku tablicu koriste\u0107i put(rowkey). Klijent prvo mora otkriti gdje se nalazi korijenski regijski poslu\u017eitelj (Root Region Server - RRS), koji pohranjuje tablicu hbase:meta. Te informacije dobiva od ZooKeepera. Nakon toga obra\u0107a se RRS-u i \u010dita tablicu hbase:meta, iz koje izdvaja informacije o tome koji RegionServer (RS) odgovara za pohranu podataka po zadanom klju\u010du rowkey u tablici koja ga zanima. U svrhu daljnje upotrebe, meta-tablica se ke\u0161ira od strane klijenta, stoga su sljede\u0107i zahtjevi br\u017ei, izravno prema RS-u.<\/p>\n

    Nakon \u0161to RS primi zahtjev, prvo ga zapisuje u WriteAheadLog (WAL), \u0161to je potrebno za oporavak u slu\u010daju pada. Zatim pohranjuje podatke u MemStore. Ovo je predmemorija u memoriji koja sadr\u017ei sortirani set klju\u010deva za ovu regiju. Tablica mo\u017ee biti podijeljena na regije (particije), od kojih svaka sadr\u017ei nepoklapaju\u0107i set klju\u010deva. To omogu\u0107ava, raspore\u0111uju\u0107i regije na razli\u010ditim poslu\u017eiteljima, postizanje ve\u0107e performanse. Me\u0111utim, unato\u010d o\u010ditosti ove tvrdnje, vidjet \u0107emo da to ne funkcionira u svim slu\u010dajevima.<\/p>\n

    Nakon \u0161to se zapis pohrani u MemStore, klijent dobiva odgovor da je zapis uspje\u0161no spremljen. Pri tome se stvarno pohranjuje samo u predmemoriji i bit \u0107e na disku tek nakon \u0161to pro\u0111e neki vremenski interval ili kada se napuni novim podacima. <\/p>\n

    \"Teorija
    \nPrilikom izvo\u0111enja operacije \u00abDelete\u00bb, fizi\u010dko brisanje podataka se ne doga\u0111a. Oni su samo ozna\u010deni kao obrisani, dok se samo uni\u0161tavanje doga\u0111a u trenutku pozivanja funkcije major compact, o kojoj je vi\u0161e napisano u to\u010dki 7.<\/p>\n

    Datoteke u formatu HFile se sakupljaju u HDFS-u i s vremena na vrijeme pokre\u0107e se proces minor compact, koji jednostavno spaja male datoteke u ve\u0107e, ne bri\u0161u\u0107i ni\u0161ta. S vremenom to postaje problem koji se manifestira samo prilikom \u010ditanja podataka (o \u010demu \u0107emo se kasnije vratiti). <\/p>\n

    Osim gornjeg opisanog procesa u\u010ditavanja, postoji mnogo u\u010dinkovitija procedura, koja je mo\u017eda najja\u010da strana ove baze podataka \u2013 BulkLoad. To podrazumijeva da sami formiramo HFiles i stavimo ih na disk, \u0161to omogu\u0107ava izvrsno skaliranje i postizanje vrlo dobrih brzina. U su\u0161tini, ograni\u010denje ovdje nije HBase, ve\u0107 mogu\u0107nosti hardvera. U nastavku su prikazani rezultati u\u010ditavanja na klasteru koji se sastoji od 16 RegionServera i 16 NodeManager YARN-a (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niti), verzija HBase 1.2.0-cdh5.14.2. <\/p>\n

    \"Teorija
    \n
    \nOvdje se mo\u017ee vidjeti da pove\u0107anjem broja particija (regija) u tablici, kao i izvr\u0161itelja Sparka, dobivamo pove\u0107anje brzine u\u010ditavanja. Tako\u0111er, brzina ovisi o volumenu zapisa. Veliki blokovi daju pove\u0107anje u mjerenju MB\/s, dok manji pove\u0107avaju broj umetnutih zapisa u jedinici vremena, pri ostalim jednakim uvjetima. <\/p>\n

    Tako\u0111er je mogu\u0107e pokrenuti u\u010ditavanje u dvije tablice istovremeno i dobiti udvostru\u010denje brzine. Ispod je vidljivo da zapisi blokova od 10 KB odjednom u dvije tablice idu brzinom od oko 600 Mb\/s u svaku (ukupno 1275 Mb\/s), \u0161to odgovara brzini zapisivanja u jednu tablicu od 623 MB\/s (vidi br. 11 iznad).<\/p>\n

    \"Teorija
    \nMe\u0111utim, drugi poku\u0161aj s zapisima od 50 KB pokazuje da brzina u\u010ditavanja raste neznatno, \u0161to ukazuje na pribli\u017eavanje grani\u010dnim vrijednostima. Pri tome treba imati na umu da na sam HBASE ovdje prakti\u010dki nema optere\u0107enja, sve \u0161to se od njega zahtijeva je prvo predati podatke iz hbase:meta, a nakon umetanja HFiles, isprazniti podatke BlockCache i sa\u010duvati MemStore buffer na disk, ako nije prazan.<\/p>\n

    3. \u010citanje podataka iz HBASE<\/h2>\n

    \nAko se uzme u obzir da klijent ve\u0107 ima sve informacije iz hbase:meta (pogledajte to\u010dku 2), upit ide odmah na taj RS gdje se nalazi odgovaraju\u0107i klju\u010d. Prvo se pretra\u017euje u MemCache. Bez obzira na to jesu li podaci prisutni ili ne, pretra\u017eivanje se tako\u0111er vr\u0161i u bufferu BlockCache i, po potrebi, u HFiles. Ako su podaci prona\u0111eni u datoteci, stavljaju se u BlockCache i pri sljede\u0107em upitu bit \u0107e vra\u0107eni br\u017ee. Pretra\u017eivanje u HFileu se odvija relativno brzo zahvaljuju\u0107i upotrebi Bloom filtera, tj. \u010ditanjem malog volumena podataka odmah se utvr\u0111uje sadr\u017ei li ta datoteka potrebni klju\u010d, a ako ne, prelazi se na sljede\u0107i.<\/p>\n

    \"Teorija
    \nNakon \u0161to prikupi podatke iz ova tri izvora, RS formira odgovor. Konkretno, mo\u017ee odmah poslati nekoliko prona\u0111enih verzija objekta ukoliko je klijent zatra\u017eio verzioniranje.<\/p>\n

    4. Ke\u0161iranje podataka<\/h2>\n

    \nMemStore i BlockCache bufferi zauzimaju do 80% dodijeljene on-heap memorije RS-a (ostatak je rezerviran za servisne zadatke RS-a). Ako je tipi\u010dan na\u010din kori\u0161tenja takav da procesi najprije pi\u0161u, a zatim odmah \u010ditaju iste podatke, onda ima smisla smanjiti BlockCache i pove\u0107ati MemStore, jer kod pisanja podaci ne ulaze u ke\u0161 za \u010ditanje, pa \u0107e se kori\u0161tenje BlockCache-a dogoditi rje\u0111e. BlockCache buffer se sastoji od dva dijela: LruBlockCache (uvijek on-heap) i BucketCache (obi\u010dno off-heap ili na SSD-u). BucketCache treba koristiti kada ima puno upita za \u010ditanje i kada ne stanu u LruBlockCache, \u0161to dovodi do aktivnog rada Garbage Collector-a. Me\u0111utim, ne treba o\u010dekivati radikalan porast performansi pri kori\u0161tenju ke\u0161a za \u010ditanje, ali o tome \u0107emo se jo\u0161 osvrnuti u to\u010dki 8.<\/p>\n

    \"Teorija
    \nBlockCache je jedan za cijeli RS, dok je MemStore svoj za svaku tablicu (po jedan za svaki Column Family).<\/p>\n

    Kako je opisano<\/a><\/noindex> Teoretski, kod pisanja podaci ne ulaze u ke\u0161 i doista su takvi parametri CACHE_DATA_ON_WRITE za tablicu i 'Cache DATA on Write' za RS postavljeni na false. No, u praksi, ako se podaci zapisuju u MemStore, zatim se prebace na disk (tako ga o\u010diste), pa se dobivena datoteka ukloni, nakon \u010dega izvr\u0161avanje get upita uspje\u0161no vra\u0107a podatke. \u010cak i ako se potpuno isklju\u010di BlockCache i napuni tablica novim podacima, a zatim se postigne da se MemStore prebaci na disk, njihovim uklanjanjem i upitom iz druge sesije, oni \u0107e se i dalje negdje izvu\u0107i. Tako da HBase u sebi ne dr\u017ei samo podatke, ve\u0107 i tajanstvene zagonetke.<\/p>\n

    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\n<\/code><\/pre>\n
    \nParametar \"Cache DATA on Read\" postavljen je na false. Ako imate ideje, slobodno ih podijelite u komentarima.<\/p>\n
    5. Obrada podataka MultiGet\/MultiPut<\/h2>\n
    \nObrada pojedina\u010dnih zahtjeva (Get\/Put\/Delete) je prili\u010dno skupa operacija, stoga je po\u017eeljno grupirati ih u List ili List, \u0161to omogu\u0107ava zna\u010dajno pove\u0107anje performansi. To se posebno odnosi na operacije zapisivanja, dok pri \u010ditanju postoji sljede\u0107a zamka. Na grafikonu ispod prikazano je vrijeme \u010ditanja 50 000 zapisa iz MemStore-a. \u010citanje je obavljeno u jednom niti, a na horizontalnoj osi prikazani su broj klju\u010deva u zahtjevu. Ovdje se vidi da se s pove\u0107anjem na tisu\u0107u klju\u010deva u jednom zahtjevu vrijeme izvr\u0161enja smanjuje, tj. brzina se pove\u0107ava. Me\u0111utim, kada je zadani na\u010din MSLAB uklju\u010den, nakon ovog praga po\u010dinje radikalno opadanje performansi, a \u0161to je ve\u0107i volumen podataka u zapisu, to je du\u017ee vrijeme rada. <\/p>\n
    \"Teorija
    \n
    \nTestovi su provedeni na virtualnoj ma\u0161ini, 8 jezgri, verzija HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    Na\u010din MSLAB je osmi\u0161ljen da smanji fragmentaciju heap-a, koja nastaje zbog mije\u0161anja podataka novih i starih generacija. Kao rje\u0161enje problema, kada je MSLAB uklju\u010den, podaci se stavljaju u relativno male \u0107elije (chunk) i obra\u0111uju se u porcijama. Kao rezultat, kada volumen u zatra\u017eenom paketu podataka prema\u0161uje dodijeljenu veli\u010dinu, performanse drasti\u010dno padaju. S druge strane, isklju\u010divanje ovog na\u010dina tako\u0111er nije po\u017eeljno, jer \u0107e dovesti do zastoja zbog GC-a u trenucima intenzivnog rada s podacima. Dobar izlaz je pove\u0107anje volumena \u0107elije, u slu\u010daju aktivnog zapisivanja putem putanja zajedno s \u010ditanjem. Va\u017eno je napomenuti da problem ne nastaje ako nakon zapisivanja izvr\u0161ite naredbu flush koja prebacuje MemStore na disk ili ako se izvr\u0161ava u\u010ditavanje pomo\u0107u BulkLoad-a. U tablici ispod prikazano je da zahtjevi iz MemStore-a s ve\u0107im volumenom podataka (i istim brojem) dovode do usporavanja. Me\u0111utim, pove\u0107anjem chunksize-a vra\u0107amo vrijeme obrade u normalu.<\/p>\n
    \"Teorija
    \nOsim pove\u0107anja chunksizea, poma\u017ee i fragmentacija podataka po regijama, tj. splitanje tablica. To dovodi do toga da za svaku regiju dolazi manji broj zahtjeva, a ako se uklapaju u \u0107eliju, odgovor ostaje dobar.<\/p>\n
    6. Strategija dijeljenja tablica na regije (splitanje)<\/h2>\n
    \nBudu\u0107i da je HBase skladi\u0161te klju\u010d-vrijednost i particioniranje se provodi prema klju\u010du, izuzetno je va\u017eno ravnomjerno razdijeliti podatke po svim regijama. Na primjer, particioniranje takve tablice na tri dijela dovest \u0107e do razdvajanja podataka u tri regije:<\/p>\n
    \"Teorija
    \nPonekad to dovodi do naglog usporavanja, ako u\u010ditani podaci kasnije imaju oblik, na primjer, long vrijednosti ve\u0107inom po\u010dinju\u0107i istom brojkom, kao \u0161to su:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Budu\u0107i da se klju\u010devi pohranjuju u obliku niza bajtova, svi \u0107e po\u010deti jednako i pripadati jednoj regiji #1 koja pohranjuje taj raspon klju\u010deva. Postoji nekoliko strategija dijeljenja:<\/p>\n
    HexStringSplit \u2013 Pretvara klju\u010d u niz s heksadecimalnim kodiranjem u rasponu \u201e00000000\u201d => \u201eFFFFFFFF\u201d i puni lijevo nulama.<\/p>\n
    UniformSplit \u2013 Pretvara klju\u010d u niz bajtova s heksadecimalnim kodiranjem u rasponu \u201e00\u201d => \u201eFF\u201d i puni desno nulama.<\/p>\n
    Osim toga, mo\u017eete odrediti bilo koji raspon ili skup klju\u010deva za dijeljenje i postaviti automatsko splitanje. Me\u0111utim, jedan od najjednostavnijih i naju\u010dinkovitijih pristupa je UniformSplit i kori\u0161tenje konkatelacije hasha, na primjer, najstarijeg para bajtova kroz funkciju CRC32(rowkey) i samog rowkeya:<\/p>\n
    hash + rowkey<\/p>\n
    Tada \u0107e svi podaci biti ravnomjerno raspore\u0111eni po regijama. Pri \u010ditanju prva dva bajta jednostavno se odbacuju i ostaje izvorni klju\u010d. Tako\u0111er, RS kontrolira koli\u010dinu podataka i klju\u010deva u regiji i kada se prekora\u010de limiti, automatski ih dijeli na dijelove. <\/p>\n
    7. Otpornost na gre\u0161ke i lokalnost podataka<\/h2>\n
    \nBudu\u0107i da svaki skup klju\u010deva pripada samo jednoj regiji, rje\u0161enje za probleme povezane s padovima RS-a ili isklju\u010divanjem je pohranjivanje svih potrebnih podataka u HDFS. Kada do\u0111e do pada RS-a, master to otkriva putem nedostatka heartbeat-a na \u010dvoru ZooKeeper. Tada imenuje novog RS-a za upravljanje regijom, a budu\u0107i da su HFiles pohranjeni u distribuiranom datote\u010dnom sustavu, novi vlasnik ih \u010dita i nastavlja upravljati podacima. Me\u0111utim, budu\u0107i da dio podataka mo\u017ee biti u MemStore-u i nije stigao u HFiles, za obnavljanje povijesti operacija koristi se WAL, koji se tako\u0111er pohranjuje u HDFS. Nakon primjene promjena, RS je sposoban odgovarati na zahtjeve, no premje\u0161taj dovodi do toga da dio podataka i procesi koji ih obra\u0111uju zavr\u0161avaju na razli\u010ditim \u010dvorovima, tj. smanjuje se lokalnost. <\/p>\n
    Rje\u0161enje problema je major compaction \u2013 ova procedura premje\u0161ta datoteke na one \u010dvorove koji su odgovorni za njih (gdje se nalaze njihove regije), pri \u010demu u toku ove procedure naglo raste optere\u0107enje mre\u017ee i diskova. Me\u0111utim, kasnije je pristup podacima znatno br\u017ei. Osim toga, major_compaction spaja sve HFiles u jedan datoteku unutar regije, te tako\u0111er \u010disti podatke u skladu s postavkama tablice. Na primjer, mogu\u0107e je odrediti koliko verzija objekta treba zadr\u017eati ili vrijeme njegovog trajanja, nakon kojeg se objekt fizi\u010dki bri\u0161e.<\/p>\n
    Ova procedura mo\u017ee imati vrlo pozitivan utjecaj na rad HBase-a. Na slici ispod vidljivo je kako je performansa degradirala zbog aktivnog zapisivanja podataka. Ovdje se vidi kako je 40 niti pisalo u jednu tablicu, dok je 40 niti istovremeno \u010ditalo podatke. Niti za pisanje stvaraju sve vi\u0161e i vi\u0161e HFiles, koje druge niti \u010ditaju. Kao rezultat, sve vi\u0161e podataka mora se ukloniti iz memorije i na kraju po\u010dinje raditi GC, koji prakti\u010dki paralizira cijeli rad. Pokretanje major compaction-a dovelo je do \u010di\u0161\u0107enja nastalih nagomilavanja i obnavljanja performansi.<\/p>\n
    \"Teorija
    \nTest je proveden na 3 DataNode-a i 4 RS-a (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niti). Verzija HBase-a 1.2.0-cdh5.14.2<\/p>\n
    Va\u017eno je napomenuti da je major compaction pokrenut na '\u017eivom' tabeli, u koju se aktivno upisivalo i o\u010ditavalo podatke. Na internetu se pojavila tvrdnja da to mo\u017ee dovesti do neto\u010dnih odgovora prilikom o\u010ditavanja podataka. Za provjeru, pokrenut je proces koji je generirao nove podatke i upisivao ih u tabelu, a zatim ih odmah o\u010ditavao i uspore\u0111ivao da li se dobivena vrijednost poklapa s onom koja je zapisana. Tokom rada ovog procesa major compaction je pokrenut oko 200 puta i nije zabilje\u017een nijedan kvar. Mogu\u0107e je da se problem pojavljuje samo rijetko i tokom velike optere\u0107enosti, stoga je ipak sigurnije planirano zaustavljanje procesa pisanja i o\u010ditavanja te izvo\u0111enje \u010di\u0161\u0107enja bez bogatih GC optere\u0107enja.<\/p>\n
    Tako\u0111er, major compaction ne utje\u010de na stanje MemStore-a; za njegovo prebacivanje na disk i kompaktiranje potrebno je koristiti flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Postavke i performanse<\/h2>\n
    \nKao \u0161to je ve\u0107 re\u010deno, HBase pokazuje najve\u0107i uspjeh kada nema drugih zadataka za obaviti tijekom izvo\u0111enja BulkLoad-a. Ipak, to se odnosi na ve\u0107inu sistema i ljudi. Me\u0111utim, ovaj alat vi\u0161e odgovara masovnom postavljanju podataka u velikim blokovima, dok se za procese koji zahtijevaju izvr\u0161enje brojnih konkurentnih o\u010ditavanja i pisanja koriste gore opisane komande Get i Put. Kako bi se odredile optimalne parametre, izvedena su pokretanja uz razli\u010dite kombinacije parametara tabela i postavki:<\/p>\n