このような機会があり、この構成の4つのノードのクラスターで、テストすることにしました。
-3ノード：Intel Xeon CPU W3530 @ 2.80GHz 12GB RAM
-1ノード：Intel Xeon CPU X5450 @ 3.00GHz。 8GB RAM
OS debian、hadoop 1.2（off.siteから）、java 7（ORACLEから）。
ソースデータ：
-CMLファイル： dumps.wikimedia.org/enwiki/20130904/enwiki-20130904-stub-meta-current.xml.gz
-解凍すると、ファイルは18GBのスペースを占有します。
-3,100万のWikiページ。
-Bzip2はこのファイルを2GBに圧縮します
-ファイル内の593.045.627行
1つのエントリの例：
<page> <title>AfghanistanHistory</title> <ns>0</ns> <id>13</id> <redirect title="History of Afghanistan" /> <revision> <id>74466652</id> <parentid>15898948</parentid> <timestamp>2006-09-08T04:15:52Z</timestamp> <contributor> <username>Rory096</username> <id>750223</id> </contributor> <comment>cat rd</comment> <text id="74089594" bytes="57" /> <sha1>d4tdz2eojqzamnuockahzcbrgd1t9oi</sha1> <model>wikitext</model> <format>text/x-wiki</format> </revision> </page>
テストとして、従来のツールを使用するか、MapReduceを使用してコンソールで解決できる単純な問題を取り上げました。 簡単に言えば、タスクは次の形式で表されます。
time bunzip2 -c /mnt/hadoop/data_hadoop/test.xml.bz2 | grep "<title>" |wc 31127663 84114856 1382659030 real 9m32.953s user 10m16.779s sys 0m12.737s
同様の問題は、3分40秒でhadoopクラスター全体で解決されました。 （はい、並列展開では、展開はネイティブではなくJavaで行われました）。
ファイルがアンパック状態（18GB）であった場合、処理は2分と30秒でhadoopクラスターで終了しました。 （2分12秒で最速）。 この場合、ディスクは100％でロードされます
まあ、それについて考えるために））ファイルは以前にpbzip2によって挟まれていました... Intel Xeon CPU W3530 @ 2.80GHz
time pbzip2 -d -c -p8 /mnt/hadoop/data_hadoop/testpbzip.xml.bz2 | grep "<title>" |wc 31127663 84114856 1382659030 real 2m44.507s user 21m28.493s sys 0m19.833s
結論を出すつもりはありません...しかし、インターネット上のどこかで、hadoopクラスターが4つのノードから自身を表示し始めたことに出会いました...おそらく理由がありました。