Hadoopにすればビッグデータ活用の課題をすべて克服できるわけではない
ビッグデータの活用では非構造化データを大量に蓄積する必要があり、それをリレーショナルデータベースに入れるのは得策ではないのでHadoopなどを利用する。これはいまやビッグデータ・ソリューションの定番になりつつある流れだ。拡張性の高い分散ファイルシステムのHadoopは、増え続けるデータを格納するのに向いている。とはいえHadoopに入れれば、それで問題がすべて解決するわけではない。
ビッグデータ活用はインサイト・エコノミーの時代になっている、と言うのは日本IBM 理事 IBMアナリティクス事業部長の三浦美穂氏だ。インサイト・エコノミーでは収集した大量データを分析可能な品質に素早くまとめ上げ、素早く分析する必要がある。そうすることでタイムリーな行動に結び付くから。増え続けるデータに対し、こういった環境を提供し続けるのはじつは容易ではない。
溜め込んだデータに対して時間をかけ整理し、分析するアルゴリズムも時間をかけて構築する。その分析アルゴリズムを使って、数年に渡り収集データの分析を行う。この方法は別に間違いではない。変化のない世界であれば、これでも成果を得られるだろう。しかし、顧客の嗜好の変化も激しく、提供する製品やサービスもどんどん変化するインサイト・エコノミーの時代では、このスピード感では意味をなさない。
「大量データをスピーディに分析し、なるべくリアルタイムなアクションに結び付ける。さらに、データサイエンティストがやるようなアナリティクスのアルゴリズム開発をする人には、より柔軟なプラットフォームが必要です」(三浦氏)
そんな要求の中、オープンなテクノロジーとしてHadoopは生まれた。Hadoopは大量データを処理するのはたしかに得意だ。しかしながら限界もある。その1つが開発者には使い難いことだ。Map Reduceを使いこなせる技術者は簡単には育成できず、多くのHadoopディストリビューションで結局は使い慣れたSQLインターフェイスを実装するに至っている。
さらに、Hadoopが基本的にはバッチ処理重視の仕組みだったことも、リアルタイム分析を求めるインサイト・エコノミー時代にはそぐわない。結果的に莫大なデータを扱うとなると、Hadoopには分散システムによる拡張性があるとはいえ、ディスクIO部分がボトルネックになることも課題だった。そんなときに登場したのが、Apache Sparkという新しい仕組みだ。
「Hadoopの課題を解決するために出てきた技術がSparkです。SparkはHadoopを置き換えるものではなく、補完するものです」(三浦氏)
Apache Sparkは、ビッグデータの処理を分散クラスター上で高速に実行する。その際、Hadoopのようにファイルシステムにアクセスするのではなく、分散インメモリを使うので高速で低遅延の分析処理が可能となるのだ。さらに、SQLインターフェイスを持ち機械学習、グラフ処理、ストリーム処理などの最近のビッグデータ活用でよく登場する分析アルゴリズムをライブラリーで用意している。これらがあれば、すぐにデータサイエンティストによる独自の分析アルゴリズムの開発も可能だろう。