HDFS では、ローカル読み取り( DFSClient と Datanode が同じノード上にある) であっても読み取り( DFSClient と Datanode が同じノード上にない) であっても、基礎となる処理方法は同じであり、データは最初にDatanode によって読み取られます。次に、 RPC ( TCPベース ) を通じて、データを DFSClientに渡します。この処理は比較的単純ですが、途中でデータノードが転送を行う必要があるため、パフォーマンスに影響します。

特にローカル読み取りの場合、 DFSClient とデータは同じマシン上にあるため、 DFSClient が Datanode をバイパスして単独でデータを読み取るというのが自然な考え方です。いわゆる「ショートサーキット」読み取りは DataNodeをバイパスし、クライアントがファイルを直接読み取ることができます。明らかに、これはクライアントがデータと同じマシン上にある場合にのみ機能します。短絡読み取りにより、多くのアプリケーションのパフォーマンスが大幅に向上します。

1.2 旧バージョンの設計と実装

HDFS-2246 この JIRA では、エンジニアのアイデアは、読み取りデータ DFSClient とデータが同じマシン上にあるため、 Datanode はファイルシステム内のデータのパスを読み取り(オフセット)を行うというものです。 ) 、読み取る量(長さ) 、およびその他の情報をDFSClientに伝え、 DFSClient がファイルを開いてそれ自体を読み取ります。

アイデアは良いですが、問題は複雑な構成とセキュリティの問題にあります。

1 つ目は構成の問題です。DFSClient はファイルを開いてデータを読み取るため、ホワイトリストを構成して、どのユーザーが Datanode のデータディレクトリにアクセスできるかを定義する必要があります。

新しいユーザーが参加する場合は、ホワイトリストを変更する必要があります。これは、クライアントが Datanode にアクセスできるようにするデータディレクトリであることに注意してください。つまり、この権限を持つユーザーはディレクトリ内の他のデータにアクセスでき、これがセキュリティホールにつながります。

したがって、この実装は非推奨となります。

1.3 セキュリティ強化版の設計と実装

HDFS-347 では、ローカル読み取りデータの短絡をより安全にするための新しいソリューションが提案されています。Linux には、 Unix Domain Socketと呼ばれるテクノロジーがあります。Unix Domain Socket は、同じマシン上の 2 つのプロセスがSocketの形式で通信できるようにするプロセス間通信方法です。これがもたらすもう 1 つの大きな利点は、2 つのプロセスがこれを使用して、通常のデータに加えてプロセス間でファイル記述子を転送できることです。

マシン上に 2 人のユーザー Aと Bがいて、A には特定のファイルにアクセスする権限があるが、 B には権限がなく、 B はこのファイルにアクセスする必要があるとします。Unix ドメインソケットの助けを借りて、 A はファイルを開いてファイル記述子を取得し、そのファイル記述子を Bに渡すことができます。また、 B は、対応するアクセス許可を持っていなくても、ファイルの内容を読み取ることができます。

HDFS シナリオでは、A は Datanode 、B はDFSClientで、読み取られるファイルは Datanode データディレクトリ内のファイルです。

1.4 短絡ローカル読み取り構成

1.4.1 libhadoop.so

Java は Unix ドメインソケットを直接操作できないため、 Hadoop のネイティブパッケージlibhadoop.soをインストールする必要があります。これは、 Hadoop ソースコードをコンパイルするときにネイティブモジュールをコンパイルすることによって取得できます。次のコマンドを使用して、ネイティブパッケージがインストールされているかどうかを確認できます。

1.4.2 hdfs-site.xml

[root@hadoop01 ~]# vim /bigdata/hadoop/server/hadoop-3.2.4/etc/hadoop/hdfs-site.xml 
<property>
  <name>dfs.client.read.shortcircuit</name>
  <value>true</value>
</property>
<property>
  <name>dfs.domain.socket.path</name>
  <value>/var/lib/hadoop-hdfs/dn_socket</value>
</property>

