ビッグデータの今と未来を示す5つの最新オープンソース技術

次の記事

クラウドソーシングのクラウドワークスが伊藤忠テクノロジーベンチャーズなどから3億円を調達

Screen Shot 2012-10-26 at 11.53.10 PM

今四半期にはビッグデータがどのCIOの心にもあり、しかもそれは当然だ。今年中に企業がビッグデータ技術に費やす費用は43億ドルに上(のぼ)る、と予想されている。

話はそれだけで終わらない。企業が投ずるそれらの費用はドミノ効果を作りだし、アップグレードや新規事業のへの支出は2013年に340億ドルに達する、とGartnerは推計している。今後5年間の支出総額の推計は2320億ドルである。

しかし今見えているものは、巨大な氷山の一角にすぎない。

ビッグデータは現在のところ、Hadoopや“NoSQL”タイプのデータベース…Mongo(ドキュメント)やCassandra(キー-ヴァリュー)…を指す。今日では、リアルタイムの分析をストリーミングすることも、容易にできる。クラスタのスケーリングなんかは(かなり)朝飯前で、20分足らずでできる。しかし本当の勝負は、これから始まる。

これらおなじみの、今やありふれた顔ぶれたちのさらに向こう側には、完全な処女地のようなアドバンテージや、本格的にでっかい機会が存在する。

今市場には、実用レベルのオープンソース技術が何件ないし何点あるかご存じか? 25万あまりだ。われわれの四囲に、イノベーションが充満している。システムの複雑性は日に日に増す。こんなふうに:

この選択肢の多さは…控えめに言っても、すごい。しかもそれらの、トレンディーな動き、うごめきに関して、ほとんどの人が無知無関心だ。

でも今、われわれのレーダーには何が映っていて、Fortune 2000企業のところへはこれから何が下りていくのか? 今勃興している多くのオープンソースプロジェクトの中で、実用レベルで今後もっとも定着しそうなものは何か? これから、片時も目を離すべきでないものは何か?

それを見つけるための調査とテストを、われわれ〔筆者がプロマネを務めるInfochimps社〕がやった。ではこれから、これからのビッグデータの世界を揺るがしていく5つの新技術を見ていこう。いずれも、見過ごすことのできない最新のツールであり、あなたのお隣の会社にそれがやってくるのも、もうすぐだろう。〔訳注: 原文のコメントでは、この記事が見落としているオープンソースの重要/優秀技術が、いくつか指摘されている。〕

StormとKafka

StormKafkaは、ストリーム処理の未来であり、すでにGrouponやAlibaba、The Weather Channelなど多くのの著名な企業で使われている。

Twitterの内部で生まれたStormは、いわば“分散リアルタイム計算機利用システム”だ。Stormは、Hadoopがバッチでやることをリアルタイムでやる。一方Kafkaは、LinkedInで開発されたメッセージングシステムで、同社のアクティビティストリームとその背後のデータ処理パイプラインの基盤として、お役に立っている。

この二者を併用すると、データストリームをリアルタイムで得られ、しかもそれをリニア〔linear, 一次式的〕なスケールで行える。

なぜそれが重要か?
===ビッグデータのリアルタイムストリーム処理===

StormとKafkaを使うと、ストリーム処理をリニアなスケールで行え、各メッセージが確実にリアルタイムで処理され、信頼性も高い。StormとKafkaの二人三脚は、毎秒数万の速度でメッセージを処理できる。

StormとKafkaのようなストリーム処理のソリューションが多くの企業から注目されているのは、それらの、ETL(extract, transform, load) (取り出し、加工変形、ロード)への優れたアプローチと、データの統合化のせいだ。

StormとKafkaは、インメモリの分析とリアルタイムの意思決定サポートでも優れている。企業が今急速に目覚めつつあるのは、Hadoopのバッチ処理ではリアルタイムのビジネスニーズを満たせないことだ。リアルタイムでストリーミングする分析は、すべての企業向けビッグデータソリューションないしスタックの、必須要件だ。なぜなら、それらは、“三つのV(volume, velocity,variety)(量、速度、多種類性)”にエレガントに対応できるからだ。

StormとKafkaは弊社Infochimpsでももっとも重視し、もっとも真剣に取り組んでいる技術だ。客先だけでなく、弊社のプラットホームで使うようになるのも、近いだろう。

DrillとDremel

DrillDremelは、データに対する大規模でアドホックなクェリを可能にし、ビッグデータを調べることにつきまとう遅延を大幅に縮小する。数ペタバイトのデータを数秒でスキャンでき、アドホックなクェリに答え、さらには強力なデータ視覚化を駆動する。

DrillとDremelを使うと、データエンジニアではなくビジネスアナリストの仕事ができるようになる。つまりIT側よりむしろ、経営管理や企画調査などの人たちがDrillとDremelを愛する。

