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

御徒町@Serializable @okachimachiorz

@m_mouri @tatsuya6502　とはいえ、HDFSのパフォーマンスをどう維持するかは、それなりにやり方がある（らしい）ので、それはそれでちょっと（そのうち）やってみる、って感じです。

M.Mouri @m_mouri

@okachimachiorz AWSのベンチマークはこちらにあります。http://bit.ly/98jez7 これによると、m1.xlargeで197.14MByte/secぐらいだそうですが、手元のPCでdbenchを使うとやたらと遅いです。

M.Mouri @m_mouri

@okachimachiorz @tatsuya6502 よく見るとhdparamによるEBSの結果は60MByte/secなので、tatsuyaさんの結果に一致しますね。HFileがこの値より速い理由は不明ですが。

豊月 @yutuki_r

@m_mouri Hadoopが使っているファイル、InstanceにアタッチしたEBSVol上に置いていますか？Instanceに最初からついてきたDisk領域と、あとからアタッチしたEBSVol上のDisk領域だとIO速度が違うはず。このBenchは最初からついてる方では

M.Mouri @m_mouri

@yutuki_r あっ、自分は手元のPCです。AWSは実は使ったことがありません(苦笑)

Tatsuya Kawano @tatsuya6502

.@m_mouri ちなみに僕が使ってるのは、エフェメラルディスク /dev/sdb なので、EBSより速くなるようです。先ほどご紹介のページですと、hdparmで 170.98 MB/sec になってます。

Tatsuya Kawano @tatsuya6502

@okachimachiorz @m_mouri んー、テストプログラムを見るとわかるのですが、ディスクキャッシュの影響については、SequenceFileのほうが圧倒的に有利にな実行順になっています。まあ、念のため次回はもっと大きいデータ（30GBくらい？）も試してみますね

Tatsuya Kawano @tatsuya6502

HFile直読み、大きなファイルで再テストしました。 @okachimachiorz さんのご指摘通り、土曜日の小さなファイルでのテストは不公平なことがわかりました。HFile.Reader「だけ」にディスクキャッシュの効果がでていたようです。 #hadoopreading

Tatsuya Kawano @tatsuya6502

今回の結果、SequenceFile.Reader：１ファイル 37.6GB、スループット 45.31MB/sec。HFile.Reader：215ファイル 合計39.9GB、42.62MB/sec。SeqFileはブロック圧縮無効のままです。 #hadoopreading

Tatsuya Kawano @tatsuya6502

お薦めのsar -bとtopでリソース使用率を監視したところ、重要なことがわかりました。SeqFile.Readerの性能はCPUがボトルネックで、HFile.Readerはディスクreadがボトルネックです（CPU使用率90% vs. 35%） #hadoopreading

Tatsuya Kawano @tatsuya6502

つまり、HFileはディスクのread性能が上がれば、CPUがボトルネックになるいまの２〜３倍の速度が出ます。だから、小さいファイルでテストしたときに、HFileだけディスクキャッシュの効果があって、SeqFileには効果がなかったのだと思います。 #hadoopreading

Tatsuya Kawano @tatsuya6502

あと、sar -bによると、どちらのReaderの実行時も、ディスクからは約90MB/secでreadしているようです。なぜ、２倍の速度でreadしているんでしょうか？ 読み込んだ半分はどこへ消えてしまうのでしょう？。 #hadoopreading

Tatsuya Kawano @tatsuya6502

次は、ディスクドライブを増やして、HFile.Readerの性能が上がるか調べたり、SeqFile.Readerのブロック圧縮を有効にしてボトルネックがCPUからディスクreadに変わるか調べたいです。 HBaseへの組み込みも進めないと。 #hadoopreading

Tatsuya Kawano @tatsuya6502

ん？ でも整理し直すと、こういうことか。SequenceFile.Readerは HFile.Readerと同じ仕事をするのに2.5倍のCPUリソースが必要。これがSeqFileの遅さの理由。ブロック圧縮を有効にすれば改善できるかもしれない。 #hadoopreading

M.Mouri @m_mouri

@tatsuya6502 Noneコーディックとかは、できれば今日中に送ります。あと、今日は会社のPCで圧縮なしのベンチを軽く取るつもりです。それにしても、SeqFileのデシリアライズはCPU負荷が高いようですね。データが小さいとスループットが落ちますし。

Tatsuya Kawano @tatsuya6502

@m_mouri Noneコーデックの件、ありがとうございます。僕も今夜テストできるかどうかはわからないので、無理しないでくださいね。

Tatsuya Kawano @tatsuya6502

@m_mouri SeqFileのデシリアライズが非効率な件は、他にも気になる部分があります。バイト列を取り出すために、内部で、java.io.ByteArrayOutputStreamのサブクラスをいくつも使用してるんですよね。

Tatsuya Kawano @tatsuya6502

@m_mouri 一方、HFileの方は java.nio.buffer.ByteBufferひとつで同じことを実現してます。この辺も、効率の良し悪しに関わってそうです。

Tatsuya Kawano @tatsuya6502

SeqFileで、この数字（CPUネックで50M以下）を裏付ける結果がでました。QT @okachimachiorz: @m_mouri @tatsuya6502　HDFS的にはN/Wネックの100Mまでは出せますが、通常の処理だとCPUネックで50M以下が多いのが現状ですね

Tatsuya Kawano @tatsuya6502

.@okachimachiorz @m_mouri ただ、HFileの結果を見ると、SeqFileの実装に、なにか非効率な部分があるみたいです。それを改良できると、100MB/secに近づくことができそうです。

Tatsuya Kawano @tatsuya6502

.@okachimachiorz 「結果」について、詳しくは #hadoopreading タグで書きました。

御徒町@Serializable @okachimachiorz

@tatsuya6502　お疲れ様です。了解です。後で見ますです～ #hadoopreading

M.Mouri @m_mouri

@tatsuya6502 手元のPCでRowCountを走らせてみたのですが、Block圧縮なしの場合、CPUは40～50%ですがスループットは46MByte/sec,hdparamやbonnieでは190MByte/secというボトルネックが不明な結果がでました。うーん。

M.Mouri @m_mouri

@tatsuya6502 Block圧縮ON(gzip)の場合はCPUが60%程度で、スループットが34MByte/secでした。複数台のslave構成なのでネットワーク転送が発生した可能性もありますが、よく分かりません。

Tatsuya Kawano @tatsuya6502

@m_mouri ディスクがボトルネックみたいですね。僕の環境も、rx7のブログでは hdparmで 170.98 MB/sec になってましたが、HDFSは45MB/s程度でしたから。小さいファイルで２回実行して、２回目が速くなったらディスクと考えていいと思います。