dfs.client.read.shortcircuit は、ショートサーキットローカル読み取り機能を有効にするスイッチです。
dfs.domain.socket.path は、 Dtanode と DFSClient の間で通信される Socket のローカルパスです。

また、ソケットのローカルパスが事前に作成されていることを確認してください (クラスターの各ノードを作成する必要があります)。

[root@hadoop01 ~]# mkdir -p /var/lib/hadoop-hdfs

注: フォルダーhadoop -hdfs はここに作成され、上記の構成の dn_socket は フォルダーではなくdatanode 自体によって作成されます。

最後に、構成ファイルを他のノードにプッシュし、HDFS クラスターを再起動します。

1.4.3 データノードのログを表示する

Datanode の起動ログでは、次の関連ログに Unix Domain Socket が有効であることが示され、構成が有効であることが確認されます。

[root@hadoop01 ~]# cd /bigdata/hadoop/server/hadoop-3.2.4/logs/
[root@hadoop01 /bigdata/hadoop/server/hadoop-3.2.4/logs]# tail -100 hadoop-root-datanode-hadoop01.log

2. HDFS ブロックロードバランサー:バランサー

2.1 背景

HDFS データは、DataNode 間で常に均等に分散されるとは限りません。一般的な原因は、既存のクラスターに新しいデータノードを追加することです。HDFS は、ブロック配置情報を分析し、バランスが取れているとみなされるまでデータノード全体でデータのバランスをとるバランサープログラムを提供します。

いわゆるバランスとは、各 DataNode の使用率(マシンの総容量に対するマシンの使用容量の比率) とクラスターの使用率(全体の使用容量の比率) の差を意味します。 HDFS クラスターの総容量に対する HDFS の割合は、指定されたしきい値のパーセンテージを超えません。バランサーは、単一のDataNode 上の個々のボリューム (ディスク)間でバランスをとることはできません。

2.2 コマンドライン設定

[root@hadoop01 ~]# hdfs balancer --help
Usage: hdfs balancer
	[-policy <policy>]	the balancing policy: datanode or blockpool
	[-threshold <threshold>]	Percentage of disk capacity
	[-exclude [-f <hosts-file> | <comma-separated list of hosts>]]	Excludes the specified datanodes.
	[-include [-f <hosts-file> | <comma-separated list of hosts>]]	Includes only the specified datanodes.
	[-source [-f <hosts-file> | <comma-separated list of hosts>]]	Pick only the specified datanodes as source nodes.
	[-blockpools <comma-separated list of blockpool ids>]	The balancer will only run on blockpools included in this list.
	[-idleiterations <idleiterations>]	Number of consecutive idle iterations (-1 for Infinite) before exit.
	[-runDuringUpgrade]	Whether to run the balancer during an ongoing HDFS upgrade.This is usually not desired since it will not affect used space on over-utilized machines.

-threshold 10 クラスタバランスの条件、データノード間のディスク使用量差の閾値、間隔選択: 0~100
-policy datanode Balance ポリシー。デフォルトは datanode です。datanodeがバランスされている場合、クラスターはバランスされています。
-exclude -f /tmp/ip1.txt はデフォルトでは空です。ipのこの部分がバランスに参加しないことを指定し、-f は入力がファイルであることを指定します。
-include -f /tmp/ip2.txt はデフォルトでは空であり、ip のこの部分のみがバランスに参加することを許可します。 -fは入力をファイルとして指定します
-idleiterations 5 反復5

2.3 バランサーの実行方法

2.3.1 バランスの取れたデータ転送ベルトのセットアップ

hdfs dfsadmin -setBalancerBandwidth newbandwidth

ここで、 newbandwidth は、バランシング操作中に各データノードが使用できるネットワーク帯域幅の最大量 ( バイト/秒)です。

例: hdfs dfsadmin - setBalancerBandwidth 104857600 ( 100M )

2.3.2 ランバランサ

デフォルトパラメータで実行: HDFSバランサー

実行するしきい値を指定します。hdfs Balancer -threshold 5 バランサーはしきい値の 5 % (デフォルトは 10% )で実行されます。

