JP2023165932A - データ処理システム、データ処理方法、処理装置、およびプログラム - Google Patents

Abstract

【課題】ラムダアーキテクチャにおいて応答の高速化を図る。【解決手段】データ処理システムは、受信したデータをストリーム処理するとともに、データを蓄積後にバッチ処理するデータ処理システムであり、受信したデータに対してストリーム処理の一部の処理を実行する高速応答処理装置１１と、高速応答処理装置１１の処理結果を保持する高速応答処理結果提供装置１２と、高速応答処理装置１１の処理結果に対してストリーム処理の残りの処理を実行するリアルタイム処理装置２１と、受信したデータを蓄積するストレージ３１と、ストレージ３１に蓄積されたデータをバッチ処理するバッチ処理装置３２を備える。【選択図】図１

Description

本発明は、データ処理システム、データ処理方法、処理装置、およびプログラムに関する。

近年、Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）の普及とともに、身近にある様々な機器がインターネットにつながるようになってきた。クラウドサーバに配置されたアプリケーションとＩｏＴ端末が連携することで、ＩｏＴ端末の計算能力が非力であっても、データの解析や解析結果に応じた動作変更などシステム全体として複雑な処理が可能である。

ＩｏＴ端末の増加とともにクラウドサーバへ送信されるデータ量が増加しており、ネットワークコストの増加とクラウドサーバ上のアプリケーションへの負荷の増大が問題となっている。また、コネクテッドカーやＩｏＴ化された工場ロボットには、サーバからのより高速な応答が要求される。サーバと端末との物理的な距離が遠い場合、応答の高速化が困難であるという問題がある。

このような背景のもと、ネットワークの周辺部（エッジ）にサーバを配備し、このサーバ上にアプリケーションの一部を配置するエッジコンピューティングが注目されている。エッジコンピューティング環境を用いることで、クラウドサーバへ送信されるデータの削減および端末への応答の高速化を実現できる。例えば、ＩｏＴ端末が送信した情報を集約するアプリケーションの処理群（以下、ロジックと称する）をエッジサーバに配置することで、クラウドサーバへのデータ送信に要する通信量を削減できる。端末と頻繁に通信するロジックをエッジサーバに配置することで、アプリケーションの応答時間を短縮できる。

アプリケーションを複数のマシンで分散的に動作させるためには、アプリケーションを複数のロジックに分割して、各マシンに配置する必要がある（非特許文献１参照）。しかしながら、アプリケーションの分割・配置にあたっては、アプリケーションの動作環境やロジックの処理内容をふまえた設計が必要になるため、開発者にとって大きな負担となってしまうという問題がある。

一方で、ＩｏＴデータをはじめとするストリームデータをリアルタイムに処理するアプリケーションの構成として、ラムダアーキテクチャと呼ばれるモデルが知られている（非特許文献２，３参照）。ラムダアーキテクチャでは、非常に大規模なデータセットに対して、バッチ処理とストリーム処理を同時に行うことによって、細やかな処理結果と即時的な処理結果の両方を取得可能である。ラムダアーキテクチャは、いくつかのＩｏＴ向けの商用アプリケーションで使われている。ラムダアーキテクチャに基づいてアプリケーションを実装することにより、処理結果を問合せするユーザや端末は、一時的な処理結果をリアルタイムに取得しつつ、バッチ処理が終わり次第、精度の高い詳細な処理結果を取得できる。

Alex Reznik, et al., "Developing Software for Multi-Access Edge Computing,"ETSI White Paper, No. 20, Sept. 2017. Nathan Marz, "Dig Data Lambda Architecture,"インターネット〈 URL：http://www.databasetube.com/database/big-data-lambda-architecture/〉 Dutta, K. and Jayapal, M., "Big data analytics for real time systems,"Big data analytics seminar, pp.1-13, 2015.

エッジコンピューティング環境でラムダアーキテクチャに基づくアプリケーションを作る場合、単純には、エッジサーバでストリーム処理を実行することで応答時間を短縮できる。しかしながら、ラムダアーキテクチャでは、ストリーム処理の更なる高速化を想定していない。

処理結果を利用するユーザや端末側で、処理結果の精度低下等を許容できる場合、応答の更なる高速化が期待できる。しかし、ラムダアーキテクチャではストリーム処理の更なる高速化は想定されていないため、これを実現できる仕組みが必要となる。

