なぜMapReduceでToolRunnerを使うのか

つい先日、気になったこと。

というのも、自分がMapReduceジョブを実装するときは、
直接Jobを実装するので事足りており、
ToolRunnerを使ったことがなかったから。

ということで、CDH3u3のソースコードを調べてみた。

org.apache.hadoop.util.ToolRunner

  public static int run(Tool tool, String[] args) 
    throws Exception{
    return run(tool.getConf(), tool, args);
  }

  public static int run(Configuration conf, Tool tool, String[] args) 
    throws Exception{
    if(conf == null) {
      conf = new Configuration();
    }
    GenericOptionsParser parser = new GenericOptionsParser(conf, args);
    //set the configuration back, so that Tool can configure itself
    tool.setConf(conf);
    
    //get the args w/o generic hadoop args
    String[] toolArgs = parser.getRemainingArgs();
    return tool.run(toolArgs);
  }

どうやら、ToolRunnerは
GenericOptionsParserを仕掛けてくれるだけらしい。

細かいこというと、
引数読み込んだ後のConfigurationの設定もしているが。

ToolRunnerを使用しない場合は、
GenericOptionsParserによるパースを自分で呼び出したうえで、
Jobオブジェクトを生成する必要がある。

これだけ聞くとToolRunner使う方が便利そうだが、
ToolRunnerを使う場合、
MapReduceジョブはToolインタフェースを実装する必要がある。

このToolインタフェースを実装するには、
ジョブを実行するrun()メソッド以外にも、
Toolインタフェースの親であるConfigurableのメソッド（getConfとsetConf）
も併せて実装する必要がある。
大したことではないが、手間はかかる。

結局のところ、どちらを使うべき、というものはないと思うが、
個人的には、ToolRunnerは使わず、
GenericOptionsParserを自前で呼び出す方が好み。

というのも、ToolRunnerを使う場合
誰も使用しないConfigurableのメソッド（getConfとsetConf）
を実装する必要があり、
個人的に、使わないメソッドを実装するのはイヤだから。

もちろん、ToolRunnerを使わない場合も注意点はある。

GenericOptionsParserにより、
引数の情報を読み込んだConfigurationオブジェクトを使って、
Jobを生成するようにする必要がある。

どっちのやり方でするにしても、面倒さは変わらない。。。