{"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\/ro\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Teoria \u0219i practica utiliz\u0103rii HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bun\u0103 ziua! M\u0103 numesc Danil Lipovoy, echipa noastr\u0103 de la Sbertech a \u00eenceput s\u0103 foloseasc\u0103 HBase ca stocare pentru datele opera\u021bionale. \u00cen timpul studierii sale, am acumulat experien\u021b\u0103 pe care am dorit s\u0103 o sistematiz\u0103m \u0219i s\u0103 o descriem (sper\u0103m c\u0103 va fi util\u0103 multora). Toate experimentele de mai jos au fost efectuate cu versiunile HBase 1.2.0-cdh5.14.2 \u0219i 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. Arhitectura general\u0103 <\/li>\n
  2. Scrierea datelor \u00een HBASE<\/li>\n
  3. Citirea datelor din HBASE<\/li>\n
  4. Cache-ul de date<\/li>\n
  5. Procesarea \u00een lot a datelor MultiGet\/MultiPut<\/li>\n
  6. Strategia de fragmentare a tabelelor \u00een regiuni (splitting)<\/li>\n
  7. Toleran\u021ba la erori, compactarea \u0219i localitatea datelor<\/li>\n
  8. Configur\u0103ri \u0219i performan\u021b\u0103<\/li>\n
  9. Testare de \u00eenc\u0103rcare<\/li>\n
  10. Conclusions<\/li>\n<\/ol>\n

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

    1. Arhitectura general\u0103<\/h2>\n

    \n\"Teoria
    \nMasterul de rezerv\u0103 ascult\u0103 heartbeat-ul masterului activ pe nodul ZooKeeper \u0219i, \u00een cazul dispari\u021biei acestuia, preia func\u021biile masterului. <\/p>\n

    2. Scrierea datelor \u00een HBASE<\/h2>\n

    \nMai \u00eent\u00e2i, s\u0103 lu\u0103m \u00een considerare cel mai simplu caz \u2013 scrierea unui obiect cheie-valoare \u00eentr-o anumit\u0103 tabel\u0103 folosind put(rowkey). Clientul trebuie s\u0103 afle mai \u00eent\u00e2i unde se afl\u0103 serverul de regiune r\u0103d\u0103cin\u0103 (Root Region Server \u2014 RRS), care stocheaz\u0103 tabela hbase:meta. Informa\u021bia aceasta o ob\u021bine de la ZooKeeper. Apoi se adreseaz\u0103 RRS-ului \u0219i cite\u0219te tabela hbase:meta, din care extrage informa\u021bia despre care RegionServer (RS) este responsabil pentru stocarea datelor pentru cheia rowkey dat\u0103 \u00een tabela care \u00eel intereseaz\u0103. \u00cen scopul utiliz\u0103rii ulterioare, tabela meta este cached de c\u0103tre client \u0219i, prin urmare, apelurile urm\u0103toare se desf\u0103\u0219oar\u0103 mai rapid, direct c\u0103tre RS.<\/p>\n

    Apoi, RS-ul, primind cererea, mai \u00eent\u00e2i o scrie \u00een WriteAheadLog (WAL), ceea ce este necesar pentru recuperare \u00een caz de c\u0103dere. Apoi, datele sunt salvate \u00een MemStore. Acesta este un buffer \u00een memorie care con\u021bine un set ordonat de chei ale acestei regiuni. Tabela poate fi divizat\u0103 \u00een regiuni (parti\u021bii), fiecare av\u00e2nd un set de chei ne\u00eencruci\u0219at. Acest lucru permite ca, plas\u00e2nd regiunile pe servere diferite, s\u0103 se ob\u021bin\u0103 o performan\u021b\u0103 mai bun\u0103. Cu toate acestea, \u00een ciuda eviden\u021bei acestei afirma\u021bii, vom vedea mai departe c\u0103 nu func\u021bioneaz\u0103 \u00een toate cazurile.<\/p>\n

    Dup\u0103 ce \u00eenregistrarea a fost plasat\u0103 \u00een MemStore, clientului i se returneaz\u0103 un r\u0103spuns c\u0103 \u00eenregistrarea a fost salvat\u0103 cu succes. Aceasta este, de fapt, stocat\u0103 doar \u00een buffer \u0219i va ajunge pe disc doar dup\u0103 ce va trece un anumit interval de timp sau c\u00e2nd va fi umplut cu date noi. <\/p>\n

    \"Teoria
    \nAt the execution of the 'Delete' operation, physical data deletion does not occur. They are simply marked as deleted, while the actual destruction takes place at the moment the major compact function is called, which is described in detail in section 7.<\/p>\n

    Files in HFile format accumulate in HDFS, and from time to time, a minor compact process is triggered, which merely merges small files into larger ones without deleting anything. Over time, this turns into a problem that only manifests during data reading (we will return to this shortly). <\/p>\n

    In addition to the loading process mentioned above, there is a much more efficient procedure, which arguably represents the strongest aspect of this database \u2013 BulkLoad. This involves manually creating HFiles and placing them on the disk, which allows for excellent scalability and achieving quite impressive speeds. Essentially, the limitation here is not HBase, but the hardware capabilities. Below are the loading results on a cluster consisting of 16 RegionServers and 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), HBase version 1.2.0-cdh5.14.2. <\/p>\n

    \"Teoria
    \n
    \nHere, it is evident that increasing the number of partitions (regions) in the table, as well as Spark executors, results in an increase in loading speed. Speed also depends on the volume of the write operation. Large blocks yield increases measured in MB\/sec, while small ones increase the number of inserted records per unit of time, with other factors being equal. <\/p>\n

    It is also possible to initiate loading into two tables simultaneously, which can double the speed. Below it is shown that writing 10 KB blocks simultaneously into two tables occurs at a speed of around 600 MB\/sec each (totaling 1275 MB\/sec), which corresponds to the writing speed into one table of 623 MB\/sec (see No. 11 above).<\/p>\n

    \"Teoria
    \nHowever, the second run with 50 KB records shows that the loading speed increases only slightly, indicating that we are approaching the limits. It should be noted that there is practically no load on HBASE itself; all that is required from it is to first deliver data from hbase:meta, and after placing HFiles, flush the BlockCache data and save the MemStore buffer to disk, if it is not empty.<\/p>\n

    3. Reading data from HBASE<\/h2>\n

    \nDac\u0103 presupunem c\u0103 toat\u0103 informa\u021bia din hbase:meta este deja disponibil\u0103 clientului (vezi p. 2), atunci cererea se trimite direct c\u0103tre RS-ul unde este stocat cheia dorit\u0103. Mai \u00eent\u00e2i, c\u0103utarea se desf\u0103\u0219oar\u0103 \u00een MemCache. Indiferent dac\u0103 datele sunt disponibile sau nu, c\u0103utarea se efectueaz\u0103 \u0219i \u00een bufferul BlockCache \u0219i, dac\u0103 este necesar, \u00een HFiles. Dac\u0103 datele sunt g\u0103site \u00een fi\u0219ier, ele sunt plasate \u00een BlockCache \u0219i la urm\u0103toarea cerere vor fi returnate mai repede. C\u0103utarea \u00een HFile se desf\u0103\u0219oar\u0103 relativ rapid datorit\u0103 utiliz\u0103rii filtrului Bloom, adic\u0103, citind un volum mic de date, se determin\u0103 imediat dac\u0103 acest fi\u0219ier con\u021bine cheia dorit\u0103 \u0219i, dac\u0103 nu, se trece la urm\u0103torul.<\/p>\n

    \"Teoria
    \nDup\u0103 ob\u021binerea datelor din aceste trei surse, RS-ul formeaz\u0103 un r\u0103spuns. \u00cen special, poate transmite mai multe versiuni g\u0103site ale obiectului, dac\u0103 clientul a solicitat versionare.<\/p>\n

    4. Cache-ul de date<\/h2>\n

    \nBuffer-ele MemStore \u0219i BlockCache ocup\u0103 p\u00e2n\u0103 la 80% din memoria on-heap alocat\u0103 pentru RS (restul este rezervat pentru sarcini de servicii ale RS-ului). Dac\u0103 modul tipic de utilizare este c\u0103 procesele scriu \u0219i citesc imediat aceste date, are sens s\u0103 se reduc\u0103 BlockCache \u0219i s\u0103 se creasc\u0103 MemStore, av\u00e2nd \u00een vedere c\u0103, la scriere, datele nu ajung \u00een cache-ul de citire, astfel utilizarea BlockCache-ului va fi mai rar\u0103. Buffer-ul BlockCache este compus din dou\u0103 p\u0103r\u021bi: LruBlockCache (\u00eentotdeauna on-heap) \u0219i BucketCache (de obicei off-heap sau pe SSD). Este recomandat s\u0103 utiliza\u021bi BucketCache atunci c\u00e2nd exist\u0103 foarte multe cereri de citire \u0219i acestea nu se \u00eencadreaz\u0103 \u00een LruBlockCache, ceea ce duce la o activitate intens\u0103 a Garbage Collector-ului. Totu\u0219i, nu ar trebui s\u0103 a\u0219tepta\u021bi o cre\u0219tere radical\u0103 a performan\u021bei din utilizarea cache-ului de citire, dar la acest subiect ne vom \u00eentoarce \u00een p. 8.<\/p>\n

    \"Teoria
    \nBlockCache-ul este comun pentru \u00eentreg RS-ul, iar MemStore-ul este specific fiec\u0103rei tabele (c\u00e2te unul pentru fiecare Column Family).<\/p>\n

    Cum este descris<\/a><\/noindex> Teoretic, la scriere, datele nu ajung \u00een cache \u0219i \u00eentr-adev\u0103r, parametrii CACHE_DATA_ON_WRITE pentru tabel\u0103 \u0219i \u201eCache DATA on Write\u201d pentru RS sunt seta\u021bi pe false. Cu toate acestea, \u00een practic\u0103, dac\u0103 scrie\u021bi date \u00een MemStore, apoi le salva\u021bi pe disc (astfel cur\u0103\u021b\u00e2ndu-l), apoi \u0219terge\u021bi fi\u0219ierul rezultat, atunci, efectu\u00e2nd o cerere get, vom ob\u021bine cu succes datele. Chiar \u0219i dac\u0103 dezactiva\u021bi complet BlockCache \u0219i umple\u021bi tabelul cu date noi, apoi reu\u0219i\u021bi s\u0103 salva\u021bi MemStore-ul pe disc, s\u0103 le \u0219terge\u021bi \u0219i s\u0103 solicita\u021bi dintr-o alt\u0103 sesiune, acestea vor fi extrase totu\u0219i din undeva. A\u0219adar, HBase stocheaz\u0103 nu doar date, ci \u0219i mistere fascinante.<\/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
    \nParametrul \u201eCache DATA on Read\u201d este setat pe false. Dac\u0103 ave\u021bi sugestii, v\u0103 rug\u0103m s\u0103 le discuta\u021bi \u00een comentarii.<\/p>\n
    5. Procesarea \u00een loturi a datelor MultiGet\/MultiPut<\/h2>\n
    \nProcesarea cererilor individuale (Get\/Put\/Delete) este o opera\u021biune destul de costisitoare, a\u0219a c\u0103 ar trebui s\u0103 le combin\u0103m, dac\u0103 este posibil, \u00eentr-o List sau List, ceea ce permite ob\u021binerea unui c\u00e2\u0219tig semnificativ de performan\u021b\u0103. Acest lucru este deosebit de important \u00een cazul opera\u021biunilor de scriere, iar \u00een ceea ce prive\u0219te citirea, exist\u0103 un alt obstacol. \u00cen graficul de mai jos este prezentat timpul necesar pentru citirea a 50.000 de \u00eenregistr\u0103ri din MemStore. Citirea a fost efectuat\u0103 pe un singur fir, iar pe axa orizontal\u0103 este ar\u0103tat num\u0103rul de chei \u00een cerere. Se poate observa c\u0103, atunci c\u00e2nd num\u0103rul de chei \u00eentr-o cerere ajunge la o mie, timpul de execu\u021bie scade, adic\u0103 viteza cre\u0219te. Cu toate acestea, \u00een modul MSLAB activat implicit, dup\u0103 acest prag, performan\u021ba \u00eencepe s\u0103 scad\u0103 dramatic, iar cu c\u00e2t volumul de date din \u00eenregistrare este mai mare, cu at\u00e2t timpul de execu\u021bie este mai mare. <\/p>\n
    \"Teoria
    \n
    \nTeste au fost efectuate pe o ma\u0219in\u0103 virtual\u0103, cu 8 nuclee, versiunea HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    Modul MSLAB este destinat reducerii fragment\u0103rii heap-ului, care apare din amestecarea datelor din genera\u021bii noi \u0219i vechi. Ca solu\u021bie, atunci c\u00e2nd MSLAB este activat, datele sunt plasate \u00een celule relativ mici (chunk) \u0219i sunt procesate pe por\u021biuni. Drept rezultat, atunci c\u00e2nd volumul datelor solicitate dep\u0103\u0219e\u0219te dimensiunea alocat\u0103, performan\u021ba scade brusc. Pe de alt\u0103 parte, dezactivarea acestui mod nu este de asemenea de dorit, deoarece va duce la opriri din cauza GC \u00een momentele de munc\u0103 intens\u0103 cu datele. O solu\u021bie bun\u0103 este cre\u0219terea dimensiunilor celulei, \u00een cazul unei scrieri active prin put simultan cu citirea. Este de men\u021bionat c\u0103 problema nu apare dac\u0103 dup\u0103 scriere se execut\u0103 comanda flush, care descarc\u0103 MemStore pe disc sau dac\u0103 se efectueaz\u0103 \u00eenc\u0103rcarea prin BulkLoad. \u00cen tabelul de mai jos se arat\u0103 c\u0103 cererile din MemStore pentru date de volum mai mare (\u0219i acela\u0219i num\u0103r) duc la \u00eencetinire. Cu toate acestea, cresc\u00e2nd chunksize, timpul de procesare revine la normal.<\/p>\n
    \"Teoria
    \nPe l\u00e2ng\u0103 cre\u0219terea chunksize, ajut\u0103 \u0219i divizarea datelor pe regiuni, adic\u0103 splitarea tabelelor. Acest lucru face ca pentru fiecare regiune s\u0103 vin\u0103 un num\u0103r mai mic de cereri \u0219i, dac\u0103 acestea sunt plasate \u00een celule, r\u0103spunsul r\u0103m\u00e2ne bun.<\/p>\n
    6. Strategia de divizare a tabelelor pe regiuni (splitare)<\/h2>\n
    \nDeoarece HBase este o stocare de tip key-value \u0219i partizionarea se face pe cheie, este extrem de important s\u0103 se \u00eempart\u0103 datele uniform pe toate regiunile. De exemplu, partionarea unei astfel de tabele \u00een trei p\u0103r\u021bi va duce la faptul c\u0103 datele vor fi \u00eemp\u0103r\u021bite \u00een trei regiuni:<\/p>\n
    \"Teoria
    \nUneori, aceasta duce la o \u00eencetinire brusc\u0103, dac\u0103 datele ulterior \u00eenc\u0103rcate vor avea, de exemplu, valori de tip long care \u00een mare parte \u00eencep cu aceea\u0219i cifr\u0103, de exemplu:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Deoarece cheile sunt stocate sub forma unui array de bytes, toate acestea vor \u00eencepe la fel \u0219i vor apar\u021bine acelea\u0219i regiuni #1 care stocheaz\u0103 acest interval de chei. Exist\u0103 mai multe strategii de divizare:<\/p>\n
    HexStringSplit \u2013 Transform\u0103 cheia \u00eentr-un \u0219ir cu codificare hexadecimal\u0103 \u00een intervalul \u201e00000000\u201d => \u201eFFFFFFFF\u201d \u0219i complet\u00e2nd cu zerouri la st\u00e2nga.<\/p>\n
    UniformSplit \u2013 Transform\u0103 cheia \u00eentr-un array de bytes cu codificare hexadecimal\u0103 \u00een intervalul \u201e00\u201d => \u201eFF\u201d \u0219i complet\u00e2nd cu zerouri la dreapta.<\/p>\n
    \u00cen plus, se poate specifica orice interval sau set de chei pentru divizare \u0219i se poate activa autosplitarea. Totu\u0219i, una dintre cele mai simple \u0219i eficiente abord\u0103ri este UniformSplit \u0219i utilizarea concaten\u0103rii hash-ului, de exemplu, prima pereche de bytes din rularea cheii prin func\u021bia CRC32(rowkey) \u0219i cheia rowkey propriu-zis\u0103:<\/p>\n
    hash + rowkey<\/p>\n
    Atunci toate datele vor fi distribuite uniform pe regiuni. La citire, primii doi bytes sunt pur \u0219i simplu elimina\u021bi \u0219i r\u0103m\u00e2ne cheia original\u0103. De asemenea, RS controleaz\u0103 cantitatea de date \u0219i chei din regiune \u0219i, \u00een cazul dep\u0103\u0219irii limitelor, le \u00eemp\u0103r\u021beste automat \u00een p\u0103r\u021bi. <\/p>\n
    7. Toleran\u021ba la erori \u0219i localizarea datelor<\/h2>\n
    \nDat fiecare set de chei este responsabil pentru o singur\u0103 regiune, solu\u021bia problemelor legate de pr\u0103bu\u0219irile RS sau de externalizarea acestora este stocarea tuturor datelor necesare \u00een HDFS. Atunci c\u00e2nd RS cedeaz\u0103, masterul detecteaz\u0103 acest lucru prin absen\u021ba heartbeat-ului pe nodul ZooKeeper. Acesta nume\u0219te o regiune alternativ\u0103 unui alt RS \u0219i, deoarece HFiles sunt stocate \u00een sistemul de fi\u0219iere distribuit, noul proprietar le cite\u0219te \u0219i continu\u0103 s\u0103 serveasc\u0103 datele. Totu\u0219i, deoarece o parte din date poate fi \u00een MemStore \u0219i nu a ajuns s\u0103 fie transferat\u0103 \u00een HFiles, pentru a restaura istoricul opera\u021biunilor se utilizeaz\u0103 WAL, care sunt de asemenea stocate \u00een HDFS. Dup\u0103 aplicarea modific\u0103rilor, RS-ul este capabil s\u0103 r\u0103spund\u0103 la cereri, \u00eens\u0103 migrarea duce la faptul c\u0103 o parte din date \u0219i procesele care le servesc se afl\u0103 pe noduri diferite, adic\u0103 localitatea scade. <\/p>\n
    Solu\u021bia problemei este major compaction \u2013 aceast\u0103 procedur\u0103 mut\u0103 fi\u0219ierele pe nodurile care le gestioneaz\u0103 (acolo unde sunt situate regiunile lor), rezult\u00e2nd \u00eentr-o \u00eenc\u0103rcare brusc\u0103 a re\u021belei \u0219i discurilor \u00een timpul acestei proceduri. Cu toate acestea, accesul la date devine semnificativ mai rapid ulterior. \u00cen plus, major_compaction realizeaz\u0103 combinarea tuturor HFiles \u00eentr-un singur fi\u0219ier \u00een cadrul regiunii, precum \u0219i cur\u0103\u021barea datelor \u00een func\u021bie de set\u0103rile tabelului. De exemplu, se poate seta num\u0103rul de versiuni ale unui obiect care trebuie p\u0103strat sau timpul s\u0103u de via\u021b\u0103, dup\u0103 expirarea c\u0103ruia obiectul este \u0219ters fizic.<\/p>\n
    Aceast\u0103 procedur\u0103 poate avea un impact foarte pozitiv asupra func\u021bion\u0103rii HBase. \u00cen imaginea de mai jos se poate observa cum a degenerat performan\u021ba ca urmare a scrierii active de date. Aici se poate observa cum 40 de fire scriu \u00eentr-un singur tabel \u0219i 40 de fire citesc simultan datele. Firele care scriu formeaz\u0103 din ce \u00een ce mai multe HFiles, care sunt citite de celelalte fire. Ca rezultat, din ce \u00een ce mai multe date trebuie \u0219terse din memorie \u0219i, la un moment dat, \u00eencepe s\u0103 func\u021bioneze GC-ul, care practic paralizeaz\u0103 toat\u0103 activitatea. Lansarea major compaction a dus la cur\u0103\u021barea acumul\u0103rilor create \u0219i la restabilirea performan\u021bei.<\/p>\n
    \"Teoria
    \nTestul a fost efectuat pe 3 DataNode \u0219i 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 fire). Versiunea HBase este 1.2.0-cdh5.14.2<\/p>\n
    Este important de men\u021bionat c\u0103 lansarea major compaction a fost efectuat\u0103 pe o tabel\u0103 \u201evie\u201d, \u00een care se scriau \u0219i se citeau activ date. \u00cen re\u021bea s-a \u00eent\u00e2lnit afirma\u021bia c\u0103 acest lucru poate duce la un r\u0103spuns incorect atunci c\u00e2nd se citesc date. Pentru verificare, a fost lansat un proces care genera date noi \u0219i le scria \u00een tabel\u0103. Dup\u0103 aceea, datele erau citite imediat \u0219i se verifica dac\u0103 valoarea ob\u021binut\u0103 corespundea cu ceea ce fusese scris. \u00cen timpul desf\u0103\u0219ur\u0103rii acestui proces, major compaction a fost lansat de aproximativ 200 de ori \u0219i nu a fost \u00eenregistrat\u0103 nicio eroare. Este posibil ca problema s\u0103 se manifeste rar \u0219i doar \u00een timpul unei sarcini mari, a\u0219a c\u0103 mai sigur ar fi totu\u0219i s\u0103 se opreasc\u0103 planificat procesele de scriere \u0219i citire \u0219i s\u0103 se efectueze cur\u0103\u021barea, evit\u00e2nd astfel sc\u0103derile GC.<\/p>\n
    De asemenea, major compaction nu influen\u021beaz\u0103 starea MemStore, pentru a-l scrie pe disc \u0219i a compacta, trebuie utilizat flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Set\u0103ri \u0219i performan\u021b\u0103<\/h2>\n
    \nDup\u0103 cum s-a spus, HBase \u00ee\u0219i arat\u0103 cel mai mare succes acolo unde nu trebuie s\u0103 fac\u0103 nimic, \u00een timpul execut\u0103rii BulkLoad. Totu\u0219i, acest lucru se aplic\u0103 majorit\u0103\u021bii sistemelor \u0219i oamenilor. Cu toate acestea, acest instrument este mai potrivit pentru \u00eenc\u0103rcarea masiv\u0103 a datelor \u00een blocuri mari, \u00een timp ce, dac\u0103 procesul necesit\u0103 executarea unui num\u0103r mare de cereri concurente de citire \u0219i scriere, se folosesc comenzile Get \u0219i Put descrise mai sus. Pentru a determina parametrii optimi, au fost efectuate lans\u0103ri cu diferite combina\u021bii de parametri de tabele \u0219i set\u0103ri:<\/p>\n