これは、各データノードのディスク使用量がクラスター全体の使用量と 5 %を超えて変わらないことをプログラムが保証することを意味します。たとえば、クラスター内のすべてのDataNode の合計使用量がクラスターの合計ディスクストレージ容量の 40 % である場合、プログラムは各DataNode のディスク使用量がそのDataNode のディスクストレージ容量の35 % から 45 % の間にあることを保証します。。

3.ディスクバランサー: HDFS ディスクバランサー

3.1 背景

個人の PC と比較して、サーバーは一般に複数のディスクを搭載することで 1 台のマシンの記憶容量を拡張できます。Hadoop HDFS では、DataNode が最終的なデータブロックのストレージを担当し、ホストマシン上のディスク間でデータブロックを分散します。新しいブロックを書き込むとき、DataNodes は選択ポリシー (ラウンドロビンポリシーまたは空き領域ポリシー)に従ってブロックのディスク (ボリューム)を選択します。

ラウンドロビン戦略: 新しいブロックを利用可能なディスク全体に均等に分散します。このポリシーはデフォルトです。
空き容量ポリシー: このポリシーは、(パーセンテージで) より多くの空き容量があるディスクにデータを書き込みます。

しかし、長時間実行されるクラスターでラウンドロビン戦略を使用すると、データノードがストレージディレクトリ(ディスク/ボリューム) に不均等にデータを配置することがあり、一部のディスクがいっぱいで、他のディスクがほとんど使用されないという状況が発生します。これは、大量の書き込みおよび削除操作、またはディスクの交換によって発生する可能性があります。

また、空き領域に基づく選択戦略を使用する場合、新しい書き込みはそれぞれ新しく追加された空のディスクに送られ、その期間中他のディスクは空き状態になります。これにより、新しいディスクにボトルネックが発生します。したがって、ディスク交換やランダムな書き込みと削除によって発生するデータノード内スキュー (ディスク上のブロックの不均一な分散) に対処するには、データノード内バランシング( DataNode 内のデータブロックの均一な分散) が必要です。

そのため、 Hadoop 3.0 では、 DataNodes 内でのデータの分散に重点を置いたDisk Balancer と呼ばれるツールが導入されました。

3.2 HDFSディスクバランサの概要

HDFS ディスクバランサーは 、 Hadoop 3 で導入されたコマンドラインツールで、ディスク間のデータノード内のデータの不均一な分散のバランスをとるために使用されます。ここで特に注意してください。HDFSディスクバランサーは HDFS バランサーとは異なります。

HDFS ディスクバランサーは、特定の DataNode 上で動作し、あるディスクから別のディスクにブロックを移動します。これにより、 DataNode の内部データが異なるディスク間でバランスがとられます。
HDFS バランサーは、 DataNode ノード間の分散のバランスをとります。

3.3 HDFSディスクバランサー機能

3.3.1 データ配布レポート

クラスター内のどのコンピューターがデータの不均一な分散に苦しんでいるかを測定するために、ディスクバランサーは、ボリュームデータ密度メトリック(ボリューム/ディスクデータ密度メトリック)とノードデータ密度メトリック(ノードデータ密度メトリック)を定義します。

ボリューム (ディスク) データ密度: 同じマシン上の異なるボリューム間のデータ分散を比較します。
ノードのデータ密度: 比較は異なるマシン間で行われます。

3.3.1.1 ボリュームデータ密度メトリック（ボリュームデータ密度）の計算

ボリュームデータ密度の正の値はディスクが十分に利用されていないことを示し、負の値は現在の理想的なストレージターゲットと比較してディスクが過剰に利用されている。

コンピューターに 4 つのボリューム/ディスク( Disk1 、Disk2 、Disk3 、Disk4 ) があると仮定すると、個々のディスク使用量は次のようになります。

合計容量= 200 + 300 + 350 + 500 = 1350 GB

合計使用量 = 100 + 76 + 300 + 475 = 951 GB

