HadoopTimes

ストリーミングアーキテクチャ Apache Kafka とMapR Streams による新しい設計手法
最新動向

Apache Spark、Kafka、Drill、その他 2016年の予想

さあ楽しいことをしよう。

新しい年の始まり―私たちは何か新しいことの入り口に立っている。だから、2016年にやることを楽しみにしようではありませんか。もちろん、予測を立てることのリスクは承知している、特に記録に関することは。しかし、何ならまた今から1年後に戻ってきて私の2016の予測が当たっていたか確認してみたって構わない。

2016年に何をやるか?

2016年の予測をする前に、まず未来がどんなものになるかを推測するというチャレンジについて一般的に(そして冗談交じりに)考えてみたい。データとモデルから予想するか?それとも観察と直感で予想するだろうか?覚えておかなければいけないのは、未来の描写が正確かどうかは、ターゲットがどれくらい先の未来にあるかということに依存する。

人々の生活がどうなっているかについて未来をぼんやりと予想するのはよくある。当たっていることもあるけれど、面白いぐらい間違っていることが多いものだ。未来がどうなっていると考えられるかを振り返ることは、私が「未来を思い出すこと」と呼んでいるエンターテイメントなのだ。

例えば、2000年はという年は人々の想像力を長い間捉え続けた。私は1900年に出版された レディーズ・ホーム・ジャーナル(Ladies Home Journal) 掲載のエッセイを見たことがある。概ね正しい予測だったのは、新聞紙が1時間以内に印刷できるようになること、アメリカの人口が準州を含めて3億5千万人を突破するだろうということだ(2000年の国勢調査によるとアメリカの人口は2億8200万人なので、少し足りない)。不正確な予測としては、ハエや蚊が全くいないこと、都市の交通が地下鉄か高架線になって、都市は「騒音知らず」になること、CやXまたはQの文字の使用を止めてしまうことだ。

未来がここで描かれたようにはならなかったのは、私達が同じ問題を予想された同じ方法で解決するわけではないからでもある。現在の都市間の交通は高速道路が利用されているけれど、騒音は取り除かれているわけではない。そして特定の子音の「解雇」によって綴りが標準化される代わりに、私達は自動の綴り修正システムに頼っている(時には笑ってしまうような結果を伴うものだ)。

ビッグデータに話を戻そう

「未来を思い出すこと」というアイデアは、Strata Hadoop ワールドカンファレンスのビッグデータ・シンガポール会合で、ビッグデータトレンドの現在と未来について、テッド・ダニングが行ったプレゼンテーションのテーマだった。また、ビッグデータ・システムは将来どこへ向かうのかという考えに触れていたのは、もう一人のプレゼンターであるHadoopの創設者のダグ・カッティングだ。

テッド・ダニング(左)とダグ・カッティング(右) 2015年12月のビッグデータ・シンガポール会合での「等しい身長」の話者たち。聴衆の笑いを誘った。 (image © E.Friedman)

テッド・ダニング(左)とダグ・カッティング(右)
2015年12月のビッグデータ・シンガポール会合での「等しい身長」の話者たち。聴衆の笑いを誘った。
(image © E.Friedman)

ダグはHadoopエコシステムの進化について、特に解析に着目して話した。バッチベースでの計算は多くの場合、インメモリー・マイクロバッチの計算能力に取って代わられる。なぜなら Apache Sparkに大きな関心が高まりつつあるからだ。

テッドは成功した進歩的なビッグデータのプロジェクトについて話す前に、まず文化的トレンドが予想したようにはならなかったことを話して聴衆を笑わせた。彼のビッグデータプロジェクトは、海と風のデータを上手く使って航海用にナビゲーション表を作成した19世紀からのオープンソース・プロジェクトだ。現在では、テッドは実際的な価値を伝えるような機械学習プロジェクトの単純化に向かう現在のビッグデータのトレンドについて説明した。また、彼は数百もの表を作成しなければならなくなる(従来のリレーショナルシステムについてもそうだ)のを避けるために、複雑なデータを扱えるもっと合理化された方法が必要だとも語り、こうした状況でSQLエンジンの Apache Drillの柔軟性を活用することの優位性を示した。

2016年6つの予想

ビッグデータのトレンドについて説明した他の人々に触発されたので、私も2016年に皆さんが何をしているかについて予想(純粋なる意見)を立てるという危険に身をさらしてみようではないか。

ストリーミングデータ

私は皆さんが2016年を通じて ストリーミングデータとストリーミング解析に対してす爆発的に関心を持つだろう確信している。ストリーミングデータは以前よりももっと多くの組織で、新しいやり方で使われるようになる。IoT センサーデータの増加するボリュームはストリーミングデータのソースの1つにすぎない。ウェブトラフィックからのクリックストリームデータや、マシンログファイルなど一連の事は、Apache Sparkでのリアルタイムに近い処理やさらに新しいツール Apache Flinkでの本当のリアルタイム分析を利用してストリームとしてもっと分析されるだろう。

大きなシフトのうちの一つは、これらのアプリケーションを最適にサポートするアーキテクチャについて異なる考え方になるだろう。メッセージキューがこれらのシステムの設計で中心的に強化される。メッセージングレイヤは、ストリーミングのワークフローにおいて解析プログラムの単なる安全なバッファー以上のものになる。正しく行われれば、メッセージキューは、リアルタイム解析アプリケーションやデータベースス、ドキュメント検索など複数のことに役立つ、再生可能で不変の永続的なログになる。これらの理由から、すでに人気のメッセージングツールApache Kafkaが、Kafka APIをサポートする相互的メッセージング技術として強い関心を持たれている新しい MapR Streamsと共に利用が増大すると私は予想する。