本発明は、上記に鑑みてなされたものであり、ラムダアーキテクチャにおいて応答の高速化を図ることを目的とする。

本発明の一態様のデータ処理システムは、受信したデータをストリーム処理するとともに、前記受信したデータを蓄積後にバッチ処理するデータ処理システムであって、前記データに対して前記ストリーム処理のうちの第１の処理を実行し、処理結果を保持する第１処理装置と、前記第１処理装置の処理結果に対して前記ストリーム処理のうちの第２の処理を実行する第２処理装置と、前記受信したデータを蓄積するストレージと、前記ストレージに蓄積されたデータをバッチ処理するバッチ処理装置と、を備える。

本発明によれば、ラムダアーキテクチャにおいて応答の高速化を図ることができる。

図１は、本実施形態のデータ処理システムの概要を示す図である。 図２は、高速応答処理装置と高速応答処理結果提供装置の構成例を示す図である。 図３は、車載カメラ画像とＣＡＮデータに基づいて障害物を検出する実施例を説明するための図である。 図４は、エッジコンピューティング環境における各層の配置例を示す図である。 図５は、エッジコンピューティング環境における各層の別の配置例を示す図である。 図６は、高速応答処理装置および高速応答処理結果提供装置のハードウェア構成の一例を示す図である。

以下、本発明の実施形態について図面を用いて説明する。

図１を参照し、本実施形態のデータ処理システムについて説明する。同図に示すデータ処理システムは、高速応答処理層、リアルタイム処理層、バッチ処理層、および処理結果提供層で構成される。本実施形態のデータ処理システムでは、リアルタイム処理層の処理結果が出力されるまでの間に、処理結果の一部を参照できるように、新たに高速応答処理層を追加した。

センサなどの多数の端末のそれぞれから処理すべきデータが送信される。処理すべきデータは、バッチ処理装置と高速応答処理層の両方に送信される。バッチ処理層では、受信したデータを蓄積しておき、所定の間隔でデータをバッチ処理する。高速応答処理層とリアルタイム処理層は、受信したデータをストリーム処理する。

本実施形態では、リアルタイム処理層が実行するストリーム処理の一部を高速応答処理層での処理として分割する。具体的には、リアルタイム処理層内のデータフローに基づき、処理の順番が早い処理から順に高速応答処理層での処理として切り出す。上記の手順を繰り返し、高速応答処理層の合計処理時間が所定の閾値を超えないように高速応答処理層での処理を決定する。高速応答処理層では、リアルタイム処理層から分割された処理が実行されて、処理結果をリアルタイム処理層に送信するとともに、クライアントからの問い合わせに返信できるように保持しておく。リアルタイム処理層は、データと処理結果を引き継ぎ、ストリーム処理の残りの処理を実行する。

高速応答処理層は、高速応答処理装置１１と高速応答処理結果提供装置１２を含む。リアルタイム処理層は、リアルタイム処理装置２１とリアルタイム処理結果提供装置２２を含む。バッチ処理層は、ストレージ３１とバッチ処理装置３２を含む。処理結果提供層は、バッチ処理結果提供装置３３を含む。以下、データ処理システムの備える各装置について説明する。

高速応答処理装置１１は、データを受信し、リアルタイム処理装置２１の前段においてデータを処理する。高速応答処理装置１１は、処理結果（以下、高速応答処理結果と称する）をリアルタイム処理装置２１と高速応答処理結果提供装置１２に送信する。

高速応答処理結果提供装置１２は、高速応答処理装置１１から受信した高速応答処理結果を保持し、クライアントからの問い合わせに応じて高速応答処理結果を返信する。

リアルタイム処理装置２１は、高速応答処理結果に基づいてデータを処理し、処理結果（以下、リアルタイム処理結果と称する）をリアルタイム処理結果提供装置２２に送信する。リアルタイム処理装置２１は、リアルタイム処理結果を高速応答処理結果提供装置１２に送信してもよい。高速応答処理結果提供装置１２は、リアルタイム処理結果を受信すると、リアルタイム処理結果に基づいて高速応答処理結果を修正する。

リアルタイム処理結果提供装置２２は、リアルタイム処理結果を保持し、クライアントからの問い合わせに応じてリアルタイム処理結果を返信する。

ストレージ３１は、処理対象の全データを保持する。バッチ処理層では、データを受信すると、ストレージ３１に格納する。

