―――「技術者でなくても使いやすい」「すぐにデータ分析が始められる」「さまざまなデータソースに対応できる」というのがSparkのメリットである一方で、エンタープライズで導入する課題はどのようなものでしょうか。
下田氏 Sparkの利用実績があるお客さまはまだまだ少なく、現在、公開されている事例のほとんどは、「B to CのWeb系の企業がトライアル的にHadoopで扱っていたデータをSparkで処理してどうなったか」というものです。「現実的に、どこまでミッションクリティカルな課題を解決できるか」については、国内の事例はほとんどなく、本格導入までに至っている企業も少ないのが現状だと思います。
Sparkの使い勝手自体にはあまりネガティブなところはありませんが、あえて言えば、機械学習のアルゴリズムがまだそろっておらず、今後使えるようになってくることが期待されます。
土屋氏 今のSparkを取り巻く環境は、Hadoopが出てきたころに似ていると思います。今は、「Sparkを使って、どのような領域で何ができるか」を試行錯誤している段階で、下田さんが言われるように、「Webのログを分析するケースが多い」という印象はありますね。一方で、エンタープライズIoTでセンサーログを集めて分析し、活用する事例も着実に増えてきていることは確かだと思います。
―――事例が少ないために、用途が分かりづらいということでしょうか。
土屋氏 用途が分かりづらいのではなく、企業は「どのような使い方をすれば一番よいのか」「どういった分析に適しているのか」を知りたいのだと思います。
下田氏 「IoTで集めたデータを可視化できるとうれしい」にとどまっているケースが多く、これであれば、Hadoopでもほとんどのニーズを満たすことができてしまいます。インタラクティブな分析や高速な処理といったSparkのポテンシャルを生かすビジネスアイデアが出ていないケースが多いのが実感です。
土屋氏 海外では、製造業やWeb、流通などでの先行事例が出始めているので、日本のお客さまに対して海外の成功事例をお話しするケースが多いですね。日本よりも欧米の方が、使い方が分かっていて、「使い始めれば思いっ切り使う」という印象があります。
下田氏 日米の文化の違いだと思いますが、使うときのアクセルの踏み方はすごいです。日本では、「ちょっと使ってみよう」と思っても、「やっぱりメリットがないからHadoopでいい」となってしまうケースがまだまだ多いように感じています。
また欧米では、データ分析が速くなれば、「ビジネスオペレーションも改善しよう」という流れができやすいように思います。一方、日本では「ビジネスオペレーションに課題があるからフィットする分析技術を選ぼう」とします。Sparkのポテンシャルを生かすように現状のビジネスオペレーションを一気に変える意思決定ができないケースが多く、まだまだ「日本では分析技術の発展にビジネスオペレーションが追いついていない」と感じています。
土屋氏 日本と欧米の最大の違いは、取り組み方と規模感ですね。日本では、リサーチやトライアルの範囲でSparkを使っていますが、企業で大々的に活用するケースはあまりありません。やはり、最初に明確な費用対効果が求められることが、その要因の一つとなっているのではないでしょうか。
―――技術者以外の分析者が扱いやすいものとしてセルフBIがありますが、セルフBIとSparkの違いを教えてください。
土屋氏 セルフBIは、どちらかというとデータを可視化する意味が大きいと思います。Sparkは、これまでやってきたバッチ処理を行ったり、機械学習的に分析を行ったりするという点がセルフBIとは異なります。
下田氏 例えば、携帯電話でインターネットができたり、PCが小さくなってタブレットになったりするなど、アプローチが違っていても目指しているところが近い場合と同じようなことが、データ分析を取り巻く環境でも起きているように感じます。
当社でも取り扱っているセルフBIのTableauは、分析機能を高めていくことで、可視化のツールから分析のプラットフォームになろうとしています。一方で、Sparkも将来的には、結果のビジュアライズが行える機能が出てくるでしょう。順番が違うだけで、目指しているものは同じになるのではないか、と個人的には考えています。
―――機械学習という面で、Sparkはどのようなメリットがありますか。
下田氏 機械学習では、必ずループをぐるぐる回すようなイテレーション(繰り返し)処理が発生します。このような処理では、「データをどのように効率的に保持して処理するか」が課題です。HadoopにもApache Mahoutという機械学習のライブラリがありましたが、Hadoopでイテレーションを実現するためには、多段のMapReduce処理を重ねる必要があり、結果として処理が遅くなるなど、多くの課題がありました。
Sparkの機械学習ライブラリ「MLlib」は、メモリ上でデータを保持するなど、イテレーション処理に適した設計になっていることがポイントです。小さなデータであれば、Pythonの「scikit-learn」やR言語で機械学習のニーズを満たせますが、大規模データで機械学習をしっかりやろうとするのであれば、Sparkは大きな選択肢になると思います。
―――オープンソースソフトウエア(OSS)は、「コスト削減や自由に扱えるというメリットがある」と言われていますが、Sparkはどうなのでしょうか。
土屋氏 OSSを使って内製化できるお客さまは、Sparkにも取り組んでいることが多いと思います。エンタープライズの領域で、Sparkに限らず「OSSを使いたい」という企業は多いですが、やはり、自分たちで扱うには手に余ってしまうケースも多いですね。「単に安くてさまざまなことができるだけではなく、分析やインフラのスキルが必要である」ことをしっかりと認識しているかどうかが重要だと思います。
下田氏 Sparkを導入するには、クラスターを構築する必要があるため、インフラの知識は必須ですし、大規模データを処理する際にデータの特性によってチューニングするポイントが変わってくるところも課題です。Sparkの特性を生かせるチューニングにする必要があります。
オンプレミスやプライベートクラウドではなく、as a ServiceでSparkを提供しているサービスも多くなっているので、インフラの課題はある程度解決できるかもしれませんが、チューニングについては、ある程度の知見がないと、「やってみたけどパフォーマンスに課題が残る」ケースが起こり得ます。
ただしSparkの場合は、「自分たちの独自のものを使う」ケースはあまりなく、「自分たちに必要なものを作ったらコミュニティやプロダクトに還元していく」という流れができています。Hadoopから続くコミュニティ作りが非常にうまくいっているので、クラウドベンダーやディストリビューターとうまく付き合っていくことが重要だと思います。
土屋氏 IBMもSparkを取り扱っていますが、独自テクノロジではなく100%OSSですし、コミュニティを介して改善などを行うことを基本的な考え方としています。あくまでも独自路線ではなく、中立的な立場でエコシステムを作っています。
Copyright © ITmedia, Inc. All Rights Reserved.