Najlepsza odpowiedź
Cóż, współczynnik replikacji to 3 Domyślnie w HDFS . W tym przypadku jeden to oryginalny blok i dwie repliki.
Ale można to Ustawić przez nas.
Pozwól, że wyjaśnię ci, jak to zrobić.
Widzisz, są na to dwa sposoby. Jeden jest za pomocą polecenia i other to bezpośrednia zmiana w hdfs-site.xml plik.
Pierwsza jest prosta, wystarczy wpisać następujące polecenie:
Możesz także zmień współczynnik replikacji na podstawie pliku za pomocą powłoki Hadoop FS .
[sawant@localhost ~]$ hadoop fs –setrep –w 3 /my/file
Alternatywnie możesz zmienić współczynnik replikacji wszystkich plików w katalogu.
[sawant@localhost ~]$ hadoop fs –setrep –w 3 -R /my/dir
jako widzisz powyższe polecenie, po prostu zamień 3 na dowolne ze swoich wymagań.
Rozumiemy drugie…
Otwórz witrynę hdfs plik .xml . Ten plik zwykle znajduje się w folderze conf / katalogu instalacyjnego Hadoop. Zmień lub dodaj następującą właściwość do hdfs-site.xml….
hdfs-site.xml służy do konfigurowania HDFS. Zmiana właściwości dfs.replication w hdfs-site.xml spowoduje zmianę domyślnej replikacji dla wszystkie pliki umieszczone w HDFS.
Powyżej właściwość dfs.replication po prostu zastąp 3 dowolną wartością.
Dziękuję !!
Odpowiedź
Prawdziwym powodem wybrania replikacji trzech jest to, że jest to najmniejsza liczba, która pozwala na wysoce niezawodny projekt. Przeanalizujmy prawdziwą analizę, dlaczego.
Weź pod uwagę, że utracisz dane, jeśli wystąpi błąd sprzętowy na sprzęcie przechowującym każdą replikę danych. W przypadku nowoczesnych dysków wirujących wskaźnik awaryjności jest stosunkowo prosty i wynosi około 5\% rocznie (liczby mogą być wyższe lub niższe w zależności od metody szacowania i kupowanego sprzętu). Jeśli wszystkie awarie są niezależne (tak naprawdę nie są, ponieważ otrzymujesz złe partie), oznacza to, że poszczególne dyski zawodzą z częstotliwością około 1,6e-9 awarii na sekundę, a awarie powinny być rozdzielane zgodnie z rozkładem Poissona. Tysiąc dysków powinno spowodować utratę danych około 1000 razy większą w krótkich okresach, jeśli nie założysz żadnej replikacji.
Możemy wykorzystać te liczby do obliczenia czegoś, co nazywa się średnim czasem do utraty danych. W przypadku jednego dysku masz 95\% szans na zachowanie danych po roku, ale w przypadku tysiąca dysków masz znikomą szansę na uniknięcie utraty danych po roku. Szczerze mówiąc, nie sądzę, aby nawet obudowa jednego dysku była do przyjęcia.
Więc replikujemy dane.
Tysiąc dysków będzie miał około 50 awarii rocznie, co przekłada się na utrata dysku co tydzień. Nie oznacza to, że będzie się to działo dokładnie w tygodniowych odstępach. Oznacza to po prostu, że średni czas między awariami dysku wyniesie około tygodnia. Po awarii dysku będziemy musieli ponownie zreplikować dane, ponieważ nie chcemy systemu, który z czasem ulega degradacji. Jeśli uda nam się ponownie zreplikować dane, zanim następny dysk zawierający nasze dane ulegnie awarii, nasz system uniknie utraty danych z powodu pierwszej awarii.
Jednak sztuczka polega na tym, że czas między poszczególnymi dyskami awarie będą się zmniejszać wraz ze wzrostem rozmiaru systemów. Jeśli jednak dobrze zaprojektujemy, czas ponownej replikacji * zmniejszy się * w tej samej proporcji. Czas potrzebny na odzyskanie danych zależy od liczby dysków na komputer i przepustowości sieci między komputerami.
Oznacza to, że możemy łatwo oszacować średni czas do utraty danych. W przypadku dwóch kopii musimy obliczyć współczynnik utraty dysku, a następnie obliczyć prawdopodobieństwo kolejnej utraty dysku w czasie odzyskiwania po tej utracie. W przypadku dwóch kopii musimy to rozszerzyć na przypadek, w którym dwa dyski umierają w czasie odzyskiwania pierwszego dysku. Staje się to bardziej skomplikowane, gdy rozłożymy dyski i masz wymyślne strategie odzyskiwania, które starają się zachować normalne działanie po pierwszej awarii, ale poświęcają wszystkie zasoby na odzyskanie po drugiej awarii.
Jeśli wykonasz obliczenia matematyczne, jedna kopia danych daje bardzo wysokie prawdopodobieństwo (w rzeczywistości prawie pewne) utraty danych w dużym klastrze.
W przypadku dwóch kopii istnieje prawdopodobieństwo utraty danych, które mieści się w zakresie 0,3 \% – 5\% w zależności od parametrów klastra. To nie jest wystarczające dla większości firm, ale niektóre aplikacje mogą to tolerować.
W przypadku trzech kopii zwykle można zwiększyć prawdopodobieństwo utraty danych do ,1\% rocznie, co odpowiada średniemu czasowi utraty danych wynoszącemu 1000 lat lub więcej, jeśli postępujesz właściwie.
Więc to jest powód.