HadoopOperationsのメモ10

※以下はHadoopOperationsを読んで自分なりに理解をしたことをかいていますので、 誤りを含んでいることがあります。もちろん、意図することではありません。。。。 本文内の英文はHadoopOperationsの抜粋です。 ●第4章 Namenode consideration この付近では、NameNodeやSecondaryNameNodeなど各ノードのハードウェアスペックはどの程度が良いのか、という内容が説明されている。 NameNodeのスペックはやはり搭載メモリのサイズがポイントだ。 管理するファイルのサイズというより、ファイルの数によってサイズを見積もる必要があるのは、 よく知られたことだと思う。

Remember that the metadata contains the filename, permissions, owner and group data,
list of blocks that make up each file, and current known location of each replica of 
each block

このあとに、ファイル名が長いほど、よりメモリが必要になるという記述も。 こんなに細かい管理をしているようだ。 おおまかには、100万ブロックの管理には1GBのメモリが必要、という計算になるらしい。 と言われても、一体どれだけなんだ？と思ってしまうが。。 どこかで読んだ、1ファイルあたり100バイトや150バイトくらいになるのだろうか。 他にも書きたいことはあるのだが、 あまり書くのも気が引けるので気になった点のみとした。（今更だが）

commonsのdigesterを使用してXMLロード

今更感は否めないが、Javaのapache commons-digesterを使用して、
XMLファイルの読み込みを作成してみた。（バージョンは1.8）

XMLを読み込むには読込ルールが必要で、
それをコーディングもしくは外部ファイル(XML)で定義することになる。

やはり、外部ファイルだろうということで、そちらを選択した。

書き方はいくつかのサイトで紹介されている。
例えば、、、
http://www.syboos.jp/java/doc/xml-to-java-object-by-digester.html
http://www.h7.dion.ne.jp/~s_wat/jakarta/digester.html

ということで、少し詰まったところを以下に残すことにする。

・特定のタグが来たら、タグのテキスト(Body)を引数にして指定のメソッドを呼ぶ

ここでは、"tag/item/value"という構成のタグが出たら、
"addItemValue"というメソッドを実行するようにしている。
詰まったのは、paramcountのところだ。
このattributeを付けないと、引数無しのメソッドが呼ばれてしまう。
paramcountだから引数の数かと思って1とすると、それも外れ。(確か、タグのattributeの1つめを引数にしようとする、、だったような)
正解の0を指定すると、タグのテキストを引数としてくれる。
なんだか直感的には分かりにくい。

・ルールファイルと対象のXMLファイルを読み込む

FileInputStream ruleIn= new FileInputStream(rulePath);
Digester digester = DigesterLoader.createDigester(new InputSource(ruleIn));

FileInputStream queryIn = new FileInputStream(queryPath);
Utsuwa info = (Utsuwa) digester.parse(queryIn);

いくつかのサイトで書かれていたDigesterオブジェクトを作る方法がdeprecatedになっていた。
"createDigester(new File("sampleRule.xml").toURL())"の"toURL()"が。
なんてことはないが、代わりに上のようにすれば動く。


なんといってもメリットは、XML読み込みがルールファイルのみで柔軟に変更できることだろう。
構造が多少変わっても、ルールを変えるだけで済む。

以上とします。

FileのlistFilesを敢えて試した結果

Javaで、あるディレクトリ直下にあるディレクトリ・ファイルの一覧を取得したい。

その時よく使われるのは、FileクラスのlistFilesだ。

listFilesには引数無しメソッドに加えて、オーバーロードが２つあって、
それぞれFileFilterとFilenameFilterを引数にとる。

もう既に様々なサイトで使用方法は示されているけれど、
敢えて全パターンを書いてみて、一番”格好良い”のはどれか見てみた。

条件としては以下だ。
・そのディレクトリには、ディレクトリとファイルが存在しているが、必要なのはファイルのみ。
・ファイルといってもjarファイルのみが欲しい。（拡張子が.jarで判断）
・メソッドの戻りはListで欲しい。nullになっちゃう配列は嫌！

そして、こんな感じのソースを書いた。(全力で)

public class ForTest {

  private static final String PATH = "U:\\test";
  private static final String TARGET_EXTENTION = "jar";

  public static void main(String args[]){
  
    for (int i =0 ; i<1000; i++){
       filterPatternA();
      filterPatternB();
      filterPatternC();
    }
  }
  
  private static void filterPatternA(){
    File[] farr = new File(PATH).listFiles();
    List flist = new ArrayList(farr.length);
    for (File file : farr){
      if (file.isFile() && file.getName().endsWith(TARGET_EXTENTION)){
        flist.add(file);
      }
    }
  }
  
  private static void filterPatternB(){
    File[] farr = new File(PATH).listFiles(new FileFilter() {
      @Override
      public boolean accept(File f) {
        return f.isFile() && f.getName().endsWith(TARGET_EXTENTION);
      }
    });
    List flist = Arrays.asList(farr);
  }
  
  private static void filterPatternC(){
    File[] farr = new File(PATH).listFiles(new FilenameFilter() {

      @Override
      public boolean accept(File dir, String name) {
        if (!new File(dir.getAbsolutePath() + "\\" + name).isFile()) return false;
        return name.endsWith(TARGET_EXTENTION);
      }
      
    });
    List flist = Arrays.asList(farr);
  }

}

そして、約３４００ファイルあるディレクトリ(U:\test)で実行。
ついでに実行時間も計測（まぁいろんなサイトで速度は変わらん！と言っているが）。
１０００回ループさせた。

平均値をとると、A：115.29ミリ秒、B:117.168ミリ秒、C:120.384ミリ秒。
誤差もいいとこ。
やるだけ無駄。速度に優劣無しと判断する。


ところで、本題はどれが一番格好良いか。
Cはあまり好きじゃないなぁ。
FilenameFilterでファイルかどうかを判断するのはスマートじゃないね、きっと。

AかBか、ぱっと見で分かりやすいのはAではないだろうか。
一覧とって判断してるのね、と直感的に分かる。

だけど、やっぱり格好良いのは、Bに決定する（謎
If文無いし。(厳密には書き方なだけだが。。。)

いやいや、AのIf文のところをリファクタリングして、
分かりやすいメソッド名を付けるのが一番格好良いでしょ！という意見もありそう。。。

そういや、該当ファイル無しのときにnullで落ちるのは愛嬌で。。。
勢いで、null判断を入れるの忘れた。

そんじゃ、甲乙つけがたしで（笑