編集部からのお知らせ
解説集:台頭するロボット市場のいま
解説集:データ活用で考えるデータの選び方
海外コメンタリー

ビッグデータの今後とストリーミング--AkkaプロジェクトのJ・ボナー氏に聞く

Matt Asay (Special to TechRepublic) 翻訳校正: 村上雅章 野崎裕子

2015-07-14 06:30

 ビッグデータのリアルタイム処理にまつわる技術分野では、イノベーションが進んでいるものの、リアクティブ運動を提唱しているJonas Bonér氏によるとそれによって問題も生み出されているという。


 ビッグデータのあるところ、激しい競争がある。

 ビッグデータのアーキテクチャが進歩するなか、ビッグデータ「スタック」のレイヤすべてでベンダー同士による激しいシェアの奪い合いが起こっている。そして現在、最も激しい戦いが繰り広げられているのは、バックエンドへのデータ移送と、システム間のロジックというレイヤだろう。多くのベンダーにとって、「ビッグデータ」という言葉における「ビッグ」は、データの全体量を指しているではなく、リアルタイムでのデータのやり取りにおけるスループットを指すものとなっている。

 そしてこのことは、企業がバッチ処理からストリーミング処理に目を向けつつある現状と相まって、「MapReduce」から「Apache Spark」へのシフトを引き起こしている。

 筆者はストリーミング処理の進化を促している最新テクノロジのトレンドを理解するために、分散コンピューティングの専門家であり、Typesafeの共同創業者兼最高技術責任者(CTO)、そしてAkkaプロジェクトの創始者であり、「リアクティブ宣言」の共同提唱者でもあるJonas Bonér氏に話を聞いた。

——データをシャッフルするようなバックエンドシステムでは、現在どのような変化が進行しているのでしょうか?

 基本的な変化は、「Data at Rest」(アーカイブ目的等で保存されている、保存場所は固定であるがすぐに使えないデータ)から「Data in Motion」(特定の保存場所は持たないが、すぐに移送でき、使用可能な状態にあるデータ)へのシフトです。今までオフラインだったデータが、今ではオンラインになっているのです。

 ビッグデータにおける最初の波が押し寄せた時、取り扱われるデータはまだ「Data at Rest」でした。大量のデータは「Hadoop Distributed File System」(HDFS)のようなファイルシステムに格納された後、一晩かけてバッチ形式で処理されるため、何時間ものレイテンシが発生する場合もしばしばありました。

 2つ目の波が押し寄せた時、「Data in Motion」に向けてリアルタイムで対処するというニーズが生まれました。つまり、リアルタイムで発生する生のデータを捕捉して処理した後、その結果を秒単位で、場合によっては1秒未満で稼働中のシステムにフィードバックすることがますます重要になってきたわけです。

 これにより、ラムダアーキテクチャのような、「スピードレイヤ」と「バッチレイヤ」という2つのレイヤを持ったハイブリッドアーキテクチャが登場しました。このようなアーキテクチャでは、「スピードレイヤ」内のリアルタイム処理の結果が、後で「バッチレイヤ」にマージされるようになっています。これで(少なくともサブセットの)データに迅速に対応する必要があるという、当面の問題が解決されたわけです。

 ただ、2つの独立したモデルと、2つの独立したデータ処理パイプラインをメンテナンスし、最後にデータをマージするという、本来ならば必要のない複雑さももたらされました。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

Special PR

特集

CIO

セキュリティ

スペシャル

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]