MapR StreamsはIoTで生まれる膨大なデータを扱うためのワールドワイド対応の仕組み
Q：MapR Streamsでは具体的にどんなことができるのでしょうか？
スリバス：MapR Streamsは、毎秒何十億ものデータを取得できる仕組みです。得られるデータは100％信頼できるものになります。データソースは何億あってもかまいません。たとえば、何百万のデータソースがあっても、5ミリ秒程度でデータを受け取ることができます。
Streamsの仕組みは、ワールドワイドな接続環境にも対応します。数多くのクラスターに対応し、ソースとなるようなミニチュア・データセンターは何十万とあってもかまいません。ここで言うミニチュア・データセンターは、たとえばクルマやトラックなど大量なデータが発生するもののことです。
Q：今では他社からもストリームデータを処理する仕組みやIoT対応と言われる製品が出ています。MapR Streamsはそれらとどんなところが違うのでしょうか？
スリバス：もっとも違うのは、毎秒何十億ものデータを処理できることです。そしてデータを受け取るクラスターがたとえば10万あってもいい。それらがワールドワイドに展開していてもデータを受け取ることができます。これができるのはMapR Streamsだけだと考えています。さらにHadoopデータベース、Spark、ストレージなどと連携した1つのプラットフォームになっているのもMapR Streamsだけです。1つのプラットフォームになっているのでファイルシステムのデータも、データベースにあるデータも、IoTから得られるストリームデータでも、SQLのクエリーを使って統合的に取得できます。
Q：他社のものより優れていると言いますが、現時点でMapR Streamsに弱点や足りないところはないのですか？
スリバス：もちろんまだ弱いところ、改善すべきポイントはたくさんあるでしょう。メッセージブローカーの技術に関しては先人が前を走っているので、それを辿っていくところもあります。また、将来的には、私たちの製品よりも優れている技術も出てくるかもしれません。とはいえ今は、MapRは市場にベストな製品を提供できていると考えています。弱点もありますが、それが顕在化して製品の弱味となるようなものではありません。
今後拡張したいポイントとしては、セキュリティがあります。そのためのプロジェクトである「Cheyenne（ネイティブアメリカンのシャイアン族の名前）」はすでに動き始めています。これは次世代のセキュリティ基盤となるもので、100％オープンソースとして開発しています。セキュリティのあり方、実行の仕方を変えるようなものです。
Cheyenneは、StreamsだけでなくMapRの製品全体に関わるものでもあります。その他にもSparkやImpala、Dockerコンテナベース、ワークフローなどにも関わるでしょう。
StreamsとSparkはIoT時代に極めて重要な補完関係となる
Q：ここ最近、Hadoop周辺ではSparkに話題が集まっています。MapR StreamsとSparkの関係性はどのようなものになりますか？
スリバス：この2つは、もっとも高いレベルで連携するものです。Streamsはデータのトランスポーティングの役割を担います。それで集められた多量なデータを処理するのがSparkの役割です。これら2つは、IoTの時代に極めて重要な補完関係を築くものになります。
Q：メッセージブローカー的な機能としては、Apache Kafkaがあります。MapR StreamsではKafkaを取り込むのではなくKafka互換のAPIを持っているとのことですが、なぜAPI互換だけなのですか？
スリバス：StreamsをKafkaベースにしなかったのは、自分たちでフルに統合化できるものにしたかったからです。つまり、MapRの1つのプラットフォーム上で動くようにしたかったのです。Kafkaベースの仕組みにしていまうと、メッセージブローカーのためにもう1つ別のクラスターを構成しなければなりません。ユーザーは、管理すべきクラスターが増えることを望んでいません。
それと、Kafkaはシングルクラスターベースの仕組みです。これではワールドワイドに展開することは難しいというのもあります。グローバル展開するようなIoTの用途では、Kafkaだと限定的なものになると判断したのです。
一方でKafkaのAPIを選んだのは、Kafkaがすでにユーザーに使われているからです。すでに使っている人がいるのならば、彼らがそのまま使えるようにしたほうがいいでしょう。もちろんMapR StreamsはKafkaから学んだ部分もあります。MapR Streamsをいかに効率的にするかといったところは、Kafkaから学んでいます。
