Beste svaret
Vel, replikasjonsfaktoren er 3 Som standard i HDFS . I dette er en originalblokk og to kopier.
Men det kan være Sett av oss.
La meg forklare deg hvordan du gjør det.
Se, det er to måter å gjøre det på. En er ved å bruke kommando og annet er direkte endring i hdfs-site.xml fil.
Den første er enkel, du trenger bare å skrive kommandoen slik:
Du kan også endre replikasjonsfaktoren på per fil ved hjelp av Hadoop FS-skallet .
[sawant@localhost ~]$ hadoop fs –setrep –w 3 /my/file
Alternativt kan du endre replikasjonsfaktoren for alle filene under en katalog.
[sawant@localhost ~]$ hadoop fs –setrep –w 3 -R /my/dir
som du ser kommandoen ovenfor, bare bytt ut 3 med hva du måtte ønske deg.
La oss forstå den andre …
Åpne hdfs-siden .xml -fil. Denne filen finnes vanligvis i conf / -mappen i Hadoop-installasjonskatalogen. Endre eller legg til følgende egenskap i hdfs-site.xml….
hdfs-site.xml brukes til å konfigurere HDFS. Hvis du endrer eiendommen dfs.replication i hdfs-site.xml , endres standardreplikasjonen for alle filene som er plassert i HDFS.
Ovenfor dfs.replication-egenskap erstatter du bare 3 med hva du måtte ønske.
Takk !!
Svar
Den virkelige grunnen til å velge replikering av tre er at det er det minste tallet som gir en svært pålitelig design. La oss gå gjennom en reell analyse av hvorfor.
Vurder at du mister data hvis du har en maskinvarefeil på maskinvaren som lagrer hver replika av dataene. For moderne spinneskiver er feilprosenten relativt enkel og er omtrent 5\% per år (tallene dine kan være høyere eller lavere, avhengig av beregningsmetode og maskinvare du kjøper). Hvis alle feil er uavhengige (de er ikke, egentlig siden du får dårlige batcher), betyr dette at individuelle disker mislykkes med en hastighet på omtrent 1,6e-9 feil per sekund, og feilene bør fordeles i henhold til en Poisson-fordeling. Tusen disker bør ha tap av data på omtrent 1000 ganger denne hastigheten over korte tidsperioder hvis du ikke antar noen replikering.
Vi kan bruke disse tallene til å beregne noe som kalles middel tid til tap av data. I enkeltdisksaken har du en 95\% sjanse for å beholde dataene dine etter et år, men i tusen disksaken har du en ubetydelig sjanse for å unngå tap av data etter et år. Jeg tror ikke at selv den eneste disksaken er akseptabel, ærlig talt.
Så vi replikerer dataene.
De tusen disksaken vil ha omtrent 50 feil per år, som oversettes til et disketap hver uke eller så. Det betyr ikke at det vil skje med nøyaktige ukentlige intervaller. Det betyr bare at gjennomsnittlig tid mellom diskfeil vil være omtrent en uke. Etter en disksvikt, må vi replikere dataene på nytt fordi vi ikke vil ha et system som brytes ned over tid. Hvis vi kan replikere dataene før neste disk mislykkes som inneholder dataene våre, vil systemet vårt unngå tap av data på grunn av den første feilen.
Trikset er imidlertid at tiden mellom individuell disk feil vil reduseres ettersom systemene øker i størrelse. Hvis vi designer ting bra, vil replikeringstiden imidlertid * reduseres * i samme andel. Tiden for gjenoppretting vil avhenge av antall stasjoner per maskin og nettverksbåndbredden mellom maskinene.
Det betyr at vi ganske enkelt kan gjøre et raskt estimat av tiden for tap av data. For to eksemplarer må vi beregne frekvensen for disktap og deretter beregne sannsynligheten for et annet disktap i løpet av gjenopprettingstiden for det tapet. For to eksemplarer må vi utvide dette til tilfellet der to stasjoner dør i løpet av gjenopprettingstiden for den første stasjonen. Dette blir mer komplekst når du striper disker og har fancy gjenopprettingsstrategier som prøver å beholde normal drift etter den første feilen, men som bruker alle ressurser på å gjenopprette etter den andre feilen.
Hvis du gjør matematikken, en kopi av data gir deg en veldig høy sannsynlighet (nesten sikker, faktisk) for å miste data i en stor klynge.
For to kopier har du en sannsynlighet for å miste data som er i området 0,3 \% – 5\% avhengig av klyngeparametere. Dette er ikke bra nok for de fleste bedrifter, men noen applikasjoner tåler dette.
For tre eksemplarer kan du vanligvis utvide sannsynligheten for tap av data til ,1\% per år, tilsvarende en gjennomsnittlig tid til tap av data på 1000 år eller mer hvis du gjør ting riktig.
Så det er grunnen.