Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Tá ardfheidhmíocht ar cheann de na príomhriachtanais nuair a bhíonn tú ag obair le sonraí móra. Sa roinn luchtaithe sonraí ag Sberbank, déanaimid beagnach gach idirbheart a chaidéil isteach inár n-Scamall Sonraí atá bunaithe ar Hadoop agus mar sin déileálaimid le sreafaí mór faisnéise. Ar ndóigh, táimid i gcónaí ag lorg bealaí chun feidhmíocht a fheabhsú, agus anois ba mhaith linn a insint duit conas a d'éirigh linn HBase RegionServer agus an cliant HDFS a phaisteáil, a bhuíochas sin bhíomar in ann luas na n-oibríochtaí léite a mhéadú go suntasach.
Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Mar sin féin, sula dtéann tú ar aghaidh go dtí croílár na bhfeabhsuithe, is fiú labhairt faoi shrianta nach féidir, i bprionsabal, dul timpeall orthu má shuíonn tú ar HDD.

Cén fáth nach bhfuil léamha HDD agus Rochtana Randamach tapa ag luí
Mar is eol duit, déanann HBase, agus go leor bunachair shonraí eile, sonraí a stóráil i mbloic de na deicheanna cilibheart i méid. De réir réamhshocraithe tá sé thart ar 64 KB. Anois, déanaimis a shamhlú nach mór dúinn ach 100 bytes a fháil agus iarraimid ar HBase na sonraí seo a thabhairt dúinn ag baint úsáide as eochair áirithe. Ós rud é gurb é méid na mbloc in HFiles ná 64 KB, beidh an t-iarratas 640 uair níos mó (ach nóiméad!) ná mar is gá.

Ansin, toisc go rachaidh an t-iarratas trí HDFS agus a mheicníocht taisce meiteashonraí ShortCircuitCache (a cheadaíonn rochtain dhíreach ar chomhaid), dá bharr seo go léitear 1 MB ón diosca cheana féin. Mar sin féin, is féidir é seo a choigeartú leis an bparaiméadar dfs.cliant.léamh.shortchiorcaid.méid agus i go leor cásanna bíonn ciall leis an luach seo a laghdú, mar shampla go 126 KB.

Ligean le rá go ndéanaimid é seo, ach ina theannta sin, nuair a thosaímid ag léamh sonraí tríd an api java, mar fheidhmeanna cosúil le FileChannel.read agus iarr ar an gcóras oibriúcháin an méid sonraithe sonraí a léamh, léann sé "ar eagla na heagla" 2 uair níos mó , i.e. 256 KB inár gcás. Tá sé seo amhlaidh toisc nach bhfuil bealach éasca ag java an bhratach FADV_RANDOM a shocrú chun an iompar seo a chosc.

Mar thoradh air sin, chun ár 100 beart a fháil, léitear 2600 uair níos mó faoin gcochall. Dhealródh sé go bhfuil an réiteach soiléir, déanaimis an méid bloc a laghdú go cilibheart, socraigh an bhratach atá luaite agus faighimid luasghéarú mór ar an tsolais. Ach is é an deacracht atá ann, trí mhéid an bhloc a laghdú faoi 2 uair, go laghdóimid freisin líon na mbeart a léitear in aghaidh an aonaid ama faoi 2 uair.

Is féidir roinnt gnóthachain a bhaint as an mbratach FADV_RANDOM a shocrú, ach amháin le il-snáithe ard agus le blocmhéid de 128 KB, ach seo cúpla deich faoin gcéad ar a mhéad:

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Rinneadh tástálacha ar 100 comhad, gach ceann de 1 GB i méid agus iad suite ar 10 HDD.

Déanaimis a ríomh cad is féidir linn, i bprionsabal, a áireamh ar an luas seo:
Ligean le rá go léann muid ó 10 dioscaí ar luas 280 MB/soic, i.e. 3 mhilliún uair 100 bytes. Ach de réir mar a chuimhnímid, tá na sonraí a theastaíonn uainn 2600 uair níos lú ná an méid a léitear. Mar sin, roinnimid 3 mhilliún ar 2600 agus faighimid 1100 taifead in aghaidh an tsoicind.

Diabhaltach, nach ea? Sin é nádúr Rochtain randamach rochtain ar shonraí ar an HDD - beag beann ar mhéid an bhloc. Is é seo teorainn fhisiciúil na rochtana randamacha agus ní féidir le haon bhunachar sonraí brú amach níos mó faoi na coinníollacha sin.

Conas mar sin a bhaineann bunachair shonraí amach luasanna i bhfad níos airde? Chun an cheist seo a fhreagairt, déanaimis féachaint ar cad atá ag tarlú sa phictiúr seo a leanas:

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Anseo feicimid go bhfuil an luas i ndáiríre thart ar míle taifead in aghaidh an tsoicind don chéad chúpla nóiméad. Ina theannta sin, áfach, toisc go léitear i bhfad níos mó ná mar a iarradh, críochnaíonn na sonraí i mbabht/taisce an chórais oibriúcháin (linux) agus méadaíonn an luas go dtí 60 míle in aghaidh an tsoicind níos réasúnta.

