Mi a replikációs tényező a HDFS-ben, és hogyan állíthatjuk be?


Legjobb válasz

Nos, a replikációs tényező 3 Alapértelmezés szerint a HDFS-ben . Ebben az egyik eredeti blokk és két másolat.

De lehet Beállítás általunk.

Hadd magyarázzam el, hogyan kell csinálni.

Lásd, kétféleképpen tehetjük meg. Egy a parancs használatával, az egyéb pedig a hdfs-site.xml fájl.

Az első egyszerű, csak be kell írnia a parancsot az alábbiak szerint:

módosítsa a replikációs tényezőt fájlonként a Hadoop FS shell használatával.

[sawant@localhost ~]$ hadoop fs –setrep –w 3 /my/file

Alternatív megoldásként megváltoztathatja az fájlok replikációs tényezőjét egy könyvtár alatt.

[sawant@localhost ~]$ hadoop fs –setrep –w 3 -R /my/dir

as látja a fenti parancsot, egyszerűen cserélje le a 3-at a kívántra.

Értsük meg a másodikat …

Nyissa meg a hdfs webhelyet .xml fájl. Ez a fájl általában a Hadoop telepítési könyvtár conf / mappájában található. Módosítsa vagy adja hozzá a következő tulajdonságot a következőhöz: hdfs-site.xml….

dfs.replication

3

Block Replication

hdfs-site.xml a HDFS konfigurálására szolgál. A dfs.replication tulajdonság megváltoztatása a hdfs-site.xml fájlban megváltoztatja a az összes fájl a HDFS-be került.

A fenti dfs.replication tulajdonságban csak 3-at cseréljen a kívántra.

Köszönöm !!

Válasz

A három replikáció kiválasztásának az az igazi oka, hogy a legkisebb szám teszi lehetővé a nagyon megbízható kialakítást. Vizsgáljuk át a miértek valódi elemzését.

Fontolja meg, hogy elveszíti az adatokat, ha hardverhiba van az adatok minden másolatát tároló hardverben. A modern forgó lemezek esetében a meghibásodási arány viszonylag egyszerű és nagyjából körülbelül 5\% évente (a számok magasabbak vagy alacsonyabbak lehetnek a becslési módszertől és a megvásárolt hardvertől függően). Ha minden hiba független (valóban nem az, mivel rossz kötegeket kap), akkor ez azt jelenti, hogy az egyes lemezek kb. 1,6e-9 meghibásodás / másodperc arányban hibásodnak meg, és a hibákat Poisson-eloszlás szerint kell elosztani. Ezer lemeznek ennek az aránynak az 1000-szeresének kell lennie rövid időn belül, ha nem feltételezünk replikációt.

Ezekkel a számokkal kiszámíthatunk egy úgynevezett átlagveszteséget. Az egylemezes esetben 95\% esélye van arra, hogy egy év után megőrizze adatait, de az ezer lemez esetében elhanyagolható esélye van arra, hogy egy év múlva elkerülje az adatvesztést. Nem hiszem, hogy őszintén szólva még az egylemezes eset is elfogadható.

Tehát megismételjük az adatokat.

Az ezer lemezes esetnek évente körülbelül 50 meghibásodása lesz, ami nagyjából hetente lemezveszteség. Ez nem azt jelenti, hogy pontosan heti időközönként fog történni. Ez csak azt jelenti, hogy a lemezhibák közötti átlagos idő körülbelül egy hét lesz. Lemezhiba után újra kell ismételnünk az adatokat, mert nem akarunk olyan rendszert, amely idővel romlik. Ha újrareplikálhatjuk az adatokat, mielőtt a következő lemez meghibásodna, amely tartalmazza az adatainkat, akkor rendszerünk elkerüli az első hiba miatt bekövetkező adatvesztést.

A trükk azonban az, hogy az egyes lemezek közötti idő a kudarcok a rendszerek méretének növekedésével csökkennek. Ha jól tervezünk dolgokat, akkor az újrareplikációs idő ugyanabban az arányban * csökken *. A helyreállítás ideje függ a gépenkénti meghajtók számától és a gépek közötti hálózati sávszélességtől.

Ez azt jelenti, hogy elég könnyen meg tudjuk becsülni az adatvesztésig eltelt idő átlagát. Két példány esetén ki kell számolnunk a lemezveszteség mértékét, majd ki kell számolnunk annak a valószínűségét, hogy a helyreállítási idő alatt egy másik lemez elveszik. Két példány esetén ezt ki kell terjesztenünk arra az esetre, amikor két meghajtó meghal az első meghajtó helyreállítási ideje alatt. Ez bonyolultabbá válik, ha lemezeket csíkol, és olyan fantasztikus helyreállítási stratégiákat alkalmaz, amelyek megpróbálják megtartani a normális működést az első hiba után, de amelyek minden erőforrást a második hiba után történő helyreállításra fordítanak.

Ha elvégzed a matematikát, az adatok egy példánya nagy valószínűséggel (valójában szinte biztosan) elveszíti az adatokat egy nagy fürtben.

Két példány esetén az adatok elvesztésének valószínűsége 0,3 tartományba esik. \% – 5\% a fürt paramétereitől függően. Ez nem elég jó a legtöbb vállalkozás számára, de egyes alkalmazások ezt elviselik.

Három példány esetén általában megnövelheti az adatvesztés valószínűségét ,1\% -ra évente, ami megfelel az 1000 éves vagy annál hosszabb átlagos veszteségnek, ha jól csinálod a dolgokat.

Tehát ez az oka.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük