{"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\/sv\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Teori och praktik f\u00f6r anv\u00e4ndning av HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej! Jag heter Danil Lipovoy, och v\u00e5rt team p\u00e5 Sbertech har b\u00f6rjat anv\u00e4nda HBase som ett datalagringssystem. Under studiet av detta har vi samlat erfarenhet som vi ville systematisera och beskriva (vi hoppas att det blir till nytta f\u00f6r m\u00e5nga). Alla experiment som beskrivs nedan utf\u00f6rdes med versionerna HBase 1.2.0-cdh5.14.2 och 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. \u00d6vergripande arkitektur <\/li>\n
  2. Skriva data till HBASE<\/li>\n
  3. L\u00e4sa data fr\u00e5n HBASE<\/li>\n
  4. Cachning av data<\/li>\n
  5. Batchbehandling av data MultiGet\/MultiPut<\/li>\n
  6. Strategi f\u00f6r uppdelning av tabeller i regioner (splitting)<\/li>\n
  7. T\u00e5lighet, komprimering och lokalitet av data<\/li>\n
  8. Inst\u00e4llningar och prestanda<\/li>\n
  9. Belastningstestning<\/li>\n
  10. Slutsatser<\/li>\n<\/ol>\n

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

    1. \u00d6vergripande arkitektur<\/h2>\n

    \n\"Teori
    \nEn reserv Master \u00f6vervakar heartbeat fr\u00e5n den aktiva p\u00e5 noden ZooKeeper och tar \u00f6ver masterfunktionen i h\u00e4ndelse av att den avaktiveras. <\/p>\n

    2. Skriva data till HBASE<\/h2>\n

    \nF\u00f6rst tittar vi p\u00e5 det enklaste fallet \u2013 att skriva ett nyckel-v\u00e4rde-objekt till en viss tabell med hj\u00e4lp av put(rowkey). Klienten m\u00e5ste f\u00f6rst ta reda p\u00e5 var den rotregioner servern (Root Region Server \u2013 RRS) ligger, som lagrar tabellen hbase:meta. Denna information f\u00e5r den fr\u00e5n ZooKeeper. D\u00e4refter kontaktar den RRS och l\u00e4ser tabellen hbase:meta, fr\u00e5n vilken den h\u00e4mtar information om vilken RegionServer (RS) som ansvarar f\u00f6r att lagra data f\u00f6r den angivna nyckeln rowkey i den tabell som intresserar den. F\u00f6r framtida anv\u00e4ndning cachar klienten metatabellen, och d\u00e4rf\u00f6r g\u00e5r de efterf\u00f6ljande f\u00f6rfr\u00e5gningarna snabbare, direkt till RS.<\/p>\n

    D\u00e4refter skriver RS, efter att ha mottagit f\u00f6rfr\u00e5gan, f\u00f6rst in den i WriteAheadLog (WAL), vilket \u00e4r n\u00f6dv\u00e4ndigt f\u00f6r \u00e5terst\u00e4llning vid ett systemhaveri. Sedan sparas data i MemStore. Detta \u00e4r en minnesbuffer som inneh\u00e5ller en sorterad upps\u00e4ttning nycklar f\u00f6r denna region. Tabellen kan delas upp i regioner (partitioner), som var och en inneh\u00e5ller en icke-\u00f6verliggande upps\u00e4ttning nycklar. Detta till\u00e5ter, genom att placera regionerna p\u00e5 olika servrar, att uppn\u00e5 h\u00f6gre prestanda. Men trots att denna slutsats \u00e4r uppenbar, kommer vi att se att det inte alltid fungerar p\u00e5 detta s\u00e4tt.<\/p>\n

    Efter att posten har lagts i MemStore f\u00e5r klienten en bekr\u00e4ftelse p\u00e5 att posten har sparats framg\u00e5ngsrikt. Den sparas dock egentligen bara i bufferten och kommer att \u00f6verf\u00f6ras till disken f\u00f6rst efter att en viss tidsperiod har passerat eller n\u00e4r den har fyllts med nya data. <\/p>\n

    \"Teori
    \nVid utf\u00f6randet av operationen \"Delete\" sker ingen fysisk radering av data. De markeras helt enkelt som raderade, och sj\u00e4lva f\u00f6rst\u00f6relsen sker vid anrop av funktionen major compact, som beskrivs mer detaljerat i punkt 7.<\/p>\n

    Filer i HFile-format samlas i HDFS och med j\u00e4mna mellanrum k\u00f6rs processen minor compact, som helt enkelt sammanfogar sm\u00e5 filer till st\u00f6rre utan att radera n\u00e5got. Med tiden blir detta ett problem som endast visar sig vid l\u00e4sning av data (detta kommer vi att \u00e5terkomma till senare). <\/p>\n

    F\u00f6rutom den beskrivna uppladdningsprocessen finns det en mycket effektivare procedur, som utg\u00f6r kanske den starkaste sidan av denna databas \u2013 BulkLoad. Det handlar om att vi sj\u00e4lva skapar HFiles och l\u00e4gger in dem p\u00e5 disken, vilket till\u00e5ter utm\u00e4rkt skalning och uppn\u00e5else av ganska anst\u00e4ndiga hastigheter. I princip \u00e4r det inte HBase som s\u00e4tter gr\u00e4nser h\u00e4r, utan h\u00e5rdvarans kapabiliteter. Nedan visas resultaten av uppladdningen p\u00e5 en kluster best\u00e5ende av 16 RegionServers och 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tr\u00e5dar), version HBase 1.2.0-cdh5.14.2. <\/p>\n

    \"Teori
    \n
    \nH\u00e4r kan vi se att genom att \u00f6ka antalet partitioner (regioner) i tabellen samt Spark-exekverare f\u00e5r vi en \u00f6kning av uppladdningshastigheten. Hastigheten beror ocks\u00e5 p\u00e5 skrivvolymen. Stora block ger en \u00f6kning i m\u00e5tt av MB\/s, medan sm\u00e5 block \u00f6kar antalet inskrivna poster per tidsenhet, vid \u00f6vriga lika f\u00f6rh\u00e5llanden. <\/p>\n

    Det \u00e4r ocks\u00e5 m\u00f6jligt att starta uppladdning i tv\u00e5 tabeller samtidigt och f\u00e5 en dubblering av hastigheten. Nedan kan vi se att skrivningen av 10 KB block direkt i tv\u00e5 tabeller g\u00e5r med en hastighet p\u00e5 cirka 600 Mb\/s i varje (totalt 1275 Mb\/s), vilket st\u00e4mmer \u00f6verens med skrivhastigheten i en tabell p\u00e5 623 MB\/s (se punkt \u211611 ovan).<\/p>\n

    \"Teori
    \nDen andra k\u00f6rningen med 50 KB-inspelningar visar att uppladdningshastigheten \u00f6kar endast i begr\u00e4nsad utstr\u00e4ckning, vilket indikerar att vi n\u00e4rmar oss de maximala v\u00e4rdena. H\u00e4rvid b\u00f6r man ha i \u00e5tanke att HBASE i princip inte belastas alls, allt som kr\u00e4vs fr\u00e5n den \u00e4r att f\u00f6rst returnera data fr\u00e5n hbase:meta, och efter inlagan av HFiles, t\u00f6mma BlockCache och spara MemStore-bufferten p\u00e5 disken, om den inte \u00e4r tom.<\/p>\n

    3. L\u00e4sa data fr\u00e5n HBASE<\/h2>\n

    \nOm vi antar att all information fr\u00e5n hbase:meta redan finns hos kunden (se p.2), g\u00e5r f\u00f6rfr\u00e5gan direkt till den RS d\u00e4r den \u00f6nskade nyckeln lagras. F\u00f6rst sker s\u00f6kningen i MemCache. Oavsett om det finns data d\u00e4r eller inte, sker s\u00f6kningen ocks\u00e5 i BlockCache och vid behov i HFiles. Om data hittas i filen placeras de i BlockCache och kommer att returneras snabbare vid n\u00e4sta f\u00f6rfr\u00e5gan. S\u00f6kningen i HFile sker relativt snabbt tack vare anv\u00e4ndningen av en Bloom-filter, det vill s\u00e4ga genom att l\u00e4sa en liten m\u00e4ngd data kan det direkt avg\u00f6ra om denna fil inneh\u00e5ller den \u00f6nskade nyckeln, och om inte, g\u00e5r det vidare till n\u00e4sta.<\/p>\n

    \"Teori
    \nN\u00e4r data har erh\u00e5llits fr\u00e5n dessa tre k\u00e4llor bildar RS svaret. I synnerhet kan det skicka flera hittade versioner av objektet om kunden har beg\u00e4rt versionering.<\/p>\n

    4. Cachning av data<\/h2>\n

    \nBuffrarna MemStore och BlockCache tar upp till 80% av den tilldelade on-heap-minnet p\u00e5 RS (resten \u00e4r reserverat f\u00f6r tj\u00e4nsteuppgifter i RS). Om den typiska anv\u00e4ndningen \u00e4r s\u00e5dan att processer skriver och omedelbart l\u00e4ser dessa samma data, \u00e4r det meningsfullt att minska BlockCache och \u00f6ka MemStore, eftersom data vid skrivning inte g\u00e5r in i l\u00e4scachen, vilket g\u00f6r att anv\u00e4ndningen av BlockCache blir mindre frekvent. BlockCache-bufferten best\u00e5r av tv\u00e5 delar: LruBlockCache (alltid on-heap) och BucketCache (vanligtvis off-heap eller p\u00e5 SSD). BucketCache b\u00f6r anv\u00e4ndas n\u00e4r det finns m\u00e5nga l\u00e4sningsf\u00f6rfr\u00e5gningar som inte f\u00e5r plats i LruBlockCache, vilket leder till aktivt arbete av Garbage Collector. Vid detta tillf\u00e4lle b\u00f6r man inte f\u00f6rv\u00e4nta sig en radikal \u00f6kning av prestanda fr\u00e5n anv\u00e4ndningen av l\u00e4s-cache, men vi \u00e5terkommer till detta i p. 8.<\/p>\n

    \"Teori
    \nBlockCache \u00e4r gemensam f\u00f6r hela RS, medan MemStore \u00e4r specifik f\u00f6r varje tabell (en f\u00f6r varje Column Family).<\/p>\n

    Hur beskrivet<\/a><\/noindex> I teorin g\u00e5r data inte in i cachen vid skrivning och faktiskt \u00e4r s\u00e5dana parametrar CACHE_DATA_ON_WRITE f\u00f6r tabellen och 'Cache DATA on Write' f\u00f6r RS inst\u00e4llda p\u00e5 false. Men i praktiken, om man skriver data till MemStore, sedan spolar det till disk (\u00e5terst\u00e4ller d\u00e4rmed), f\u00f6r att sedan ta bort den resulterande filen, kommer en get-f\u00f6rfr\u00e5gan framg\u00e5ngsrikt att returnera data. Dessutom, \u00e4ven om BlockCache helt st\u00e4ngs av och tabellen fylls med nya data, f\u00f6r att sedan uppn\u00e5 en spoling av MemStore till disk, radera dem och be om dem fr\u00e5n en annan session, kommer de \u00e4nd\u00e5 att h\u00e4mtas fr\u00e5n n\u00e5gonstans. S\u00e5 HBase lagrar inte bara data utan \u00e4ven mystiska mysterier.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nSkapade tabell 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
    \nParametern \"Cache DATA on Read\" \u00e4r inst\u00e4lld p\u00e5 false. Om det finns id\u00e9er, v\u00e4lkomna att diskutera detta i kommentarerna.<\/p>\n
    5. Batchbearbetning av data MultiGet\/MultiPut<\/h2>\n
    \nBearbetning av enskilda f\u00f6rfr\u00e5gningar (Get\/Put\/Delete) \u00e4r en ganska kostsam operation, s\u00e5 det \u00e4r b\u00e4st att gruppera dem i List eller List, vilket ger en betydande prestanda\u00f6kning. Detta g\u00e4ller s\u00e4rskilt f\u00f6r skrivoperationer, men vid l\u00e4sning finns f\u00f6ljande fallgropp. I diagrammet nedan visas tiden f\u00f6r att l\u00e4sa 50 000 poster fr\u00e5n MemStore. L\u00e4sningen utf\u00f6rdes i en tr\u00e5d och p\u00e5 den horisontella axeln visas antalet nycklar i f\u00f6rfr\u00e5gan. H\u00e4r kan vi se att n\u00e4r antalet nycklar i en f\u00f6rfr\u00e5gan \u00f6kar till tusen, minskar exekveringstiden, det vill s\u00e4ga hastigheten \u00f6kar. Men med standardl\u00e4get f\u00f6r MSLAB b\u00f6rjar prestandan falla kraftigt efter denna tr\u00f6skel, och ju st\u00f6rre datam\u00e4ngden i posten \u00e4r, desto mer \u00f6kar arbetstiden. <\/p>\n
    \"Teori
    \n
    \nTester utf\u00f6rdes p\u00e5 en virtuell maskin med 8 k\u00e4rnor, version HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    MSLAB-l\u00e4get syftar till att minska fragmenteringen av heap, vilket uppst\u00e5r genom blandning av nya och gamla generationers data. F\u00f6r att l\u00f6sa problemet, n\u00e4r MSLAB \u00e4r aktiverat, placeras data i relativt sm\u00e5 celler (chunk) och bearbetas i portioner. Som ett resultat, n\u00e4r volymen i den beg\u00e4rda datapaketet \u00f6verskrider den tilldelade storleken, minskar prestandan kraftigt. \u00c5 andra sidan \u00e4r det inte \u00f6nskv\u00e4rt att st\u00e4nga av detta l\u00e4ge, eftersom det kan leda till stopp p\u00e5 grund av GC vid intensiva databehandlingsmoment. En bra l\u00f6sning \u00e4r att \u00f6ka storleken p\u00e5 cellerna vid aktiv skrivning med put samtidigt som man l\u00e4ser. Det b\u00f6r noteras att problemet inte uppst\u00e5r om man efter skrivningen utf\u00f6r flush-kommandot som \u00f6verf\u00f6r MemStore till disken eller om data laddas med hj\u00e4lp av BulkLoad. I tabellen nedan visas att f\u00f6rfr\u00e5gningar fr\u00e5n MemStore med st\u00f6rre datam\u00e4ngder (och samma antal) leder till f\u00f6rdr\u00f6jningar. Men genom att \u00f6ka chunksize \u00e5terf\u00e5r vi bearbetningstiden till det normala.<\/p>\n
    \"Teori
    \nF\u00f6rutom att \u00f6ka chunksize \u00e4r det ocks\u00e5 effektivt att dela upp data efter regioner, det vill s\u00e4ga tabellsplittring. Detta inneb\u00e4r att varje region f\u00e5r f\u00e4rre f\u00f6rfr\u00e5gningar och om de placeras i en cell, f\u00f6rblir svarstiden bra.<\/p>\n
    6. Strategi f\u00f6r att dela upp tabeller i regioner (splittring)<\/h2>\n
    \nEftersom HBase \u00e4r en nyckel-v\u00e4rde lagringsl\u00f6sning och partitioneringen sker baserat p\u00e5 nyckel, \u00e4r det mycket viktigt att f\u00f6rdela data j\u00e4mnt \u00f6ver alla regioner. Till exempel kommer partitionering av en s\u00e5dan tabell i tre delar att resultera i att data delas upp i tre regioner:<\/p>\n
    \"Teori
    \nDet h\u00e4nder att detta leder till en kraftig nedgradering, om den data som laddas in senare mestadels best\u00e5r av long-v\u00e4rden som b\u00f6rjar med samma siffra, till exempel:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Eftersom nycklarna lagras i form av byte-arrayer, kommer alla att b\u00f6rja likadant och tillh\u00f6ra en region #1 som lagrar detta nyckelintervall. Det finns flera strategier f\u00f6r splittring:<\/p>\n
    HexStringSplit \u2013 Konverterar nyckeln till en str\u00e4ng med hexadecimalt kodande inom intervallet \u00ab00000000\u00bb => \u00abFFFFFFFF\u00bb och fyller v\u00e4nster med nollor.<\/p>\n
    UniformSplit \u2013 Konverterar nyckeln till en byte-array med hexadecimalt kodande inom intervallet \u00ab00\u00bb => \u00abFF\u00bb och fyller h\u00f6ger med nollor.<\/p>\n
    Dessutom kan man ange vilket intervall eller upps\u00e4ttning av nycklar som helst f\u00f6r splittring och konfigurera automatisk splittring. Men en av de enklaste och mest effektiva metoderna \u00e4r UniformSplit och att anv\u00e4nda hash-konkatenation, till exempel den h\u00f6gsta byte-paret fr\u00e5n k\u00f6rningen av nyckeln genom CRC32(rowkey) funktionen och sj\u00e4lva rowkey:<\/p>\n
    hash + rowkey<\/p>\n
    D\u00e5 kommer alla data att f\u00f6rdelas j\u00e4mnt \u00f6ver regionerna. Vid l\u00e4sning kastas de f\u00f6rsta tv\u00e5 bytesen helt enkelt bort och den ursprungliga nyckeln kvarst\u00e5r. RS kontrollerar \u00e4ven m\u00e4ngden data och nycklar i regionen och bryter automatiskt upp den i delar n\u00e4r gr\u00e4nserna \u00f6verskrids. <\/p>\n
    7. Felresiliens och datalokalisering<\/h2>\n
    \nEftersom varje nyckelset bara ansvarar f\u00f6r en region \u00e4r l\u00f6sningen p\u00e5 problem relaterade till RS-nederlag eller nedl\u00e4ggning att lagra all n\u00f6dv\u00e4ndig data i HDFS. Vid ett RS-nederlag uppt\u00e4cker master detta genom att inte f\u00e5 n\u00e5gon heartbeat fr\u00e5n ZooKeeper-noden. D\u00e5 tilldelar den en annan RS den drabbade regionen, och eftersom HFiles lagras i ett distribuerat filsystem, s\u00e5 l\u00e4ser den nya \u00e4garen dem och forts\u00e4tter att betj\u00e4na data. Emellertid, eftersom en del data kan vara i MemStore och \u00e4nnu inte har kommit in i HFiles, anv\u00e4nds WAL f\u00f6r att \u00e5terst\u00e4lla operationernas historik, som ocks\u00e5 lagras i HDFS. Efter att f\u00f6r\u00e4ndringar har genomf\u00f6rts kan RS svara p\u00e5 f\u00f6rfr\u00e5gningar, men flyttningen inneb\u00e4r att en del data och processer som hanterar dem hamnar p\u00e5 olika noder, vilket reducerar lokalitet. <\/p>\n
    L\u00f6sningen p\u00e5 problemet \u00e4r major compaction \u2013 denna procedur flyttar filer till de noder som ansvarar f\u00f6r dem (dit d\u00e4r deras regioner ligger), vilket resulterar i att belastningen p\u00e5 n\u00e4tverket och diskarna \u00f6kar kraftigt under denna procedur. Men senare f\u00f6rb\u00e4ttras \u00e5tkomsten till data markant. Dessutom utf\u00f6r major_compaction en sammanslagning av alla HFiles till en enda fil inom regionen och rensar data beroende p\u00e5 tabellinst\u00e4llningarna. Till exempel kan du st\u00e4lla in antalet versioner av ett objekt som ska sparas eller dess livsl\u00e4ngd, efter vilken objektet tas bort fysiskt.<\/p>\n
    Denna procedur kan ha en mycket positiv effekt p\u00e5 HBase:s prestanda. P\u00e5 bilden nedan kan man se hur prestandan f\u00f6rs\u00e4mrades till f\u00f6ljd av aktiv dataskrivning. H\u00e4r syns hur 40 tr\u00e5dar skrev till en tabell och 40 tr\u00e5dar l\u00e4ste data samtidigt. Skrivraven genererar fler och fler HFiles som l\u00e4ses av andra tr\u00e5dar. Som resultat m\u00e5ste allt fler data tas bort fr\u00e5n minnet och till slut startar GC, som i stort sett lamnar hela arbetet. Starten av major compaction ledde till rensning av de uppkomna avlagringarna och \u00e5terst\u00e4llande av prestandan.<\/p>\n
    \"Teori
    \nTestet utf\u00f6rdes p\u00e5 3 DataNode och 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tr\u00e5dar). HBase version 1.2.0-cdh5.14.2<\/p>\n
    Det \u00e4r v\u00e4rt att notera att major compaction k\u00f6rdes p\u00e5 en \"levande\" tabell d\u00e4r data aktivt skrivits och l\u00e4sts. Det har p\u00e5st\u00e5tts p\u00e5 n\u00e4tet att detta kan leda till felaktiga svar vid l\u00e4sning av data. F\u00f6r att verifiera detta startades en process som genererade nya data och skrev dem till tabellen. D\u00e4refter l\u00e4stes dessa data omedelbart och j\u00e4mf\u00f6rdes med det som hade skrivits. Under denna process k\u00f6rdes major compaction cirka 200 g\u00e5nger och inga fel registrerades. Problemet kan eventuellt upptr\u00e4da s\u00e4llan och endast vid h\u00f6g belastning, d\u00e4rf\u00f6r \u00e4r det mer s\u00e4kert att planera stopp av skriv- och l\u00e4sprocesser och utf\u00f6ra rensning f\u00f6r att undvika s\u00e5dana GC-fall.<\/p>\n
    Dessutom p\u00e5verkar major compaction inte tillst\u00e5ndet f\u00f6r MemStore; f\u00f6r att spola dess inneh\u00e5ll till disk och kompaktera m\u00e5ste flush anv\u00e4ndas (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Inst\u00e4llningar och prestanda<\/h2>\n
    \nSom redan n\u00e4mnts visar HBase st\u00f6rst framg\u00e5ng d\u00e4r det inte beh\u00f6ver utf\u00f6ra n\u00e5gra \u00e5tg\u00e4rder, vid anv\u00e4ndning av BulkLoad. Detta g\u00e4ller dock de flesta system och m\u00e4nniskor. Men detta verktyg \u00e4r mer l\u00e4mpligt f\u00f6r massins\u00e4ttning av data i stora block, medan om processen kr\u00e4ver utf\u00f6rande av m\u00e5nga konkurrerande l\u00e4sa- och skrivf\u00f6rfr\u00e5gningar anv\u00e4nds de ovan beskrivna kommandona Get och Put. F\u00f6r att fastst\u00e4lla optimala parametrar genomf\u00f6rdes k\u00f6rningar med olika kombinationer av tabellparametrar och inst\u00e4llningar:<\/p>\n