ビッグデータのリアルタイム処理にまつわる技術分野では、イノベーションが進んでいるものの、リアクティブ運動を提唱している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つの独立したデータ処理パイプラインをメンテナンスし、最後にデータをマージするという、本来ならば必要のない複雑さももたらされました。