Mar sin, ina theannta sin déileálfaimid le rochtain a luathú ar na sonraí atá i dtaisce an OS nó atá suite i bhfeistí stórála SSD/NVMe a bhfuil luas rochtana inchomparáide acu.

Inár gcás, déanfaimid tástálacha ar bhinse de 4 fhreastalaí, agus gearrtar gach ceann acu mar seo a leanas:

LAP: Xeon E5-2680 v4 @ 2.40GHz 64 snáitheanna.
Cuimhne: 730 GB.
leagan java: 1.8.0_111

Agus anseo is é an príomhphointe ná an méid sonraí sna táblaí is gá a léamh. Is é fírinne an scéil, má léann tú sonraí ó thábla atá curtha go hiomlán i dtaisce HBase, ansin ní fiú é a léamh ó bhac / taisce an chórais oibriúcháin. Toisc go leithdháileann HBase de réir réamhshocraithe 40% de chuimhne ar struchtúr ar a dtugtar BlockCache. Go bunúsach is ConcurrentHashMap é seo, áit a bhfuil an eochair ainm comhaid + fritháireamh an bhloc, agus is é an luach na sonraí iarbhír ag an bhfritháireamh seo.

Dá bhrí sin, nuair a léamh amháin as an struchtúr seo, táimid feicimid luas den scoth, cosúil le milliún iarratas in aghaidh an tsoicind. Ach samhlaímid nach féidir linn na céadta ghigibheart de chuimhne a leithdháileadh díreach do riachtanais bhunachar sonraí, mar go bhfuil go leor rudaí úsáideacha eile ar siúl ar na freastalaithe seo.

Mar shampla, inár gcás, tá méid BlockCache ar RS amháin thart ar 12 GB. Tháinig muid i dtír dhá RS ar nód amháin, i.e. Leithdháiltear 96 GB do BlockCache ar gach nód. Agus tá go leor uaireanta níos mó sonraí, mar shampla, lig sé a bheith 4 táblaí, 130 réigiún an ceann, ina bhfuil comhaid 800 MB i méid, comhbhrúite ag FAST_DIFF, i.e. 410 GB san iomlán (sonraí íona iad seo, i.e. gan an fachtóir macasamhlaithe a chur san áireamh).

Mar sin, níl BlockCache ach thart ar 23% den mhéid iomlán sonraí agus tá sé seo i bhfad níos gaire do na fíorchoinníollacha ar a dtugtar BigData. Agus is é seo an áit a dtosaíonn an spraoi - mar is léir, dá lú amas taisce, is measa an fheidhmíocht. Tar éis an tsaoil, má chailleann tú, beidh ort a lán oibre a dhéanamh - i.e. téigh síos go dtí feidhmeanna córais glaonna. Ní féidir é seo a sheachaint, áfach, mar sin déanaimis féachaint ar ghné iomlán difriúil - cad a tharlaíonn do na sonraí taobh istigh den taisce?

Déanaimis an scéal a shimpliú agus glacadh leis go bhfuil taisce againn nach n-oireann ach do 1 réad. Seo sampla de cad a tharlóidh nuair a dhéanaimid iarracht oibriú le toirt sonraí 3 huaire níos mó ná an taisce, beidh orainn:

1. Cuir bloc 1 sa taisce
2. Bain bloc 1 ón taisce
3. Cuir bloc 2 sa taisce
4. Bain bloc 2 ón taisce
5. Cuir bloc 3 sa taisce

5 ghníomh curtha i gcrích! Mar sin féin, ní féidir gnáthchás a thabhairt ar an gcás seo; go deimhin, táimid ag cur iallach ar HBase cuid mhór oibre gan úsáid a dhéanamh. Léann sé i gcónaí sonraí ó thaisce an OS, cuireann sé i BlockCache é, ach é a chaitheamh amach beagnach láithreach toisc go bhfuil cuid nua sonraí tagtha. Léiríonn an beochan ag tús an phoist croílár na faidhbe - tá an Bhailitheoir Dramhaíl ag dul as scála, tá an t-atmaisféar ag téamh suas, tá Greta beag sa tSualainn i bhfad i gcéin agus tá an tSualainn te ag dul trína chéile. Agus ní maith linn é nuair a bhíonn leanaí brónach, mar sin tosaíonn muid ag smaoineamh ar cad is féidir linn a dhéanamh faoi.

Cad a tharlóidh mura gcuireann tú gach bloc sa taisce, ach gan ach céatadán áirithe díobh, ionas nach gcuirfidh an taisce thar maoil? Cuirimis tús le cúpla líne de chód a chur le tús na feidhme chun sonraí a chur isteach i BlockCache:

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

Is é seo a leanas an pointe anseo: is é an fhritháireamh suíomh an bhloc sa chomhad agus déantar a dhigit dheireanacha a dháileadh go randamach agus go cothrom ó 00 go 99. Dá bhrí sin, ní dhéanfaimid ach na cinn a thagann isteach sa raon a theastaíonn uainn a scipeáil.

