Hadoop Conference Japan 2014 に行ってきて感じた事まとめ

2014/08/11

さる2014/07/08、Hadoop Conference Japan 2014が開催されました。1ヶ月以上もアウトプットできなかった理由はおいといて、基調講演には出れていないのだけれど、いくつか回ったセッションを総合して、感じた事をまとめておきたいと思います。前提として、自分はHadoopの素人且つエンジニア1年目なので、鋭いマサカリ投げられると失禁したまま気絶する事が予想されますが、事実と異なる事書いてしまっていたり、それちがうんじゃねーのか、的な指摘は是非コメントください！間違ってる事書いておくの嫌ですし、他の人達がどう考えているのか知りたいです。

見て回ったセッション

SQLによるバッチ処理とストリーム処理資料
A Deeper Understanding of Spark Internals 資料
Spark1.0での動作検証 - Hadoopユーザ・デベロッパから見たSparkへの期待資料
Evolution of Impala - Hadoop 上の高速SQLエンジン、最新情報資料
並列SQLエンジンPresto - 大規模データセットを高速にグラフ化する方法資料

思ったこと

このカンファレンスに出て思ったことが3つある。

「大規模データ処理」という言葉の細分化
SQL系のDSLが支配的になってきてる背景
リアルタイムデータ処理の先にあるもの

これら思ったことについて順にまとめていく。

「大規模データ処理」という言葉の細分化

今回一連のセッションを聞いていて一番深く感じ入ったのは、タゴモリさんの公演「SQLによるバッチ処理とストリーム処理」に出てきた分類表。

Batch processing and Stream processing by SQL from SATOSHI TAGOMORI

大規模なデータを処理している人たちにとってみたらもはやあたりまえの事なのかもしれないですが、自分の中でこのような分類がなされていなかったため、今後何をどこで使っていくのか、ということを考える際に凄い参考になりました。

####Batch

少し前の時代、大量のデータに対して実行される高いレイテンシを持つ処理(週単位、月単位とか)を、安全確実/自動リカバリ付きでコモディティHW上でも実行できるYARNベースの夜間バッチが「所謂大規模データ処理」のメインストリームだったように思えます。(YARNベース、ちょっと言葉おかしいかもしれないけど、リソース管理、スケジューリング、投機的実行を管理しているのがYARNなのでHiveもJavaやその他言語で書いたMapReduceも含む)。そこで集計されたサマリ値をRDBMSに投入し、日別の実績推移を確認できる。これで今までRDBMSで処理していたバッチ処理というものを、より速く確実にスケールする構成で実行できるようになっていった。これが表のBatch部分。

####Short Batch (Interactive Query)

次はShort Batch部分。時代は移り変わり「既存RDBMSで捌ききれなかったような大量データを安全確実に集計処理できる」から一歩進んで「既存RDBMSで捌ききれなかったような大量データを、軽快に、エンジニア以外の人が分析したい」という要望が発生してきている。至極当然な流れで、結局大量のデータを処理するのは、膨大なファクトから商売に対する示唆を得て実際の施策成功精度向上/仮説検証プロセスの高速化であり、事実から示唆を絞り出すのはエンジニアよりも現場で商売を回している人達の方がその商売独自の勘所もある。こういった要望に対して、Hadoopで集計してRDBMSに入れて、というプロセスで対応出来ないことも無い。対応出来ないことも無いけど、ちょっと想定と異なる軸で見ようとすると新規集計バッチを作らなければいけなくなったり、例えばささっと作ったHiveQLを作って流さないといけなかったりする(流石にアドホックにMapReduceを書く事はあまり無いような気がする)。そうなると、Hiveはもともと高いレイテンシ向けの処理用に作られており、JVMの起動、リソース確保、スケジューリング、MapReduceアルゴリズムへの変換、等の処理で起動/実行のオーバーヘッド大きいため、インタラクティブに示唆を！という要望にはあんまりマッチしなかったりするように思う。shibとかがこの領域で頑張っていた雰囲気。

上記のような若干無茶な要望に対応するようにMPP(Massively Parallel Processing)系のクエリエンジンが勃興してきている。始祖はGoogleが2010年に出したDremel: Interactive Analysis of Web-Scale Datasetsという論文。この辺りをオープンソースで実装したプロダクトで有名なのがImpala。なぜHiveではないのか、なぜImpalaを作ろうと思ったのか、その辺りの歴史の変遷はCouderaさんのこの記事に詳しく書いてあり大変勉強になりました。MapReduceを利用せず、Hadoopコンポーネントが提供するYARNを利用せず、だがしかし分散ストレージHDFSとHiveの既存DDLは有効活用し、よりインタラクティブなクエリを実行できるようなプロダクトになっている。その他にもMPP系エンジン括りでいくと、Presto、Apache Drill等が代表選手。特にPrestoはその出生の原因がこの、「エンジニアが頑張らなくてもインタラクティブに分析したい欲」をよく表しており、やっぱエンジニア以外がサクサク分析できてなんぼ感がある。Facebook、分散SQLエンジン「Presto」公開。大規模データをMapReduce/Hiveの10倍効率よく処理すると

(ただ、高レイテンシ向けに設計されたHadoop上のHiveと低レイテンシを狙ったImpala/Presto/Drillを比較して10倍効率が良いって言うのには若干抵抗がある。みんなちがって、みんないい、と言いたい。)

