11/26 の『Hadoopソースコードリーディング 第13回』でCloudera Impalaの発表をしてきました。
きっかけはTwitter上で、ビールの化身 も◯す の外道父を呼べば？から始まって、１分かからず依頼ツィートが飛んできて引き受けた感じで、Twitterで数分で全てが完結する非常にフットワークの軽い業界になります。
それでは、発表資料や補足などを書いていきます。
リンク
発表資料
60分の内容としては十分詰め込めたと思うのですが、
それよりも私のHadoop/Hiveロゴの好きっぷりをよく表せたかな、と満足しています。
補足
検証していて、アレもコレもやんなきゃなーというのはいっぱいあったのですが、資料に詰め込むのはそれなりの量と簡潔さにしなくちゃなので、上記資料だけではまだまだ気になる点は多かったと思います。発表後の質疑応答やツィートなども踏まえて、検証しなくちゃリストはこんな感じになります。
SELECT * ～ のfieldを指定するとどうなるか
今回は最もシンプルなSELECTのfieldを * で検証しましたが、fieldを指定するとHiveでは動きが結構異なる、ということで確かに気になるところです。WHERE句
WHERE句をつけたクエリを試していないので、これも比較できればなと。つけたらちゃんと負荷分散されたりするのかな？と思ったりしましたが、@repeatedly @oza_x86 のお話を聞く限りは、絞った分は速くなっても負荷分散はされなさそうですね。
JOINテーブルを大きくしてみる
今回はJOINテーブルの最大サイズが500MBでしたが、先日の @shiumachi 資料 によると、INSERTしてみる
SELECTばっかりでINSERTをやっていないので、これもHiveと比較してみなくちゃです。impala-shell で使えるクエリ一覧を見る限りは、今のところSELECTとINSERTしか重要なのはないですね。
tcpトラフィックはどんな感じか
話の中でも出しましたが、impalaのCPU処理が停滞気味になるタイミングがあり、HDFSファイルの転送に時間がかかったりしてるのかな、と予想しました。なので、ノード間のトラフィックも計測してみるべきですね。ulimit は?
万全の65536でやっていますが、/etc/security/limits.d/impala.conf を追加する、というのを資料に書き忘れました。同時にクエリ発行
1つのPlanner impaladに、複数クライアントから同時にクエリを発行したら処理順序とか負荷はどうなるのかな、と。リソースについて
CPUリソースというか負荷分散や実行計画など内部の処理については @repeatedly @oza_x86 の発表のとおりですが、メモリの方は @shiumachi ツィートによると、GAでは全実行ノードの総メモリを使うようになる、とのことなので、効率面と安定面に期待したいところです。
impalaはいいものであることは間違いないけど、まだまだユーザが少ないので、サッサとCDH4にしてどんどん検証して、皆でClouderaの中の人にゴリゴリ報告してよりいいものになっていくというスピーディーな展開を作っていきたいですね。
最後に、資料内で活躍したimpalaロゴ案の画像でも添付して終わりにしたいと思います。
このロゴに決定したくないなら、中の人は早く正式なロゴを公開するとよいのではないでしょうか。
画像１：Hiveから乗り移ってImpalaQL
画像２：O’Reilly本のイメージ