Mar shampla, socraigh cacheDataBlockPercent = 20 agus féach cad a tharlaíonn:

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Is léir an toradh. Sna graif thíos, éiríonn sé soiléir cén fáth ar tharla a leithéid de luasghéarú - sábhálann muid go leor acmhainní GC gan obair Sisyphean a dhéanamh chun sonraí a chur sa taisce ach amháin chun é a chaitheamh láithreach síos draein na madraí Martian:

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Ag an am céanna, méadaíonn úsáid LAP, ach tá sé i bhfad níos lú ná táirgiúlacht:

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Is fiú a thabhairt faoi deara freisin go bhfuil na bloic atá stóráilte i BlockCache difriúil. Is sonraí iad féin an chuid is mó, thart ar 95%. Agus is meiteashonraí iad an chuid eile, mar scagairí Bloom nó LEAF_INDEX agus т.д.. Níl na sonraí seo go leor, ach tá sé an-úsáideach, mar roimh rochtain a fháil ar na sonraí go díreach, casann HBase chuig an meta chun a thuiscint an bhfuil sé riachtanach tuilleadh cuardach a dhéanamh anseo agus, má tá, cá háit go díreach atá an bloc spéise suite.

Dá bhrí sin, sa chód feicimid coinníoll seiceála buf.getBlockType().isData() agus a bhuíochas leis an meta seo, fágfaimid sa taisce é ar aon nós.

Anois, déanaimis an t-ualach a mhéadú agus an ghné a dhéanamh níos doichte in aon turas amháin. Sa chéad tástáil rinneamar an céatadán gearrtha = 20 agus rinneadh tearcúsáid ar BlockCache. Anois socróimid go 23% é agus cuirimis 100 snáithe leis gach 5 nóiméad féachaint cén pointe a tharlaíonn sáithiú:

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Anseo feicimid go mbuaileann an bunleagan beagnach láithreach an uasteorainn ag thart ar 100 míle iarratas in aghaidh an tsoicind. De bharr an méid a thugann an paiste luasghéarú suas le 300 míle. Ag an am céanna, is léir nach bhfuil luasghéarú breise “saor in aisce” a thuilleadh; tá méadú ag teacht ar úsáid LAP freisin.

Mar sin féin, ní réiteach an-galánta é seo, ós rud é nach bhfuil a fhios againn roimh ré cén céatadán de na bloic is gá a thaisceadh, braitheann sé ar phróifíl an ualaigh. Dá bhrí sin, cuireadh meicníocht i bhfeidhm chun an paraiméadar seo a choigeartú go huathoibríoch ag brath ar ghníomhaíocht na n-oibríochtaí léitheoireachta.

Cuireadh trí rogha leis chun é seo a rialú:

hbase.lru.taisce.trom.teorainn.chuntais — socraíonn sé cé mhéad uair is cóir don phróiseas díshealbhaithe sonraí ón taisce a reáchtáil sula dtosaímid ag baint úsáide as leas iomlán a bhaint (i.e. bloic gan bacadh le). De réir réamhshocraithe tá sé comhionann le MAX_INT = 2147483647 agus ciallaíonn sé go deimhin nach dtosóidh an ghné ag obair leis an luach seo choíche. Toisc go dtosaíonn an próiseas díshealbhaithe gach 5 - 10 soicind (braitheann sé ar an ualach) agus 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 bliain. Mar sin féin, is féidir linn an paraiméadar seo a shocrú go 0 agus an ghné a dhéanamh ag obair díreach tar éis seolta.

Mar sin féin, tá pálasta sa pharaiméadar seo freisin. Má tá ár n-ualach den sórt sin go bhfuil léamha gearrthéarmacha (abair i rith an lae) agus léamha fadtéarmacha (san oíche) idirscartha i gcónaí, ansin is féidir linn a chinntiú nach gcuirtear an ghné ar siúl ach amháin nuair a bhíonn oibríochtaí léite fada ar siúl.

Mar shampla, tá a fhios againn go maireann léamha gearrthéarmacha thart ar 1 nóiméad de ghnáth. Ní gá tús a chur le bloic a chaitheamh amach, ní bheidh am ag an taisce éirí as dáta agus ansin is féidir linn an paraiméadar seo a shocrú cothrom le, mar shampla, 10. Beidh sé seo mar thoradh ar an bhfíric go dtosóidh an leas iomlán a bhaint as ag obair ach amháin nuair a bheidh fad-. tá tús curtha le léamh gníomhach téarma, i.e. i 100 soicind. Mar sin, má tá léamh gearrthéarmach againn, ansin rachaidh na bloic go léir isteach sa taisce agus beidh siad ar fáil (ach amháin iad siúd a dhíshealbhóidh an algartam caighdeánach). Agus nuair a dhéanaimid léann fadtéarmach, cuirtear an ghné ar siúl agus bheadh ​​feidhmíocht i bhfad níos airde againn.