Drillは、GoogleがDremelでやっていることのオープンソースバージョンだ(Google自身は同社のBigQueryで、Dremel-as-a-Serviceを提供している)。しかし自分に合ったツールを作りたい企業が多いから、Drillのほうに注目していくべきだろう。まだ先の話だが、デベロッパコミュニティはすでに強い関心を示しているから、ツールとしての成熟も早いだろう。

なぜそれが重要か?
===ビッグデータクェリのアドホック化, バッチ処理を卒業===

DrillとDremelは、いろんな点でHadoopよりも良い。Hadoopはあくまでもバッチ処理だから、場合によってはとても不利だ。

Hadoopは、MapReduceを誰もが利用できるアドホック分析のツールにしようとして、コミュニティが頑張った力作だ。またそれをフレンドリにし、ビジネス指向にするために、SawzallPigHiveなどなど、いろんなインタフェイスレイヤが作られた。しかし、SQL的な取っつきやすさを実現したそれらの抽象化レイヤは、重要な現実を忘れている… MapReduceは(したがってHadoopは)、大規模なデータ処理という目的のために作られたツールだ。言い換えるとそれは、ジョブないし“ワークフロー”をこなすことが仕事だ。

ジョブを走らせることなんかよりも、データの分析、クェリ、そして答を得ることに関心があるのだけど…。データを切り刻んで、何かが分かることに関心があるんだよ、こっちは。

そのニーズを一言で言うなら、“アドホックな探査(ad hoc exploration)”だ。データはすでに処理されている。しかし、知りたいことがあるたびに、また新たにジョブを作って動かすのか? 質問をするたびに、長時間待たされるのか?

ワークフローをベースとする方法の対極にあるのが、企業が使うBIや分析クェリだ。それらは本質的にアドホックであり、対話的であり、待ち時間のない分析だ。多くのビジネスアナリストにとって、MapReduceのワークフローを書くことは禁じ手であり、ジョブの開始を数分待ち、ワークフローの完了を数時間待つことは、データの対話的体験につながらない。データを自由自在に比較対照し、ズームインし、ズームアウトして、(うちの会社の動向等について)新しい発見をすることには、つながらないのだ。

一部のデータサイエンティストたちはDrillとDremelのほうがHadoopよりも良い、とすら考えている。リプレースしてもよい、と。それは少々極端な見方かもしれないが、しかしクェリ指向で低遅延の分析方法には、大きなメリットがある。

Infochimpsで私たちは、高度なデータ探査のためのツールとして、全文検索エンジンでデータベースでもあるElasticsearchを気に入っているが、日常の本当に有能なビッグデータクェリのためには、Drillがデファクトのソリューションになるだろう。〔参考: Dremelオープンソース実装Cloudera Impala、その評価記事。〕

R

Rはオープンソースの統計分析用のプログラミング言語だ。きわめて強力で、200万人以上のアナリストが使っている。誕生は、1997年と比較的若い。その前には、Bell Labs(ベル研)が作ったSという統計コンピューティング用の言語があった。それの現代バージョンであるRは、急速に、統計分析の新たなスタンダードになりつつある。

Rは複雑なデータ分析をかなり低コストで行う(お金の面でもそのほかの面でも)。Rには、SASやSPSSを王座から引きずり下ろす勢いがあり、世界最高峰の統計専門家たち(やデータサイエンティスト、アナリスト)も、今ではもっぱらRを使うようになっている。

なぜそれが重要か?
===ビッグデータ分析の成熟したコミュニティ===

Rのまわりには強力なコミュニティがあり、何かやりたいことがあると、ほとんど必ず、それはRのライブラリにすでにある。つまり、ありとあらゆる種類のデータ分析を、コードを一行も書かずにできる。Rはメンテしている人たちが優秀で、イノベーションの量と頻度も高い。今のビッグデータの世界においてRは、もっとも心ワクワクする場所の一つだ。

Rは、あなたのビッグデータプログラムの長寿命(非陳腐化)を保証する方法としても優れている。このわずか数か月間でも、文字どおり何千もの新機能が導入され、また企業が必要とするどんなタイプの分析にとっても、誰もが利用できる知識ベースが充実している。古くならない。

また、RはHadoopとの相性がよいから、総合的なビッグデータ技術の一員として、理想的なメンバーだ。

もう一つの注目: Juliaは、Rに代わる今成長株の統計言語として関心をそそる。とくに、Rのインタープリタがとてつもなく遅いという問題に、挑戦している。コミュニティはまだ未熟だが、スピードがメインのニーズの方はご注目を。

GremlinとGiraph

GremlinGiraphは、グラフの分析を支援し、Neo4jInfiniteGraphなどのグラフデータベースと併用されることが多い。Giraphの場合は、Hadoopとも併用される。今伸びているグラフベースの高度なプロジェクトとしては、Golden Orbがある。

