Hadoopソースコードリーディング 第13回 まとめ

SKS rep @repeatedly

Impala本とJubatus本，どっちが早くでるのか．先にFluentd本は出せそうだが…

DaichiMiki @DaichiMiki

2013年に玉川さんが翻訳予定の本についてのお話がありました。Hadoopの象本第三版、Programming Hive、Hadoop Operations。いずれもオライリーから。 #hadoopreading

DaichiMiki @DaichiMiki

玉川さんのお話の続き。Bad Dataという本の翻訳を検討中とのこと。データの前処理についての本。事例がいっぱいある感じらしい。 #hadoopreading

DaichiMiki @DaichiMiki

ちなみにProgramming Pigの翻訳はタイミングが悪くて出来なかったとのこと。ちょうど別の翻訳が立て込んでいたため。あとPig本はページ数が少ないので出版の企画にgoが出にくいかも、という事情も。300ページ超えてるとまた話は別のようです。 #hadoopreading

Sadayuki Furuhashi @frsyuki

MB単位だったら1台でいいし、PostgreSQL + foreign data wrapper が完璧な解決策なのでは…SQL互換性高いし。データ採るところの並列性は高い一方で、ごりっとした処理を分散してくれないというのは、プランナの問題かな。 #hadoopreading

Sadayuki Furuhashi @frsyuki

#hadoopreading に乗り遅れたらしいのだけども…Impala の他と比べて良いところを140文字で表現すると何なんでしょう！？ #hadoopreading

oza @oza_x86

HDFS の上で動くとこ、かな... “@frsyuki: #hadoopreading に乗り遅れたらしいのだけども…Impala の他と比べて良いところを140文字で表現すると何なんでしょう！？ #hadoopreading”

oza @oza_x86

あと、集約演算とORDER BY LIMIT みたいな、フィルタ処理が早い “@frsyuki: #hadoopreading に乗り遅れたらしいのだけども…Impala の他と比べて良いところを140文字で表現すると何なんでしょう！？ #hadoopreading”

Sadayuki Furuhashi @frsyuki

@oza_x86 ほう！ どのくらいのサイズだと、Hive やフツーのRDBと比べて速いんでしょう！？

oza @oza_x86

@frsyuki ちなみに、商用の分散RDBはこの辺の最適化は真っ先に行うでしょうから、そことの差異はHDFSの上かどうかくらいだろうなぁ、という印象です

Sadayuki Furuhashi @frsyuki

@oza_x86 商用の分散RDBに行く前に、メモリに載る程度のデータ量なら PostgreSQL の方が速いのでは、という印象さえある今日この頃なのですが…

oza @oza_x86

@frsyuki 正しい印象だと思いますよ^^;

Sadayuki Furuhashi @frsyuki

@oza_x86 ぇぇ…では Impala の使い道はどこに…？ ここは @shiumachi さんを煽るべきか

Satoshi Noto @n3104

Impala のいいところは、HDFS 上に存在する DB だとレスポンスが帰ってこないぐらいの量のデータに対してクエリを発行できて、かつ Hive よりも一桁ぐらい早く結果がわかるということなのかと。あと、limit の実装を見るにサンプリング前提な気が。

Sho Shimauchi @shiumachi

@frsyuki @oza_x86 流れ全然追ってないのでアレですが「◯◯がないじゃん」といった話のほとんどは当然議論されてるし将来的に実装されますのでご期待ください。メモリの話だったらGA時には全実行ノードの総メモリを使うようになるので単一ノードじゃ届かない世界に到達できます

たむたむ🏫 @tamtam180

HDFSのデータに対して低レイテンシで試行錯誤できるというのがキモであって、Postgresのが速いならそっち使えばいいけど、 ロードするだけでも大変なような。( ；´Д｀)

外道父 | Noko @GedowFather

Cloudera Impala発表資料 | 外道父の匠 http://t.co/DFnbNUQc #Cloudera #Impala #CDH4 #hadoopreading

SKS rep @repeatedly

昨日帰りの電車で，Impalaで負荷分散するなら，前に本物のSparrowみたいなスケジューラが必要だよね，みたいな話はした > "Hadoopソースコードリーディング 第13回 まとめ" http://t.co/R5zFUyhd #hadoopreading

SKS rep @repeatedly

実際の話，今のImpalaのソースコードを読んだ限りは，あまり処理も負荷も分散しないし，でかいデータだとアレな感じになるので，HDFS上のデータを他のRDBMSに移さなくても良い，というのが現状のメリットかなぁという感じ．まぁそこら中にTODOがあるので，これからなのは確か

tagomoris @tagomoris

昨日の画像、本当にいちばん酷かったのはこの画像でしたね http://t.co/sEbDSaMX

SKS rep @repeatedly

URI changed. number-13 to 13th > "Inside Impala Coordinator at HSCR 13th" http://t.co/Op0dORwi #hadoopreading

oza @oza_x86

昨日のImpala コードリーディングの発表資料を公開しました→ http://t.co/OjTLzYLZ #hadoopreading

Sho Shimauchi @shiumachi

なんか社内で外道父さんの資料を紹介したら、なぜか「まさに外道」の画像に注目が集まった。注目するところそこじゃねーから

Justin Kestelyn | @ke.stelyn on Threads @kestelyn

Cloudera Impala preso by @GedowFather - entirely in Japanese, cannot read, but the graphics are awesome http://t.co/ufD1cH9U