hbase.lru.cache.trom.díshealbhú.mb.size.limit — leagann sé seo cé mhéad meigibheart ba mhaith linn a chur sa taisce (agus, ar ndóigh, díshealbhú) i 10 soicind. Déanfaidh an ghné iarracht an luach seo a bhaint amach agus é a chothabháil. Is é an pointe seo: má chuirimid ghigibheart isteach sa taisce, ansin beidh orainn ghigibheart a dhíshealbhú, agus tá sé seo, mar a chonaic muid thuas, an-daor. Mar sin féin, níor cheart duit iarracht a dhéanamh é a shocrú ró-bheag, mar go n-éireoidh sé seo as an modh bloc-scipeála roimh am. Maidir le freastalaithe cumhachtacha (thart ar 20-40 croíthe fisiceacha), is fearr thart ar 300-400 MB a shocrú. Don mheánaicme (~10 cores) 200-300 MB. I gcás córais laga (2-5 chroí) d’fhéadfadh 50-100 MB a bheith gnáth (gan tástáil orthu seo).

Breathnaímid ar conas a oibríonn sé seo: déanaimis a rá go leagaimid hbase.lru.cache.heavy.eviction.mb.size.limit = 500, tá ualach de chineál éigin (léamh) ann agus ansin gach ~ 10 soicind ríomhaimid cé mhéad beart a bhí ann. díshealbhaíodh ag baint úsáide as an bhfoirmle :

Lastuas = Suim Freed Bytes (MB) * 100 / Teorainn (MB) - 100;

Más rud é go deimhin gur díshealbhaíodh 2000 MB, ansin is ionann Forchostas agus:

2000 * 100 / 500 - 100 = 300%

Déanann na halgartaim iarracht gan níos mó ná cúpla deich faoin gcéad a choimeád ar bun, mar sin laghdóidh an ghné céatadán na mbloic i dtaisce, rud a chuirfidh meicníocht uathchoigeartaithe i bhfeidhm.

Mar sin féin, má thiteann an t-ualach, abair linn nach ndíshealbhaítear ach 200 MB agus go n-éiríonn Lastuas diúltach (an ró-láimhseáil mar a thugtar air):

200 * 100 / 500 - 100 = -60%

Ar a mhalairt, méadóidh an ghné céatadán na mbloic i dtaisce go dtí go n-éireoidh Overhead dearfach.

Seo thíos sampla de conas a bhreathnaíonn sé seo ar shonraí fíor. Ní gá iarracht a dhéanamh teacht ar 0%, tá sé dodhéanta. Tá sé an-mhaith nuair a bhíonn sé thart ar 30 - 100%, cuidíonn sé seo le himeacht roimh am a sheachaint ón modh leas iomlán a bhaint le linn borrtha gearrthéarmacha.

hbase.lru.taisce.trom.díshealbhú.forchostais — leagann sé amach cé chomh tapa agus ba mhaith linn an toradh a fháil. Má tá a fhios againn go cinnte go bhfuil ár léamh fada den chuid is mó agus nach mian linn fanacht, is féidir linn an cóimheas seo a mhéadú agus ardfheidhmíocht a fháil níos tapúla.

Mar shampla, leagamar an chomhéifeacht seo = 0.01. Ciallaíonn sé seo go ndéanfar Forchostais (féach thuas) a iolrú faoin uimhir seo faoin toradh a bheidh mar thoradh air agus laghdófar céatadán na mbloic i dtaisce. Glacaimid leis go Lastuas = 300% agus comhéifeacht = 0.01, ansin beidh an céatadán de na bloic i dtaisce a laghdú de 3%.

