Hadoop Conference Japan 2014にいってきた

Hadoop Conference Japan 2014 Tickets, Tue, Jul 8, 2014 at 10:00 AM | Eventbrite

第５回になるそうです。僕は3回目から参加していますが、毎度のことながらランチが出るし至れり尽くせりのカンファレンスですね。スタッフの皆様ありがとうございます。m( )m

全体的な印象をいうと事例の話が減ってYARNとかSparkの話が増えたのかなと。

僕はYARNとPrestoが気になっていたのでその辺が聞けるセッションを中心にまわっていました。

YARNの設定をどうすればいいのかって話がありましたが、僕は全然わかってなくてAmbari任せですね。ただAmbariを使うとどうしてもブラックボックスになるし、いざ障害が起きたときに何をすればいいのか調査しづらい面はあると思います。初期セットアップなんかはAmbariを使った方が明らかに楽ですが、この辺のトレードオフはあると思います。あと細かいセッティング（例えばAmbari経由でNagiosを使う場合の注意点 - wyukawa’s blogで書いたyarn.nodemanager.webapp.addressなんか）はAmbariには向いてない気がします。

あと設定ファイルのバージョン管理も出来ないのでTreasure DataみたいにChef使ってるような環境だとAmbariは使えないでしょうね。ただAmbariはAPIを持っているのでそのAPIをたたくChefなりAnsibleなりを作ればいいのかも。

Prestoのセッションでは、集計用のRDBMSはもはや不要なのではという話もありましたが、これに関しては僕はまだ懐疑的です。そこまでPrestoが早いとは思ってないので。最近の例だと1GBぐらいのデータ量のjoinで10分くらいかかってました。もっとも同じクエリをHiveで実行するとreduceが66%ぐらいでずっと止まっていて終わらなかったんですけどね。。。

もちろん集計用のRDBMSが無くなるならそれに超した事は無いです。

HDFSにデータ溜めて集計結果をRDBMSもしくは商用DWHに格納するというのは確立化された王道パターンだと思いますが、これって要はBIツールやレポーティングツールとの安定的な接続を考えるとHDFSでは難しいという消極的な理由からだと思ってます。HiveがJDBCドライバを提供しているからといってBIツールとの接続が即OKだとは思えないし、裏でMapReduceが実行されるような環境だとレイテンシが大き過ぎる。なので仕方なく集計結果をRDBMSに入れるんだけど、そうするとRDBMSが肥大化して辛いとかスケールアウトが出来ないとか、HDFSとRDBMSという２つのデータストアを運用するのが辛いとかそういう問題が出てきます。

なのでPrestoが十分なスピードが出るならもう集計用RDBMSいらなくてだいぶハッピーなのですが、まだその時期ではないような気がしてます。時間かかるクエリがあると他のクエリが実行されないとかもPrestoではあるようですし。

とはいえPrestoが面白いソフトであることは間違いないので使っていきたいと思います。あとPrestogresもね。