グラフデータベースは、今日の最先端技術だ。とくに、関係データベースとの違いがおもしろく、そのため、最初からグラフで行ったほうが良いタイプの問題もある。

グラフベースのアプローチに近いものとして、GoogleのPregelがある。GremlinとGiraphは、いわばそのオープンソース版だ。というか、Hadoopが典型的にそうであるように、Googleの技術の物真似が、それ自体別途、‘家内工業’になっているのだ(そのことについて、こんな優れた記事がある)。

なぜそれが重要か?
===ビッグデータのグラフ分析は明日の必殺トレンド===

グラフは、コンピュータネットワークやソーシャルネットワークなどをうまくモデリングする。要するに、複数のデータが互いにリンクしあっている構造なら何でも。また地図や道路交通計画でも、グラフ理論はよく使われる。たとえば、AからBまでの最短経路を求めるとか。ソーシャルネットワークの場合には、AさんとBさんのあいだの、関係の近さを分析したりするだろう。

グラフはバイオや物理学方面でもよく利用される。たとえば、分子の構造の分析など。

大局的に見ると、グラフデータベースとその分析言語とフレームワークは、ビッグデータが、たった一つのデータベースやプログラミング言語で何かを成し遂げるものではない、という理解の萌芽あるいは浸透を表している。データや実体(‘人’など)のノードがたくさんあって、それらが複雑なネットワーク状に関係している場合、そしてしかもそれらのあいだにさまざまな経路が存在する場合、グラフを用いるソリューションはいわば、キラーアプリケーションだ。

つねにイノベーションを志向している科学者や技術者は、それぞれの仕事に最適のツールを使おうとする。そうやって、あらゆる要素が互いに関連したり対話したりする状態を見つけたり作ったりするのだ。その場合、要素間の関係を表現し記述するための‘糊’の技術が、もっとも重要になってくる。

SAP Hana

SAP Hana*はインメモリの分析プラットホームで、インメモリのデータベースと一連のツールと、正しい形式で分析プロセスを作ったりデータを出し入れするソフトウェアが含まれる。〔*: Hanaはオープンソースプロジェクトではない。関連記事。〕

なぜそれが重要か?
===ビッグデータ処理をインメモリで超高速化===

SAPは伝統的に、エンタプライズソフトウェアの超大手だが、そこがHanaのようなデベロッパが無料で利用できる製品を提供するのはめずらしい。それだけでなく、SAPはスタートアップたちがHanaを採用するよう、熱心に働きかけている。同社は本気でコミュニティ育成に取り組み、そのおかげでデベロッパ界隈ではHanaは好印象を持たれるようになっている。

Hanaは(インメモリなので)、金融財務のモデリングや意思決定サポートなど、スピードが重視されるビッグデータアプリケーションに向いている。そのほか、Webサイトの個人化、詐欺行為の発見なども、大量のデータを高速で処理しなければならない分野だ。

ただしもちろん、Hanaのような大規模データを扱うインメモリ技術は、ふつうにハードディスクを利用するアプリケーションに比べて高くつく。

でも、費用がいくら高くてもスピードが肝心、というニーズにおいては、Hanaがうってつけだろう。

選外佳作: D3

===JavaScriptのデータ視覚化ライブラリ===

D3は今回のリストに入らないのだが、ご紹介しておく価値はある。

D3は、ドキュメントを視覚化するためのJavaScriptライブラリであり、情報をクリエイティブに視覚化し対話的にするための強力な技術としては、革命的だ(Webクライアント上で実現、という意味で)。それは、The New York Timesでグラフィックエディタ(図版担当編集者)をやっているMichael Bostockの、仕事上のニーズから生まれた。

たとえばHTMLでいちいちTABLEを書かなくても、D3のコードで数列から表を生成できる。また同じデータから、対話的なバーチャート(棒グラフ)を作って、その遷移や対話的アクションをスムーズに行うこともできる。

D3の作例が、ここにある。これはオバマ大統領の2013年の予算案を視覚化し、個別データ表示のナビゲーションもできるようにしている。

プログラマは、D3を使ってゴージャスなダッシュボードを作れる。企業は、規模の大小を問わず、D3で優れた視覚化プラットホームを作れる。去年まで使っていたアラートなんかより、ずっとましな。


編集者注記: Tim GasperはInfochimpsのプロダクトマネージャだ。同社は、ビッグデータのためのクラウドプラットホームとしてベスト、と評価されている。彼は、マーケティングと製品開発と顧客発見を担当している。その前の彼はKeepstreamの協同ファウンダでCMO、同社はソーシャルメディアの加工・編纂・分析をやっていたが、2010年の夏にInfochimpsが買収した。Twitterで彼をフォローしたい人は、ここへ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))