Cuirtear loighic chomhchosúil “Cúlbhrú” i bhfeidhm freisin do luachanna diúltacha Lastuas (ró-láimhseáil). Ós rud é go bhfuil luaineachtaí gearrthéarmacha i líon na léite agus na ndíshealbhuithe indéanta i gcónaí, ceadaíonn an meicníocht seo duit imeacht roimh am ón modh leas iomlán a bhaint a sheachaint. Tá loighic inbhéartaithe ag backpressure: dá láidre an ró-láimhseáil, is amhlaidh is mó bloic a thaisceadh.

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Cód forfheidhmithe

        LruBlockCache cache = this.cache.get();
        if (cache == null) {
          break;
        }
        freedSumMb += cache.evict()/1024/1024;
        /*
        * Sometimes we are reading more data than can fit into BlockCache
        * and it is the cause a high rate of evictions.
        * This in turn leads to heavy Garbage Collector works.
        * So a lot of blocks put into BlockCache but never read,
        * but spending a lot of CPU resources.
        * Here we will analyze how many bytes were freed and decide
        * decide whether the time has come to reduce amount of caching blocks.
        * It help avoid put too many blocks into BlockCache
        * when evict() works very active and save CPU for other jobs.
        * More delails: https://issues.apache.org/jira/browse/HBASE-23887
        */

        // First of all we have to control how much time
        // has passed since previuos evict() was launched
        // This is should be almost the same time (+/- 10s)
        // because we get comparable volumes of freed bytes each time.
        // 10s because this is default period to run evict() (see above this.wait)
        long stopTime = System.currentTimeMillis();
        if ((stopTime - startTime) > 1000 * 10 - 1) {
          // Here we have to calc what situation we have got.
          // We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"
          // and can calculte overhead on it.
          // We will use this information to decide,
          // how to change percent of caching blocks.
          freedDataOverheadPercent =
            (int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
          if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
            // Now we are in the situation when we are above the limit
            // But maybe we are going to ignore it because it will end quite soon
            heavyEvictionCount++;
            if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
              // It is going for a long time and we have to reduce of caching
              // blocks now. So we calculate here how many blocks we want to skip.
              // It depends on:
             // 1. Overhead - if overhead is big we could more aggressive
              // reducing amount of caching blocks.
              // 2. How fast we want to get the result. If we know that our
              // heavy reading for a long time, we don't want to wait and can
              // increase the coefficient and get good performance quite soon.
              // But if we don't sure we can do it slowly and it could prevent
              // premature exit from this mode. So, when the coefficient is
              // higher we can get better performance when heavy reading is stable.
              // But when reading is changing we can adjust to it and set
              // the coefficient to lower value.
              int change =
                (int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
              // But practice shows that 15% of reducing is quite enough.
              // We are not greedy (it could lead to premature exit).
              change = Math.min(15, change);
              change = Math.max(0, change); // I think it will never happen but check for sure
              // So this is the key point, here we are reducing % of caching blocks
              cache.cacheDataBlockPercent -= change;
              // If we go down too deep we have to stop here, 1% any way should be.
              cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
            }
          } else {
            // Well, we have got overshooting.
            // Mayby it is just short-term fluctuation and we can stay in this mode.
            // It help avoid permature exit during short-term fluctuation.
            // If overshooting less than 90%, we will try to increase the percent of
            // caching blocks and hope it is enough.
            if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
              // Simple logic: more overshooting - more caching blocks (backpressure)
              int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
              cache.cacheDataBlockPercent += change;
              // But it can't be more then 100%, so check it.
              cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
            } else {
              // Looks like heavy reading is over.
              // Just exit form this mode.
              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;
       }

Breathnaímid anois ar seo go léir ag baint úsáide as sampla fíor. Tá an script tástála seo a leanas againn:

  1. Tosaímid ag déanamh Scan (25 snáithe, baisce = 100)
  2. Tar éis 5 nóiméad, cuir il-gets (25 snáitheanna, bhaisc = 100)
  3. Tar éis 5 nóiméad, múch il-gets (níl ann ach scanadh arís)

Déanaimid dhá rith, an chéad hbase.lru.cache.heavy.eviction.count.limit = 10000 (a dhíchumasaíonn iarbhír an ghné), agus ansin a leagtar teorainn = 0 (a chumasaíonn sé).

Sna logs thíos feicimid conas a chuirtear an ghné ar siúl agus athshocraíonn sé Ró-láimhseáil go 14-71%. Ó am go chéile laghdaítear an t-ualach, rud a chuireann Backpressure ar agus HBase níos mó bloic a thaisceadh arís.

Logáil RéigiúnServer
díshealbhaithe (MB): 0, cóimheas 0.0, lastuas (%): -100, cuntar díshealbhaithe trom: 0, caching reatha DataBlock (%): 100
díshealbhaithe (MB): 0, cóimheas 0.0, lastuas (%): -100, cuntar díshealbhaithe trom: 0, caching reatha DataBlock (%): 100
díshealbhaithe (MB): 2170, cóimheas 1.09, lastuas (%): 985, cuntar díshealbhaithe trom: 1, taisceadh reatha DataBlock (%): 91 < tús
díshealbhaithe (MB): 3763, cóimheas 1.08, lastuas (%): 1781, cuntar díshealbhaithe trom: 2, caching reatha DataBlock (%): 76
díshealbhaithe (MB): 3306, cóimheas 1.07, lastuas (%): 1553, cuntar díshealbhaithe trom: 3, caching reatha DataBlock (%): 61
díshealbhaithe (MB): 2508, cóimheas 1.06, lastuas (%): 1154, cuntar díshealbhaithe trom: 4, caching reatha DataBlock (%): 50
díshealbhaithe (MB): 1824, cóimheas 1.04, lastuas (%): 812, cuntar díshealbhaithe trom: 5, caching reatha DataBlock (%): 42
díshealbhaithe (MB): 1482, cóimheas 1.03, lastuas (%): 641, cuntar díshealbhaithe trom: 6, caching reatha DataBlock (%): 36
díshealbhaithe (MB): 1140, cóimheas 1.01, lastuas (%): 470, cuntar díshealbhaithe trom: 7, caching reatha DataBlock (%): 32
díshealbhaithe (MB): 913, cóimheas 1.0, lastuas (%): 356, cuntar díshealbhaithe trom: 8, caching reatha DataBlock (%): 29
díshealbhaithe (MB): 912, cóimheas 0.89, lastuas (%): 356, cuntar díshealbhaithe trom: 9, caching reatha DataBlock (%): 26
díshealbhaithe (MB): 684, cóimheas 0.76, lastuas (%): 242, cuntar díshealbhaithe trom: 10, caching reatha DataBlock (%): 24
díshealbhaithe (MB): 684, cóimheas 0.61, lastuas (%): 242, cuntar díshealbhaithe trom: 11, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 456, cóimheas 0.51, lastuas (%): 128, cuntar díshealbhaithe trom: 12, caching reatha DataBlock (%): 21
díshealbhaithe (MB): 456, cóimheas 0.42, lastuas (%): 128, cuntar díshealbhaithe trom: 13, caching reatha DataBlock (%): 20
díshealbhaithe (MB): 456, cóimheas 0.33, lastuas (%): 128, cuntar díshealbhaithe trom: 14, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 15, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 342, cóimheas 0.32, lastuas (%): 71, cuntar díshealbhaithe trom: 16, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 342, cóimheas 0.31, lastuas (%): 71, cuntar díshealbhaithe trom: 17, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 228, cóimheas 0.3, lastuas (%): 14, cuntar díshealbhaithe trom: 18, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 228, cóimheas 0.29, lastuas (%): 14, cuntar díshealbhaithe trom: 19, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 228, cóimheas 0.27, lastuas (%): 14, cuntar díshealbhaithe trom: 20, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 228, cóimheas 0.25, lastuas (%): 14, cuntar díshealbhaithe trom: 21, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 228, cóimheas 0.24, lastuas (%): 14, cuntar díshealbhaithe trom: 22, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 228, cóimheas 0.22, lastuas (%): 14, cuntar díshealbhaithe trom: 23, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 228, cóimheas 0.21, lastuas (%): 14, cuntar díshealbhaithe trom: 24, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 228, cóimheas 0.2, lastuas (%): 14, cuntar díshealbhaithe trom: 25, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 228, cóimheas 0.17, lastuas (%): 14, cuntar díshealbhaithe trom: 26, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 456, cóimheas 0.17, lastuas (%): 128, cuntar díshealbhaithe trom: 27, caching reatha DataBlock (%): 18 < faigheann breise (ach tábla mar an gcéanna)
díshealbhaithe (MB): 456, cóimheas 0.15, lastuas (%): 128, cuntar díshealbhaithe trom: 28, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 342, cóimheas 0.13, lastuas (%): 71, cuntar díshealbhaithe trom: 29, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 342, cóimheas 0.11, lastuas (%): 71, cuntar díshealbhaithe trom: 30, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 342, cóimheas 0.09, lastuas (%): 71, cuntar díshealbhaithe trom: 31, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 228, cóimheas 0.08, lastuas (%): 14, cuntar díshealbhaithe trom: 32, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 228, cóimheas 0.07, lastuas (%): 14, cuntar díshealbhaithe trom: 33, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 228, cóimheas 0.06, lastuas (%): 14, cuntar díshealbhaithe trom: 34, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 228, cóimheas 0.05, lastuas (%): 14, cuntar díshealbhaithe trom: 35, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 228, cóimheas 0.05, lastuas (%): 14, cuntar díshealbhaithe trom: 36, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 228, cóimheas 0.04, lastuas (%): 14, cuntar díshealbhaithe trom: 37, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 109, cóimheas 0.04, lastuas (%): -46, cuntar díshealbhaithe trom: 37, caching reatha DataBlock (%): 22 < brú ar ais
díshealbhaithe (MB): 798, cóimheas 0.24, lastuas (%): 299, cuntar díshealbhaithe trom: 38, caching reatha DataBlock (%): 20
díshealbhaithe (MB): 798, cóimheas 0.29, lastuas (%): 299, cuntar díshealbhaithe trom: 39, caching reatha DataBlock (%): 18
díshealbhaithe (MB): 570, cóimheas 0.27, lastuas (%): 185, cuntar díshealbhaithe trom: 40, caching reatha DataBlock (%): 17
díshealbhaithe (MB): 456, cóimheas 0.22, lastuas (%): 128, cuntar díshealbhaithe trom: 41, caching reatha DataBlock (%): 16
díshealbhaithe (MB): 342, cóimheas 0.16, lastuas (%): 71, cuntar díshealbhaithe trom: 42, caching reatha DataBlock (%): 16
díshealbhaithe (MB): 342, cóimheas 0.11, lastuas (%): 71, cuntar díshealbhaithe trom: 43, caching reatha DataBlock (%): 16
díshealbhaithe (MB): 228, cóimheas 0.09, lastuas (%): 14, cuntar díshealbhaithe trom: 44, caching reatha DataBlock (%): 16
díshealbhaithe (MB): 228, cóimheas 0.07, lastuas (%): 14, cuntar díshealbhaithe trom: 45, caching reatha DataBlock (%): 16
díshealbhaithe (MB): 228, cóimheas 0.05, lastuas (%): 14, cuntar díshealbhaithe trom: 46, caching reatha DataBlock (%): 16
díshealbhaithe (MB): 222, cóimheas 0.04, lastuas (%): 11, cuntar díshealbhaithe trom: 47, caching reatha DataBlock (%): 16
díshealbhaithe (MB): 104, cóimheas 0.03, lastuas (%): -48, cuntar díshealbhaithe trom: 47, taisceadh reatha DataBlock (%): 21 < idirbhriseadh faigheann
díshealbhaithe (MB): 684, cóimheas 0.2, lastuas (%): 242, cuntar díshealbhaithe trom: 48, caching reatha DataBlock (%): 19
díshealbhaithe (MB): 570, cóimheas 0.23, lastuas (%): 185, cuntar díshealbhaithe trom: 49, caching reatha DataBlock (%): 18
díshealbhaithe (MB): 342, cóimheas 0.22, lastuas (%): 71, cuntar díshealbhaithe trom: 50, caching reatha DataBlock (%): 18
díshealbhaithe (MB): 228, cóimheas 0.21, lastuas (%): 14, cuntar díshealbhaithe trom: 51, caching reatha DataBlock (%): 18
díshealbhaithe (MB): 228, cóimheas 0.2, lastuas (%): 14, cuntar díshealbhaithe trom: 52, caching reatha DataBlock (%): 18
díshealbhaithe (MB): 228, cóimheas 0.18, lastuas (%): 14, cuntar díshealbhaithe trom: 53, caching reatha DataBlock (%): 18
díshealbhaithe (MB): 228, cóimheas 0.16, lastuas (%): 14, cuntar díshealbhaithe trom: 54, caching reatha DataBlock (%): 18
díshealbhaithe (MB): 228, cóimheas 0.14, lastuas (%): 14, cuntar díshealbhaithe trom: 55, caching reatha DataBlock (%): 18
díshealbhaithe (MB): 112, cóimheas 0.14, lastuas (%): -44, cuntar díshealbhaithe trom: 55, caching reatha DataBlock (%): 23 < brú ar ais
díshealbhaithe (MB): 456, cóimheas 0.26, lastuas (%): 128, cuntar díshealbhaithe trom: 56, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.31, lastuas (%): 71, cuntar díshealbhaithe trom: 57, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 58, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 59, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 60, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 61, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 62, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 63, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.32, lastuas (%): 71, cuntar díshealbhaithe trom: 64, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 65, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 66, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.32, lastuas (%): 71, cuntar díshealbhaithe trom: 67, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 68, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.32, lastuas (%): 71, cuntar díshealbhaithe trom: 69, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.32, lastuas (%): 71, cuntar díshealbhaithe trom: 70, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 71, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 72, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 73, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 74, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 75, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 342, cóimheas 0.33, lastuas (%): 71, cuntar díshealbhaithe trom: 76, caching reatha DataBlock (%): 22
díshealbhaithe (MB): 21, cóimheas 0.33, lastuas (%): -90, cuntar díshealbhaithe trom: 76, caching reatha DataBlock (%): 32
díshealbhaithe (MB): 0, cóimheas 0.0, lastuas (%): -100, cuntar díshealbhaithe trom: 0, caching reatha DataBlock (%): 100
díshealbhaithe (MB): 0, cóimheas 0.0, lastuas (%): -100, cuntar díshealbhaithe trom: 0, caching reatha DataBlock (%): 100

Bhí gá leis na scananna chun an próiseas céanna a thaispeáint i bhfoirm graif den ghaol idir dhá chuid taisce - singil (mar a bhfuil bloic nár iarradh riamh roimhe seo) agus il (sonraí “iarrtha” á stóráil uair amháin ar a laghad anseo):

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Agus ar deireadh, cad is cosúil le feidhmiú na bparaiméadar i bhfoirm graif. Chun comparáid a dhéanamh, bhí an taisce múchta go hiomlán ag an tús, ansin seoladh HBase le caching agus moill a chur ar thús na hoibre leas iomlán a bhaint 5 nóiméad (30 timthriallta díshealbhaithe).

Is féidir cód iomlán a fháil in Iarratas Tarraingthe HBASE 23887 ar github.

Mar sin féin, ní féidir 300 míle léamh in aghaidh an tsoicind a bhaint amach ar na crua-earraí seo faoi na coinníollacha seo. Is é an fírinne ná nuair is gá duit rochtain a fháil ar shonraí trí HDFS, úsáidtear meicníocht ShortCircuitCache (dá ngairtear SSC anseo feasta), a ligeann duit rochtain a fháil ar na sonraí go díreach, ag seachaint idirghníomhaíochtaí líonra.

Léirigh próifíliú, cé go dtugann an mheicníocht seo gnóthachan mór, go dtiocfaidh sé chun bheith ina bhac freisin ag pointe éigin, toisc go dtarlaíonn beagnach gach oibríocht throm taobh istigh de ghlas, rud a fhágann go gcuirtear bac ar an chuid is mó den am.

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Tar éis dúinn é seo a bhaint amach, thuig muid gur féidir an fhadhb a shárú trí raon de SSCanna neamhspleácha a chruthú:

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

Agus ansin bí ag obair leo, gan crosbhealaí a áireamh freisin ag an digit fhritháireamh deiridh:

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

Anois is féidir leat tosú ar thástáil. Chun seo a dhéanamh, léifimid comhaid ó HDFS le feidhmchlár simplí il-snáithithe. Socraigh na paraiméadair:

conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждам
conf.set("dfs.client.short.circuit.num", num); // от 1 до 10

Agus níl le déanamh ach na comhaid a léamh:

FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i < count; i++) {
    position += 65536;
    if (position > 900000000)
        position = 0L;
    int res = in.read(position, byteBuffer, 0, 65536);
}

