Treasure Data Tech Talkに行ってきた

Hadoop

先週のことだけどTreasure Data Tech Talkに行ってきました。

主催者のTreasure Dataさん、会場を提供をしてくださったDeNAさん、またイベント開催にご協力頂いたdots.さん、ありがとうございます。寿司おいしかったです。

セッションの内容は
Treasure Data Tech Talk #1 開催報告 - トレジャーデータ（Treasure Data）ブログ
を見ると良いと思います。

Treasure Dataはクラウド上にサービスを展開していてかつPrestoとかHadoopをがんがん改造していることもあり、ちょっと真似できない部分もありますが、いろいろと参考になりました。

S3上のデータにリクエストすると失敗することがあるので、Prestoでリトライするような機能を作り込んでいるとありましたが、こういうのは僕の環境ではいらないかなと思いました。

というのもオンプレミス環境なので１度失敗したらリトライしても同じだろうから。ただリトライがあったほうがメンテナンスが気楽にできるというメリットがあると指摘されたときはなるほどと思いました。

あとPrestoのクエリ実行履歴をどうやって取っているのか質問したら、QueryCompletionEventを使っているとのことでした。
ただ設定をちょろっと変えれば出来るというものでもないようなので僕は試してません。

FaceBookと似たやり方の模様。まあTreasure DataはScribeじゃなくてFluentd使っているだろうけど。

For an example, see QueryCompletionEvent, which records stats about each query run in Presto. At FB, we convert these events to JSON and send them to Scribe. Another system appends the Scribe JSON event to a Hive table and then we use Presto to analyze the events.

Google グループ

セッションの話はこれくらいにしときます。

実はセッション始まる前に僕がTreasure Dataの人といろいろ話したんですが、それが面白かったです。

kazeburowareはcontrollerを読めばわかるけどmoriswareはコンテキストを把握していないと理解が難しいと僕が聞いたけどどうなんだとか、Norikra, Shibの話とかです。

最初の話はGrowthForecastとYabitzのことだと思うんですけど、僕はどっちもソース読んでないので詳細は分かりません。
前者はRRDの面倒なところをうまく抽象化しているらしいです。


ただまあ例えばNorikraは重厚なので理解するのが難しいと僕は思います。これは解決しようとしている問題が複雑なのでやむを得ない側面があると思います。

Norikraのアーキテクチャはこれが分かりやすいです。

EsperがJavaで書かれたミドルウェアでNorikraはJRubyベースで実装されています。
そしてmizunoというRackサーバを使いますが、これはJettyを内包しています。
クライアントとの通信にはmsgpack-rpc-over-httpを使います。いやあ難しいですよねw

ここでちょっと前に僕の環境のNorikraがJavaヒープmax近くまでいって、データを送るFluentd側でバッファ溢れが起きた話を相談しました。

そこで出てきたアイデアがNorikra側で新規接続をrejectすればFluentd側であとでリトライするから良いのではという話。

例えば下記をみるとリクエストキューにjava.util.concurrent.ArrayBlockingQueueを使うと良さそう。
Jetty/Howto/High Load - Eclipsepedia

少し調べた感じだとJettyはキューにデフォルトだとorg.eclipse.jetty.util.BlockingArrayQueueを使っていてこれはリクエストをブロックせずにどんどんキューにためる。
一方java.util.concurrent.ArrayBlockingQueueなら上限を設定してブロックできる。

ただmizuno側でキューをいじれなそうでした。
https://github.com/matadon/mizuno/blob/master/lib/mizuno/server.rb#L72-L77

そうじゃなくてJavaヒープをどれぐらいつかっているかをもとに現在の負荷を判断してしきい値を超えたらrejectするみたいな方向が検討されています。
https://github.com/norikra/norikra/issues/69
これはこれで
https://github.com/norikra/norikra/issues/70
という問題もあるようですが、この辺はウオッチしたいと思います。


Shibも意外と難しいです。
何が難しいかというとステータス管理が難しい。
ShibはクエリをsubmitするとDBにrunning状態で保存します。そして処理が終了したらexecutedにします。
Shibは1プロセスで動いていて定期的にポーリングして状態を確認します。この辺はcallbackが書きやすくかつsetInterval使えるJavaScriptならではという気がします。
普通だったらジョブをsubmitするプロセスとは別にキューをポーリングするプロセスがバックグラウンドで定期的に動くアーキテクチャになるでしょう。
その辺のメリット、デメリットはこちらに詳しいです。
Node.jsなWebアプリでJobQueueなしにラクラク巨大処理を実行 - たごもりすメモ

Shibのようなアーキテクチャだとセットアップが簡単という反面、障害時にちょっとわかりにくい状態になります。
例えばクエリをsubmitしてその処理が終わる前にShibが落ちるとMapReduceジョブは正常終了しているけどDB上にはrunningとして保存されているので実行中として扱われます。

Shibも枯れてきているので簡単に落ちることは無いんですが、API経由で意図しないパラメーターでアクセスされると落ちるということがありました。ブラウザで操作している分には遭遇しないと思います。
ただしこの辺も僕が修正したので今は大丈夫です。何かあればissue登録すると良いと思います。

長くなりましたが、そんな感じの良いイベントでした。