価値を創出するまでの時間の短縮

ビジネスが短期間で価値を得る実用的な方法を欲しているならば、 あなたのビジネスはSQLを必要とする。したがって2016年中にApache Drill を使うことになる可能性は高い。より頻繁なリリースによって、Drillの機能は拡張され続ける。Drillは高性能で拡張性があり、スタンダードなSQLを使用する非常に柔軟性の高いクエリエンジンだ。このことは、従来のバックグラウンドからビッグデータに来た人々にも、JSONやParquet など非構造化データやネスト化したデータタイプを簡単に手広く扱えるクエリエンジンが欲しいHadoopやNoSQL界のベテランにも、同じように魅力的に映るはずだ。

恐らく、試してみたいと思わせるDrillの特徴は、ほとんど、あるいは全く準備なしにデータの問い合わせを行える能力だろう。このためにデータから分析するのにかかる時間が数時間から数日短縮することが可能だ。クエリを始める前に時間がかからなくなるので、Drillでは最初のクエリで学んだことをもとに二回目のクエリを素早く行うことができる。より早い進行、より早い分析、価値を創出するまでのより短い時間というわけだ。

Apache Drillはしばしば、クエリをスタートさせる前に必要な段階を減らしてデータを直接扱うことができる。この柔軟性によりタイム・トゥ・バリュー(価値を創出するまでの時間)を大きく改善する。 (image © E.Friedman)

Apache Drillはしばしば、クエリをスタートさせる前に必要な段階を減らしてデータを直接扱うことができる。この柔軟性によりタイム・トゥ・バリュー(価値を創出するまでの時間)を大きく改善する。
(image © E.Friedman)

集中化

ますます多くの人がビッグデータのプラットフォームを特別な目的のプロジェクトというよりも組織全体の中心として考えるようになるだろう。 ビッグデータプラットフォーム には Hadoop やNoSQLベースのシステム などがあるが、これらのプラットフォームは企業のデータウェアハウス、リレーショナル・データベース、BIツールなどの従来の技術に簡単に接続できるようにする必要があるだろう。

グローバル企業にとって集中化の逆説的な面とは、データを世界中に配布する必要があることだ。あなたの会社の様々な部署から統合データセットにアクセスする必要がある。地理的に隔たりがあるセンターの内部あるいはそのセンター間で他部門と連携を取り合わない仕事のやり方を打ち破るとき、伝搬の遅れは避けたいだろう。データのローカライズが必要な法的問題があるかもしれない。これらの理由から、素早く同期することが可能な複合的データセンターを安全で信頼性のある方法によって維持するシステムを多くの企業が欲しがるだろうと予想する。

特別トピック:医療

医療産業 におけるビッグデータに利用は、2016年で急速な拡大の様相をみせていると私は考えている。不正を減らし、医療提供を向上させるために患者の電子病歴データ、機械の長期的なメンテナンス記録、センサー情報の流れなど、データを利用することの力を人々は認識しはじめている。データ機密保護と管理に優れていることはこうした 利用事例にはもちろん重要だ。

特別トピック:遠隔通信

2016年のビッグデータスペースでますます存在感を示しているもう一つのエリアが 遠隔通信だ。遠隔通信だ。通信会社はすでにETLの負担をHadoopに移すというビッグデータの優れた使用事例を持っているが、一方で企業の商品管理所で携帯電話の各基地局のデータ異常を検出したり、突然の使用率の移り変わりに迅速に対応して複雑な請求管理を行っている。またリアルタイム解析を採用し、通信が遮断された後に素早くユーザー対応をして利用体験の質を向上させ、顧客離れを防いでいる。

ストリーミングデータのアーキテクチャや(前述のような)技術を拡大することは、遠隔通信にとって利益になる。しかし、あなた自身が遠隔通信で仕事をしていないとしても、この特別な事例はあなたに影響があるかもしれない。より多くの、電話以外のアプリケーションが通信ネットワークを利用している。例えば車のセンサーは、頻繁に遠隔通信ネットワークを経由してデータを送る。これらすべてを考慮し、あなたが2016年にビッグデータを高度な遠隔通信と結び付けている可能性が高いと私は予想する。

最高の予想:あなたが私にサプライズを与える

さて、2016年の私に最高の予想というのは、あなたが、私が思いも及ばなかったようなビッグデータの革新的な利用方法を思いつくということだ。多分、それは私がすでに気付いている問題かもしれないが、それを今までにないやり方で解決するのだ。あるいは、全く新しい何かかもしれない。いずれにしても、2017年の1月までに私はすでに見た「未来を思い出す」だろう。そして何か新しいことに驚くだろうが、もしかしたら上記の5つの予想が大当たりだったりするかもしれない。

著者情報

エレン·フリードマン
(MapR Technologies ビッグデータ・コンサルタント Apache Mahoutコミッター)

導入事例:メディカル・データ・ビジョン株式会社

導入事例:メディカル・データ・ビジョン株式会社
社名に“豊富な実証データに基づいた医療の実現”という意味がこめられたメディカル・データ・ビジョン株式会社は、2003年の創業以来、膨大に蓄積された医療・健康情報を有効活用することが、医療の質向上、ひいては生活者にとってのメリット創出につながると考え、医療データの収集と利活用を中心に事業を展開しています。同社では、蓄積した医療ビッグデータの基盤として安定的かつ高性能、将来を見越した拡張性を備えたMapRを採用しました。

こちらの資料では、同社の課題である、

  • データ量の増大による拡張性

  • データ量の増大によるパフォーマンス問題

  • 様々なデータフォーマットに対応する基盤の必要性


を、MapRを導入することでどのように解決したのかをお話いただきました。

無料ダウンロードはこちら