🥇Kuidas suurendada HBase lugemise kiirus 3 korda ja HDFS 5 korda

Kõrge jõudlus on üks peamisi nõudmisi suurte andmete töötlemisel. Meie andmehalduse meeskond Sberis tegeleb praktiliselt kõigi tehingute edastamisega meie Hadoopi andmepilve ja seega puutume kokku tõeliselt suurte infovoogudega. Loomulikult otsime me pidevalt võimalusi jõudluse parandamiseks ning nüüd tahame rääkida, kuidas suutsime parandada RegionServer HBase ja HDFS-kliendi, mille abil suutsime oluliselt suurendada lugemisoperatsiooni kiirus.

Kuid enne, kui läheme edasi muudatuste tõelise olemuse juurde, tasub rääkida piirangutest, mida on põhimõtteliselt võimatu ületada, kui kasutada HDD-d.

Miks HDD ja kiired juhuslikud lugemised ei sobi kokku
Nagu teada, salvestavad HBase ja paljud muud andmebaasid andmeid plokkidena, mille suurus on mitukümmend kilobaiti. Vaikimisi on see umbes 64 KB. Kujutame nüüd ette, et peame välja tooma vaid 100 baiti ja palume HBase'il need andmed teatud võtme alusel välja anda. Kuna HFiles'i ploki suurus on 64 KB, tellitakse 640 korda rohkem (pange tähele!) kui vajalik.

Edasi liikudes, kuna päring liigub HDFS-i ja selle metaanmete vahemälu mehhanismi kaudu ShortCircuitCache (mis võimaldab otsefailidele juurde pääseda), toob see kaasa lugemise juba 1 MB andmeid kettalt. Siiski saab seda reguleerida parameetriga dfs.client.read.shortcircuit.buffer.size ja paljudes juhtudes on mõistlik seda väärtust vähendada, näiteks 126 KB-ni.

Oletame, et me teeme seda, kuid kui hakkame lugema andmeid java api kaudu, näiteks funktsioonide nagu FileChannel.read abil, ja palume operatsioonisüsteemil lugeda määratud andmemahtu, siis loetakse "igaks juhuks" 2 korda rohkem, st 256 KB meie puhul. See juhtub sellepärast, et javast puudub lihtne võimalus seada lippu FADV_RANDOM, mis takistaks sellist käitumist.

Kokkuvõttes, et saada meie 100 baiti, loetakse mastaabis 2600 korda rohkem. Tundub, et lahendus on ilmne, vähendame ploki suurust kilobaitide kaupa, seame nimetatud lipu ja saavutame suurepärase kiirenduse. Kuid probleem on selles, et ploki suurust vähendades vähendame ka lugemisvõimekust ajavahemiku jooksul sama palju.

Mõningast kasu FADV_RANDOM lipu seadmisest võib saada, kuid ainult suure mitme lõime korral ja ploki suuruse korral alates 128 Kb, kuid see on maksimaalselt paar tosinat protsenti:

Testid viidi läbi 100 failiga, igaüks 1 GB suurune ja paigutatud 10 HDD kettale.

Arvestagem, millega me sellise kiiruseta üldse arvestada saame:
Oletame, et loeme 10 kettalt kiirusel 280 MB/s, st 3 miljonit korda 100 baiti. Kuid nagu me mäletame, on andmed, mida me vajame, 2600 korda vähem, kui loetud. Seega jagame 3 miljonit 2600-ga ja saame 1100 kirjet sekundis.

Kurvastav, eks? Nii on lood Juhusliku juurdepääsu andmetele HDD-l — sõltumata ploki suurusest. See on füüsiline piir juhusliku juurdepääsu puhul ja suuremat ei suuda sellistes tingimustes ükski andmebaas välja pigistada.

Kuidas siis andmebaasid suudavad palju kõrgemat kiirus saavutada? Selle küsimuse vastamiseks vaatame, mis toimub järgmisel pildil:

Siin näeme, et esimestel minutitel on kiirus tõepoolest ligikaudu tuhat kirjet sekundis. Kuid hiljem, kuna loetakse märkimisväärselt rohkem, kui on seadistatud, jäävad andmed operatsioonisüsteemi (Linux) buff/cache'i ning kiirus tõuseb enam-vähem 60 000-ni sekundis.

Seega vaatame edaspidi, kuidas kiirusel juurde pääseda ainult neile andmetele, mis on operatsioonisüsteemi cache'is või samalaadsetes, näiteks SSD/NVMe salvestites.

Meie puhul teeme teste nelja serveri seadistusel, millest igaühes on järgmine konfiguratsioon:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 lõime.
Mälu: 730 GB.
java versioon: 1.8.0_111

