私が GraphX を推す理由

Hadoop Spark GraphX

この記事は、Spark, SQL on Hadoop etc. Advent Calendar 2014 - Qiitaの21日目の記事です。

なぜ GraphX を推すのか

私は、GraphX Advent Calendar 2014 - Adventarを立ち上げて「全部俺」状態で頑張っています（だいぶ遅延を見せていますが…）。もしやと思っていましたが、誰も参加してきてくれる人がおらず、ブログのアクセスも全く伸びません（笑）ブログに限らず、GraphXの情報自体、非常に少ないです。そのため、ブログを書いて、情報量自体を増やしていこうとしているわけですが、なぜ誰もろくに見向きもしない GraphX という技術に、私はここまで熱くなっているのでしょうか。この記事は GraphX のアドベントカレンダーではないので、一度、改めて、私が GraphX に感じる魅力、それをどうしてみんなに知ってもらいたいと思うのか、整理したいと思います。

そもそも GraphX とは

GraphX とは、Apache Spark のコンポーネントのひとつです。 グラフ構造の大容量データを並列分散環境上で処理するためのフレームワークです。

グラフ構造での分析技術は、R言語の igraph パッケージなどがよく使われますが、大容量のデータを扱う技術はこれまでなかなかありませんでした。グラフ構造データは頂点が辺で接続しているので、分散格納されたグラフ構造データに対する処理を行うと、分散環境間で情報の共有が必要で、並列分散処理自体に適さないためです。これを Spark の技術で解決しているのが GprahX です。

近頃出てきた、大容量グラフ構造データの処理技術には、他に Apache Giraph や、GraphLab がありますが、どれもグラフ処理専用のフレームワークです。GraphX は、Spark の一部ですので、Spark Core の ETL 処理や、 Spark MLlib による機械学習処理、 Spark SQL によるクエリ処理、あるいは Spark Streaming によるストリーミング処理とシームレスにひとつのプログラム・システムで実装できるのが最大の特徴です。

GraphX を推す理由

グラフ処理でしかできないことがある

一番はなんと言ってもこれです。

グラフ構造データといっても、元々は表構造のデータです。これを表構造のままで扱っていてはできない処理を、グラフ構造で扱うことで初めてできることがいろいろとあります。

開発生産性があがるとか、そういうことではありません。できなかったことができるようになる、そうした興奮がGraphXにはあるのです。

ETL処理、SQL処理と一緒に開発できる

前述の通り、Spark のコンポーネントのひとつであることで、グラフ処理に関連する処理も含めて、ひとつのシステムに実装することができます。これはとっても便利です。一度味わうと離れられません。

Scala が向いている

これ、私がちゃんと Scala を理解していないせいでちゃんと説明できないんですが、 Scala での処理がすごく向いていると思います。関数が渡せること、ジェネリクス、ラムダ ... よーわかりませんが ^^; そういうのがいいんだと思います（適当）。てか、Scala、Java、JavaScript、ActionScript くらいしかわからないんですが、だいぶよく書けると思います。

最後に

いろいろ書いてきましたが、結局は、グラフ処理ならできることと、自分の仕事とをどうリンク付けて発想できるかだと思います。グラフ処理に、GraphX 処理に対して興味を持ち、何かできるんじゃないかと思ったなら是非一緒に議論してみたいと思います。よろしければお声がけください。（ GraphX 勉強会も開催したいなぁ）

アドベントカレンダーも応援よろしくお願いします！