したがって、各ボリューム/ディスク上の理想的なストレージは次のようになります。

理想的なストレージ=合計使用量 ÷合計容量= 951 ÷ 1350 = 0.70

つまり、各ディスクは理想的なストレージ容量の70 %に維持する必要があります。

ボリュームのデータ密度=理想的なストレージ– dfs 使用率

たとえば、 Disk1 のボリュームデータ密度は= 0.70 - 0.50 = 0.20 です。その他など。

3.3.1.2 ノードデータ密度の計算プロセス

ノードデータ密度(ノードデータ密度) =ノード上のすべてのボリュームデータ密度ボリューム (ディスク)のデータ密度の絶対値の合計。

上の例のノードデータ密度=|0.20|+|0.45|+|-0.15|+|-0.24| =1.04

ノードのデータ密度の値が低いほど、マシンノードのスケーラビリティが優れていることを示し、値が高いほど、ノードのデータ分散がより偏っていることを示します。

ボリュームデータ密度とノードデータ密度を取得すると、クラスター内のデータ分布が偏っているノードと、データが偏っているディスクをマシン上で段階的に見つけることができます。

3.3.2 ディスクバランシング

DataNode ノードがディスクデータバランス用に指定されている場合、現在のボリュームのデータ密度(ディスクボリュームのデータ密度)を最初に計算または読み取ることができます。この情報を使用すると、どのボリュームがオーバープロビジョニングされているか、どのボリュームがアンダープロビジョニングされているかを簡単に判断できます。

DataNode 内のあるボリュームから別のボリュームにデータを移動するために、 Hadoop 開発では RPC プロトコルに基づいてディスクバランサを実装します。

3.4 オープンHDFSディスクバランサー

HDFS ディスクバランサーは、2 つのディスク間で移動するデータの量を記述した一連のステートメントであるプランを作成し、そのステートメントセットをデータノード上で実行することによって動作します。計画には複数の移動ステップが含まれています。計画の各移動ステップには、宛先ディスク、つまりソースディスクのアドレスがあります。移動ステップには、移動するバイト数も含まれます。プランは、運用中のDataNode に対して実行されます。

デフォルトでは、ディスクバランサー機能は Hadoop クラスターで有効になっています。hdfs-site.xml のdfs.disk.balancer.enabled パラメーター値を調整することで、 Hadoop でディスクバランサーを有効にするかどうかを選択します。

3.5 HDFSディスクバランサー関連コマンド

3.5.1 計画計画

コマンド: hdfs discbalancer -plan <データノード>

-out は、プランファイルの出力場所を制御します。
-bandwidth は、 Disk Balancer を実行するための最大帯域幅を設定します。デフォルトの帯域幅は 10 MB/秒です。
-thresholdPercentage は、ディスクがデータの再分散またはバランス操作に参加し始める値を定義します。デフォルトのthresholdPercentage 値は 10 %です。これは、ディスクに含まれるデータが理想的に格納されているデータの10 %以下である場合にのみ、ディスクがバランス操作に使用されることを意味します。
-maxerror を使用すると、ユーザーは 2 つのディスク間の移動操作で、移動ステップを中止する前に無視するエラーの数を指定できます。
-v Verbose モード。このオプションを指定すると、 plan コマンドでプランの概要が stdout に強制的に表示されます。
-fs このオプションは、使用する NameNode を指定します。指定しない場合、Disk Balancer は構成からのデフォルトのNameNodeを使用します。

3.5.2 _の実行

コマンド：hdfs discbalancer -execute <JSON ファイルパス>

実行コマンドは、プランが生成されたデータノードに対してプランを実行します。

3.5.3 クエリクエリ

コマンド: hdfs discbalancer -query <データノード>

クエリコマンドは、スケジュールを実行している DataNode から HDFS ディスクバランサーの現在の状態を取得します。

3.5.4 キャンセル _

命令：hdfs diskbalancer -cancel <JSON file path>

hdfs discbalancer -cancel planID ノード <ノード名>