Déantar an cód seo a fhorghníomhú i snáitheanna ar leith agus méadóimid líon na gcomhad a léitear ag an am céanna (ó 10 go 200 - ais chothrománach) agus líon na caches (ó 1 go 10 - grafaicí). Taispeánann an ais ingearach an luasghéarú a eascraíonn as méadú ar SSC i gcoibhneas leis an gcás nuair nach bhfuil ach taisce amháin ann.

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Conas an graf a léamh: Teastaíonn 100 soicind chun an t-am forghníomhaithe do 64 míle léamh i 78 bloic KB le taisce amháin. Cé go dtógann sé 5 soicind le 16 taisce. Iad siúd. tá luasghéarú ~5 huaire ann. Mar is léir ón ngraf, níl an éifeacht an-suntasach do líon beag léamh comhthreomhara; tosaíonn sé ag imirt ról suntasach nuair a bhíonn níos mó ná 50 léamh snáithe ann. Tá sé faoi deara freisin go méadaítear líon na SSC ó 6 agus thuas tugann sé méadú suntasach níos lú ar fheidhmíocht.

Nóta 1: ós rud é go bhfuil na torthaí tástála sách luaineach (féach thíos), rinneadh 3 rith agus meánaíodh na luachanna mar thoradh orthu.

Nóta 2: Tá an gnóthachan feidhmíochta ó chumrú rochtain randamach mar an gcéanna, cé go bhfuil an rochtain féin beagán níos moille.

