Hadoop の全順序パーティショナーとランダム サンプラーを入力サンプラーとして使用します。
しかし、スレーブ ノードを増やしてタスクを 8 に減らすと、次のエラーが発生します。
Caused by: java.io.IOException: Split points are out of order
このエラーの理由はわかりません。
関数の 3 つのパラメーターの数を設定するにはどうすればよいinputsampler.randomsampler
ですか?
Hadoop の全順序パーティショナーとランダム サンプラーを入力サンプラーとして使用します。
しかし、スレーブ ノードを増やしてタスクを 8 に減らすと、次のエラーが発生します。
Caused by: java.io.IOException: Split points are out of order
このエラーの理由はわかりません。
関数の 3 つのパラメーターの数を設定するにはどうすればよいinputsampler.randomsampler
ですか?
考えられる 2 つの問題
これは、パーティション ファイルをダウンロードしてその内容を調べることで診断できます。パーティションファイルは、total.order.partitioner.path
設定されているかどうかの値です_partition.lst
。キーがテキストの場合は、実行hdfs dfs -text path_to_partition_file | less
して確認できます。これは他のキー タイプでも機能する可能性がありますが、試したことはありません。
パーティション ファイルに重複する行がある場合は、キーが重複しています。それ以外の場合は、間違ったコンパレータを使用している可能性があります。
私の最善の推測は、キーが非常に不均衡であるため、パーティション間でレコードを均等に分割すると、同じ分割ポイントを持つパーティションが生成されることです。
これを解決するには、いくつかのオプションがあります。
a
、パーティションキーファイルa
に、、、、、、、、b
c
c
c
d
e
分割ポイントとして、9 つのレデューサー (8 つの分割ポイント) と 3 の最大複製があります。したがって、3 つのレデューサー (3=floor(9/3)) を使用し、サンプリングが良好であれば、おそらく適切な分割になるでしょう。ポイント。完全な安定性を得るには、エントリが重複している場合にパーティション手順を再実行できるようにする必要があります。これにより、不均衡なキーの時折のオーバーサンプリングを防ぐことができますが、そのレベルの複雑さでは、調べることもできます次の解決策。num_non_duplicates
)、num_non_duplicates+1
リデューサーを使用します。重複したキーを持つレデューサーは、他のレデューサーよりもはるかに多くの作業を行い、実行時間が長くなります。reduce 操作が交換可能かつ結合的である場合、コンバイナーを使用することでこれを軽減できる場合があります。を使用して呼び出しとジョブのmapred.output.key.comparator.class
両方で同じように設定していることを確認してくださいwritePartitionFile
TotalOrderPartitioner
Split points are out of order
エラーメッセージはコードから来ています:
RawComparator<K> comparator =
(RawComparator<K>) job.getOutputKeyComparator();
for (int i = 0; i < splitPoints.length - 1; ++i) {
if (comparator.compare(splitPoints[i], splitPoints[i+1]) >= 0) {
throw new IOException("Split points are out of order");
}
}
この線comparator.compare(splitPoints[i], splitPoints[i+1]) >= 0
は、分割点のペアが同一または順不同である場合に拒否されることを意味します。
分割ポイントは 1 つしかなく、ループは実行されないため、1 つまたは 2 つのレデューサーでこのエラーが発生することはありません。
十分なキーを生成していますか? javadoc から: TotalOrderPartitioner
入力ファイルは、同じコンパレーターでソートされ、以下を含む必要があります
JobContextImpl.getNumReduceTasks() - 1 keys.