ベストアンサー
まあ、レプリケーション係数は 3デフォルトでHDFSに。この場合、1つは元のブロックで2つはレプリカです。
ただし、設定することもできます。
その方法を説明しましょう。
ほら、2つの方法があります。 1つはコマンドを使用することで、その他は hdfs-site.xml ファイル。
最初のは単純で、次のようにコマンドを入力するだけです：
また、 HadoopFSシェルを使用してファイルごとにレプリケーション係数を変更します。
[sawant@localhost ~]$ hadoop fs –setrep –w 3 /my/file
または、ディレクトリの下にあるすべてのファイルのレプリケーション係数を変更できます。
[sawant@localhost ~]$ hadoop fs –setrep –w 3 -R /my/dir
as上記のコマンドが表示されたら、3を要件に置き換えてください。
2番目のコマンドを理解しましょう…
hdfs-siteを開きます.xml ファイル。このファイルは通常、Hadoopインストールディレクトリの conf / フォルダーにあります。次のプロパティを変更するか、 hdfs-site.xml…。
hdfs-site.xml は、HDFSを構成するために使用されます。 hdfs-site.xml の dfs.replication プロパティを変更すると、のデフォルトのレプリケーションが変更されます。すべてのファイルがHDFSに配置されます。
上記の dfs.replicationプロパティは、3を要件に置き換えるだけです。
ありがとう!!
回答
3つのレプリケーションを選択する本当の理由は、信頼性の高い設計を可能にする最小の数であるためです。理由の実際の分析を見ていきましょう。
データの各レプリカを保存しているハードウェアにハードウェア障害があると、データが失われることを考慮してください。最新のスピニングディスクの場合、故障率は比較的単純で、年間約5％です（見積もり方法と購入するハードウェアに応じて、数値が高くなることも低くなることもあります）。すべての障害が独立している場合（実際には悪いバッチが発生するため、そうではありません）、これは、個々のディスクが1秒あたり約1.6e-9の障害の割合で障害が発生することを意味し、障害はポアソン分布に従って分散する必要があります。レプリケーションがないと仮定した場合、1,000台のディスクでは、短期間にこの速度の約1000倍のデータ損失が発生するはずです。
これらの数値を使用して、データ損失までの平均時間と呼ばれるものを計算できます。シングルディスクの場合、1年後にデータを保持する可能性は95％ですが、1000ディスクの場合、1年後にデータの損失を回避する可能性はごくわずかです。率直に言って、単一のディスクケースでも受け入れられるとは思いません。
データを複製します。
1000台のディスクケースでは、年間約50回の障害が発生します。毎週かそこらのディスク損失。それは正確な週間隔で起こるという意味ではありません。これは、ディスク障害の平均間隔が約1週間になることを意味します。ディスクに障害が発生した後、時間の経過とともに劣化するシステムは必要ないため、データを再複製する必要があります。データを含む次のディスクに障害が発生する前にデータを再複製できれば、システムは最初の障害によるデータの損失を回避できます。
ただし、トリックは、個々のディスク間の時間です。システムのサイズが大きくなると、障害は減少します。ただし、うまく設計すれば、再複製時間は同じ割合で*減少*します。回復にかかる時間は、マシンあたりのドライブ数とマシン間のネットワーク帯域幅によって異なります。
つまり、データ損失までの平均時間を非常に簡単にすばやく見積もることができます。 2つのコピーの場合、ディスク損失の割合を計算してから、その損失の回復時間中に別のディスク損失の確率を計算する必要があります。 2つのコピーの場合、最初のドライブの回復時間中に2つのドライブが停止する場合にこれを拡張する必要があります。これは、ディスクをストライプ化し、最初の障害後も通常の動作を維持しようとするが、2回目の障害後の回復にすべてのリソースを費やすという凝った回復戦略がある場合、より複雑になります。
計算を行う場合、データのコピーが1つあると、大規模なクラスターでデータが失われる可能性が非常に高くなります（実際にはほぼ確実です）。
2つのコピーの場合、0.3の範囲のデータが失われる可能性があります。 ％-5％は、クラスターパラメーターによって異なります。これはほとんどの企業にとって十分ではありませんが、一部のアプリケーションはこれを許容できます。
3つのコピーの場合、通常、データ損失の確率を年間0.1％未満に拡張できます。これは、適切に実行した場合、データ損失までの平均時間が1000年以上になることに相当します。
それが理由です。