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

M.Mouri @m_mouri

@tatsuya6502 そうか、圧縮してもサイズが減らないようなランダムなデータを用意して試せば分かりますね。

M.Mouri @m_mouri

@tatsuya6502 もちろん、NONE codecを用意するのが正攻法だと思います。ランダムデータは手抜きの方法ですw

Tatsuya Kawano @tatsuya6502

. @m_mouri さんから、Noneコーデック（何もしない圧縮コーデック）を作って、SequenceFile.Writer/Readerに使わたら、非圧縮のままブロックreadできるのでは、というアイデアをいただきました。ぜひ試したいですね。 #hadoopreading

M.Mouri @m_mouri

@tatsuya6502 CompressionCodecのAPI Docsを見てみたのですが、None codecの実装は簡単そうです。return in;とreturn out;と書けば済みそう。http://bit.ly/cqSMwx

Tatsuya Kawano @tatsuya6502

@m_mouri None codec の実装は簡単そうですか。では、週末にやってみますね。

Tatsuya Kawano @tatsuya6502

SequenceFile.Reader の性能改善として FSDataInputStream のバッファサイズを大きくしましたが、小さいレコードでは大きな効果があるものの、大きなレコードでは10%くらいしか性能が改善されませんでした。 #hadoopreading

Tatsuya Kawano @tatsuya6502

明日以降は Noneコーデック（何もしない圧縮コーデック）を作って block read を有効にする策を試します。 #hadoopreading

Tatsuya Kawano @tatsuya6502

#HBase HFile直読みプログラムのソースコードを公開しました。コードを読みたい方は、READMEのSource Tourから始めてください。 http://ow.ly/2sVoI #hadoopreading

Tatsuya Kawano @tatsuya6502

#HBase HFile 直読みプログラムの最新（8月21日）の測定結果はこちら: http://ow.ly/2sVpj 　HDFS SequenceFile.Readerのバッファサイズを増やしましたがあまり性能が改善されませんでした。 #hadoopreading

M.Mouri @m_mouri

@tatsuya6502 うーん、遅いですね。もっと速くなりそうなものですが。次はBLOCK圧縮を試すのですか？しまった、SequenceFileを読み出してBLOCK圧縮してコピーするソースは会社のPCにしか入ってない。そんなに難しくないですが。

Tatsuya Kawano @tatsuya6502

@m_mouri はい、次はBLOCK圧縮ですが、１回のテストに３時間ほどかかるので、次の週末までお預けかも。先に HBase への組み込みの話を進めてます。

M.Mouri @m_mouri

@tatsuya6502 3時間か。それは時間がかかりますね。そうですね、3倍速くなるなら組み込みの方が優先順位は高いですね。

Tatsuya Kawano @tatsuya6502

ソースにはHDFS SeqFileの性能テストも含まれてます。遅い原因についての突っ込みとヘルプ歓迎します！RT: #HBase HFile直読みのソースコード。READMEのSource Tourから始めて http://ow.ly/2sVoI #hadoopreading

M.Mouri @m_mouri

@tatsuya6502 さんが忙しそうなので、代わりといってはなんですが、SeqFileをBlock圧縮してコピーするコードとNoneコーディックを書いてみようかと思っているのですが、書いたらtatsuyaさんの方でベンチマークを取ってもらえますか？

Tatsuya Kawano @tatsuya6502

@m_mouri そうしていただけると助かります。もちろん、ベンチマークはこちらでとります。QT: SeqFileをBlock圧縮してコピーするコードとNoneコーディックを書いてみようかと思っているのですが、書いたらtatsuyaさんの方でベンチマークを取ってもらえますか？

御徒町@Serializable @okachimachiorz

@tatsuya6502 う～。これ対象データって1Gで20万件程度かな？100倍ぐらいのもの＋最低でも5ノード程度でやらないと、HDFS的にはちょっと。もともと細切れのデータですよね？それでも50M近くでているんで、HDFS的にはそんなもんかと。通常だと普通に100Mでます。

M.Mouri @m_mouri

@okachimachiorz @tatsuya6502 細切れのデータでスループットが出ないとすると、ボトルネックはCPUになると思うのですが、使っているのが4CoreのCPUなのでちょっと僕には考えにくいです。topでcpu,sys,idle,waitを見るとなにか分かるかも

御徒町@Serializable @okachimachiorz

sarとかでいんじゃね。えっと、単純にIOボトルネックじゃないかね？細切れだとIOが結構発生するって話。 @m_mouri @tatsuya6502 細切れのデータでスループットが出ないとすると、・・topでcpu,sys,idle,waitを見るとなにか分かるかも

M.Mouri @m_mouri

@okachimachiorz ファイルが細切れだとIOがボトルネックだと思いますが、SeqFileはファイル自体は細切れではありません。データが細切れでもファイルはHDFSのブロックサイズを超えた大きなものになります。

御徒町@Serializable @okachimachiorz

@m_mouri あぁ、気になっているのは、このテスト用のSeqFileってのがどんな感じなのかな、と思って。HBaseの方がよくわからんであれだけど。普通のSeqFileなのかね？だとすれば上位のボトルネックだけど。HBaseと比較で有る以上同じデータじゃないと意味ないでほ。

御徒町@Serializable @okachimachiorz

@m_mouri さんの方のHDFSでのスループットってどんなものかね？こっちは、（もちろん処理にもよるけど）100Mは大抵出てるし、想定してる感じだけど・・その感覚で50Mっていうと、「あー半分だわね。なんかチガウ」ってのが第一印象です。

M.Mouri @m_mouri

@okachimachiorz なるほど、SeqFileが細切れの可能性もあると。でも、HDFSのブロックサイズが64Mbyteなのでそこに細切れのSeqFileを詰め込むととんでもなくディスクスペースを食ってしまいますね。HFileは複数のデータをまとめた構造なので、

M.Mouri @m_mouri

@okachimachiorz ひょっとしたら、SeqFileも細切れの可能性がありますね。

御徒町@Serializable @okachimachiorz

@m_mouri うん。その可能性あるかな～、と思って。HBaseでアクセスするなんか途中で、なんかゴニャゴニャやっちまって、SeqFileの「皮かぶせて」読み込んでないかなとおもったりして。

M.Mouri @m_mouri

@okachimachiorz HDFSのスループットはちゃんと計ったことはないですが、Block圧縮を入れた状態で今計算してみると、34Mとでました。あれ？遅すぎる。明日RowCountを走らせて調べてみます。