cancel コマンドは実行計画をキャンセルします。

3.5.5 レポート _

コマンド: hdfs discbalancer -fs hdfs://nn_host:8020 -report

4.イレイジャーコーディング技術：Erasurecoding

4.1 背景: 3 コピー戦略の欠点

フォールトトレランスを提供するために、HDFS はレプリケーションファクター(レプリケーションファクター) に従ってファイルブロックを異なるデータノードに複製します。

デフォルトのレプリケーション係数は 3 です(ここでの3 は、追加の 3 ではなく、 1+2=3を指すことに注意してください)。そのため、元のブロックを除いて 2 つの追加コピーが存在します。各コピーはストレージオーバーヘッドの 100 % を使用するため、ストレージオーバーヘッドは200 % になります。これらのコピーは、ネットワーク帯域幅などの他のリソースも消費します。

レプリケーション係数が N の場合、 N-1 のフォールトトレランス機能がありますが、ストレージ効率は1/Nにすぎません。

4.2 イレイジャーコーディング( EC )の概要

イレイジャーコーディングテクノロジー ( 略してEC )は、コーディングエラー耐性のあるテクノロジーです。これは、通信業界とデータ伝送におけるデータ回復で最初に使用されました。データをブロックに分割し、各部分のデータが関連付けられるように検証データを計算します。データブロックの一部が失われた場合、残りのデータブロックとチェックブロックを通じて失われたデータブロックを計算することができます。

Hadoop 3.0 以降は、ストレージ使用率を50% 以上向上させ、データの信頼性を確保できる消去コーディング技術 (Erasurecoding ) が導入されました。

4.3 リードソロモン( RS ) コード

リードソロモン ( RS ) コードは一般的に使用される消去コードであり、 RS(k , m)として記録される 2 つのパラメーターk および mを持ちます。

k データブロックで構成されるベクトルに生成行列 (Generator Matrix ) GT を乗算して、 k データブロック ( d0,d1..d3 )と m チェックブロック ( c0,c1 )で構成されるコードワード ( codeword ) ベクトルを取得します。形状。

データブロックが失われた場合、 GT逆行列にコードワードベクトルを乗算することで、失われたデータブロックを回復できます。

例えば、元データは７、８、９の３つであり、行列乗算により２つの検証データ５０、１２２が算出される。

このとき、元のデータと検証データの合計 7 、8 、9 、50 、122 、 2 つの合計 5 つのデータが任意に失われますが、アルゴリズムによって復元できます。

4.4 Hadoop ECアーキテクチャ

イレイジャーコーディングをサポートするために、 HDFS アーキテクチャにはいくつかの変更と調整が加えられています。

ネームノードの拡張子

ストライプ HDFS ファイルは論理的にブロックグループ(ブロックグループ)で構成され、各ブロックグループには一定数の内部ブロックが含まれます。これにより、ブロックレベルではなくブロックグループレベルでのファイル管理が可能になります。

クライアント拡張機能

クライアントの読み取りパスと書き込みパスが強化され、ブロックグループ内の複数の内部ブロックを並行して処理できるようになりました。

データノード拡張

DataNodes は、失敗したイレイジャーコーディングブロックをバックグラウンドで回復するために、追加の ErasureCodingWorker ( ECWorker ) タスクを実行します。NameNode は障害が発生した EC ブロックを検出し、その後、 NameNode が回復作業を実行するDataNode を選択します。

イレージコーディング戦略

異種ワークロードに対応するために、 HDFS クラスター内のファイルとディレクトリには、異なるレプリケーションポリシーとイレイジャーコーディングポリシーを適用できます。イレイジャーコーディングポリシーは、ファイルのエンコード/デコード方法をカプセル化します。デフォルトでは、 RS-6-3-1024k ポリシーが有効になっており、RS はエンコーダアルゴリズムリードソロモンを表し、6と3はデータブロックとパリティブロックの数を表し、1024k はストライピングユニットのサイズを表します。