正直Short BatchよりもInteractive Queryingという言葉の方が自分的にはしっくりきている。MPPエンジンはrepeatedlyさんがまとめているこの記事が最高にまとまってて参考になる。

MPP on Hadoop, Redshift, BigQuery

####Stream Processing

最後に表のStream部分。これはInteractive Queryより更に踏み込んでおり、自分もまだ手元に環境作って試せていないのですが、Streamとして送られてくるデータをストレージに書き込む前に集計してしまう代物らしい。ニアリアルタイムとか、5分毎のバッチ、そういう甘い話ではなく、流れてくるデータがストレージに書き込まれる前に集計されて記録される。そしてタゴモリさんが作っているNorikraは、集計の記述にSQLライクな言語を利用できるという。

すごい未来感(小並)。

ただ、商売に直結するか否かに関しては、自分の中でまだ疑問も残っている(詳細後述)。LINEさんでは小さいバジェットで広告を配信した際でもリアルタイムで集計できていれば、追加で枠を買ったり等の判断を行える為便利だ、という話をされていた。

あと印象に残った言葉は、「再実行が難しい」という部分。確かにリアルタイムで、データがPersistentな形になる前に集計しているので、コケた際に再度集計っていうのが難しそう。

Batch, Interactive Query, Stream Processingという、今まで「大規模データ処理」で一括りにされていた部分が細分化され、それぞれの領域で活躍できるソフトウェアがある、用途に合わせて選ぶべし、というのは多分今回のカンファレンスで一番響いた部分。

次。

SQL系のDSLが支配的になってきてる背景

コレはやっぱり感じた。Norikraもそうだけど、ImpalaもPrestoもSQL。Sparkも今までのプログラミングモデル(メソッドチェーン的なヤツ)からSQL系のDSLに乗り換えていく、という話をされていた。DataBricks，Sparkで構造化データを操作するSpark SQLを発表

これはなんとなく、納得がいく気がしている。たぶん以下三点。

既存知識流用できる(次々出てくるDSLに脳味噌を対応させていくより、既に有る脳内のモデルを再利用できる方が客はつく気がする。客とはこの場合ソフトウェアのユーザを意味する。)
宣言的記述のできる言語はとりあえず楽(データを取得する為の手続き/集計の最適化やEventual Consistentとか考えながらよりも、宣言的に欲しいデータの形だけ描いて、あとはオプティマイザに任せる、っていうのが楽。そこまで甘くはないけど、でも無いより全然楽。)
ビジネスサイドももっとデータ弄りたい(なにげにコレが一番でかいのではないかという気がする。仮説を立てるのも、検証するのもビジネスサイドで実施することが多いし、彼らが自分たちで集計できれば、エンジニアサイドとのコミュニケーションコストも下がる。)

自分はSQLかなり好きなのでこの流れは個人的に嬉しいです。

リアルタイムデータ処理の先にあるもの

ココは本当に未来な感じだし、自分もまだよく考えが練れていない。

システムの異常監視、とある条件を設定した閾値を超えた場合通知とかには多分凄いマッチする気がする。条件設定した以上のエラーが吐かれていたら通知、スケールアウトする、とか。

ただ、若干抽象的になってしまうけど、「人間の意思決定」がどこかに挟まるとその力は途端に弱くなってしまうな、という印象。人間の意思決定、もう少し踏み込むと「会社の意思決定」というのはやはり時間がかかるため、5分に1回でいいのでは、という素朴な疑問が出てきてしまう。

先ほどのシステム監視の例は自分がプログラムを書く側だからすっと思いつく例なのかもしれない。もしかしたらビジネスサイドの人々にこういう機構もあるよ、という話をしたらリアルタイムデータ処理が力を発揮する場所を思いつくのかも。

今自分が会社で扱っている商売の範囲だと、「在庫(枠)と広告(CPM, CPC, CPM)の全体的なポートフォリオをリアルタイムで最適化していけるから最高の利益を出せるんです」的な領域では力を発揮しそう。いくらで買ったどの枠にどういう属性を持っている人が来た時にこの広告を出す、というのを決めるパラメタを、リアルタイムで実績を反映させて更新し続けていく仕組み。DSPでもリアルタイムに「どの広告をビットレスポンスとして返すのか」を決める内部的なパラメタにフィードバックを行っているのだろうか。DSPの仕組みはなんとなく把握しているけど、かの仕組みにリアルタイムに何かを集計して得になる部分をしっかりイメージできない。修行不足である。

こういった仕組を、SQLライクなDSLを持ったStream Processing系ソフトウェアを使う事でより柔軟にできるのでは、という仮説はある。

「人間の意思決定」を挟まないところには非常に有効だが、リアルタイムに集計されるグラフを見て人がその場で値千金の意思決定を秒速でする、というのは、どうもあまりしっくり来てない。しっくりきてないんだけど、この領域はまだ見ぬ応用方法が色々ありそうでとっても面白そうだなーー、と思いながら新橋から帰りました。

まとめ

最後になりますが、一ヶ月も経ってなんだよ、という感じではありますが、会場の準備をしてくださった方々、公演してくださった方々、本当にありがとうございました！あの大規模なカンファレンスが無料という奇跡、本当に凄いです。