Ja siin on tõeliselt oluline hetk — andmete maht tabelites, mida tuleb lugeda. Asi on selles, et kui lugeda andmeid tabelist, mis mahub täielikult HBase'i cache'i, siis ei jõua isegi operatsioonisüsteemi buff/cache'i lugemine. Sest HBase eraldab vaikimisi 40% mälust struktuurile, mida nimetatakse BlockCache'iks. Sisuliselt on see ConcurrentHashMap, kus võti on failinimi + ploki hüvitamine ja väärtus on tegelikult andmed selle hüvitamise kohta.

Seetõttu, kui lugemine toimub ainult sellest struktuurist, me näeme suurepärast kiirus, umbes miljoni päringuga sekundis. Kuid kujutame ette, et me ei saa anda sadu gigabaiti mälu ainult andmebaasi vajadustele, kuna nendel serveritel töötab ka palju muud kasulikku.

Näiteks meie juhul on ühe RS BlockCache'i maht umbes 12 GB. Me oleme kaks RS-d ühele sõlmele installinud, st BlockCache'ile on eraldatud kokku 96 GB kõigil sõlmedel. Andmeid on aga palju rohkem, oletame, et need on 4 tabelit, 130 piirkonnas, milles failide suurus on 800 MB, kokkutõmmatud FAST_DIFF meetodil, st kokku 410 GB (need on puhtad andmed, st replikatsiooni tegurit arvesse võtmata).

Seega moodustavad BlockCache vaid umbes 23% kogu andmete mahust ja see on palju lähemal reaalsetele tingimustele, mida nimetatakse BigData'ks. Ja siin algab kõige huvitavam — on ju selge, et mida vähem on pääsukesi vahemälus, seda halvem on jõudlus. Sest kui vahemälu ei toimi, tuleb teha palju tööd — st minna süsteemsete funktsioonide kutsumise tasemeni. Kuid sellest ei saa mööda ja seega vaatame hoopis teist aspekti — mis juhtub andmetega vahemälus?

Lihtsustame olukorda ja oletame, et meil on vahemälu, kuhu mahtub ainult 1 objekt. Siin on näide sellest, mis juhtub, kui proovime töötada andmemahtudega, mis on 3 korda suuremad kui vahemälu, peame:

1. Asetama ploki 1 vahemällu
2. Eemaldama ploki 1 vahemälust
3. Asetama ploki 2 vahemällu
4. Eemaldama ploki 2 vahemälust
5. Asetama ploki 3 vahemällu

Tehti 5 toimingut! Kuid normaalne ei saa seda olukorda kuidagi nimetada, põhimõtteliselt paneme HBase'i tegema hunniku täiesti kasutut tööd. Ta loeb pidevalt andmeid operatsioonisüsteemi vahemälust, asetab need endale BlockCache'i, et peaaegu kohe need kõrvale visata, kuna saabub uus andmepakett. Postituse alguses olev animatsioon näitab probleemi olemust — Garbage Collector töötab üle, atmosfäär soojeneb, väike Greta kaugel kuumas Rootsis on mures. Ja meie, IT spetsialistid, ei armasta väga, kui lapsed on kurvad, seega hakkame mõtlema, mida selle probleemiga ette võtta.

Aga mis siis, kui asetada vahemällu mitte kõiki plokkide, vaid ainult teatud protsent neist, et vahemälu ei oleks ületäidetud? Alustame lihtsalt paar rida koodi lisamisega funktsiooni alguses, mis asetab andmed BlockCache'i:

  public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
    if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
      if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
        return;
      }
    }
...

Siin on mõte järgmine: ofset on ploki asukoht failis ja viimased numbrid on juhuslikult ja ühtlaselt jaotatud vahemikus 00 kuni 99. Seetõttu jätame vahele vaid need, mis jäävad soovitud vahemikku.

Näiteks seadke cacheDataBlockPercent = 20 ja vaatame, mis juhtub:

Tulemus on käes. Allolevatelt graafikutelt nähtub, kuidas kiirus on saavutatud — säästame hulga GC ressursse, et mitte tegeleda sisefilosoofia tööga, et andmed vahemälu paigutada, ainult selleks, et visata need marsi koertele saba alla:

CPU kasutamine kasvab, kuid oluliselt vähem kui tootlikkus:

Siin tasub veel märkida, et BlockCache'is hoitavad plokid võivad olla erinevad. Enamik, umbes 95%, on tegelikult andmed. Ülejäänud on metaandmed, näiteks Bloom filtri või LEAF_INDEX ja jne.. Nende andmete on vähe, kuid need on väga kasulikud, kuna enne, kui pöörduda otse andmete poole, pöördub HBase meta poole, et mõista, kas on vaja otsida edasi ja kui jah, siis kus täpselt asub huvipakkuv plokk.

