HBaseのHFile直読みとHDFSのReaderの速度比較

@m_mouri あい～。宜しくです～。

2010-08-23 00:36:05

@tatsuya6502 いずれにしろ、Hbaseの下位がHDFSだとして、それをHDFSとしてアクセスするとき（例えば、SeqFileのインターフェイス）に、物理的にどうやっているのかがわかればいいかと思いますです。#HBase #hadoopreading

2010-08-23 00:39:13

ぶっちゃけHBaseの物理構成は不勉強で、よくわからん・・・あとで調べよ。

2010-08-23 00:40:46

.@okachimachiorz @m_mouri コメントありがとうございます。HDFSでは、データの読み書きのためにFSDataInputStreamと同OutputStreamが用意されていて、その上にいくつかのファイル形式が構築されています #hadoopreading

2010-08-23 07:48:17

.@okachimachiorz ファイル形式には、SequenceFileの他に、MapFileなどのバリエーションがありますが、HBaseのHFileもそのバリエーションのひとつです。 #hadoopreading

2010-08-23 07:50:26

.@okachimachiorz ファイル形式ごとにReaderクラスがあって、HFile.ReaderはSequenceFile.Readerとは無関係の独自実装です。どのReaderもFSDataInputStreamを使ってreadします。 #hadoopreading

2010-08-23 07:56:32

.@okachimachiorz テストデータですが、データ長8,000のケースでは、SeqFileは１つのファイルに20万件全て書き込んであって、1,538.09 MB。V2は９ファイルに分かれていて、合計1,636.33 MBでした。 #hadoopreading

2010-08-23 08:00:10

.@okachimachiorz １レコードの内容は、20バイトのkeyと、8,009バイトのvalue（800バイトのランダムなASCII文字列 x 10 ＋フィールド区切としてtab記号9個）となっています。 #hadoopreading

2010-08-23 08:04:35

.@okachimachiorz このケースでは、SeqFile.Readerの方がHFile.Readerより遅くなります。 #hadoopreading

2010-08-23 08:09:52

.@okachimachiorz データ長 500のケースでは、SeqFileは１ファイル20万件で70.06 MB。V2は２ファイルで合計163.65 MB。このケースだと、ファイルサイズの小さい SeqFileの方が速くなりました。 #hadoopreading

2010-08-23 08:11:10

.@okachimachiorz いま注目しているのは、FSDataInputStreamから１回にreadするデータ量の違いです。HFileはブロック単位のreadで、SeqFileは圧縮なしだと、レコード単位で細かくreadするようです。 #hadoopreading

2010-08-23 08:15:31

.@okachimachiorz SequenceFile.Readerも、ブロック圧縮をオンにすれば、ブロック単位でreadするようになるので、性能が上がる可能性があります。つぎはこれを試してみたいと思っています。 #hadoopreading

2010-08-23 08:17:27

@tatsuya6502 @okachimachiorz 今、SeqFileのスループットを手元で計測してみましたが、遅いです。 Block圧縮なし40Mbyte/sec Block圧縮あり、codec gzip 11Mbytes/sec 分散させているので一台当たりの速度

2010-08-23 10:49:53

@tatsuya6502 @okachimachiorz dbenchでスループットを計測したところ19.48Mと言われた。bonnie++だとBlockInputで235Mが出ました。

2010-08-23 11:38:46

@tatsuya6502 @okachimachiorz HDFSのSeqFileは自分が思っていたよりも、かなり遅いようです。設定でもっと速くならないかしら。

2010-08-23 11:42:10

@tatsuya6502 すんません、テストケースでの、データのサイズが200MB以下って感じですか？ #hadoopreading

2010-08-23 14:12:39

.@okachimachiorz ここに書かれているテストデータ構成の最初の８つについて、20万レコードずつ作成しました。いちばん小さなSequenceFileは70MB、大きなものは1,538MBでした。 http://ow.ly/1qNVOA #hadoopreading

2010-08-23 14:47:35

.@okachimachiorz ファイルサイズが大きくなるほど SequenceFile.Reader の遅さが目立ちました。 #hadoopreading

2010-08-23 14:49:24

@m_mouri そうですか。前にブロック圧縮をオンにして速くなったときは、どのコーデックをつかいましたか？ LZO？

2010-08-23 14:51:07

これだけ小さいとDisk cacheに収まるのでI/Oがボトルネックにはならなそうなのですが... QT @tatsuya6502: .@okachimachiorz いちばん小さなSequenceFileは70MB、大きなものは1,538MBでした。

2010-08-23 14:51:57

@tatsuya6502 default codecのgzipです。RowCountは速くなりましたが、Disk I/Oのスループットが速くなったかは計測してません。

2010-08-23 14:53:40

@tatsuya6502 対象ファイルサイズが大きくなるとスループットが速くなりそうなので、Block圧縮をやめて計測しようとしています。

2010-08-23 14:55:19

@m_mouri @tatsuya6502　えっととりあえず確認しましたけど、HDFS的にはN/Wネックの100Mまでは出せますが、通常の処理だとCPUネックで50M以下が多いのが現状ですね。まーYahooのベンチが妥当でしょう。http://yhoo.it/cSTNlG 続）

2010-08-23 15:17:43

@m_mouri @tatsuya6502　AWSのディスク性能とかによるんですけど、普通に遅いので、むしろHDFSの数値は健闘しているか、またはCPUネックになってると思います。メトリクスとらんとわかりません。んで、むしろHBaseの数字が結構出ている感があって、(続

2010-08-23 15:22:03