私のユースケースでの CustomWritable の必要性に関して、さらに設計上の質問があります。
したがって、パイプラインを介して処理し、中間データと最終データを HDFS に書き出すドキュメント ペアがあります。私のキーは、ObjectId - DocId - Pair - Lang のようなものになります。このユースケースで CustomWritable が必要な理由/場合がわかりません。キーがなかったら、CustomWritable が必要になると思いますか? また、Reducer で HDFS にデータを書き出すときは、Custom Partitioner を使用します。それで、それはカスタム書き込み可能の必要性を排除しますか?
Custom Writable 権限が必要であるという概念を理解できたかどうかはわかりません。誰かが私を正しい方向に向けることができますか?
書き込み可能オブジェクトは、オブジェクトのデシリアライズに使用できます。たとえば、ログ エントリには、タイムスタンプ、ユーザー IP、およびブラウザー エージェントを含めることができます。したがって、このエントリを識別するキーに対して独自の WritableComparable を実装し、ログ エントリの属性を読み書きする Writable を実装する値クラスを実装する必要があります。
これらのシリアル化は、データをバイナリ形式からオブジェクトに取得する便利な方法です。HBase などの一部のフレームワークでは、データを永続化するためにバイト配列が必要です。そのため、これを自分で転送すると多くのオーバーヘッドが発生し、コードが台無しになります。
トーマスの答えは少し説明します。遅すぎますが、将来の読者のために次のことを追加したいと思います。
パーティショナーは、map フェーズと reduce フェーズの間でのみ機能し、reducer から出力ファイルへの書き込みには何の役割も果たしません。
ほとんどの場合、中間データを hdfs に書き込む必要はないと思いますが、同じことを行うために適用できるハックがいくつかあります。
レデューサーから hdfs に書き込む場合、キーは自動的にソートされ、各レデューサーは 1 つの個別のファイルに書き込みます。メソッドに基づいてcompareTo、キーがソートされます。したがって、複数の変数に基づいてソートする場合は、 を拡張するカスタム キー クラスを選択し、およびメソッドWritableComparableを実装します。実装に基づいて、キーのソート方法を制御できるようになりましたwritereadFieldscompareTocompareTo