Seetõttu näeme koodis tingimust, mis kontrollib buf.getBlockType().isData() ja tänu sellele metale jätame me vahemälu igal juhul.

Nüüd suurendame koormust ja samal ajal pisut kohandame funktsiooni. Esimeses testis seadsime lõikeprotsendi = 20 ja BlockCache oli veidi alakoormatud. Nüüd seadke 23% ja lisame 100 niiti iga 5 minuti järel, et näha, millal toimub küllastus:

Siin näeme, et algversioon jõuab peaaegu kohe piiri 100 tuhat päringut sekundis. Samas, patch annab kiiruseni 300 tuhat. Samal ajal on selge, et edasine kiirus ei ole enam nii 'tasuta', CPU kasutamine kasvab samuti.

Kuid see pole väga elegantne lahendus, kuna me ei tea ette, kui suur protsent plokke on vaja vahemälu salvestada, see sõltub koormuse profiilist. Seetõttu on realiseeritud mehhanism selle parameetri automaatseks kohandamiseks lugemisoperatsioonide aktiivsuse põhjal.

Selle haldamiseks on lisatud kolm parameetrit:

hbase.lru.cache.heavy.eviction.count.limit — seabestab, mitu korda tuleb andmete eemaldamise protsess töösse võtta enne, kui hakkame kasutama optimeerimist (st vahevälistama plokke). Vaikimisi on see MAX_INT = 2147483647 ja tähendab tegelikult, et funktsioon ei hakka kunagi nii suure väärtuse korral tööle. Kuna andmete eemaldamine käivitub iga 5–10 sekundi järel (sõltub koormusest) ja 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 aastat. Siiski saame selle parameetri seadistada 0 peale, mis sunnib funktsiooni kohe pärast käivitamist tööle.

Kuid selle parameetri puhul on ka kasulik koormus. Kui meie koormusetüüp tähendab, et lühiajalised lugemised (näiteks päeval) ja pikaajalised (öösiti) vahelduvad pidevalt, saame teha nii, et funktsioon aktiveerub ainult siis, kui käivad pikaajalised lugemised.

Näiteks me teame, et lühiajalised lugemised kestavad tavaliselt umbes 1 minuti. Siis ei tohiks alustada plokkide eemaldamist, kuna vahemälu ei jõua aeguda ja saame määrata selle parameetri näiteks 10. See tähendab, et optimeerimine hakkab tööle alles siis, kui on alanud pikaajaline aktiivne lugemine, st 100 sekundi pärast. Seega, kui meil on lühiajaline lugemine, pääsevad kõik plokid vahemällu ja on kergesti kättesaadavad (välja arvatud need, mis eemaldatakse standardse algoritmi poolt). Kui aga teeme pikaajalisi lugemisi, hakkab funktsioon tööle ja meil on tunduvalt kõrgem jõudlus.

hbase.lru.cache.heavy.eviction.mb.size.limit — seab, kui palju megabaiti soovime vahemällu paigutada (ja loomulikult eemaldada) 10 sekundi jooksul. Funktsioon püüab saavutada seda väärtust ja hoida seda. Idee on järgmine: kui paneme vahemällu gigabaite, peame ka eemaldama gigabaite, mis nagu me eespool nägime, on üsna kulukas. Samuti ei tohiks proovida seda määrata liiga väikseks, kuna see viib plokkide vahelt ära jäämise režiimist varakult väljumiseni. Tugevatele serveritele (20-40 füüsilise tuumaga) on ideaalne seada umbes 300-400 MB. Keskmise klassi (~10 tuuma) puhul 200-300 MB. Nõrgematele süsteemidele (2-5 tuuma) võib olla normaalne 50-100 MB (selliseid pole testitud).

Vaatame, kuidas see töötab: oletame, et oleme seadnud hbase.lru.cache.heavy.eviction.mb.size.limit = 500, toimub mingi koormus (lugemine) ja siis iga ~10 sekundi järel arvutame, kui palju baite on välja visatud järgmise valemi järgi:

Overhead = Vabastatud baitide kogus (MB) * 100 / Limiit (MB) — 100;

Kui tegelikult on välja visatud 2000 MB, siis Overhead on:

2000 * 100 / 500 — 100 = 300%

Algoritmid püüavad hoida üle 10% ei rohkem, nii et funktsioon vähendab vahemälu blokeeringute protsenti, rakendades sellega automaatse häälestamise mehhanismi.

Kuid kui koormus on langenud, oletame, et välja on visatud ainult 200 MB ja Overhead on muutunud negatiivseks (nn overshooting):

200 * 100 / 500 — 100 = -60%

