- Amazon Elastic MapReduceの例で出てくるのは今まで見た限りでは、みんなs3n://で始まるS3 Native FileSystem上にファイルを置いている。
- http://wiki.apache.org/hadoop/AmazonS3 にあるように、もう一つ s3://で始まるS3 Block FileSystemというのがある。
- これまでS3fsって言ってたけどこれはs3-fuseと紛らわしいし、名前として正しくないのでS3 Block FileSystemと呼ぶべきでした。
- で、これを使いたい。
- メリットは、以下のように理解してる。
- ファイルがブロックに分割されるので、通常5GBまでというS3のファイルサイズの制限を超えられる
- ファイルがブロックに分割されるので、HDFSと同様Hadoopの各
jobtaskに処理を効率よく分散できる
- デメリットは、たぶんこんな感じ。
- bucket全体をS3 Block FileSystemに割り振らないといけない
- ファイルの管理をするクライアントがHadoopのCLI以外ない
- ほんで手前味噌ですがNet::Amazon::HadoopEC2::S3fsというのがあるんですよ。
- 手元でblocksizeを指定できるようにした。CPANにあがってるのにはついてないのでこのあと追加します。
- そんで以下のように指定して起動。
- ちゃんと動いたね。
- ということでS3 Block FileSystemでも動きました。
- パフォーマンスはどうなんでしょう。
- ブロックサイズをすごく小さくしたけど、これはちゃんと分割されたファイルが正しく処理されてるかをチェックするためで、2 ** 25がデフォルト。
- 以上のことから、機能面では十分使えそう、ということが分かった。
- Webインターフェイスがしょぼいのでチューニングのヒントが分かりづらい。
- これまで