デフォルトの REPLICATION スキームはディレクトリでもサポートされます。これをディレクトリにのみ設定して、ディレクトリに 3 倍のレプリケーションスキームを強制的に適用し、その祖先の消去コーディングポリシーを継承させないようにすることができます。この戦略により、3xレプリケーションスキームのディレクトリをイレイジャーコード化されたディレクトリとインターリーブできるようになります。レプリケーションは常に有効です。

さらに、ユーザーは、 XML ファイルを使用して独自の EC ポリシーを定義することもできます。Hadoop conf ディレクトリには、 user_ec_policies.xml.template という名前のサンプル EC ポリシー XML ファイルがあり、ユーザーはこのファイルを参照できます。

インテルISA-L

Intel ISA-L は、 Intel Intelligent Storage Acceleration Libraryの略です。ISA-L は、ストレージアプリケーション向けに最適化された低レベル関数のオープンソースコレクションです。これには、 Intel AVX および AVX2 命令セット用に最適化された高速ブロックリードソロモンタイプの消去コードが含まれています。HDFS 消去コードは ISA-L を使用して、エンコードとデコードの計算を高速化できます。

4.5 イレイジャーコーディングの導入方法

4.5.1 クラスタとハードウェア構成

エンコードおよびデコード作業では、HDFSクライアントおよびDataNode上の追加のCPUが消費されます。

ラックのフォールトトレランスのために、消去符号化されたファイルもラック全体に分散されます。これは、ストライプファイルの読み取りと書き込みの際、ほとんどの操作がラック上で実行されることを意味します。したがって、ネットワーク帯域幅も非常に重要です。

ラックのフォールトトレランスを実現するには、十分な数のラックを用意し、各ラックにEC パリティブロックの数を超えるブロックを保持しないことも重要です。ラック数= (データブロック+パリティブロック) /四捨五入後のパリティブロック。

EC 戦略 RS ( 6,3 ) の場合、これは、計画的および計画外のダウンタイムに対処するために、最小 3 ラック (( 6+3 ) /3=3で計算)、理想的には 9 以上のラックを意味します。パリティユニットよりもラックの数が少ないクラスターの場合、HDFS はラックのフォールトトレランスを維持できませんが、ノードレベルのフォールトトレランスを維持するために複数のノードにストライプファイルを分散しようとします。したがって、同数の DataNode を使用してラックをセットアップすることをお勧めします。

4.5.2 イレイジャーコードポリシーの設定

イレイジャーコードポリシーはパラメータ dfs.namenode.ec.system.default.policy で指定され、デフォルトは RS-6-3-1024kで、他のポリシーはデフォルトで無効になっています。

ポリシーセットは、 hdfs ec [-enablePolicy -policy <policyName>] コマンドで有効にできます。

4.5.3 Intel ISA-L (インテリジェントストレージアクセラレーションライブラリ)を有効にする

デフォルトの RS コーデックのHDFS ネイティブ実装は、インテル ISA-L ライブラリを利用して、エンコードおよびデコードの計算を改善します。Intel ISA-L を有効にして使用するには、3 つの手順が必要です。

ISA-L ライブラリを構築します。
ISA-L サポートを使用して Hadoopを構築します。
-Dbundle.isalを使用して、 isal.lib ディレクトリの内容を最終的な tar ファイルにコピーします。tar ファイルを使用して Hadoopをデプロイします。ISA-L が HDFS クライアントと DataNode で利用可能であることを確認してください。

必要なソフトウェア:

ソフトウェア	バージョン
ハドゥープ	3.2.4
ワンエル	2.28.0
名前	2.14.02
ヤスム	1.2.0

4.5.3.1 yasm と nasm のインストール

# 在Hadoop集群所有节点上安装yasm和nasm。
yum install -y yasm
yum install -y nasm

# 注意：isa-l-2.28.0 对 nasm 和 yasm 有版本要求，低版本在安装时会报错。

4.5.3.2 isa-l-2.28.0 のコンパイルとインストール

