GedowFatherさんがImpalaを本番投入した件

tagomoris @tagomoris

自分以外に試してくれる人がいるのはいいものだなあ……

外道父 | Noko @GedowFather

何やったかわからなくなりそうだったのでとりあえず１枚のテキストにずらずら保存していく作業

外道父 | Noko @GedowFather

中心のimpaladとそれ以外のCPUもあとでみる

外道父 | Noko @GedowFather

impaladがゲシュタルト崩壊してきた

外道父 | Noko @GedowFather

3.1GB, 6895209行, 15file のCOUNT(distinct xxx)でHive 50s : Impala 27s。次は容量倍にしたり微複雑なクエリにしたり

外道父 | Noko @GedowFather

容量が大きくなるほど、MpaReduce開始オーバーヘッドの差が影響しなくなってくのは１つあるだろうな

外道父 | Noko @GedowFather

Hive, Impalaそれぞれ得意な集計関数とかあるのかな

Geforce RTX 3060Ti @showyou

@GedowFather Hive早くないっすか？

外道父 | Noko @GedowFather

痒いところに手が届く情報：impalaはORDER BY に LIMIT がついてないと怒られます ERROR: ORDER BY without LIMIT currently not supported

Sadayuki Furuhashi @frsyuki

@GedowFather ファイル数よりノード数の方が多いんでしょうか…？

tagomoris @tagomoris

だいぶ差が縮まってきた……ｗ

Sadayuki Furuhashi @frsyuki

@GedowFather Impala だと大きなテーブル同士の JOIN は厳しいようですが、普通の GROUP BY + 集約関数でも、GROUP BY で出てきたグループ数が多くなると遅くなりそうです。それでも LIMIT を付けると速いかもです。アーキテクチャ上は。

外道父 | Noko @GedowFather

ブドウ糖が切れたのでチョコレートを補給

Sadayuki Furuhashi @frsyuki

差が２倍くらいだと、チューニングパラメータを変えるくらいの違いしか無いと言う話に…。10倍くらい速くなると嬉しいな。数百GBの GROUP BY + 集約関数で。

Sadayuki Furuhashi @frsyuki

（横から言うだけの簡単なお仕事

外道父 | Noko @GedowFather

connectするimpaladとそれ以外のimpaladの呼び名が欲しい

外道父 | Noko @GedowFather

アーキテクチャ資料を見てくる。名前ねーかな

Suguru ARAKAWA @ashigeru

悪人がいまさら

三上俊輔 @shun0102

@GedowFather データの形式はSequenceFileでしょうか？Textですか？

外道父 | Noko @GedowFather

CPU情報：30秒間のimpalaクエリにおいて、(仮)中心impaladは単独プロセスでCPU1100%を観測。周辺impaladは3～4ノードで1～2秒間だけ500%

外道父 | Noko @GedowFather

あぁ・・・ノード数の分母がないと参考にならないか　まぁいいや

Sho Shimauchi @shiumachi

打ち合わせ終わった。結局 Impala の件はその後どうなったんだ

外道父 | Noko @GedowFather

中心impaladの重い処理はPlannerなのかCoordinatorなのか

Sho Shimauchi @shiumachi

@GedowFather 1つのクエリでディスクあたりに読み込むデータサイズが増えると、その分ディスクIOの速度が支配的になっていくというのは考えられますね。環境の詳細や結果の詳細を見ていないんであくまで推測ですが

三上俊輔 @shun0102

ImpalaはTrevniのファイルフォーマットが出てから試せばいいやと思ってる