{"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\/da\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Teori og praksis i brugen af HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Goddag! Mit navn er Danil Lipovoy, og vores team i Sbertech er begyndt at bruge HBase som lager til operationelle data. Gennem vores unders\u00f8gelse er der blevet indsamlet erfaring, som vi \u00f8nskede at systematisere og beskrive (vi h\u00e5ber, det vil v\u00e6re nyttigt for mange). Alle de f\u00f8lgende eksperimenter er udf\u00f8rt med versioner af HBase 1.2.0-cdh5.14.2 og 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. Generel Arkitektur <\/li>\n
  2. Skrivning af data til HBASE<\/li>\n
  3. L\u00e6sning af data fra HBASE<\/li>\n
  4. Cachelagring af data<\/li>\n
  5. Batchbehandling af data MultiGet\/MultiPut<\/li>\n
  6. Strategi for opdeling af tabeller i regioner (splittning)<\/li>\n
  7. Fejltolerance, komprimering og datalokalsitet<\/li>\n
  8. Indstillinger og ydeevne<\/li>\n
  9. Belastningstest<\/li>\n
  10. Konklusioner<\/li>\n<\/ol>\n

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

    1. Generel Arkitektur<\/h2>\n

    \n\"Teori
    \nDen backup Master overv\u00e5ger heartbeat fra den aktive p\u00e5 ZooKeeper og p\u00e5tager sig masterens funktioner i tilf\u00e6lde af nedbrud. <\/p>\n

    2. Skrivning af data til HBASE<\/h2>\n

    \nLad os f\u00f8rst se p\u00e5 det enkleste tilf\u00e6lde \u2013 skrivning af et n\u00f8gle-v\u00e6rdi objekt til en given tabel ved hj\u00e6lp af put(rowkey). Klienten skal f\u00f8rst finde ud af, hvor roden region server (Root Region Server \u2014 RRS) er placeret, som opbevarer tabellen hbase:meta. Denne information f\u00e5r han fra ZooKeeper. Derefter henvender han sig til RRS og l\u00e6ser tabellen hbase:meta, hvorfra han udtr\u00e6kker information om, hvilken RegionServer (RS) der ansvarer for opbevaring af dataene for den angivne rowkey i den \u00f8nskede tabel. Af hensyn til videre brug cachelageres meta-tabellen af klienten, og derfor g\u00e5r efterf\u00f8lgende henvendelser hurtigere, direkte til RS.<\/p>\n

    N\u00e5r RS modtager anmodningen, skriver den f\u00f8rst denne til WriteAheadLog (WAL), som er n\u00f8dvendig for at kunne genskabe ved nedbrud. Derefter gemmer den dataene i MemStore. Dette er en buffer i hukommelsen, som indeholder et sorteret s\u00e6t af n\u00f8gler for denne region. Tabellen kan opdeles i regioner (partitioner), hver af dem indeholder et ikke-overlappende s\u00e6t af n\u00f8gler. Dette g\u00f8r det muligt at opn\u00e5 h\u00f8jere ydeevne ved at placere regionerne p\u00e5 forskellige servere. Men p\u00e5 trods af \u00e5benlyse fordele vil vi se, at dette ikke altid fungerer.<\/p>\n

    Efter at posten er placeret i MemStore, f\u00e5r klienten et svar om, at posten er gemt succesfuldt. I virkeligheden opbevares den kun i bufferen og vil blive skrevet til disken f\u00f8rst efter en vis tidsperiode eller ved at blive fyldt med nye data. <\/p>\n

    \"Teori
    \nVed udf\u00f8relse af operationen \u00abDelete\u00bb sker der ikke fysisk sletning af data. De markeres blot som slettede, og selve destruktionen finder sted ved opkald af funktionen major compact, som der st\u00e5r mere om i punkt 7.<\/p>\n

    Filer i HFile-formatet oplagres i HDFS, og der startes fra tid til anden en minor compact-proces, der blot sammenklemmer sm\u00e5 filer til st\u00f8rre, uden at slette noget. Over tid bliver dette et problem, der kun viser sig ved l\u00e6sning af data (det vender vi tilbage til senere). <\/p>\n

    Udover den ovenfor beskrevne indl\u00e6sning er der en langt mere effektiv procedure, som m\u00e5ske er den st\u00e6rkeste side ved denne database \u2013 BulkLoad. Det involverer, at vi selv opretter HFiles og placerer dem p\u00e5 disken, hvilket g\u00f8r det muligt at skalere fremragende og opn\u00e5 ganske respektable hastigheder. I bund og grund er begr\u00e6nsningen ikke HBase, men hardware-mulighederne. Nedenfor er resultaterne af indl\u00e6sning p\u00e5 en klynge best\u00e5ende af 16 RegionServers og 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tr\u00e5de), HBase version 1.2.0-cdh5.14.2. <\/p>\n

    \"Teori
    \n
    \nHer kan vi se, at ved at \u00f8ge antallet af partitioner (regioner) i tabellen samt Spark-udf\u00f8rere, f\u00e5r vi en stigning i indl\u00e6sningshastigheden. Hastigheden afh\u00e6nger ogs\u00e5 af m\u00e6ngden af data, der skrives. Store blokke giver en stigning m\u00e5lt i MB\/sek, mens sm\u00e5 giver en stigning i antallet af indsatte poster pr. tidsenhed, alt andet lige. <\/p>\n

    Man kan ogs\u00e5 starte indl\u00e6sningen i to tabeller samtidigt og opn\u00e5 en fordobling af hastigheden. Nedenfor ses det, at skrivning af 10 KB blokke samtidigt i to tabeller sker med en hastighed p\u00e5 omkring 600 MB\/sek til hver (i alt 1275 MB\/sek), hvilket matcher skrivningshastigheden i en enkelt tabel p\u00e5 623 MB\/sek (se nr. 11 ovenfor).<\/p>\n

    \"Teori
    \nMen den anden k\u00f8rsel med indskrifter p\u00e5 50 KB viser, at indl\u00e6sningshastigheden kun stiger ubetydeligt, hvilket indikerer, at vi n\u00e6rmer os de maksimale v\u00e6rdier. Det skal bem\u00e6rkes, at der ikke praktisk talt skabes belastning p\u00e5 selve HBASE; alt hvad der kr\u00e6ves af den, er f\u00f8rst at sende data fra hbase:meta, og efter placeringen af HFiles, at tilbagel\u00e6gge data fra BlockCache og gemme MemStore-pufferen p\u00e5 disken, hvis den ikke er tom.<\/p>\n

    3. L\u00e6sning af data fra HBASE<\/h2>\n

    \nHvis man antager, at alle oplysninger fra hbase:meta allerede er tilg\u00e6ngelige for kunden (se punkt 2), s\u00e5 sendes foresp\u00f8rgslen straks til den RS, hvor den n\u00f8dvendige n\u00f8gle er gemt. F\u00f8rst udf\u00f8res s\u00f8gningen i MemCache. Uanset om der er data der eller ej, udf\u00f8res s\u00f8gningen ogs\u00e5 i BlockCache-bufferen og om n\u00f8dvendigt i HFiles. Hvis dataene findes i filen, placeres de i BlockCache, og ved n\u00e6ste foresp\u00f8rgsel vil de blive returneret hurtigere. S\u00f8gningen i HFile sker relativt hurtigt takket v\u00e6re brugen af en Bloom-filter, dvs. ved at l\u00e6se et lille datavolumen bestemmer den straks, om denne fil indeholder den n\u00f8dvendige n\u00f8gle, og hvis ikke, g\u00e5r den videre til den n\u00e6ste.<\/p>\n

    \"Teori
    \nN\u00e5r RS har modtaget data fra disse tre kilder, danner den et svar. Specifikt kan den straks overf\u00f8re flere fundne versioner af objektet, hvis klienten har anmodet om versionskontrol.<\/p>\n

    4. Data caching<\/h2>\n

    \nMemStore- og BlockCache-bufferne optager op til 80% af den tildelte on-heap hukommelse hos RS (det resterende er reserveret til servicem\u00e6ssige opgaver hos RS). Hvis den typiske brug er s\u00e5dan, at processerne skriver og straks l\u00e6ser disse data, giver det mening at reducere BlockCache og \u00f8ge MemStore, da dataene ved skrivning ikke kommer ind i cache til l\u00e6sning, s\u00e5 brugen af BlockCache vil ske sj\u00e6ldnere. BlockCache-bufferen best\u00e5r af to dele: LruBlockCache (altid on-heap) og BucketCache (normalt off-heap eller p\u00e5 SSD). BucketCache b\u00f8r bruges, n\u00e5r der er mange l\u00e6seanmodninger, og de ikke kan v\u00e6re i LruBlockCache, hvilket f\u00f8rer til aktiv drift af Garbage Collector. Selvom man ikke skal forvente en dramatisk stigning i ydeevnen ved brug af cache til l\u00e6sning, vil vi komme tilbage til dette i punkt 8.<\/p>\n

    \"Teori
    \nBlockCache er f\u00e6lles for hele RS, mens MemStore er unik for hver tabel (\u00e9n for hver Column Family).<\/p>\n

    siger beskrevet<\/a><\/noindex> Teoretisk set, n\u00e5r data skrives, kommer de ikke ind i cache, og faktisk er s\u00e5danne parametre CACHE_DATA_ON_WRITE for tabellen og 'Cache DATA on Write' for RS indstillet til false. Men i praksis, hvis man skriver data i MemStore, derefter t\u00f8mer den til disk (derved rydder op), og s\u00e5 sletter den resulterende fil, s\u00e5 vil en get-anmodning stadig give os dataene. Og selvom man helt deaktiverer BlockCache og fylder tabellen med nye data, og derefter opn\u00e5r en t\u00f8mming af MemStore til disk, sletter dem og anmoder fra en anden session, s\u00e5 vil dataene stadig blive hentet fra et eller andet sted. S\u00e5 HBase opbevarer ikke kun data, men ogs\u00e5 g\u00e5defulde mysterier.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nOprettet tabel ns:magic\nTog 1.1533 sekunder\nhbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'\nTog 0.2610 sekunder\nhbase(main):003:0> flush 'ns:magic'\nTog 0.6161 sekunder\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
    \nIndstillingen \"Cache DATA on Read\" er sat til false. Hvis du har ideer, er du velkommen til at diskutere dette i kommentarerne.<\/p>\n
    5. Batch behandling af data MultiGet\/MultiPut<\/h2>\n
    \nBehandling af enkeltanmodninger (Get\/Put\/Delete) er en relativt dyr operation, s\u00e5 de b\u00f8r kombineres i en List, hvilket kan give en betydelig ydelsesfor\u00f8gelse. Dette g\u00e6lder is\u00e6r for skriveoperationer, men ved l\u00e6sning er der en faldgrube. P\u00e5 grafen nedenfor vises tid til at l\u00e6se 50.000 poster fra MemStore. L\u00e6sningen blev udf\u00f8rt i en enkelt tr\u00e5d, og p\u00e5 den vandrette akse vises antallet af n\u00f8gler i anmodningen. Her ses det, at ved at \u00f8ge til tusind n\u00f8gler i \u00e9n anmodning falder udf\u00f8relsestiden, dvs. hastigheden \u00f8ges. Men med den som standard aktiverede MSLAB-tilstand starter der en dramatisk nedgang i ydelsen efter denne t\u00e6rskel, des mere data der er i posterne, jo l\u00e6ngere tid tager det. <\/p>\n
    \"Teori
    \n
    \nTestene blev udf\u00f8rt p\u00e5 en virtuel maskine, 8 kerner, version HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    MSLAB-tilstand er designet til at mindske fragmenteringen af heapen, som opst\u00e5r p\u00e5 grund af blanding af data fra nye og gamle generationer. Som en l\u00f8sning p\u00e5 problemet placeres data i relativt sm\u00e5 celler (chunk) og behandles i portioner, n\u00e5r MSLAB er aktiveret. Resultatet er, at n\u00e5r m\u00e6ngden i den anmodede datapakke overskrider den tildelte st\u00f8rrelse, falder ydelsen drastisk. P\u00e5 den anden side er det heller ikke \u00f8nskeligt at deaktivere denne tilstand, da det f\u00f8rer til pauser p\u00e5 grund af GC i perioder med intensiv databehandling. En god l\u00f8sning er at \u00f8ge st\u00f8rrelsen af cellerne, n\u00e5r der skrives aktivt via put samtidig med l\u00e6sning. Det er v\u00e6rd at bem\u00e6rke, at problemet ikke opst\u00e5r, hvis man efter skrivning udf\u00f8rer flush-kommandoen, som skyder MemStore til disken, eller hvis der udf\u00f8res indl\u00e6sning via BulkLoad. I tabellen nedenfor vises, at anmodninger fra MemStore med st\u00f8rre data (og samme m\u00e6ngde) f\u00f8rer til nedsat hastighed. Men ved at \u00f8ge chunksize kan vi bringe behandlingstiden tilbage til det normale.<\/p>\n
    \"Teori
    \nUdover at \u00f8ge chunksize hj\u00e6lper det at opdele data efter regioner, dvs. splitting af tabeller. Dette medf\u00f8rer, at f\u00e6rre foresp\u00f8rgsler kommer til hver region, og hvis de placeres i en celle, forbliver responsen god.<\/p>\n
    6. Strategi for opdeling af tabeller efter regioner (splitting)<\/h2>\n
    \nDa HBase er et key-value lager, og partitionering udf\u00f8res efter n\u00f8gle, er det ekstremt vigtigt at fordele data j\u00e6vnt over alle regioner. For eksempel vil partitionering af en s\u00e5dan tabel i tre dele f\u00f8re til, at datae bliver delt i tre regioner:<\/p>\n
    \"Teori
    \nDet kan f\u00f8re til en skarpe forsinkelse, hvis de data, der senere bliver indl\u00e6st, for eksempel har lange v\u00e6rdier, der for det meste begynder med det samme ciffer, for eksempel:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Da n\u00f8glerne gemmes som en byte-array, vil alle starte ens og h\u00f8re til den region #1, der gemmer dette n\u00f8gleomr\u00e5de. Der er flere opdelingsstrategier:<\/p>\n
    HexStringSplit \u2013 Konverterer n\u00f8glen til en streng med hexadecimale koder i omr\u00e5det \"00000000\" => \"FFFFFFFF\" og fylder til venstre med nuller.<\/p>\n
    UniformSplit \u2013 Konverterer n\u00f8glen til en byte-array med hexadecimale koder i omr\u00e5det \"00\" => \"FF\" og fylder til h\u00f8jre med nuller.<\/p>\n
    Derudover kan man angive ethvert omr\u00e5de eller s\u00e6t n\u00f8gler til opdeling og indstille automatisk splitning. Dog er en af de mest enkle og effektive metoder UniformSplit og brugen af hash-katstring, for eksempel det h\u00f8jeste byte-par fra k\u00f8rslen af n\u00f8glen gennem CRC32(rowkey) funktionen og selve rowkey:<\/p>\n
    hash + rowkey<\/p>\n
    S\u00e5 vil alle dataene v\u00e6re j\u00e6vnt fordelt over regioner. Ved l\u00e6sning bliver de f\u00f8rste to bytes blot bortkastet, og den oprindelige n\u00f8gle forbliver. Derudover overv\u00e5ger RS m\u00e6ngden af data og n\u00f8gler i regionen, og ved overskridelse af gr\u00e6nserne opdeles den automatisk i dele. <\/p>\n
    7. Fejltolerance og lokalitet af data<\/h2>\n
    \nDa hver n\u00f8glepakke kun er ansvarlig for \u00e9n region, er l\u00f8sningen p\u00e5 problemer relateret til nedbrud af RS eller udfasning at opbevare alle n\u00f8dvendige data i HDFS. Ved nedbrud registrerer masteren dette gennem manglende heartbeat p\u00e5 ZooKeeper-noden. Den tildeler derefter den d\u00e6kkede region til en anden RS, og da HFiles gemmes i det distribuerede filsystem, vil den nye ejer l\u00e6se dem og forts\u00e6tte med at betjene dataene. Men da en del af dataene kan v\u00e6re i MemStore og ikke er n\u00e5et til HFiles, anvendes WAL til at gendanne operationernes historie, som ogs\u00e5 er gemt i HDFS. Efter at \u00e6ndringerne er anvendt, er RS i stand til at svare p\u00e5 foresp\u00f8rgsler, men flytningen medf\u00f8rer, at en del data og de processer, der betjener dem, havner p\u00e5 forskellige noder, hvilket resulterer i nedsat lokalitet. <\/p>\n
    L\u00f8sningen p\u00e5 problemet er major compaction \u2013 denne procedure flytter filer til de noder, som er ansvarlige for dem (til dem, hvor deres regioner er placeret), hvilket medf\u00f8rer, at belastningen p\u00e5 netv\u00e6rk og diske pludselig stiger under denne procedure. Dog kan adgangen til dataene m\u00e6rkbart accelereres p\u00e5 l\u00e6ngere sigt. Desuden udf\u00f8rer major_compaction en sammenl\u00e6gning af alle HFiles til \u00e9n fil inden for regionen og rydder dataene baseret p\u00e5 tabelindstillingerne. For eksempel kan man angive antallet af versioner af et objekt, der skal bevares, eller dets levetid, efter hvilken objektet fysisk fjernes.<\/p>\n
    Denne procedure kan have en meget positiv indvirkning p\u00e5 HBase's ydeevne. P\u00e5 billedet nedenfor kan man se, hvordan ydeevnen er blevet degraderet som f\u00f8lge af aktiv dataindsamling. Her kan man se, at der i \u00e9n tabel blev skrevet af 40 tr\u00e5de, mens 40 tr\u00e5de l\u00e6ste data samtidig. De skrivende tr\u00e5de genererer flere og flere HFiles, som bliver l\u00e6st af de andre tr\u00e5de. Som et resultat skal der slettes flere og flere data fra hukommelsen, og til sidst begynder GC at arbejde, hvilket i praksis lammer hele processen. Udf\u00f8relsen af major compaction f\u00f8rte til oprydning af de opst\u00e5ede affald og gendannelse af ydeevnen.<\/p>\n
    \"Teori
    \nTesten blev udf\u00f8rt p\u00e5 3 DataNode og 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tr\u00e5de). Version HBase 1.2.0-cdh5.14.2<\/p>\n
    Det skal bem\u00e6rkes, at major compaction blev udf\u00f8rt p\u00e5 en \"live\" tabel, hvor der aktivt blev skrevet og l\u00e6st data. Der har v\u00e6ret p\u00e5stande p\u00e5 nettet om, at dette kan f\u00f8re til forkerte svar ved l\u00e6sning af data. For at teste blev der startet en proces, der genererede nye data og skrev dem til tabellen. Efterf\u00f8lgende blev der straks l\u00e6st og tjekket, om den modtagne v\u00e6rdi stemte overens med det, der var skrevet. Under operationen blev major compaction udf\u00f8rt omkring 200 gange, og der blev ikke registreret nogen nedbrud. M\u00e5ske viser problemet sig sj\u00e6ldent og kun under h\u00f8j belastning, s\u00e5 det er derfor mere sikkert at planm\u00e6ssigt stoppe skrive- og l\u00e6seprocesserne og udf\u00f8re reng\u00f8ring undg\u00e5else af s\u00e5danne GC-dyk.<\/p>\n
    Desuden p\u00e5virker major compaction ikke tilstanden af MemStore; for at nulstille det til disk og komprimere skal der bruges flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Indstillinger og ydeevne<\/h2>\n
    \nSom allerede n\u00e6vnt viser HBase den st\u00f8rste succes, hvor den ikke har noget at g\u00f8re ved udf\u00f8relsen af BulkLoad. Dette g\u00e6lder dog for de fleste systemer og mennesker. Men dette v\u00e6rkt\u00f8j er mere egnet til masseoverf\u00f8rsel af data i store blokke, mens processer, der kr\u00e6ver mange konkurrerende l\u00e6se- og skriveanmodninger, bruger de f\u00f8rn\u00e6vnte Get- og Put-kommandoer. For at bestemme de optimale parametre blev der udf\u00f8rt tests med forskellige kombinationer af tabelparametre og indstillinger:<\/p>\n