Siis funktsioon vastupidi, suurendab vahemälu blokeeringute protsenti, kuni Overhead muutub positiivseks.

Allpool on näide, kuidas see tegelike andmete põhjal välja näeb. Ei tohiks püüda saavutada 0%, see on võimatu. Üsna hea, kui see on umbes 30–100%, see aitab vältida enneaegset eemaldumist optimeerimisrežiimist lühiajaliste tõusude korral.

hbase.lru.cache.heavy.eviction.overhead.coefficient — määrab, kui kiiresti soovime tulemust saada. Kui me teame kindlasti, et meie lugemine on peamiselt pikk ja me ei soovi oodata, saame seda koefitsienti suurendada ja saavutada kõrge jõudluse kiiremini.

Näiteks oleme seadnud selle koefitsiendi = 0.01. See tähendab, et Overhead (vt ülal) korrutatakse selle numbriga ja saadud tulemusena väheneb vahemälu blokeeringute protsent. Oletame, et Overhead = 300%, ja koefitsient = 0.01, siis vahemälu blokeeringute protsent väheneb 3%.

Sarnane «Backpressure» loogika on rakendatud ka negatiivsete Overhead väärtuste (overshooting) jaoks. Kuna lühiajalised kõikumised lugemiste ja välja viskamiste mahtudes on alati võimalikud, võimaldab see mehhanism vältida enneaegset eemaldumist optimeerimisrežiimist. Backpressure'l on pööratud loogika: mida tugevam on overshooting, seda rohkem blokeeringuid on vahemälus.

Rakenduskood

        LruBlockCache cache = this.cache.get();
        if (cache == null) {
          break;
        }
        freedSumMb += cache.evict() / 1024 / 1024;
        /*
        * Mõnikord loeme me rohkem andmeid, kui BlockCache mahutab
        * ja see on põhjus kõrgele evakueerimise määrale.
        * See omakorda viib tugeva prügikoguja töödeni.
        * Nii et palju plokke pannakse BlockCache'i, aga ei loeta,
        * kulutades palju CPU ressursse.
        * Siin analüüsime, kui palju octette on vabastatud ja otsustame,
        * kas on aeg vähendada vaheblokkide kogust.
        * See aitab vältida liigset vaheblokkide kogumist BlockCache'i,
        * kui evict() töötab väga aktiivselt ja säästab CPU-d teiste tööde jaoks.
        * Lisainfot: https://issues.apache.org/jira/browse/HBASE-23887
        */

        // Esiteks peame kontrollima, kui kaua aega
        // on möödunud eelmisest evict() teostamisest
        // See peaks olema peaaegu sama aeg (+/- 10s)
        // kuna saame iga kord vabastatud baitide sarnase mahu.
        // 10s, kuna see on vaikimisi periood evict() käivitamiseks (vt eespool this.wait)
        long stopTime = System.currentTimeMillis();
        if ((stopTime - startTime) > 1000 * 10 - 1) {
          // Siin peame arvutama, milline olukord meil on.
          // Meil on piir "hbase.lru.cache.heavy.eviction.bytes.size.limit"
          // ja saame selle ülehinnangu arvutada.
          // Kasutame seda teavet, et otsustada,
          // kuidas muuta vaheblokkide protsenti.
          freedDataOverheadPercent =
            (int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
          if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
            // Nüüd oleme olukorras, kus oleme piirist üle
            // Kuid võib-olla ignoreerime seda, sest see lõppeb üsna pea
            heavyEvictionCount++;
            if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
              // See kestab kaua ja peame nüüd vaheblokkide
              // kogust vähendama.
              // Siin arvutame, kui palju plokke soovime vahele jätta.
              // See sõltub:
             // 1. Ülehindamine - kui ülehindamine on suur, saame olla agressiivsemad
              // vaheblokkide vähendamisel.
              // 2. Kui kiiresti soovime tulemust saada. Kui teame, et meie
              // raske lugemine kestab kaua, ei soovi me oodata ja saame
              // koefitsienti suurendada ning head tulemuslikkust üsna pea.
              // Kuid kui me ei ole kindlad, saame teha seda aeglaselt ja see võib
              // vältida enneaegset lahkumist sellest režiimist. Seega, kui koefitsient on
              // kõrgem, saame paremat tulemuslikkust, kui raske lugemine on stabiilne.
              // Aga kui lugemine muutub, saame sellele kohanduda ja seada
              // koefitsient madalamale väärtusele.
              int change =
                (int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
              // Kuid praktika näitab, et 15% vähendamine on täiesti piisav.
              // Me ei ole ahned (see võib viia enneaegsele lahkumisele).
              change = Math.min(15, change);
              change = Math.max(0, change); // Ma arvan, et see ei juhtu kunagi, kuid kontrolli igaks juhuks
              // Nii et see on võtmepunkt, siin vähendame % vaheblokkidest
              cache.cacheDataBlockPercent -= change;
              // Kui me läheme liiga madalale, peame siin peatuma, 1% peaks olema igal juhul.
              cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
            }
          } else {
            // Noh, oleme saanud ületäitmise.
            // Võib-olla on see lihtsalt lühiajaline kõikumine ja saame jääda sellesse režiimi.
            // See aitab vältida enneaegset lahkumist lühiajaliste kõikumiste tõttu.
            // Kui ületäitmine on vähem kui 90%, proovime tõsta vaheblokkide
            // protsenti ja loodame, et see on piisav.
            if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
              // Lihtne loogika: rohkem ületäitmist - rohkem vahebloke (tagasisurve)
              int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
              cache.cacheDataBlockPercent += change;
              // Kuid see ei saa olla rohkem kui 100%, seega kontrollime seda.
              cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
            } else {
              // Tundub, et raske lugemine on läbi.
              // Lihtsalt lahkume sellest režiimist.
              heavyEvictionCount = 0;
              cache.cacheDataBlockPercent = 100;
            }
          }
          LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +
            "heavy eviction counter: {}, " +
            "current caching DataBlock (%): {}",
            freedSumMb, freedDataOverheadPercent,
            heavyEvictionCount, cache.cacheDataBlockPercent);

          freedSumMb = 0;
          startTime = stopTime;
       }