Mar sin féin, is gá a shoiléiriú, murab ionann agus an cás le HBase, nach bhfuil an luasghéarú seo saor in aisce i gcónaí. Anseo déanaimid “díghlasáil” ar chumas an LAP níos mó oibre a dhéanamh, in ionad a bheith ag crochadh ar ghlais.

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Anseo is féidir leat a thabhairt faoi deara, go ginearálta, go dtugann méadú ar líon na dtaisce méadú réasúnta comhréireach ar úsáid LAP. Mar sin féin, tá teaglaim bhuaigh beagán níos mó.

Mar shampla, déanaimis breathnú níos dlúithe ar an socrú SSC = 3. Tá an méadú ar fheidhmíocht ar an raon thart ar 3.3 uair. Seo thíos na torthaí ó na trí rith ar leith.

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Cé go méadaíonn tomhaltas LAP thart ar 2.8 uair. Níl an difríocht an-mhór, ach tá Greta beag sásta cheana féin agus b'fhéidir go mbeadh am aici freastal ar scoil agus ceachtanna a ghlacadh.

Mar sin, beidh tionchar dearfach aige seo ar aon uirlis a úsáideann rochtain mórchóir ar HDFS (mar shampla Spark, etc.), ar choinníoll go bhfuil cód an fheidhmchláir éadrom (i.e. tá an breiseán ar thaobh an chliaint HDFS) agus go bhfuil cumhacht LAP saor in aisce ann. . Le seiceáil, déanaimis tástáil ar an éifeacht a bheidh ag úsáid chomhcheangailte leas iomlán a bhaint BlockCache agus tiúnadh SSC le haghaidh léamh ó HBase.

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Is féidir a fheiceáil nach bhfuil an éifeacht faoi choinníollacha den sórt sin chomh mór agus atá i dtástálacha scagtha (léamh gan aon phróiseáil), ach is féidir go leor 80K breise a bhrú amach anseo. Le chéile, soláthraíonn an dá optimizations suas le 4x speedup.