# 在 Hadoop集群所有节点上编译安装 isa-l-2.28.0。
tar -zxvf isa-l-2.28.0.tar.gz
cd isa-l-2.28.0
./autogen.sh
./configure --prefix=/usr --libdir=/usr/lib64
make
make install
 
make -f Makefile.unx

# 检查 libisal.so* 是否成功
ll /lib64/libisal.so*
 
############如果有，则跳过##############
############如果没有有，则复制##############
cp bin/libisal.so bin/libisal.so.2 /lib64

4.5.3.3 Hadoop で isa-l が有効になっているかどうかを確認する

[root@hadoop01 ~]# hadoop checknative
Native library checking:
hadoop:  true /usr/hdp/3.0.0.0-1634/hadoop/lib/native/libhadoop.so.1.0.0
zlib:    true /lib64/libz.so.1
zstd  :  false
snappy:  true /usr/hdp/3.0.0.0-1634/hadoop/lib/native/libsnappy.so.1
lz4:     true revision:10301
bzip2:   true /lib64/libbz2.so.1
openssl: true /lib64/libcrypto.so
ISA-L:   true /lib64/libisal.so.2     ------------->  Shows that ISA-L is loaded.

4.5.4 EC コマンド

[root@hadoop01 ~]# hdfs ec
Usage: bin/hdfs ec [COMMAND]
          [-listPolicies]
          [-addPolicies -policyFile <file>]
          [-getPolicy -path <path>]
          [-removePolicy -policy <policy>]
          [-setPolicy -path <path> [-policy <policy>] [-replicate]]
          [-unsetPolicy -path <path>]
          [-listCodecs]
          [-enablePolicy -policy <policy>]
          [-disablePolicy -policy <policy>]
          [-verifyClusterSetup [-policy <policy>...<policy>]]
          [-help <command-name>]

[-setPolicy -path <パス> [-policy <ポリシー> ] [-replicate ]]

指定されたパスのディレクトリにイレイジャーコーディングポリシーを設定します。
パス: HDFS 内のディレクトリ。これは必須パラメータです。ポリシーの設定は、既存のファイルではなく、新しく作成されたファイルにのみ影響します。
policy : このディレクトリ下のファイルに使用するイレイジャーコーディングポリシー。デフォルトの RS-6-3-1024k ポリシー。
-replicate は、ディレクトリにデフォルトの REPLICATION スキームを適用し、ディレクトリに 3x レプリケーションスキームを強制的に適用します。replicateと -policy <policy> は オプションのパラメータです。同時に指定することはできません。

[-getPolicy -path <パス> ]

指定されたパスにあるファイルまたはディレクトリのイレイジャーコーディングポリシーの詳細を取得します。

[-unsetPolicy -path <path> ]ディレクトリ上の setPolicyへの前の呼び出しによって設定されたイレイジャーコーディングポリシーを 設定解除します 。ディレクトリが祖先ディレクトリからイレイジャーコーディングポリシーを継承している場合、unsetPolicy は 何も行われません。明示的なポリシーが設定されていないディレクトリでポリシーをキャンセルしても、エラーは返されません。

[-listPolicies] HDFS に登録されているすべてのイレイジャーコーディングポリシー (有効化、無効化、および削除)
を一覧表示します 。setPolicy コマンドでの使用 に適しているのは、有効なポリシーのみです。[-addPolicies -policyFile <file> ]ユーザー定義のイレイジャーコーディングポリシーのリストを追加します。[-listCodecs]システムでサポートされているイレイジャーコーディングコーデックとエンコーダーのリストを取得します。[-removePolicy -policy <ポリシー名> ]ユーザー定義のイレイジャーコーディングポリシーを削除します。[-enablePolicy -policy <ポリシー名> ]イレイジャーコーディングポリシーを有効にします。[-disablePolicy -policy <policyName> ]イレイジャーコーディングポリシーを無効にします。

Hadoop HDFS の高レベルの最適化スキーム

1.短絡ローカル読み取り:短絡ローカル読み取り

1.1 背景