Vaatame nüüd kõike seda reaalse näite kaudu. Meil on järgmine teststsenaarium:

Alustame Scan'i tegemisega (25 lõime, partii = 100)
Viie minuti pärast lisame multi-gets (25 lõime, partii = 100)
Viie minuti pärast peatame multi-gets'i (jääb jälle ainult scan)

Teeme kaks katset, esiteks hbase.lru.cache.heavy.eviction.count.limit = 10000 (mis põhimõtteliselt keelab funktsiooni), seejärel seadistame limiidi = 0 (lülitab sisse).

Allpool logides näeme, kuidas funktsioon aktiveeritakse, Overshooting langeb 14-71% peale. Aeg-ajalt koormus väheneb, mis aktiveerib Backpressure ja HBase salvestab rohkem bloke.

RegionServeri logi
evicted (MB): 0, suhe 0.0, lisakulu (%): -100, raske evakueerimise arvesti: 0, praegune andmeploki salvestamine (%): 100
evicted (MB): 0, suhe 0.0, lisakulu (%): -100, raske evakueerimise arvesti: 0, praegune andmeploki salvestamine (%): 100
evicted (MB): 2170, suhe 1.09, lisakulu (%): 985, raske evakueerimise arvesti: 1, praegune andmeploki salvestamine (%): 91 < start
evicted (MB): 3763, suhe 1.08, lisakulu (%): 1781, raske evakueerimise arvesti: 2, praegune andmeploki salvestamine (%): 76
evicted (MB): 3306, suhe 1.07, lisakulu (%): 1553, raske evakueerimise arvesti: 3, praegune andmeploki salvestamine (%): 61
evicted (MB): 2508, suhe 1.06, lisakulu (%): 1154, raske evakueerimise arvesti: 4, praegune andmeploki salvestamine (%): 50
evicted (MB): 1824, suhe 1.04, lisakulu (%): 812, raske evakueerimise arvesti: 5, praegune andmeploki salvestamine (%): 42
evicted (MB): 1482, suhe 1.03, lisakulu (%): 641, raske evakueerimise arvesti: 6, praegune andmeploki salvestamine (%): 36
evicted (MB): 1140, suhe 1.01, lisakulu (%): 470, raske evakueerimise arvesti: 7, praegune andmeploki salvestamine (%): 32
evicted (MB): 913, suhe 1.0, lisakulu (%): 356, raske evakueerimise arvesti: 8, praegune andmeploki salvestamine (%): 29
evicted (MB): 912, suhe 0.89, lisakulu (%): 356, raske evakueerimise arvesti: 9, praegune andmeploki salvestamine (%): 26
evicted (MB): 684, suhe 0.76, lisakulu (%): 242, raske evakueerimise arvesti: 10, praegune andmeploki salvestamine (%): 24
evicted (MB): 684, suhe 0.61, lisakulu (%): 242, raske evakueerimise arvesti: 11, praegune andmeploki salvestamine (%): 22
evicted (MB): 456, suhe 0.51, lisakulu (%): 128, raske evakueerimise arvesti: 12, praegune andmeploki salvestamine (%): 21
evicted (MB): 456, suhe 0.42, lisakulu (%): 128, raske evakueerimise arvesti: 13, praegune andmeploki salvestamine (%): 20
evicted (MB): 456, suhe 0.33, lisakulu (%): 128, raske evakueerimise arvesti: 14, praegune andmeploki salvestamine (%): 19
evicted (MB): 342, suhe 0.33, lisakulu (%): 71, raske evakueerimise arvesti: 15, praegune andmeploki salvestamine (%): 19
evicted (MB): 342, suhe 0.32, lisakulu (%): 71, raske evakueerimise arvesti: 16, praegune andmeploki salvestamine (%): 19
evicted (MB): 342, suhe 0.31, lisakulu (%): 71, raske evakueerimise arvesti: 17, praegune andmeploki salvestamine (%): 19
evicted (MB): 228, suhe 0.3, lisakulu (%): 14, raske evakueerimise arvesti: 18, praegune andmeploki salvestamine (%): 19
evicted (MB): 228, suhe 0.29, lisakulu (%): 14, raske evakueerimise arvesti: 19, praegune andmeploki salvestamine (%): 19
evicted (MB): 228, suhe 0.27, lisakulu (%): 14, raske evakueerimise arvesti: 20, praegune andmeploki salvestamine (%): 19
evicted (MB): 228, suhe 0.25, lisakulu (%): 14, raske evakueerimise arvesti: 21, praegune andmeploki salvestamine (%): 19
evicted (MB): 228, suhe 0.24, lisakulu (%): 14, raske evakueerimise arvesti: 22, praegune andmeploki salvestamine (%): 19
evicted (MB): 228, suhe 0.22, lisakulu (%): 14, raske evakueerimise arvesti: 23, praegune andmeploki salvestamine (%): 19
evicted (MB): 228, suhe 0.21, lisakulu (%): 14, raske evakueerimise arvesti: 24, praegune andmeploki salvestamine (%): 19
evicted (MB): 228, suhe 0.2, lisakulu (%): 14, raske evakueerimise arvesti: 25, praegune andmeploki salvestamine (%): 19
evicted (MB): 228, suhe 0.17, lisakulu (%): 14, raske evakueerimise arvesti: 26, praegune andmeploki salvestamine (%): 19
kustutatud (MB): 456, suhe 0.17, ülekoormus (%): 128, suur kustutamise arv: 27, praegune vahemälu DataBlock (%): 18 < lisatud saadetised (aga tabel sama)
kustutatud (MB): 456, suhe 0.15, ülekoormus (%): 128, suur kustutamise arv: 28, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 342, suhe 0.13, ülekoormus (%): 71, suur kustutamise arv: 29, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 342, suhe 0.11, ülekoormus (%): 71, suur kustutamise arv: 30, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 342, suhe 0.09, ülekoormus (%): 71, suur kustutamise arv: 31, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 228, suhe 0.08, ülekoormus (%): 14, suur kustutamise arv: 32, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 228, suhe 0.07, ülekoormus (%): 14, suur kustutamise arv: 33, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 228, suhe 0.06, ülekoormus (%): 14, suur kustutamise arv: 34, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 228, suhe 0.05, ülekoormus (%): 14, suur kustutamise arv: 35, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 228, suhe 0.05, ülekoormus (%): 14, suur kustutamise arv: 36, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 228, suhe 0.04, ülekoormus (%): 14, suur kustutamise arv: 37, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 109, suhe 0.04, ülekoormus (%): -46, suur kustutamise arv: 37, praegune vahemälu DataBlock (%): 22 < tagasisurve
kustutatud (MB): 798, suhe 0.24, ülekoormus (%): 299, suur kustutamise arv: 38, praegune vahemälu DataBlock (%): 20
kustutatud (MB): 798, suhe 0.29, ülekoormus (%): 299, suur kustutamise arv: 39, praegune vahemälu DataBlock (%): 18
kustutatud (MB): 570, suhe 0.27, ülekoormus (%): 185, suur kustutamise arv: 40, praegune vahemälu DataBlock (%): 17
kustutatud (MB): 456, suhe 0.22, ülekoormus (%): 128, suur kustutamise arv: 41, praegune vahemälu DataBlock (%): 16
kustutatud (MB): 342, suhe 0.16, ülekoormus (%): 71, suur kustutamise arv: 42, praegune vahemälu DataBlock (%): 16
kustutatud (MB): 342, suhe 0.11, ülekoormus (%): 71, suur kustutamise arv: 43, praegune vahemälu DataBlock (%): 16
kustutatud (MB): 228, suhe 0.09, ülekoormus (%): 14, suur kustutamise arv: 44, praegune vahemälu DataBlock (%): 16
kustutatud (MB): 228, suhe 0.07, ülekoormus (%): 14, suur kustutamise arv: 45, praegune vahemälu DataBlock (%): 16
kustutatud (MB): 228, suhe 0.05, ülekoormus (%): 14, suur kustutamise arv: 46, praegune vahemälu DataBlock (%): 16
kustutatud (MB): 222, suhe 0.04, ülekoormus (%): 11, suur kustutamise arv: 47, praegune vahemälu DataBlock (%): 16
kustutatud (MB): 104, suhe 0.03, ülekoormus (%): -48, suur kustutamise arv: 47, praegune vahemälu DataBlock (%): 21 < katkendlik saadetis
kustutatud (MB): 684, suhe 0.2, ülekoormus (%): 242, suur kustutamise arv: 48, praegune vahemälu DataBlock (%): 19
kustutatud (MB): 570, suhe 0.23, ülekoormus (%): 185, suur kustutamise arv: 49, praegune vahemälu DataBlock (%): 18
kustutatud (MB): 342, suhe 0.22, ülekoormus (%): 71, suur kustutamise arv: 50, praegune vahemälu DataBlock (%): 18
kustutatud (MB): 228, suhe 0.21, ülekoormus (%): 14, suur kustutamise arv: 51, praegune vahemälu DataBlock (%): 18
kustutatud (MB): 228, suhe 0.2, ülekoormus (%): 14, suur kustutamise arv: 52, praegune vahemälu DataBlock (%): 18
kustutatud (MB): 228, suhe 0.18, ülekoormus (%): 14, suur kustutamise arv: 53, praegune vahemälu DataBlock (%): 18
kustutatud (MB): 228, suhe 0.16, ülekoormus (%): 14, suur kustutamise arv: 54, praegune vahemälu DataBlock (%): 18
kustutatud (MB): 228, suhe 0.14, ülekoormus (%): 14, suur kustutamise arv: 55, praegune vahemälu DataBlock (%): 18
kustutatud (MB): 112, suhe 0.14, ülekoormus (%): -44, suur kustutamise arv: 55, praegune vahemälu DataBlock (%): 23 < tagasisurve
kustutatud (MB): 456, suhe 0.26, ülekoormus (%): 128, suur kustutamise arv: 56, praegune vahemälu DataBlock (%): 22
kustutatud (MB): 342, suhe 0.31, ülekoormus (%): 71, suur kustutamise arv: 57, praegune vahemälu DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 58, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 59, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 60, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 61, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 62, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 63, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.32, overhead (%): 71, heavy eviction counter: 64, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 65, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 66, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.32, overhead (%): 71, heavy eviction counter: 67, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 68, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.32, overhead (%): 71, heavy eviction counter: 69, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.32, overhead (%): 71, heavy eviction counter: 70, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 71, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 72, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 73, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 74, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 75, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 76, current caching DataBlock (%): 22
evicted (MB): 21, ratio 0.33, overhead (%): -90, heavy eviction counter: 76, current caching DataBlock (%): 32
evicted (MB): 0, suhe 0.0, lisakulu (%): -100, raske evakueerimise arvesti: 0, praegune andmeploki salvestamine (%): 100
evicted (MB): 0, suhe 0.0, lisakulu (%): -100, raske evakueerimise arvesti: 0, praegune andmeploki salvestamine (%): 100

