Is e coileanadh àrd aon de na prìomh riatanasan nuair a bhios tu ag obair le dàta mòr. Anns an roinn luchdachadh dàta aig Sberbank, bidh sinn a’ pumpadh cha mhòr a h-uile gnothach a-steach don Data Cloud againn stèidhichte air Hadoop agus mar sin a’ dèiligeadh ri sruthan fiosrachaidh fìor mhòr. Gu nàdarra, tha sinn an-còmhnaidh a’ coimhead airson dòighean air coileanadh a leasachadh, agus a-nis tha sinn airson innse dhut mar a chaidh againn air a’ chùis a dhèanamh air RegionServer HBase agus an teachdaiche HDFS, leis an robh e comasach dhuinn astar gnìomhachd leughaidh àrdachadh gu mòr.
Ach, mus gluais thu air adhart gu brìgh nan leasachaidhean, is fhiach bruidhinn mu chuingealachaidhean nach urrainnear, ann am prionnsapal, a sheachnadh ma tha thu nad shuidhe air HDD.
Carson a tha leughaidhean HDD agus Random Access luath neo-fhreagarrach
Mar a tha fios agad, bidh HBase, agus mòran stòran-dàta eile, a’ stòradh dàta ann am blocaichean de ghrunn deichean de kilobytes ann am meud. Gu gnàthach tha e timcheall air 64 KB. A-nis smaoinichidh sinn nach fheum sinn ach 100 bytes fhaighinn agus iarraidh sinn air HBase an dàta seo a thoirt dhuinn a’ cleachdadh iuchair shònraichte. Leis gur e meud a’ bhloca ann an HFiles 64 KB, bidh an t-iarrtas 640 uair nas motha (dìreach mionaid!)
An ath rud, leis gun tèid an t-iarrtas tro HDFS agus an uidheamachd tasgadan meata-dàta aige ShortCircuitCache (a leigeas le ruigsinneachd dìreach air faidhlichean), bidh seo a’ leantainn gu leughadh mu thràth 1 MB bhon diosc. Ach, faodar seo atharrachadh leis a’ pharamadair dfs.client.read.shortcircuit.buffer.size agus ann an iomadh cùis tha e ciallach an luach seo a lughdachadh, mar eisimpleir gu 126 KB.
Canaidh sinn gun dèan sinn seo, ach a bharrachd air an sin, nuair a thòisicheas sinn a’ leughadh dàta tron api java, leithid gnìomhan mar FileChannel.read agus iarraidh air an t-siostam obrachaidh an tomhas de dhàta ainmichte a leughadh, bidh e ag ràdh “dìreach gun fhios” 2 uair a bharrachd , i.e. 256 KB nar cùis. Tha seo air sgàth 's nach eil dòigh fhurasta aig java air a' bhratach FADV_RANDOM a shuidheachadh gus casg a chur air a' ghiùlan seo.
Mar thoradh air an sin, gus na 100 bytes againn fhaighinn, thèid 2600 uair a bharrachd a leughadh fon chochall. Bhiodh e coltach gu bheil am fuasgladh follaiseach, lughdaich sinn meud a’ bhloc gu kilobyte, suidhich am bratach ainmichte agus faigh sinn luathachadh soilleireachaidh mòr. Ach is e an duilgheadas a th’ ann le bhith a’ lughdachadh meud a’ bhloc 2 uair, gun lughdaich sinn an àireamh de bytes a leughas gach aonad ùine le 2 uair.
Gheibhear beagan buannachd bho bhith a’ suidheachadh bratach FADV_RANDOM, ach a-mhàin le ioma-snàithlean àrd agus le meud bloca de 128 KB, ach tha seo aig a’ char as àirde de dhà no trì sa cheud:
Chaidh deuchainnean a dhèanamh air 100 faidhle, gach fear 1 GB ann am meud agus suidhichte air 10 HDDs.
Feuch an obraich sinn a-mach dè as urrainn dhuinn, ann am prionnsapal, cunntadh air aig an astar seo:
Canaidh sinn gun leugh sinn bho 10 diosc aig astar 280 MB / diog, i.e. 3 millean uair 100 bytes. Ach mar a chuimhnicheas sinn, tha an dàta a tha a dhìth oirnn 2600 uair nas lugha na na tha air a leughadh. Mar sin, bidh sinn a’ roinn 3 millean le 2600 agus a’ faighinn 1100 clàran gach diog.
Duilgheadas, nach e? Is e sin nàdar Cothrom air thuaiream ruigsinneachd air dàta air an HDD - ge bith dè am meud bloca. Is e seo a’ chrìoch fiosaigeach a thaobh ruigsinneachd air thuaiream agus chan urrainn dha stòr-dàta sam bith barrachd brùthadh a-mach fo leithid de shuidheachaidhean.
Ciamar ma-thà a bhios stòran-dàta a’ coileanadh astaran mòran nas àirde? Airson a’ cheist seo a fhreagairt, leig dhuinn sùil a thoirt air na tha a’ tachairt san dealbh a leanas:
An seo chì sinn gu bheil an astar airson a’ chiad beagan mhionaidean mu mhìle clàr gach diog. Ach, nas fhaide air adhart, leis gu bheil mòran a bharrachd air a leughadh na chaidh iarraidh, tha an dàta a’ tighinn gu crìch ann am buff / tasgadan an t-siostam obrachaidh (linux) agus tha an astar ag èirigh gu 60 mìle san diog nas reusanta.
Mar sin, nas fhaide air adhart bidh sinn a’ dèiligeadh ri bhith a’ luathachadh ruigsinneachd a-mhàin don dàta a tha ann an tasgadan an OS no a tha suidhichte ann an innealan stòraidh SSD/NVMe aig astar ruigsinneachd coimeasach.
Anns a ’chùis againn, nì sinn deuchainnean air being de 4 frithealaichean, agus bidh gach fear dhiubh mar a leanas:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 snàithlean.
Cuimhne: 730 GB.
tionndadh java: 1.8.0_111
Agus an seo is e am prìomh phuing na tha de dhàta anns na clàran a dh’ fheumar a leughadh. Is e an fhìrinn ma leughas tu dàta bho bhòrd a tha gu tur air a chuir ann an tasgadan HBase, cha tig e eadhon gu bhith a’ leughadh bho buff / tasgadan an t-siostaim obrachaidh. Leis gu bheil HBase gu bunaiteach a’ riarachadh 40% de chuimhne gu structar ris an canar BlockCache. Gu bunaiteach is e seo ConcurrentHashMap, far a bheil an iuchair ainm an fhaidhle + cuir dheth a’ bhloc, agus is e an luach an fhìor dhàta aig a ’chothromachadh seo.
Mar sin, nuair a leughas sinn a-mhàin bhon structar seo, bidh sinn , mar mhillean iarrtas gach diog. Ach smaoinichidh sinn nach urrainn dhuinn na ceudan de gigabytes de chuimhne a riarachadh dìreach airson feumalachdan stòr-dàta, oir tha tòrr rudan feumail eile a’ ruith air na frithealaichean sin.
Mar eisimpleir, anns a 'chùis againn, tha an tomhas de BlockCache air aon RS mu 12 GB. Thàinig sinn gu tìr dà RS air aon nód, i.e. Tha 96 GB air a riarachadh airson BlockCache air a h-uile nod. Agus tha iomadh uair a bharrachd dàta ann, mar eisimpleir, biodh e 4 bùird, 130 roinnean gach fear, anns a bheil faidhlichean 800 MB ann am meud, air an teannachadh le FAST_DIFF, i.e. 410 GB gu h-iomlan (is e dàta fìor a tha seo, i.e. gun a bhith a’ toirt aire don fhactar ath-riochdachadh).
Mar sin, chan eil ann am BlockCache ach mu 23% den tomhas dàta iomlan agus tha seo tòrr nas fhaisge air fìor shuidheachaidhean ris an canar BigData. Agus seo far a bheil an spòrs a’ tòiseachadh - oir gu follaiseach, mar as lugha a bhuaileas tasgadan, is ann as miosa a bhios an coileanadh. Às deidh na h-uile, ma chailleas tu, bidh agad ri tòrr obrach a dhèanamh - i.e. dol sìos gu gnìomhan siostam gairm. Ach, chan urrainnear seo a sheachnadh, mar sin leig dhuinn sùil a thoirt air taobh gu tur eadar-dhealaichte - dè thachras don dàta taobh a-staigh an tasgadan?
Dèanamaid an suidheachadh nas sìmplidhe agus gabh ris gu bheil tasgadan againn nach eil a’ freagairt ach air 1 nì. Seo eisimpleir de na thachras nuair a dh’ fheuchas sinn ri obrachadh le tomhas dàta 3 tursan nas motha na an tasgadan, feumaidh sinn:
1. Cuir bloc 1 ann an tasgadan
2. Thoir air falbh bloc 1 bhon tasgadan
3. Cuir bloc 2 ann an tasgadan
4. Thoir air falbh bloc 2 bhon tasgadan
5. Cuir bloc 3 ann an tasgadan
5 gnìomhan crìochnaichte! Ach, chan urrainnear an suidheachadh seo a ghairm àbhaisteach; gu dearbh, tha sinn a ’toirt air HBase dòrlach de dh’ obair gu tur gun fheum a dhèanamh. Bidh e an-còmhnaidh a’ leughadh dàta bho tasgadan an OS, ga chuir ann am BlockCache, dìreach airson a thilgeil a-mach cha mhòr sa bhad leis gu bheil cuibhreann ùr de dhàta air ruighinn. Tha am beòthalachd aig toiseach na dreuchd a’ sealltainn brìgh na trioblaid - tha Garbage Collector a’ dol far sgèile, tha am faireachdainn a’ teasachadh, Greta beag anns an t-Suain fad às agus teth a’ fàs troimh-chèile. Agus cha toil leinn IT daoine e gu mòr nuair a tha clann brònach, agus mar sin tòisichidh sinn a’ smaoineachadh dè as urrainn dhuinn a dhèanamh mu dheidhinn.
Dè mura cuir thu a h-uile bloc san tasgadan, ach dìreach ceudad sònraichte dhiubh, gus nach bi an tasgadan a’ dol thairis? Feuch an tòisich sinn le bhith dìreach a’ cur dìreach beagan loidhnichean de chòd ri toiseach a’ ghnìomh airson dàta a chuir a-steach gu BlockCache:
public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
return;
}
}
...
Is e a’ phuing an seo na leanas: is e cuir dheth suidheachadh a’ bhloca san fhaidhle agus tha na h-àireamhan mu dheireadh aige air an cuairteachadh air thuaiream agus gu cothromach bho 00 gu 99. Mar sin, cha bhith sinn a’ leum ach an fheadhainn a thig a-steach don raon a dh’ fheumas sinn.
Mar eisimpleir, suidhich cacheDataBlockPercent = 20 agus faic dè thachras:
Tha an toradh follaiseach. Anns na grafaichean gu h-ìosal, tha e soilleir carson a thachair an leithid de luathachadh - bidh sinn a’ sàbhaladh mòran de ghoireasan GC gun a bhith a’ dèanamh obair Sisyphean gus dàta a chuir anns an tasgadan a-mhàin gus a thilgeil sa bhad sìos drèanadh coin Martian:
Aig an aon àm, tha cleachdadh CPU ag àrdachadh, ach tha e mòran nas lugha na cinneasachd:
Is fhiach a bhith mothachail cuideachd gu bheil na blocaichean a tha air an stòradh ann am BlockCache eadar-dhealaichte. Tha a’ mhòr-chuid, timcheall air 95%, na dhàta fhèin. Agus is e meata-dàta an còrr, leithid sìoltachain Bloom no LEAF_INDEX agus . Chan eil an dàta seo gu leòr, ach tha e glè fheumail, oir mus faigh thu cothrom air an dàta gu dìreach, bidh HBase a’ tionndadh chun mheata gus tuigsinn a bheil feum air tuilleadh rannsachaidh a dhèanamh an seo agus, ma tha, càite dìreach a tha am bloc ùidh.
Mar sin, anns a’ chòd chì sinn suidheachadh seic buf.getBlockType().isData() agus le taing don meta seo, fàgaidh sinn e san tasgadan co-dhiù.
A-nis leig leinn an luchd àrdachadh agus teannachadh beagan air an fheart ann an aon turas. Anns a 'chiad deuchainn rinn sinn an àireamh sa cheud gearraidh = 20 agus cha robh mòran feum air BlockCache. A-nis leig dhuinn a shuidheachadh gu 23% agus cuir 100 snàithlean ris gach 5 mionaidean gus faicinn dè an ìre a bhios sùghaidh a’ tachairt:
An seo chì sinn gu bheil an dreach tùsail cha mhòr sa bhad a ’bualadh air a’ mhullach aig timcheall air 100 mìle iarrtas gach diog. Ach tha am paiste a’ toirt luathachadh suas ri 300 mìle. Aig an aon àm, tha e soilleir nach eil tuilleadh luathachaidh cho “saor” tuilleadh; Tha cleachdadh CPU cuideachd a’ dol am meud.
Ach, chan e fuasgladh fìor eireachdail a tha seo, leis nach eil fios againn ro-làimh dè an àireamh sa cheud de bhlocaichean a dh’ fheumar a thasgadh, tha e an urra ri ìomhaigh an luchd. Mar sin, chaidh uidheamachd a chuir an gnìomh gus am paramadair seo atharrachadh gu fèin-ghluasadach a rèir gnìomhachd gnìomhachd leughaidh.
Chaidh trì roghainnean a chur ris gus seo a smachdachadh:
hbase.lru.cache.heavy.fuadach.cunnt.limit - a’ suidheachadh cia mheud uair a bu chòir don phròiseas fuadach dàta bhon tasgadan ruith mus tòisich sinn a’ cleachdadh optimization (ie blocaichean sgithidh). Gu gnàthach tha e co-ionann ri MAX_INT = 2147483647 agus gu dearbh a’ ciallachadh nach tòisich am feart gu bràth ag obair leis an luach seo. Leis gu bheil am pròiseas fuadachaidh a’ tòiseachadh a h-uile 5 - 10 diog (bidh e an urra ris an luchd) agus 2147483647 * 10/60/60/24/365 = 680 bliadhna. Ach, is urrainn dhuinn am paramadair seo a shuidheachadh gu 0 agus toirt air an fheart obrachadh dìreach às deidh a chuir air bhog.
Ach, tha uallach pàighidh anns a’ pharamadair seo cuideachd. Ma tha an luchd againn cho mòr is gu bheil leughaidhean geàrr-ùine (can tron latha) agus leughaidhean fad-ùine (air an oidhche) an-còmhnaidh eadar-dhealaichte, faodaidh sinn dèanamh cinnteach nach tèid am feart a thionndadh air ach nuair a tha gnìomhachd leughaidh fada a’ dol air adhart.
Mar eisimpleir, tha fios againn gum mair leughaidhean geàrr-ùine timcheall air 1 mhionaid mar as trice. Chan eil feum air tòiseachadh a 'tilgeil a-mach blocaichean, cha bhi ùine aig an tasgadan a bhith seann-fhasanta agus an uairsin is urrainn dhuinn am paramadair seo a shuidheachadh co-ionann ri, mar eisimpleir, 10. Bidh seo a 'leantainn gu bheil an optimization a' tòiseachadh ag obair a-mhàin nuair a dh'fhaid. tha leughadh gnìomhach teirm air tòiseachadh, i.e. ann an 100 diog. Mar sin, ma tha leughadh geàrr-ùine againn, thèid na blocaichean uile a-steach don tasgadan agus bidh iad rim faighinn (ach a-mhàin an fheadhainn a thèid fhuadach leis an algairim àbhaisteach). Agus nuair a nì sinn leughaidhean fad-ùine, tha am feart air a thionndadh air agus bhiodh coileanadh mòran nas àirde againn.
hbase.lru.cache.heavy.fuadach.mb.size.limit - a’ suidheachadh cia mheud megabytes a bu mhath leinn a chuir san tasgadan (agus, gu dearbh, fuadach) ann an 10 diogan. Feuchaidh am feart ris an luach seo a ruighinn agus a chumail suas. Is e seo a ’phuing: ma ghluaiseas sinn gigabytes a-steach don tasgadan, feumaidh sinn gigabytes fhuadach, agus tha seo, mar a chunnaic sinn gu h-àrd, gu math daor. Ach, cha bu chòir dhut feuchainn ri a shuidheachadh ro bheag, oir bheir seo air a’ mhodh sgiob bloc fàgail ro-luath. Airson frithealaichean cumhachdach (timcheall air 20-40 coraichean corporra), tha e nas fheàrr timcheall air 300-400 MB a shuidheachadh. Airson a 'chlas meadhan (~ 10 cores) 200-300 MB. Airson siostaman lag (2-5 cores) faodaidh 50-100 MB a bhith àbhaisteach (gun deuchainn orra sin).
Bheir sinn sùil air mar a tha seo ag obair: canaidh sinn gun do shuidhich sinn hbase.lru.cache.heavy.eviction.mb.size.limit = 500, tha seòrsa de luchd (leughadh) ann agus an uairsin a h-uile ~ 10 diog bidh sinn ag obrachadh a-mach cia mheud bytes a bh’ ann. air am fuadach a’ cleachdadh na foirmle:
Os cionn = Freed Bytes Sum (MB) * 100 / Crìochan (MB) - 100;
Nam biodh 2000 MB gu dearbh air am fuadach, tha Os cionn co-ionann ri:
2000 * 100 / 500 - 100 = 300%
Feuchaidh na h-algorithms gun a bhith nas fhaide na beagan deichean sa cheud a chumail, agus mar sin lughdaichidh am feart an àireamh sa cheud de bhlocaichean taisgte, agus mar sin a’ cur an gnìomh uidheamachd gleusaidh fèin-ghluasadach.
Ach, ma thuiteas an luchd, canaidh sinn nach eil ach 200 MB air am fuadach agus gu bheil Os cionn a’ fàs àicheil (an t-ainm ris an canar overshooting):
200 * 100 / 500 - 100 = -60%
Air an làimh eile, àrdaichidh am feart an àireamh sa cheud de bhlocaichean taisgte gus am bi Overhead deimhinneach.
Gu h-ìosal tha eisimpleir de mar a tha seo a 'coimhead air dàta fìor. Chan fheumar feuchainn ri 0% a ruighinn, tha e do-dhèanta. Tha e fìor mhath nuair a tha e timcheall air 30 - 100%, tha seo a’ cuideachadh le bhith a’ seachnadh fàgail ro-luath bhon mhodh optimization rè sreapadan geàrr-ùine.
hbase.lru.cache.heavy.fuadach.overhead.coefficient - a’ suidheachadh cho luath sa bu mhath leinn an toradh fhaighinn. Ma tha fios againn gu cinnteach gu bheil na leughaidhean againn fada sa mhòr-chuid agus nach eil sinn airson feitheamh, is urrainn dhuinn an co-mheas seo àrdachadh agus coileanadh àrd fhaighinn nas luaithe.
Mar eisimpleir, shuidhich sinn an coefficient seo = 0.01. Tha seo a’ ciallachadh gun tèid Overhead (faic gu h-àrd) iomadachadh leis an àireamh seo leis an toradh a thig às agus gun tèid an àireamh sa cheud de bhlocaichean taisgte a lughdachadh. Gabhamaid ris gu bheil Overhead = 300% agus coefficient = 0.01, an uairsin thèid an àireamh sa cheud de bhlocaichean taisgte a lughdachadh 3%.
Tha loidsig coltach ri “Backpressure” cuideachd air a chuir an gnìomh airson luachan àicheil Os-cionn (thar-shealladh). Leis gu bheil e an-còmhnaidh comasach atharrachaidhean geàrr-ùine ann an meud leughaidhean agus fuadaichean, leigidh an uidheamachd seo leat fàgail ro-luath bhon mhodh optimization a sheachnadh. Tha loidsig neo-dhìreach aig backpressure: mar as làidire a bhios an ro-shealladh, is ann as motha de bhlocaichean a thèid an tasgadh.
Còd buileachaidh
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;
}
Bheir sinn sùil a-nis air seo uile a’ cleachdadh fìor eisimpleir. Tha an sgriobt deuchainn a leanas againn:
- Feuch an tòisich sinn a’ dèanamh Scan (25 snàithlean, baidse = 100)
- Às deidh 5 mionaidean, cuir ioma-gheasan (25 snàithlean, baidse = 100)
- Às deidh 5 mionaidean, cuir dheth ioma-gheasan (chan eil ach scan air fhàgail a-rithist)
Bidh sinn a’ dèanamh dà ruith, an toiseach hbase.lru.cache.heavy.eviction.count.limit = 10000 (a tha dha-rìribh a’ cuir à comas am feart), agus an uairsin a’ suidheachadh crìoch = 0 (ga chomasachadh).
Anns na logaichean gu h-ìosal chì sinn mar a tha am feart air a thionndadh air agus ath-shuidheachadh Overshooting gu 14-71%. Bho àm gu àm bidh an luchd a’ dol sìos, a thionndaidheas air Backpressure agus HBase a’ tasgadh barrachd bhlocaichean a-rithist.
Log sgìre frithealaiche
air fhuadach (MB): 0, co-mheas 0.0, os cionn (%): -100, cuntair fuadachaidh trom: 0, caching gnàthach DataBlock (%): 100
air fhuadach (MB): 0, co-mheas 0.0, os cionn (%): -100, cuntair fuadachaidh trom: 0, caching gnàthach DataBlock (%): 100
air fhuadach (MB): 2170, co-mheas 1.09, os cionn (%): 985, cuntair fuadachaidh trom: 1, caching gnàthach DataBlock (%): 91 < tòiseachadh
air fhuadach (MB): 3763, co-mheas 1.08, os cionn (%): 1781, cuntair fuadachaidh trom: 2, tasgadh gnàthach DataBlock (%): 76
air fhuadach (MB): 3306, co-mheas 1.07, os cionn (%): 1553, cuntair fuadachaidh trom: 3, tasgadh gnàthach DataBlock (%): 61
air fhuadach (MB): 2508, co-mheas 1.06, os cionn (%): 1154, cuntair fuadachaidh trom: 4, tasgadh gnàthach DataBlock (%): 50
air fhuadach (MB): 1824, co-mheas 1.04, os cionn (%): 812, cuntair fuadachaidh trom: 5, tasgadh gnàthach DataBlock (%): 42
air fhuadach (MB): 1482, co-mheas 1.03, os cionn (%): 641, cuntair fuadachaidh trom: 6, tasgadh gnàthach DataBlock (%): 36
air fhuadach (MB): 1140, co-mheas 1.01, os cionn (%): 470, cuntair fuadachaidh trom: 7, tasgadh gnàthach DataBlock (%): 32
air fhuadach (MB): 913, co-mheas 1.0, os cionn (%): 356, cuntair fuadachaidh trom: 8, tasgadh gnàthach DataBlock (%): 29
air fhuadach (MB): 912, co-mheas 0.89, os cionn (%): 356, cuntair fuadachaidh trom: 9, tasgadh gnàthach DataBlock (%): 26
air fhuadach (MB): 684, co-mheas 0.76, os cionn (%): 242, cuntair fuadachaidh trom: 10, tasgadh gnàthach DataBlock (%): 24
air fhuadach (MB): 684, co-mheas 0.61, os cionn (%): 242, cuntair fuadachaidh trom: 11, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 456, co-mheas 0.51, os cionn (%): 128, cuntair fuadachaidh trom: 12, tasgadh gnàthach DataBlock (%): 21
air fhuadach (MB): 456, co-mheas 0.42, os cionn (%): 128, cuntair fuadachaidh trom: 13, tasgadh gnàthach DataBlock (%): 20
air fhuadach (MB): 456, co-mheas 0.33, os cionn (%): 128, cuntair fuadachaidh trom: 14, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 15, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 342, co-mheas 0.32, os cionn (%): 71, cuntair fuadachaidh trom: 16, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 342, co-mheas 0.31, os cionn (%): 71, cuntair fuadachaidh trom: 17, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 228, co-mheas 0.3, os cionn (%): 14, cuntair fuadachaidh trom: 18, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 228, co-mheas 0.29, os cionn (%): 14, cuntair fuadachaidh trom: 19, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 228, co-mheas 0.27, os cionn (%): 14, cuntair fuadachaidh trom: 20, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 228, co-mheas 0.25, os cionn (%): 14, cuntair fuadachaidh trom: 21, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 228, co-mheas 0.24, os cionn (%): 14, cuntair fuadachaidh trom: 22, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 228, co-mheas 0.22, os cionn (%): 14, cuntair fuadachaidh trom: 23, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 228, co-mheas 0.21, os cionn (%): 14, cuntair fuadachaidh trom: 24, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 228, co-mheas 0.2, os cionn (%): 14, cuntair fuadachaidh trom: 25, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 228, co-mheas 0.17, os cionn (%): 14, cuntair fuadachaidh trom: 26, tasgadh gnàthach DataBlock (%): 19
fhuadach (MB): 456, co-mheas 0.17, os cionn (%): 128, cuntair fuadachaidh trom: 27, caching gnàthach DataBlock (%): 18 < air a chur ris a’ faighinn (ach clàr an aon rud)
air fhuadach (MB): 456, co-mheas 0.15, os cionn (%): 128, cuntair fuadachaidh trom: 28, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 342, co-mheas 0.13, os cionn (%): 71, cuntair fuadachaidh trom: 29, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 342, co-mheas 0.11, os cionn (%): 71, cuntair fuadachaidh trom: 30, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 342, co-mheas 0.09, os cionn (%): 71, cuntair fuadachaidh trom: 31, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 228, co-mheas 0.08, os cionn (%): 14, cuntair fuadachaidh trom: 32, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 228, co-mheas 0.07, os cionn (%): 14, cuntair fuadachaidh trom: 33, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 228, co-mheas 0.06, os cionn (%): 14, cuntair fuadachaidh trom: 34, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 228, co-mheas 0.05, os cionn (%): 14, cuntair fuadachaidh trom: 35, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 228, co-mheas 0.05, os cionn (%): 14, cuntair fuadachaidh trom: 36, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 228, co-mheas 0.04, os cionn (%): 14, cuntair fuadachaidh trom: 37, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 109, co-mheas 0.04, os cionn (%): -46, cuntair fuadachaidh trom: 37, caching gnàthach DataBlock (%): 22 < cuideam cùil
air fhuadach (MB): 798, co-mheas 0.24, os cionn (%): 299, cuntair fuadachaidh trom: 38, tasgadh gnàthach DataBlock (%): 20
air fhuadach (MB): 798, co-mheas 0.29, os cionn (%): 299, cuntair fuadachaidh trom: 39, tasgadh gnàthach DataBlock (%): 18
air fhuadach (MB): 570, co-mheas 0.27, os cionn (%): 185, cuntair fuadachaidh trom: 40, tasgadh gnàthach DataBlock (%): 17
air fhuadach (MB): 456, co-mheas 0.22, os cionn (%): 128, cuntair fuadachaidh trom: 41, tasgadh gnàthach DataBlock (%): 16
air fhuadach (MB): 342, co-mheas 0.16, os cionn (%): 71, cuntair fuadachaidh trom: 42, tasgadh gnàthach DataBlock (%): 16
air fhuadach (MB): 342, co-mheas 0.11, os cionn (%): 71, cuntair fuadachaidh trom: 43, tasgadh gnàthach DataBlock (%): 16
air fhuadach (MB): 228, co-mheas 0.09, os cionn (%): 14, cuntair fuadachaidh trom: 44, tasgadh gnàthach DataBlock (%): 16
air fhuadach (MB): 228, co-mheas 0.07, os cionn (%): 14, cuntair fuadachaidh trom: 45, tasgadh gnàthach DataBlock (%): 16
air fhuadach (MB): 228, co-mheas 0.05, os cionn (%): 14, cuntair fuadachaidh trom: 46, tasgadh gnàthach DataBlock (%): 16
air fhuadach (MB): 222, co-mheas 0.04, os cionn (%): 11, cuntair fuadachaidh trom: 47, tasgadh gnàthach DataBlock (%): 16
air fhuadach (MB): 104, co-mheas 0.03, os cionn (%): -48, cuntair fuadachaidh trom: 47, caching gnàthach DataBlock (%): 21 < brisidh a’ faighinn
air fhuadach (MB): 684, co-mheas 0.2, os cionn (%): 242, cuntair fuadachaidh trom: 48, tasgadh gnàthach DataBlock (%): 19
air fhuadach (MB): 570, co-mheas 0.23, os cionn (%): 185, cuntair fuadachaidh trom: 49, tasgadh gnàthach DataBlock (%): 18
air fhuadach (MB): 342, co-mheas 0.22, os cionn (%): 71, cuntair fuadachaidh trom: 50, tasgadh gnàthach DataBlock (%): 18
air fhuadach (MB): 228, co-mheas 0.21, os cionn (%): 14, cuntair fuadachaidh trom: 51, tasgadh gnàthach DataBlock (%): 18
air fhuadach (MB): 228, co-mheas 0.2, os cionn (%): 14, cuntair fuadachaidh trom: 52, tasgadh gnàthach DataBlock (%): 18
air fhuadach (MB): 228, co-mheas 0.18, os cionn (%): 14, cuntair fuadachaidh trom: 53, tasgadh gnàthach DataBlock (%): 18
air fhuadach (MB): 228, co-mheas 0.16, os cionn (%): 14, cuntair fuadachaidh trom: 54, tasgadh gnàthach DataBlock (%): 18
air fhuadach (MB): 228, co-mheas 0.14, os cionn (%): 14, cuntair fuadachaidh trom: 55, tasgadh gnàthach DataBlock (%): 18
air fhuadach (MB): 112, co-mheas 0.14, os cionn (%): -44, cuntair fuadachaidh trom: 55, caching gnàthach DataBlock (%): 23 < cuideam cùil
air fhuadach (MB): 456, co-mheas 0.26, os cionn (%): 128, cuntair fuadachaidh trom: 56, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.31, os cionn (%): 71, cuntair fuadachaidh trom: 57, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 58, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 59, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 60, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 61, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 62, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 63, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.32, os cionn (%): 71, cuntair fuadachaidh trom: 64, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 65, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 66, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.32, os cionn (%): 71, cuntair fuadachaidh trom: 67, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 68, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.32, os cionn (%): 71, cuntair fuadachaidh trom: 69, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.32, os cionn (%): 71, cuntair fuadachaidh trom: 70, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 71, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 72, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 73, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 74, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 75, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 342, co-mheas 0.33, os cionn (%): 71, cuntair fuadachaidh trom: 76, tasgadh gnàthach DataBlock (%): 22
air fhuadach (MB): 21, co-mheas 0.33, os cionn (%): -90, cuntair fuadachaidh trom: 76, caching gnàthach DataBlock (%): 32
air fhuadach (MB): 0, co-mheas 0.0, os cionn (%): -100, cuntair fuadachaidh trom: 0, caching gnàthach DataBlock (%): 100
air fhuadach (MB): 0, co-mheas 0.0, os cionn (%): -100, cuntair fuadachaidh trom: 0, caching gnàthach DataBlock (%): 100
Bha feum air na sganaidhean gus an aon phròiseas a nochdadh ann an cruth graf den dàimh eadar dà roinn tasgadan - singilte (far a bheil blocaichean nach deach iarraidh a-riamh roimhe) agus ioma (dàta “iarraidh” co-dhiù aon uair air a stòradh an seo):
Agus mu dheireadh, cò ris a tha gnìomhachd nam paramadairean coltach ann an cruth graf. Airson coimeas a dhèanamh, chaidh an tasgadan a chuir dheth gu tur aig an toiseach, an uairsin chaidh HBase a chuir air bhog le caching agus dàil a chuir air tòiseachadh obair optimization le 5 mionaidean (30 cuairtean fuadachaidh).
Gheibhear an còd slàn ann an Pull Request air github.
Ach, chan e 300 mìle leughadh gach diog a h-uile dad a ghabhas a choileanadh air a’ bhathar-cruaidh seo fo na cumhaichean sin. Is e an fhìrinn, nuair a dh’ fheumas tu faighinn gu dàta tro HDFS, thathas a ’cleachdadh an inneal ShortCircuitCache (air an canar an-seo SSC), a leigeas leat faighinn chun dàta gu dìreach, a’ seachnadh eadar-obrachaidhean lìonra.
Sheall pròifil, ged a tha an uidheamachd seo a’ toirt buannachd mhòr, gu bheil e cuideachd aig àm air choreigin gu bhith na bhotal, leis gu bheil cha mhòr a h-uile gnìomhachd trom a’ tachairt taobh a-staigh glas, a tha a’ leantainn gu bhith a’ bacadh a’ mhòr-chuid den ùine.
An dèidh seo a thoirt gu buil, thuig sinn gum faodar faighinn seachad air an duilgheadas le bhith a’ cruthachadh sreath de SSCn neo-eisimeileach:
private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
this.shortCircuitCache[i] = new ShortCircuitCache(…);
Agus an uairsin obraich còmhla riutha, gun a bhith a’ toirt a-steach croisean-rathaid cuideachd aig an fhigear chothromachadh mu dheireadh:
public ShortCircuitCache getShortCircuitCache(long idx) {
return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}
A-nis faodaidh tu tòiseachadh air deuchainn. Gus seo a dhèanamh, leughaidh sinn faidhlichean bho HDFS le tagradh sìmplidh ioma-snàthainn. Suidhich na paramadairean:
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 dìreach leugh na faidhlichean:
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);
}
Tha an còd seo air a chur gu bàs ann an snàithleanan fa leth agus àrdaichidh sinn an àireamh de fhaidhlichean a leughas aig an aon àm (bho 10 gu 200 - axis chòmhnard) agus an àireamh de caches (bho 1 gu 10 - grafaigean). Tha an axis dhìreach a’ sealltainn an luathachadh a thig bho àrdachadh ann an SSC an coimeas ris a’ chùis nuair nach eil ann ach aon tasgadan.
Mar a leughas tu an graf: Feumaidh an ùine cur gu bàs airson 100 mìle leughadh ann am blocaichean 64 KB le aon tasgadan 78 diogan. Ach le 5 caches bheir e 16 diogan. An fheadhainn sin. tha luathachadh de ~ 5 tursan. Mar a chithear bhon ghraf, chan eil a’ bhuaidh gu math follaiseach airson àireamh bheag de leughaidhean co-shìnte; bidh e a’ tòiseachadh a’ cluich pàirt fhaicsinneach nuair a tha barrachd air 50 leughadh snàithlean. agus gu h-àrd a 'toirt àrdachadh coileanaidh gu math nas lugha.
Nota 1: leis gu bheil toraidhean an deuchainn gu math luaineach (faic gu h-ìosal), chaidh 3 ruith a dhèanamh agus chaidh na luachan a thàinig às a chuibheasachadh.
Nota 2: Tha am buannachd dèanadais bho bhith a’ rèiteachadh ruigsinneachd air thuaiream mar an ceudna, ged a tha an ruigsinneachd fhèin beagan nas slaodaiche.
Ach, feumar soilleireachadh, eu-coltach ris a’ chùis le HBase, nach eil an luathachadh seo an-còmhnaidh an-asgaidh. An seo bidh sinn “a’ fuasgladh ”comas an CPU barrachd obrach a dhèanamh, an àite a bhith a’ crochadh air glasan.
An seo chì thu gu bheil, san fharsaingeachd, àrdachadh anns an àireamh de caches a 'toirt àrdachadh timcheall air co-roinneil ann an cleachdadh CPU. Ach, tha beagan a bharrachd choimeasgaidhean buannachaidh ann.
Mar eisimpleir, leig dhuinn sùil nas mionaidiche a thoirt air suidheachadh SSC = 3. Tha an àrdachadh ann an coileanadh air an raon timcheall air 3.3 uair. Gu h-ìosal tha na toraidhean bho na trì rèisean eadar-dhealaichte.
Fhad ‘s a tha caitheamh CPU ag àrdachadh timcheall air 2.8 uair. Chan eil an eadar-dhealachadh glè mhòr, ach tha Greta beag mar-thà toilichte agus is dòcha gu bheil ùine aice a dhol don sgoil agus leasanan a ghabhail.
Mar sin, bidh buaidh mhath aig seo airson inneal sam bith a chleachdas ruigsinneachd mòr air HDFS (mar eisimpleir Spark, msaa), fhad ‘s a tha còd an tagraidh aotrom (ie tha am pluga air taobh teachdaiche HDFS) agus gu bheil cumhachd CPU an-asgaidh ann. . Gus sgrùdadh a dhèanamh, dèanamaid deuchainn dè a’ bhuaidh a bhios aig cleachdadh còmhla de optimization BlockCache agus gleusadh SSC airson leughadh bho HBase.
Chìthear nach eil a ’bhuaidh fo leithid de shuidheachaidhean cho math ri ann an deuchainnean ath-leasaichte (leughadh gun ghiullachd sam bith), ach tha e gu math comasach 80K a bharrachd a chuir a-mach an seo. Còmhla, bidh an dà optimizations a ’toirt seachad astar suas ri 4x.
Chaidh PR a dhèanamh cuideachd airson an optimization seo , a chaidh a chur còmhla agus bidh an gnìomh seo ri fhaighinn ann am fiosan san àm ri teachd.
Agus mu dheireadh, bha e inntinneach coimeas a dhèanamh eadar coileanadh leughaidh stòr-dàta colbh farsaing coltach ris, Cassandra agus HBase.
Gus seo a dhèanamh, chuir sinn air bhog eisimpleirean den ghoireas deuchainn luchd àbhaisteach YCSB bho dhà neach-aoigheachd (800 snàithlean gu h-iomlan). Air taobh an fhrithealaiche - 4 eisimpleirean de RegionServer agus Cassandra air 4 luchd-aoigheachd (chan e an fheadhainn far a bheil an luchd-dèiligidh a 'ruith, gus am buaidh a sheachnadh). Thàinig leughaidhean bho chlàran de mheud:
HBase - 300 GB air HDFS (100 GB dàta fìor)
Cassandra - 250 GB (factar mac-samhail = 3)
An fheadhainn sin. bha an tomhas timcheall air an aon rud (ann an HBase beagan a bharrachd).
Paramadairean HBase:
dfs.client.short.circuit.num = 5 (Optimization teachdaiche HDFS)
hbase.lru.cache.heavy.eviction.count.limit = 30 - tha seo a’ ciallachadh gun tòisich am paiste ag obair às deidh 30 fuadaichean (~ 5 mionaidean)
hbase.lru.cache.heavy.eviction.mb.size.limit = 300 - meud targaid de thasgadh agus fuadachadh
Chaidh logaichean YCSB a pharsadh agus a chur ri chèile ann an grafaichean Excel:
Mar a chì thu, tha na optimizations sin ga dhèanamh comasach coimeas a dhèanamh eadar coileanadh nan stòran-dàta sin fo na cumhaichean sin agus 450 mìle leughadh gach diog a choileanadh.
Tha sinn an dòchas gum bi am fiosrachadh seo feumail do chuideigin tron strì inntinneach airson cinneasachd.
Source: www.habr.com