Cel mai bun răspuns
Ei bine, factorul de replicare este 3 În mod implicit în HDFS . În aceasta, unul este blocul original și două replici.
Dar poate fi Set de la noi.
Permiteți-mi să vă explic cum să faceți acest lucru.
Vedeți, există două modalități de a o face. Una este utilizând comanda și alt este o schimbare directă în hdfs-site.xml fișier.
Mai întâi este simplu, trebuie doar să tastați comanda după cum urmează:
De asemenea, puteți modificați factorul de replicare pe pe fișier utilizând shell-ul Hadoop FS .
[sawant@localhost ~]$ hadoop fs –setrep –w 3 /my/file
Alternativ, puteți modifica factorul de replicare a toate fișierele din un director.
[sawant@localhost ~]$ hadoop fs –setrep –w 3 -R /my/dir
as vedeți comanda de mai sus, înlocuiți doar 3 cu orice cerință aveți.
Să înțelegem a doua …
Deschideți site-ul hdfs fișier .xml . Acest fișier se găsește de obicei în folderul conf / din directorul de instalare Hadoop. Schimbați sau adăugați următoarea proprietate la hdfs-site.xml….
hdfs-site.xml este utilizat pentru a configura HDFS. Modificarea proprietății dfs.replication din hdfs-site.xml va modifica replicarea implicită pentru toate fișierele plasate în HDFS.
În mai sus proprietate dfs.replication înlocuiți doar 3 cu indiferent de cerința dvs.
Mulțumesc !!
Răspuns
Motivul real pentru alegerea replicării a trei este că este cel mai mic număr care permite un design extrem de fiabil. Să parcurgem o analiză reală a motivului.
Luați în considerare faptul că veți pierde date dacă aveți o eroare hardware la hardware-ul care stochează fiecare replică a datelor. Pentru discurile rotative moderne, rata de eșec este relativ simplă și este de aproximativ 5\% pe an (numerele dvs. pot fi mai mari sau mai mici în funcție de metoda de estimare și de hardware-ul pe care îl cumpărați). Dacă toate eșecurile sunt independente (nu sunt, într-adevăr, deoarece primiți loturi proaste), atunci acest lucru înseamnă că discurile individuale eșuează cu o rată de aproximativ 1,6 e-9 eșecuri pe secundă și eșecurile ar trebui distribuite în funcție de o distribuție Poisson. O mie de discuri ar trebui să aibă o pierdere de date de aproximativ 1000 ori mai mare decât această rată pe perioade scurte de timp, dacă nu presupuneți nicio replicare.
Putem folosi aceste numere pentru a calcula ceva numit timpul mediu până la pierderea datelor. În cazul unui singur disc, aveți o șansă de 95\% să vă păstrați datele după un an, dar în cazul unui disc de o mie, aveți o șansă neglijabilă de a evita pierderea datelor după un an. Nu cred că nici măcar carcasa unui singur disc este acceptabilă, sincer.
Deci, replicăm datele.
Carcasa cu o mie de discuri va avea aproximativ 50 de eșecuri pe an o pierdere de disc în fiecare săptămână sau cam așa ceva. Asta nu înseamnă că se va întâmpla la intervale săptămânale exacte. Înseamnă doar că timpul mediu dintre defecțiunile discului va fi de aproximativ o săptămână. După o defecțiune a discului, va trebui să replicăm datele, deoarece nu dorim un sistem care se degradează în timp. Dacă putem replica datele înainte de eșuarea următorului disc care conține datele noastre, atunci sistemul nostru va evita pierderea datelor din cauza primei defecțiuni.
Totuși, trucul este acela că timpul dintre discul individual eșecurile vor scădea odată cu creșterea dimensiunii sistemelor. Dacă proiectăm lucrurile bine, totuși, timpul de replicare va * scădea * în aceeași proporție. Timpul de recuperare va depinde de numărul de unități pe mașină și de lățimea de bandă a rețelei între mașini.
Asta înseamnă că putem face o estimare rapidă a timpului mediu până la pierderea de date destul de ușor. Pentru două copii, trebuie să calculăm rata pierderii de disc și apoi să calculăm probabilitatea unei alte pierderi de disc în timpul recuperării pentru acea pierdere. Pentru două exemplare, trebuie să extindem acest lucru în cazul în care două unități mor în timpul recuperării primei unități. Acest lucru devine mai complex atunci când stripeți discuri și aveți strategii fantastice de recuperare care încearcă să păstreze funcționarea normală după primul eșec, dar care alocă toate resursele recuperării după al doilea eșec.
Dacă faceți calculul, o copie a datelor vă oferă o probabilitate foarte mare (aproape sigură, de fapt) de a pierde date într-un cluster mare.
Pentru două copii, aveți probabilitatea de a pierde date care este în intervalul de 0,3 \% – 5\% în funcție de parametrii clusterului. Acest lucru nu este suficient de bun pentru majoritatea companiilor, dar unele aplicații pot tolera acest lucru.
Pentru trei exemplare, puteți extinde, de obicei, probabilitatea pierderii de date la ,1\% pe an, echivalent cu un timp mediu până la pierderea de date de 1000 de ani sau mai mult, dacă faceți lucrurile corect.
Deci acesta este motivul.