Skane oli vajalikud, et näidata sama protsessi diagrammina kahe vahe peatükiga — single (kuhu pääsevad plokid, mida pole kunagi keegi küsinud) ja multi (siin hoitakse andmeid, mida on vähemalt korra nõutud):

Ja lõpuks, kuidas näevad parameetrite tulemused välja diagrammina. Võrdlemiseks oli vahe esimese etapi alguses täiesti välja lülitatud, seejärel käivitati HBase koos vahemälu ja 5-minutilise optimeerimise viivitusega (30 väljaüürimist).

Täiskood on saadaval Pull Requestis HBASE 23887 githubis.

Kuid 300 tuhat lugemist sekundis pole kõik, mida sellistes tingimustes selle riistvara pealt välja pigistada saab. Asi on selles, et kui andmetele tuleb pöörduda läbi HDFS-i, kasutatakse mehhanismi ShortCircuitCache (edaspidi SSC), mis võimaldab andmetele otsese juurdepääsu, vältides võrgusuhtluse kasutamist.

Profiling showed that although this mechanism provides a significant gain, it also becomes a bottleneck at some point, as nearly all heavy operations occur within the lock, leading to blocks most of the time.

Realizing this, we understood that the problem could be circumvented by creating an array of independent SSC:

private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
  this.shortCircuitCache[i] = new ShortCircuitCache(…);

And then work with them, excluding overlaps also by the last digit of the offset:

public ShortCircuitCache getShortCircuitCache(long idx) {
    return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}

Now we can proceed to the tests. For this, we will read files from HDFS using a simple multithreaded application. We set the parameters:

conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // default = 1 MB and this significantly slows down reading, so it’s better to adjust it according to actual needs
conf.set("dfs.client.short.circuit.num", num); // from 1 to 10

And just read the files:

FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i  900000000)
        position = 0L;
    int res = in.read(position, byteBuffer, 0, 65536);
}

This code runs in separate threads and we will increase the number of simultaneously read files (from 10 to 200 — horizontal axis) and the number of caches (from 1 to 10 — graphs). The vertical axis shows the acceleration gained from increasing SSC compared to the case when there is only one cache.

How to read the graph: the time taken for 100 thousand reads in blocks of 64 KB with one cache requires 78 seconds. Whereas with 5 caches, it is performed in 16 seconds. That is, there’s an acceleration of about 5 times. As seen from the graph, at a small number of parallel reads, the effect is not very noticeable; it begins to play a significant role when the number of reading threads exceeds 50. It is also noticeable that increasing the number of SSCs from 6 and above gives significantly less performance gain.

Note 1: Since the test results are quite volatile (see below), 3 runs were conducted and the obtained values were averaged.

Note 2: The performance increase from tuning for random access is the same, although the access itself is slightly slower.

Siiski on oluline märkida, et erinevalt HBase'ist ei ole see kiirusetõus alati tasuta. Siin me rohkem „vabastame“ CPU võimalusi töö tegemiseks, selle asemel et jääda lukustatud olukordadesse.

Siin on näha, et üldiselt toob vahemike arvu suurenemine ligikaudu proportsionaalse kasvu CPU-utiliseerimises. Siiski on mõned kombinatsioonid, mis on kasumlikumad.

Näiteks vaatame lähemalt SSC = 3 seadistust. Jõudluse kasv vahemikus on umbes 3,3 korda. Allpool on tulemused kolmest eraldi käivitamisest.

Samas suureneb CPU tarbimine ligikaudu 2,8 korda. Erinevus pole väga suur, kuid väikese Grete jaoks on see rõõm ja ehk tekib aeg, et osaleda koolitundides.

Seega on sellel positiivne mõju igale tööriistale, mis kasutab masstest HDFS-i (näiteks Spark jne), eeldusel et rakenduskood on kerge (st tõke on HDFS-i kliendi poolel) ning CPU-l on vaba võimsus. Kontrollimiseks testime, milline efekt on BlockCache optimeerimise ja SSC-tuning'i ühisrakendamisel HBase'ist lugemisel.

Siin on näha, et sellistes tingimustes pole efekt nii suur kui rafineeritud testides (lugemine ilma igasuguse töötlemiseta), kuid veel 80k saavutamine on täiesti võimalik. Koos annavad mõlemad optimeerimised kuni 4-kordse kiirusetõusu.

Selle optimeerimise kohta tehti ka PR [HDFS-15202], mis sai kinnitatud ja see funktsionaalsus on järgmistes versioonides saadaval.

Viimaseks oli huvitav võrrelda sarnaste wide-column andmebaaside Cassandra ja HBase lugemisjõudlust.

Selleks käivitati standardse koormustestimise utiliidi YCSB eksemplarid kahest hostist (kokku 800 lõime). Serveripooles oli 4 RegionServeri ja Cassandra eksemplari 4 hostis (mitte mingites, kus kliendid on käimas, et vältida nende mõju). Lugemine toimus tabelitest, mille suurus oli:

HBase — 300 GB HDFS-is (100 GB puhast andmeid)

Cassandra — 250 GB (replication factor = 3)

St, maht oli umbes sama (HBase'is oli veidi rohkem).

HBase parameetrid:

dfs.client.short.circuit.num = 5 (HDFS kliendi optimeerimine)

hbase.lru.cache.heavy.eviction.count.limit = 30 — see tähendab, et plaastrid hakkavad töötama 30 välja viskamise järel (~5 minutit)

hbase.lru.cache.heavy.eviction.mb.size.limit = 300 — sihtmaht, mida vahetatakse ja visatakse välja

YCSB logid töödeldi ja tuvastati Exceli graafikutesse:

Nagu näha, võimaldavad optimeerimisandmed saavutada nende andmebaaside võrdse jõudluse nii tingimustes ja jõuda 450 tuhandeni lugemistes sekundis.

Loodame, et see teave on kedagi aidanud põnevas madinas jõudluse nimel.

Allikas: habr.com

Kuidas suurendada HBase lugemise kiirus kolme ja HDFS lugemise kiirus viiega