バッチ処理装置３２は、所定のタイミングで、ストレージ３１の保持する全データを処理し、処理結果（以下、バッチ処理結果と称する）をバッチ処理結果提供装置３３に送信する。

バッチ処理結果提供装置３３は、バッチ処理結果を保持し、クライアントからの問い合わせに応じてバッチ処理結果を返信する。

図２を参照し、高速応答処理層に含まれる高速応答処理装置１１と高速応答処理結果提供装置１２について説明する。図２に示す高速応答処理装置１１は、受信部１１１、処理部１１２、および送信部１１３を備える。高速応答処理結果提供装置１２は、修正部１２１、記憶部１２２、および応答部１２３を備える。

受信部１１１は、データを受信する。このデータは、バッチ処理層にも送信される。

処理部１１２は、受信したデータを処理し、高速応答処理結果を得る。この処理は、データからリアルタイム処理結果を得るまでの処理の一部であって、所定の時間内で完了する処理である。

送信部１１３は、高速応答処理結果をリアルタイム処理層と高速応答処理結果提供装置１２へ送信する。

記憶部１２２は、高速応答処理装置１１から受信した高速応答処理結果を格納する。

応答部１２３は、クライアントからの問い合わせに応じて記憶部１２２に格納された高速応答処理結果を返信する。

修正部１２１は、リアルタイム処理層からリアルタイム処理結果を受信し、バッチ処理層からバッチ処理結果を受信して、記憶部１２２に格納された高速応答処理結果を修正する。例えば、修正部１２１が、リアルタイム処理層からリアルタイム処理結果を受信した場合、リアルタイム処理結果に対応する高速応答処理結果を記憶部１２２から削除する。あるいは、修正部１２１は、高速応答処理結果を破棄してリアルタイム処理結果を保持してもよい。

図３を参照し、本実施形態のデータ処理システムを用いて、車両の送信する車載カメラ画像およびＣｏｎｔｒｏｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ）データに基づいて障害物を検出する実施例について説明する。

従来のラムダアーキテクチャのシステムを用いた場合、バッチ処理層では、車両から受信したデータを蓄積しておき、複数の車両のデータを用いて障害物の種類と位置を求める。リアルタイム処理層では、車両からデータを受信すると、物体検知・認識処理と位置推定処理を行い、障害物の種類と位置を求める。この例を本実施形態のデータ処理システムに適用する。図３の実施例では、車載カメラ画像からの物体検知・認識処理を高速応答処理層として分割した。

以下、図３の実施例の処理について説明する。図３では、データの流れ、各層において実行される処理、および各層の保持するデータを示している。

ステップＳ１１にて、車両は、車載カメラ画像とＣＡＮデータを高速応答処理層へ送信する。また、ステップＳ１２にて、車両は、車載カメラ画像とＣＡＮデータをバッチ処理層へ送信する。

ステップＳ１３にて、高速応答処理層では、車載カメラ画像から物体を検知し、物体を認識する処理が行われる。例えば、この処理では、障害物の有無、障害物の種類、および障害物のおおよその位置が高速応答処理結果として得られる。おおよその位置は、例えば、車載カメラ画像の撮影位置と撮影方向である。車載カメラ画像、ＣＡＮデータ、および高速応答処理結果は、リアルタイム処理層へ送信される。

ステップＳ１４にて、高速応答処理層に、ステップＳ１３で得られた高速応答処理結果が蓄積される。高速応答処理層は、高速応答処理結果の問い合わせに返信できるようになる。例えば、クライアント（他の車両）が、ある位置に障害物が存在するか否かを高速応答処理層に問い合わせると、高速応答処理層は、当該位置に障害物が存在する高速応答処理結果を検索し、検索された高速応答処理結果を返信する。

ステップＳ１５にて、リアルタイム処理層では、車載カメラ画像、ＣＡＮデータ、および高速応答処理結果に基づき、車載カメラ画像から検出された障害物の正確な位置を推定する。

ステップＳ１６にて、ステップＳ１３で得られた障害物の種類とステップＳ１５で得られた障害物の位置を含むリアルタイム処理結果が蓄積されて、リアルタイム処理層は、リアルタイム処理結果の問い合わせに返信できるようになる。

また、ステップＳ１７にて、リアルタイム処理結果が高速応答処理層に送信される。高速応答処理層は、リアルタイム処理結果に基づいて高速応答処理結果を修正する。

一方、ステップＳ２１にて、バッチ処理層では、受信したデータを保持しておく。

ステップＳ２２にて、バッチ処理層では、所定の間隔または所定数のデータが蓄積されたときに、複数車両からの車載カメラ画像とＣＡＮデータに基づき、物体の検知・認識処理と位置推定処理を行う。

ステップＳ２３にて、処理結果提供層に、バッチ処理層で得られた障害物の種類と位置を含むバッチ処理結果が蓄積される。処理結果提供層は、バッチ処理結果の問い合わせに返信できるようになる。

また、ステップＳ２４にて、バッチ処理層が高速応答処理層に送信される。高速応答処理層は、バッチ処理結果に基づいて高速応答処理結果を修正する。

ここで、本実施形態のデータ処理システムを利用したときの時間短縮について説明する。例えば、従来のラムダアーキテクチャのリアルタイム処理層において、障害物の種類と位置が取得できるようになるまでの時間が６秒であるとする。処理時間の内訳は以下の通りであるとする。

車載カメラ画像とＣＡＮデータのクラウドへの送信処理：２秒
車載カメラ画像からの物体検知・認識処理：１秒
検知した物体の位置推定処理：３秒

図３の実施例では、物体検知・認識処理を高速応答処理層に分割し、物体検知・認識の処理結果を参照できるようにした。これにより、車両がデータを送信してから高速応答処理層から情報が取得できるようになるまでの時間は３秒短縮できる。

また、高速応答処理層をエッジに配置することで、車載カメラ画像とＣＡＮデータのエッジへの送信処理にかかる時間が１秒だとすると、さらに１秒短縮できる。

高速応答処理層への問い合わせについても短縮できる。例えば、クライアントのリアルタイム処理結果の問い合わせにかかる時間が１秒であり、このうち、クラウドまでの通信遅延が０．２５秒、情報の検索が０．５秒であるとする。エッジまでの通信遅延が０．１秒の場合、クライアントの高速応答処理結果の問い合わせにかかる時間は０．３秒短縮できる。

図３の実施例は、図４に示すような、クラウドを根とする木構造のエッジコンピューティング環境で実現できる。車両は、基地局に通信接続されて、データを送信したり、問い合わせを送信したりする。基地局の近くにエッジサーバを配備する。高速応答処理層をエッジサーバに配置し、リアルタイム処理層、バッチ処理層、および処理結果提供層をクラウドに配置する。

車両が送信したデータは、当該車両が通信接続される基地局の近くのエッジサーバで高速応答処理されるとともに、クラウドのバッチ処理層に送信される。高速応答処理層で得られた高速応答処理結果は、問い合わせに返信できるようにエッジサーバで保持されるとともに、クラウドのリアルタイム処理層に送信される。

車両が高速応答処理結果を問い合わせると、当該車両が通信接続する基地局のエッジサーバが高速応答処理結果を返信する。車両が通信接続していない他の基地局のエッジサーバが保持する高速応答処理結果は、クラウドを介して得ることができる。

リアルタイム処理結果およびバッチ処理結果を参照したいとき、車両はクラウドに問い合わせる。

また、車両（端末）が高い計算能力を有するときは、図５に示すように、高速応答処理層を各車両内に配置してもよい。図５では、リアルタイム処理層をエッジサーバに配置し、バッチ処理層と処理結果提供層をクラウドに配置した。

各車両は、車両の搭載したセンサから得られたデータを高速応答処理するとともに、クラウドのバッチ処理層へ送信する。各車両は、高速応答処理結果をリアルタイム処理層へ送信するとともに、各車両で保持しておく。

車両は、エッジサーバを介して他車両の保持する高速応答処理結果を取得できる。車両間で直接通信できるとき、車両は、直接、他車両から高速応答処理結果を取得してもよい。

以上説明したように、本実施形態のデータ処理システムは、受信したデータをストリーム処理するとともに、データを蓄積後にバッチ処理するラムダアーキテクチャを適用したデータ処理システムであり、受信したデータに対してストリーム処理の一部の処理を実行する高速応答処理装置１１と、高速応答処理装置１１の処理結果を保持して問い合わせに返信する高速応答処理結果提供装置１２を備える。これにより、クライアントは、バッチ処理層でのバッチ処理の処理結果が出力されるまでの間、バッチ処理よりも精度は低いが処理時間が短いリアルタイム処理層の処理結果を参照でき、さらに、リアルタイム処理層でのストリーム処理の処理結果が参照できるようになる前に、ストリーム処理の一部の処理の処理結果を参照できる。従来のラムダアーキテクチャより早い処理結果の参照が可能となるので、処理結果の精度低下を許容できる場合は、応答を高速化できる。

本実施形態のデータ処理システムでは、ストリーム処理のうち、処理の順番が早い順に合計処理時間が所定の閾値を超えないように高速応答処理層の処理に分割するので、処理の汎用的な分割および配置を提示でき、アプリケーションの分割と配置に関わる負担を軽減できる。

上記説明した高速応答処理装置１１と高速応答処理結果提供装置１２には、例えば、図６に示すような、中央演算処理装置（ＣＰＵ）９０１と、メモリ９０２と、ストレージ９０３と、通信装置９０４と、入力装置９０５と、出力装置９０６とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、高速応答処理装置１１と高速応答処理結果提供装置１２が実現される。このプログラムは磁気ディスク、光ディスク、半導体メモリ等のコンピュータ読み取り可能な記録媒体に記録することも、ネットワークを介して配信することもできる。高速応答処理装置１１と高速応答処理結果提供装置１２を１台の装置としてもよい。

１１…高速応答処理装置
１１１…受信部
１１２…処理部
１１３…送信部
１２…高速応答処理結果提供装置
１２１…修正部
１２２…記憶部
１２３…応答部
２１…リアルタイム処理装置
２２…リアルタイム処理結果提供装置
３１…ストレージ
３２…バッチ処理装置
３３…バッチ処理結果提供装置

Claims (8)

1. 受信したデータをストリーム処理するとともに、前記受信したデータを蓄積後にバッチ処理するデータ処理システムであって、
   前記ストリーム処理のうちの第１の処理工程を前記データに対して実行し、処理結果を保持する第１処理装置と、
   前記ストリーム処理のうちの第２の処理工程を前記第１処理装置の処理結果に対して実行する第２処理装置と、
   前記受信したデータを蓄積するストレージと、
   前記ストレージに蓄積されたデータをバッチ処理するバッチ処理装置と、を備える
   データ処理システム。
2. 請求項１に記載のデータ処理システムであって、
   前記第１処理装置の処理結果を保持して問い合わせに返信する第１結果提供装置と、
   前記第２処理装置の処理結果を保持して問い合わせに返信する第２結果提供装置と、
   前記バッチ処理装置の処理結果を保持して問い合わせに返信する第３結果提供装置と、を備える
   データ処理システム。
3. 受信したデータをストリーム処理するとともに、前記受信したデータを蓄積後にバッチ処理するデータ処理方法であって、
   コンピュータによる、
   前記ストリーム処理のうちの第１の処理工程を前記データに対して実行し、処理結果を保持する工程と、
   前記ストリーム処理のうちの第２の処理工程を前記第１の処理工程の処理結果に対して実行する工程と、
   前記受信したデータをストレージに蓄積する工程と、
   前記ストレージに蓄積されたデータをバッチ処理する工程と、を備える
   データ処理方法。
4. 受信したデータをストリーム処理するとともに、前記受信したデータを蓄積後にバッチ処理するデータ処理システムの備える処理装置であって、
   前記ストリーム処理のうちの一部の処理工程を前記データに対して実行する処理部と、
   前記処理部の処理結果を保持する記憶部と、
   問い合わせに対して前記処理結果を返信する応答部と、を備える
   処理装置。
5. 請求項４に記載の処理装置であって、
   前記ストリーム処理のうちの一部の処理工程は、前記ストリーム処理のうち、処理の順番と合計処理時間に基づき切り出された処理群である
   処理装置。
6. 請求項４または５に記載の処理装置であって、
   前記ストリーム処理の処理結果および前記バッチ処理の処理結果の少なくとも一方に基づいて前記記憶部の保持する処理結果を修正する修正部を備える
   処理装置。
7. 受信したデータをストリーム処理するとともに、前記受信したデータを蓄積後にバッチ処理するデータ処理システムの備える処理装置であって、
   前記データに対する前記ストリーム処理のうちの未処理の処理工程を実行する処理部と、
   前記ストリーム処理の処理結果を保持する記憶部と、
   問い合わせに対して前記処理結果を返信する応答部と、を備える
   処理装置。
8. 請求項４ないし７のいずれかに記載の処理装置としてコンピュータを動作させるプログラム。

Images