Rinneadh PR freisin don bharrfheabhsú seo [HDFS-15202], atá cumaiscthe agus beidh an fheidhmiúlacht seo ar fáil in eisiúintí amach anseo.

Agus ar deireadh, bhí sé suimiúil comparáid a dhéanamh idir feidhmíocht léitheoireachta bunachar sonraí leathan-cholún den chineál céanna, Cassandra agus HBase.

Chun seo a dhéanamh, sheolamar cásanna de ghnáthfhóntas tástála ualaigh YCSB ó dhá óstach (800 snáithe san iomlán). Ar thaobh an fhreastalaí - 4 chás de RegionServer agus Cassandra ar 4 óstach (ní na cinn ina bhfuil na cliaint ag rith, chun a dtionchar a sheachaint). Tháinig léamha ó tháblaí méide:

HBase - 300 GB ar HDFS (sonraí íona 100 GB)

Cassandra - 250 GB (fachtóir macasamhla = 3)

Iad siúd. bhí an toirt thart ar an gcéanna (i HBase beagán níos mó).

Paraiméadair HBase:

dfs.client.short.circuit.num = 5 (uasmhéadú cliant HDFS)

hbase.lru.cache.heavy.eviction.count.limit =30 - ciallaíonn sé seo go dtosóidh an paiste ag obair tar éis 30 díshealbhú (~5 nóiméad)

hbase.lru.cache.heavy.eviction.mb.size.limit = 300 — spriocmhéid taisce agus díshealbhaithe

Rinneadh logaí YCSB a pharsáil agus a thiomsú i ngraif Excel:

Conas luas léitheoireachta a mhéadú ó HBase suas le 3 huaire agus ó HDFS suas le 5 huaire

Mar a fheiceann tú, is féidir feidhmíocht na mbunachair sonraí seo a chur i gcomparáid faoi na coinníollacha seo agus 450 míle léamh in aghaidh an tsoicind a bhaint amach mar gheall ar na leas iomlán a bhaint astu.

Tá súil againn gur féidir an fhaisnéis seo a bheith úsáideach do dhuine éigin le linn an streachailt spreagúil ar son táirgiúlachta.

Foinse: will.com

Add a comment