ひしだまの変更履歴

ひしだまHPの更新履歴。
主にTRPGリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。

Hadoop Conference Japan 2014の感想(総括編)

2014-07-10 23:13:30 | PG(分散処理)

Hadoop Conference Japan 2014(HCJ)で自分が聞いた講演の個々の感想はブログに書きましたが、それとは別に全体として思ったことがあるので書いておきたいと思います。

簡単に言うと、「最近のHadoopの利用事例はどうなっているんだろう?」
もう少しくだけて言うと「皆はHadoopをどう使おうとしているんだろう?」ということです。


今回のHCJの各講演の題目を見る限り、YARN・SQL・Sparkの話題が多かったと思う。
Hadoopの主要な仕組み自体は今後YARNになっていく感じなので、YARNの話が出てくるのは分かる。
しかし、SQL関連がこんなに活発なのが個人的には驚き。

SQLは対話型ツールで使うのにはとても向いていると思う。
一度の操作ではあまり複雑なことをしない(何十ものSQL文を発行することは無い)だろうし、SQL文にエラーがあってもその場で直すことが出来る。
これに対し、バッチアプリケーションでSQLを使うのには昔から疑問を感じている。
バッチアプリケーションで使うなら、SQL文にエラーがあったらアプリケーションのコンパイル時に分かって欲しいと思うのだが、プログラム内にSQL文を文字列で埋め込むという方式では、コンパイル時のチェックなど望むべくも無い(そういうチェックツールもあったかもしれないが)。
静的なSQLならコンパイル時に解析してくれると実行時のオーバーヘッドは減るはずだが、実際には実行時にパースされることになる。
一方、プログラムでSQL文を構築する方法を採ると、実際に実行してOKだったSQL文をそのまま記述するということは出来なくなる。
どちらも一長一短^^;

RDBでデータを管理するシステムでは、基本的にSQLでしかデータにアクセスできないので、バッチアプリケーションであってもSQLを使うのは当然だ(というか他の選択肢が無い)と思う。しかしHadoopはファイルを扱うので、SQLである必要は無いはず。
(バッチアプリケーションがSQLから離れられるチャンス!w) 

ストリーミング処理のようなリアルタイムっぽい使い方をしたい場合は従来のMapReduceでは遅いので別の方式が欲しいというのは分かる。
また、得られた結果を見たいという用途ではSQLも便利だと思う。
(セキュリティー関連でテーブルの行・列ごとのアクセス制限がしたいという話も、ユーザーが直接データにアクセスする場合には確かに必要な機能だと思う)
しかし、これらの使い方は、自分が思うような「バッチ処理(バッチアプリケーション)」ではない。

自分が作ったあるバッチ(Asakusa Frameworkで作ったアプリケーション)は、Hadoopジョブに変換すると100ジョブを超えている。AsakusaFWではいくつかの演算子をまとめて1つのHadoopジョブが作られるので、演算子の個数は2~3倍あるはず。
もしSQLで作るとなると、AsakusaFWの演算子1つが概ねSQL1つになるだろうから、数百のSQL文を書かないといけない。(処理の重複も多いのでもっと減らせるかもしれないが、逆にエラー処理を行うSQL文を追加しないといけないかもしれない)
複数のSQL文にまたがった最適化など行われないだろうからバッチ全体として実行効率が落ちる気がするし(Impalaなら個々のSQLの実行が速いらしいので、トータルでも速いかも?)、そもそもそれらのSQLをそれぞれ単体テストするのは、想像するのも嫌だ^^;(AsakusaFWの演算子は普通のJavaのJUnitでテストを書ける)

つまり、Hadoopを使った複雑なバッチアプリケーションを作ろうと思ったらSQLを使う必要は無いし、Hadoopはもともとバッチ処理向けだったと思う。
にも関わらずSQLが欲しいというのは、バッチとは異なる使い方をしたいという事なのだろうか?
もしくは、少数のSQLで済む程度の処理しかしないという事だろうか? 


もうひとつ注目を集めているのがSpark。

自分がそもそもHadoopに注目したのはバッチを分散処理させる(ことによって高速化する)という点だったので、それと同じ意味で、Sparkもバッチアプリケーションを作るのに使えるかもしれないと思って注目している。

なんと言っても、SparkはScalaでコーディングできるという利点があるし!(利点ですよ、これはw)

しかしながら、Scalaは日本では(SIerには)普及しているとは思えないので、日本でSparkが注目を集めている理由(何に使おうとしているのか)がよく分からない。
Spark SQLなんてものもあるようなので、やはり少数のSQLで出来る程度の使い方を想定しているのかなぁ?


Hadoopが出た当初は、Hadoopの利用事例も盛んに発表されていました。
今となっては(Hadoop界隈では)Hadoopを使うのは当たり前なので、最近では利用事例を(自分は)あまり聞かなくなっていましたが、最近のHadoopの使い方は昔とは異なるのでしょうか。

HCJのアンケートでも、利用しているエコシステムにHBaseやFluentdが上位に来ていましたが、全く予想外でしたし。
自分はSIer出身なので、Hadoopの使い道もSIerっぽいバッチを考えていましたが、(アンケートは無かったと思いますが)HCJの参加者もSIerでない人たちが多いのかも…?  

そういう訳で「他の人たちはどういう使い方をしたいと思っているのかなぁ」という疑問を強く感じたのが、今回のHCJ全体を通しての感想でした。



最新の画像もっと見る

コメントを投稿