現在、約 19 ギガバイトのログ データを扱っています。
入力ファイルの数が 145258 (pig stat) になるように、それらは大きく分離されています。
アプリケーションの実行から Web UI での mapreduce ジョブの開始までの間に、
準備に膨大な時間 (約 3 時間?) が費やされてから、mapreduce ジョブが開始されます。
また、mapreduce ジョブ自体 (Pig スクリプトによる) はかなり遅く、約 1 時間かかります。
mapreduce ロジックは、group by 操作のようにそれほど複雑ではありません。
3 つのデータノードと 1 つのネームノード、1 つのセカンダリネームノードがあります。
mapreduce のパフォーマンスを向上させるために構成を最適化するにはどうすればよいですか?
を試して、hadoop fs -ls /path/to/files | wc -l戻ってくるまでにかかる時間を調べてください。2 つの問題があります。
したがって、すでに提案されているように、ファイルをより適切なファイル サイズ (ブロック サイズに近いか、その倍数) に結合してみてください。おそらく、同じ時間のすべてのファイルを単一の連結ファイルに結合できます (または、処理のユースケースによっては、1 日まで)。
pig.maxCombinedSplitSize を適切なサイズに設定し、pig.splitCombination がデフォルトの true に設定されていることを確認してください。
データはどこにありますか? HDFSで？S3で？データが S3 にある場合は、データを一度大きなファイルにマージしてから、その上で豚のスクリプトを実行する必要があります。そうしないと、とにかく時間がかかります - S3 はページネーション付きのオブジェクト リストを返し、フェッチに時間がかかりますリスト (バケットにさらにオブジェクトがあり、プレフィックスのみのパターンでファイルを検索していない場合も、hadoop はすべてのオブジェクトをリストします (S3 には他のオプションがないため)。
問題は Pig よりも Hadoop にあるようです。すべての小さなファイルを Hadoop アーカイブに結合して、パフォーマンスが向上するかどうかを確認してみてください。詳細については、このリンク
を参照してください。別のアプローチとして、すべてのログ ファイルを 1 つの「大きな」ログ ファイルに定期的に UNION する個別の Pig ジョブを実行することもできます。これは、メイン ジョブの処理時間を短縮するのに役立ちます。