論文の概要、ライセンス

# (参考訳) 柔軟な動的ストリーム分析のためのエッジクラウド統合フレームワーク [全文訳有]

An Edge-Cloud Integrated Framework for Flexible and Dynamic Stream Analytics ( http://arxiv.org/abs/2205.04622v2 )

ライセンス: CC BY 4.0
Xin Wang, Azim Khan, Jianwu Wang, Aryya Gangopadhyay, Carl E. Busart, Jade Freeman(参考訳) IoT(Internet of Things)やエッジコンピューティング,クラウドコンピューティングの普及に伴い,IoTセンサデータ上でのリアルタイムトレンド予測やオブジェクト検出など,ストリーム分析アプリケーションの開発がますます進んでいる。 ストリーム分析の一般的なタイプの1つは、recurrent neural network(rnn)のディープラーニングモデルに基づく時系列あるいはシーケンスデータ予測と予測である。 処理対象のデータが前もって利用可能で変更されないと仮定した従来の分析とは違って、ストリーム分析では、継続的に生成されるデータと、データトレンド/分散(コンセプトドリフト)が変更され、予測/予測精度が時間とともに低下する可能性がある。 もうひとつの課題は,ストリーム分析に最適なリソースプロビジョニングを提供することによる,全体的なレイテンシの向上だ。 本稿では,rnnベースのストリーム分析において,エッジリソースとクラウドリソースを最大限に活用し,精度とレイテンシを向上させる方法について検討する。 本稿では,エッジ上の低レイテンシ推論とクラウド上の高容量トレーニングをサポートするハイブリッドストリーム分析のための,エッジクラウド統合フレームワークを提案する。 我々は,エッジ中心,クラウド中心,エッジクラウド統合といったハイブリッド学習フレームワークの柔軟な展開について検討する。 さらに,このハイブリッド学習フレームワークは,過去のデータに基づいて事前学習したrnnモデルと,最新のデータに基づいて周期的に再訓練された別のrnnモデルから推定結果を動的に結合することができる。 実世界とシミュレートされたストリームデータセットを用いて,提案するエッジクラウドデプロイメントが,レイテンシの観点から3つのデプロイメントタイプの中で最も優れていることを示す。 実験では,3つのコンセプトドリフトシナリオすべてにおいて,動的学習手法が最善の学習手法であることを示す。

With the popularity of Internet of Things (IoT), edge computing and cloud computing, more and more stream analytics applications are being developed including real-time trend prediction and object detection on top of IoT sensing data. One popular type of stream analytics is the recurrent neural network (RNN) deep learning model based time series or sequence data prediction and forecasting. Different from traditional analytics that assumes data to be processed are available ahead of time and will not change, stream analytics deals with data that are being generated continuously and data trend/distribution could change (aka concept drift), which will cause prediction/forecasti ng accuracy to drop over time. One other challenge is to find the best resource provisioning for stream analytics to achieve good overall latency. In this paper, we study how to best leverage edge and cloud resources to achieve better accuracy and latency for RNN-based stream analytics. We propose a novel edge-cloud integrated framework for hybrid stream analytics that support low latency inference on the edge and high capacity training on the cloud. We study the flexible deployment of our hybrid learning framework, namely edge-centric, cloud-centric and edge-cloud integrated. Further, our hybrid learning framework can dynamically combine inference results from an RNN model pre-trained based on historical data and another RNN model re-trained periodically based on the most recent data. Using real-world and simulated stream datasets, our experiments show the proposed edge-cloud deployment is the best among all three deployment types in terms of latency. For accuracy, the experiments show our dynamic learning approach performs the best among all learning approaches for all three concept drift scenarios.
公開日: Wed, 11 May 2022 21:27:03 GMT

※ 翻訳結果を表に示しています。PDFがオリジナルの論文です。翻訳結果のライセンスはCC BY-SA 4.0です。詳細はトップページをご参照ください。

翻訳結果

    Page: /      
英語(論文から抽出)日本語訳スコア
An Edge-Cloud Integrated Framework エッジクラウド統合フレームワーク 0.74
for Flexible and Dynamic Stream Analytics Xin Wang∗, Azim Khan∗, Jianwu Wang∗, Aryya Gangopadhyay∗, Carl E. Busart†, Jade Freeman† ∗Department of Information Systems, University of Maryland, Baltimore County, Maryland, United States for Flexible and Dynamic Stream Analytics Xin Wang∗, Azim Khan∗, Jianwu Wang∗, Aryya Gangopadhyay∗, Carl E. Busart', Jade Freeman ∗Department of Information Systems, Maryland, Baltimore County, United States
訳抜け防止モード: For Flexible and Dynamic Stream Analytics Xin Wang∗, Azim Khan∗, Jianwu Wang∗, Aryya Gangopadhyay∗, Carl E. Busart , Jade Freeman ∗Department of Information Systems メリーランド州ボルチモア郡メリーランド大学
0.69
{xinwang11, azimkhan22, jianwu, gangopad}@umbc.edu xinwang11, azimkhan22, jianwu, gangopad}@umbc.edu 0.45
†DEVCOM Army Research Laboratory, Adelphi, Maryland, United States アメリカ合衆国メリーランド州アデルフィのdevcom陸軍研究所 0.52
{carl.e. busart.civ, jade.l. carl.e. busart.civ, jade.l. 0.36
freeman2.civ}@army.mil freeman2.civ}@army.mil 0.29
2 2 0 2 y a M 1 1 2 2 0 2 y a m 1 1 である。 0.54
] C D . s c [ ] CD。 sc [ 0.33
2 v 2 2 6 4 0 2 v 2 2 6 4 0 0.43
. 5 0 2 2 : v i X r a . 5 0 2 2 : v i X r a 0.42
Abstract—With the popularity of Internet of Things (IoT), edge computing and cloud computing, more and more stream analytics applications are being developed including real-time trend prediction and object detection on top of IoT sensing data. Abstract — IoT(Internet of Things)やエッジコンピューティング、クラウドコンピューティングの普及に伴い、リアルタイムトレンド予測やIoTセンサデータ上でのオブジェクト検出など、ストリーム分析アプリケーションの開発がますます進んでいる。 0.80
One popular type of stream analytics is the recurrent neural network (RNN) deep learning model based time series or sequence data prediction and forecasting. ストリーム分析の一般的なタイプの1つは、recurrent neural network(rnn)のディープラーニングモデルに基づく時系列あるいはシーケンスデータ予測と予測である。 0.81
Different from traditional analytics that assumes data to be processed are available ahead of time and will not change, stream analytics deals with data that are being generated continuously and data trend/distribution could change (aka concept drift), which will cause prediction/forecasti ng accuracy to drop over time. 処理対象のデータが前もって利用可能で変更されないと仮定した従来の分析とは違って、ストリーム分析では、継続的に生成されるデータと、データトレンド/分散(コンセプトドリフト)が変更され、予測/予測精度が時間とともに低下する可能性がある。 0.74
One other challenge is to find the best resource provisioning for stream analytics to achieve good overall latency. もうひとつの課題は,ストリーム分析に最適なリソースプロビジョニングを提供することによる,全体的なレイテンシの向上だ。 0.56
In this paper, we study how to best leverage edge and cloud resources to achieve better accuracy and latency for RNN-based stream analytics. 本稿では,rnnベースのストリーム分析において,エッジリソースとクラウドリソースを最大限に活用し,精度とレイテンシを向上させる方法について検討する。 0.58
We propose a novel edge-cloud integrated framework for hybrid stream analytics that support low latency inference on the edge and high capacity training on the cloud. 本稿では,エッジ上の低レイテンシ推論とクラウド上の高容量トレーニングをサポートするハイブリッドストリーム分析のための,エッジクラウド統合フレームワークを提案する。 0.73
We study the flexible deployment of our hybrid learning framework, namely edgecentric, cloud-centric and edge-cloud integrated. 我々は,エッジ中心,クラウド中心,エッジクラウド統合というハイブリッド学習フレームワークの柔軟な展開について検討する。 0.63
Further, our hybrid learning framework can dynamically combine inference results from an RNN model pre-trained based on historical data and another RNN model re-trained periodically based on the most recent data. さらに,このハイブリッド学習フレームワークは,過去のデータに基づいて事前学習したrnnモデルと,最新のデータに基づいて周期的に再訓練された別のrnnモデルから推定結果を動的に結合することができる。 0.64
Using real-world and simulated stream datasets, our experiments show the proposed edge-cloud deployment is the best among all three deployment types in terms of latency. 実世界とシミュレートされたストリームデータセットを用いて,提案するエッジクラウドデプロイメントが,レイテンシの観点から3つのデプロイメントタイプの中で最も優れていることを示す。 0.61
For accuracy, the experiments show our dynamic learning approach performs the best among all learning approaches for all three concept drift scenarios. 実験では,3つのコンセプトドリフトシナリオすべてにおいて,動的学習手法が最善の学習手法であることを示す。 0.86
Index Terms—Edge-cloud integration, stream data analytics, Index Terms - Edgeクラウド統合、ストリームデータ分析、 0.74
concept drift, hybrid learning, recurrent neural network. コンセプトドリフト ハイブリッド学習 繰り返しニューラルネットワーク 0.49
I. INTRODUCTION I. イントロダクション 0.64
Stream analytics has become a major data analytics area due to hardware and software advances in Internet of Things (IoT), edge computing and cloud computing. stream analyticsは、iot(internet of things)、エッジコンピューティング、クラウドコンピューティングにおけるハードウェアとソフトウェアの進歩により、主要なデータ分析分野となっている。 0.76
It is now much easier to obtain sensing data from IoT devices, which leads to more and more stream analytics applications including real-time trend prediction [1–3] and real-time object detection [4, 5] on top of IoT sensing data. iotデバイスからセンシングデータを取得するのがずっと簡単になったため、iotセンシングデータ上にリアルタイムトレンド予測[1-3]やリアルタイムオブジェクト検出[4,5]など、ストリーム分析アプリケーションがますます増えています。 0.77
Different from traditional analytics that assumes data to be processed are available ahead of time and will not change, stream analytics processes data that are being generated on the fly and continuously. 処理すべきデータが前もって利用可能であり、変更されないと仮定する従来の分析とは異なり、分析プロセスはオンザフライで、継続的に生成されるデータをストリームする。 0.68
A well-known challenge of stream analytics is concept drift [6, 7] which describes changes in the concept or distribution of stream data. ストリーム分析のよく知られた課題は、ストリームデータの概念や分布の変化を記述するコンセプトドリフト [6, 7] である。 0.82
There is a growing number of studies on how to conduct stream analytics by leveraging IoT, edge and cloud resources. IoT、エッジ、クラウドリソースを活用することによって、ストリーム分析の実施方法に関する研究が増えている。 0.64
Edge computing in an IoT environment brings computation and data storage closer to data sources. IoT環境でのエッジコンピューティングは、計算とデータストレージをデータソースに近づける。 0.80
It operates on “instant data” that is usually time sensitive. 通常、時間に敏感な“instant data”で動作する。 0.77
Besides the latency benefit, edge computing is normally designed for remote locations, where there is limited or no connectivity to a centralized computation location. レイテンシのメリットに加えて、エッジコンピューティングは通常、中央集中型の計算場所への接続が制限される、あるいは存在しない遠隔地向けに設計されている。 0.60
However, resources on edges are constrained and limited in their capacity/capability and can only support relatively simple data processing like inference/prediction based on a pre-trained model. しかし、エッジ上のリソースはその容量/能力に制約があり、事前訓練されたモデルに基づいた推論/予測のような比較的単純なデータ処理しかサポートできない。 0.61
So it often relies on additional resources, such as storage or memory optimized devices, for more complex processing. そのため、より複雑な処理のために、ストレージやメモリ最適化デバイスといった追加のリソースに依存することが多い。
訳抜け防止モード: そのため、ストレージやメモリ最適化デバイスなどの追加リソースに依存することが多い。 より複雑な処理のために
0.77
Cloud computing [8] provides on-demand computational resources for data analytics over the Internet and becomes a major approach for supporting complex and high-performance computation. クラウドコンピューティング [8] はインターネット上のデータ分析にオンデマンドの計算リソースを提供し、複雑でハイパフォーマンスな計算をサポートするための主要なアプローチとなる。 0.75
Besides IoT environments, streaming data could also be delivered directly to the cloud and be computed with enough computing power and storage capacity. IoT環境以外にも、ストリーミングデータをクラウドに直接配信し、十分な計算能力とストレージ容量で計算することもできる。 0.76
However, considering its distance to the data source, it is hard to have a quick response when data injection for some time-sensitive applications like earthquake warnings and automatic driving. しかし, 震源からの距離を考えると, 地震警報や自動運転など, 時間に敏感な用途にデータ注入を行う場合, 迅速な応答は得られない。 0.78
Since both edge and cloud resources have their advantages and disadvantages, a related computing paradigm like Edge-to-Cloud Continuum [9] has been proposed to integrate edge with cloud. edgeとクラウドリソースの両方に利点と欠点があるため、edgeとクラウドを統合するためにedge-to-cloud continuum[9]のような関連するコンピューティングパラダイムが提案されている。 0.69
In an edge-cloud integrated framework, the computation involves both front-end on-premise edge resources and back-end computing resources, such as big data and GPU clusters in cloud. エッジクラウド統合フレームワークでは、計算にはフロントエンドのオンプレミスのエッジリソースと、クラウド内のビッグデータやGPUクラスタといったバックエンドのコンピューティングリソースの両方が含まれる。 0.67
Deep learning has been widely used in stream analytics in IoT, edge or cloud environments. ディープラーニングは、IoT、エッジ、クラウド環境のストリーム分析に広く使用されている。 0.58
As a recent survey paper [10] shows, about one third of studies surveyed in the paper employs recurrent neural network (RNN) based deep learning models for time series or sequence data prediction and forecasting. 最近の研究論文 [10] によると、論文で調査された研究の約3分の1は、時系列またはシーケンスデータ予測と予測のためのrecurrent neural network (rnn)ベースのディープラーニングモデルを使用している。 0.72
RNN models can help learn temporal dependence and structures like trends and seasonality. RNNモデルは、時間的依存やトレンドや季節性といった構造を学ぶのに役立つ。 0.59
Most existing studies and systems, such as [10] and [5], only support deep learning based inference on IoT/edge devices. 既存の研究やシステム,例えば[10]や[5]は,IoT/エッジデバイスによるディープラーニングベースの推論のみをサポートしています。 0.69
A new research area is how to best integrate both edge resources and cloud resources for deep learning applications. 新しい研究分野は、ディープラーニングアプリケーションのためのエッジリソースとクラウドリソースの両方を統合する方法だ。 0.78
Several researchers [9, 11– 17] have proposed solutions and frameworks for streaming data analytics that leverage the capabilities of cloud services. 数名の研究者[9,11–17]が,クラウドサービスの機能を活用するストリーミングデータ分析のソリューションとフレームワークを提案している。 0.74
However, to integrate edge with cloud, we need to achieve a proper trade-off between latency and accuracy for stream analytics between edge and cloud resources. しかし、エッジとクラウドを統合するためには、エッジとクラウドリソース間のストリーム分析のレイテンシと精度の適切なトレードオフを達成する必要があります。 0.60
Accuracy and latency are two common metrics in stream ストリームにおける2つの一般的なメトリクスは正確性とレイテンシである 0.45
英語(論文から抽出)日本語訳スコア
analytics and many studies have how to balance them or make trade-offs. 分析や多くの研究には、それらのバランスをとる方法やトレードオフがある。 0.59
In the paper, we focus on how to achieve good accuracy and latency for the RNN-based deep learning model in an edge-cloud integrated environment by addressing the following two challenges. 本稿では,RNNベースのディープラーニングモデルにおいて,以下の2つの課題に対処することにより,エッジクラウド統合環境での精度とレイテンシの向上に焦点をあてる。 0.67
First, while the existing studies like [9, 11, 12] provided promising direction, it is still not clear how to best deploy RNN-based deep learning models in edge and cloud resources for stream analytics to achieve better latency. まず、[9, 11, 12]のような既存の研究は有望な方向性を提供していますが、RNNベースのディープラーニングモデルをエッジやクラウドリソースにデプロイして、ストリーム分析によるレイテンシの向上を実現する方法はまだ明確ではありません。 0.62
Second, even though there have been many studies [1, 18] on how to deal with unknown or changing data distributions in stream data, a.k.a. concept drift, it is still an open question how to balance accuracy and latency for RNN based stream analytics in an edge-cloud environment. 第2に,ストリームデータにおける未知あるいは変化したデータ分散,すなわちコンセプトドリフトの処理方法に関する[1,18]研究が数多く存在するにも関わらず,エッジクラウド環境でのRNNベースのストリーム分析の正確性とレイテンシのバランスを取るには,依然としてオープンな疑問である。 0.78
To tackle the above two challenges, we propose a novel edge-cloud integrated framework and its corresponding opensource modules [] for stream analytics. 上記の2つの課題に取り組むため,我々は新しいエッジクラウド統合フレームワークと,それに対応するオープンソースモジュールを提案する。 0.75
To the best of our knowledge, our work is the first to achieve hybrid RNNbased deep learning for stream data in an edge-cloud integrated environment. 我々の知る限りでは、エッジクラウド統合環境でデータをストリームするためのハイブリッドRNNベースのディープラーニングを初めて実現した作業です。 0.68
Our contributions are summarized as follows. 私たちの貢献は以下の通り要約される。 0.57
• We propose a novel edge-cloud integrated framework for stream analytics that supports low latency inference on the edge and high capacity training on the cloud. • エッジ上の低レイテンシ推論とクラウド上の高容量トレーニングをサポートする,ストリーム分析のための新たなエッジクラウド統合フレームワークを提案する。 0.77
Tasks like data injection, model inference and synchronization are encapsulated as modules and can be flexibly deployed on either an edge device like Raspberry Pi or a cloud resource like AWS. データインジェクション、モデル推論、同期といったタスクはモジュールとしてカプセル化され、Raspberry PiのようなエッジデバイスやAWSのようなクラウドリソースに柔軟にデプロイできる。 0.75
• Based on users’ preferences, we propose three flexible deployment modalities for our hybrid learning framework: namely edge-centric, cloud-centric and edge-cloud integrated. •ユーザの好みに基づいて,当社のハイブリッド学習フレームワークであるエッジ中心,クラウド中心,エッジクラウド統合の3つのフレキシブルなデプロイメントモードを提案します。 0.67
Based on a modular design, the hybrid learning framework can still work even if parts of the cloud services or edge analytics are unavailable. モジュラー設計に基づいて、ハイブリッド学習フレームワークは、クラウドサービスの一部やエッジ分析が利用できない場合でも動作する。 0.70
We further measured the latency differences between the three deployments using a real-world stream analytics application. さらに,実世界のストリーム分析アプリケーションを用いて,3つのデプロイメント間のレイテンシ差を測定した。 0.60
Our experiments show the proposed edge-cloud deployment is among the best in terms of latency for inference, also will not run into capacity limitation for training. 提案するエッジクラウドデプロイメントは,推論のレイテンシという点では最良であると同時に,トレーニングのキャパシティ制限に陥ることもない。 0.59
• To adapt the concept drift challenge of stream data in edge-cloud integrated environments, we propose an adaptive hybrid learning framework that combines and benefits from both cloud resources’ high capacity and edge resources’ low latency. •適応する エッジクラウド統合環境におけるストリームデータのドリフト課題として,クラウドリソースの高容量化とエッジリソースの低レイテンシ化を両立した,適応型ハイブリッド学習フレームワークを提案する。 0.78
Our hybrid learning framework contains batch learning by employing a pre-trained RNN model from large historical data, speed learning by periodically re-training an RNN model from most recent data and hybrid learning by combining predictions from batch and speed learning. ハイブリッド学習フレームワークには,大規模な履歴データから事前学習したrnnモデル,最新のデータから定期的に再トレーニングした速度学習,バッチとスピード学習からの予測を組み合わせたハイブリッド学習が含まれる。 0.83
We also study a new hybrid learning algorithm that can combine results dynamically. また,結果を動的に組み合わせるハイブリッド学習アルゴリズムについても検討した。 0.73
Our experiments show our hybrid learning approaches can have better RMSE than cloud-based batch learning and edge-based speed learning in most cases and our dynamic learning approach performs the best among all learning approaches for all three concept drift scenarios. 私たちの実験では、私たちのハイブリッド学習アプローチが、クラウドベースのバッチ学習やエッジベースのスピード学習よりも優れたrmseを持つことが示されています。 0.57
The rest of the paper is organized as follows. 残りの論文は以下の通り整理される。 0.66
In Section II, we briefly introduce the related background our work is built on. 節 第2に、我々の作品が基づいている関連する背景を簡単に紹介します。 0.42
Section III provides an overview of the proposed edge-cloud integrated hybrid learning framework. 第III節は、提案されているエッジクラウド統合ハイブリッド学習フレームワークの概要を提供する。 0.61
Section IV introduces our three flexible deployment modalities of hybrid learning framework, including edge-centric, cloud-centric and edge-cloud integrated deployments. 第4節では、エッジ中心、クラウド中心、エッジクラウド統合デプロイメントを含む、ハイブリッド学習フレームワークの3つのフレキシブルなデプロイメントモダリティを紹介しています。 0.50
The adaptive hybrid stream analytics and its two weight combinations, namely static and dynamic weighting algorithms, are explained in Section V. Evaluations and benchmarking results are next discussed in Section VI. 適応型ハイブリッドストリーム解析とその2つの重み付けアルゴリズム,すなわち静的および動的重み付けアルゴリズムについて,第V節で説明する。
訳抜け防止モード: 適応型ハイブリッドストリーム分析とその2つの重み付け、すなわち静的および動的重み付けアルゴリズムである。 次にセクション6で評価とベンチマークの結果が議論される。
0.72
We summarize related studies and compare them with our work in VII and conclude in Section VIII. 関連研究を要約し、VIIの著作と比較し、第8節で結論づける。
訳抜け防止モード: 関連研究を要約し、VIIにおける研究と比較する。 第8節で終了する。
0.67
II. BACKGROUND II。 バックグランド 0.60
A. Edge Computing and Edge-cloud Integration A.エッジコンピューティングとエッジクラウドの統合 0.83
Applications that utilize IoT devices are increasing day by day and data volumes produced by IoT edge devices could be enormous. IoTデバイスを使用するアプリケーションは日々増加しており、IoTエッジデバイスが生成するデータボリュームは巨大なものになる可能性がある。
訳抜け防止モード: IoTデバイスを利用するアプリケーションは日に日に増えている IoTエッジデバイスが生成するデータボリュームは巨大です。
0.80
In order to alleviate the heavy load of data transfer, edge devices can pre-process, analyze and quickly react to the time-sensitive application near data sources, and only deliver the processed data or inference results to backend computation centers. データ転送の負荷を軽減するために、エッジデバイスは、データソースの近くで時間に敏感なアプリケーションに対して前処理、分析、迅速に反応し、処理されたデータまたは推論結果だけをバックエンド計算センターに配信することができる。 0.69
So, when data generated by a source is handled near the edge, we could achieve faster response time, higher computing efficiency and lower network traffic in comparison to the case where IoT data is processed in a centralized computation location. したがって、ソースが生成したデータがエッジ付近で処理される場合、中央集権的な計算ロケーションで処理される場合と比較して、応答時間や計算効率の向上、ネットワークトラフィックの低減を実現できます。 0.70
However, the capacity of edge devices limits their capability to handle complex heterogeneous data and even could lead to unacceptable and unpredictable performance. しかし、エッジデバイスの容量は複雑な異種データを扱う能力を制限し、許容不可能で予測不可能なパフォーマンスにつながる可能性がある。 0.66
To deal with the challenge, work at [13] extended the idea of computing continuum, and proposed an edge-to-cloud integration to support dynamic and datadriven application workflows, which are capable of reacting to unpredictable and heterogeneous real-time data. この課題に対処するため、[13]の作業はコンティニュウム計算のアイデアを拡張し、予測不能で異種なリアルタイムデータに反応可能な、動的およびデータ駆動のアプリケーションワークフローをサポートするエッジ・ツー・クラウド統合を提案した。 0.65
Pilot-Edge [9] proposed its abstraction to support data and machine learning (ML) applications in the edge-to-cloud continuum, which was designed to address the challenge of computation performance in heterogeneous edge environments. Pilot-Edge [9]は、エッジからクラウドへの連続体において、データと機械学習(ML)アプリケーションをサポートするための抽象化を提案しました。
訳抜け防止モード: パイロット - edge [9 ]は、エッジにおけるデータと機械学習(ml)アプリケーションをサポートする抽象化を提案した。 これは異種エッジ環境における計算性能の課題に対処するために設計された。
0.65
B. Concept Drifts in Real-world IoT Data Streams B. 実世界のIoTデータストリームにおけるコンセプトドリフト 0.74
In real-world data-driven applications, analytics of IoT streaming data often encounters the change in the data distribution while extracting different features from stream sources. 実世界のデータ駆動アプリケーションでは、IoTストリーミングデータの分析は、ストリームソースからさまざまな機能を抽出しながら、データ分散の変化に直面することが多い。 0.68
These hidden changes in the concept or distribution of streaming data, which are unknown to the learning algorithms, are termed concept drift [6, 7] or nonstationary data. これらのストリーミングデータの概念や分布の隠れた変化は、学習アルゴリズムに未知であり、概念ドリフト [6, 7] または非定常データと呼ばれる。 0.84
Mathematically, if we denote X as an input vector and y as an output vector, then (X, y) will be an infinite sequence of data streams. 数学的には、X を入力ベクトル、y を出力ベクトルとすると、(X, y) はデータストリームの無限列となる。 0.68
Concept drifts between time point ti and time point tj can be defined as 時間点tiと時間点tjの間の概念ドリフトを定義できる 0.71
pti(X, y) (cid:54)= ptj(X, y) pti(X, y) (cid:54)= ptj(X, y) 0.47
(1) where pti and ptj denote joint probability distribution at (1) pti と ptj が合同確率分布を表す場合 0.59
time ti and tj, respectively. タイムtiとtjはそれぞれ。 0.59
Changes in streaming data distribution over time might appear in various ways such as gradual drift and abrupt drift. ストリーミングデータ分布の変化は、漸進的ドリフトや急進的ドリフトといった様々な方法で現れる可能性がある。 0.66
Abrupt drift happens suddenly by switching from one concept 突然のドリフトは、ある概念から切り換えることで起きる 0.62
英語(論文から抽出)日本語訳スコア
to another in any time period [7]. いつでも別の時間[7]に。 0.73
Gradual or incremental drift does not change abruptly, instead happens over a long period and therefore can be expected. 漸進的あるいは漸進的なドリフトは突然は変化せず、代わりに長い期間にわたって起こるため、期待できる。 0.66
It defines a continuous change that happens from one underlying process behavior to another one. それは、あるプロセスの振る舞いから別のプロセスへ起こる継続的変化を定義します。
訳抜け防止モード: それは連続的な変化を定義します あるプロセスの振る舞いから別のプロセスへ
0.81
In this paper, simulated datasets consisting of gradual and abrupt drift were used to know how hybrid stream analytics reacts in the context of different types of drifts. 本稿では,混合ストリーム解析が様々なドリフトの文脈でどのように反応するかを知るために,徐々にドリフトと突然ドリフトからなるシミュレーションデータセットを用いた。 0.68
C. Adaptive Learning and Lambda Architecture C.適応学習とラムダアーキテクチャ 0.74
Because underlying concepts of real-world stream data could evolve over time, adaptive learning algorithms have been proposed to address concept drift by adapting new instances and forgetting old ones in order to naturally follow drifts in the stream. 実世界のストリームデータの基本概念は時間とともに進化する可能性があるため、適応学習アルゴリズムは、新しいインスタンスを適応し、ストリーム内のドリフトを自然に追従するために古いデータを忘れることによって、概念ドリフトに対処するために提案されている。 0.58
It can also be considered as improved incremental learning algorithms that are able to integrate fresh data during their operation to react to concept drifts [7]. また、その操作中に新しいデータを統合して概念のドリフトに反応できる改良されたインクリメンタル学習アルゴリズムとも考えられる [7]。 0.82
Mentioned by [19], concept drift detector, sliding windows, online learner and ensemble learners are the most common adaptive learning approaches. 19]を取り入れたコンセプトドリフト検出器,スライドウィンドウ,オンライン学習者,アンサンブル学習者は,最も一般的な適応型学習アプローチである。 0.74
One challenge is, the estimation of performance feedback is difficult for any adaptive learning system due to the absence of ground truth in stream data. 1つの課題は、ストリームデータに基底真理が欠如しているため、適応学習システムではパフォーマンスフィードバックの推定が難しいことである。 0.77
Besides, the anomalies of the algorithm can readily be confused for changes in the stream data. さらに、アルゴリズムの異常は、ストリームデータの変更と容易に混同することができる。 0.68
In our paper, we infer and evaluate our adaptive learning method by analyzing earlier historical data and the data in the past time windows. 本稿では,過去の過去の過去のデータと過去のウィンドウのデータを解析し,適応学習手法を推論し,評価する。 0.79
Lambda architecture is a data-processing design pattern which is usually used in data-driven applications by taking advantage of both batch and stream processing methods [1]. Lambdaアーキテクチャはデータ処理設計パターンであり、通常、バッチ処理とストリーム処理の両方を利用するデータ駆動アプリケーションで使用される[1]。 0.77
The lambda architecture has three layers, batch layer for batch processing based on historical data, speed layer for real-time stream processing, and serving/hybrid layer for combining outputs from both batch and speed layer. lambdaアーキテクチャには3つのレイヤがあり、履歴データに基づくバッチ処理のためのバッチ層、リアルタイムストリーム処理のためのスピード層、バッチ層とスピード層の両方からの出力を結合するサービス/ハイブリッド層がある。
訳抜け防止モード: lambdaアーキテクチャには3つのレイヤがある。 リアルタイムストリーム処理用のspeed layerと、バッチ層とスピード層の両方からの出力を結合するservice/hybrid layerを提供する。
0.76
The goal for lambda architecture design pattern is to abstract and balance both the accuracy by using batch processing to provide comprehensive knowledge from historical data, and the latency by using stream processing to learn the resent changes from real-time data. lambda architecture design patternの目標は、バッチ処理を使用して、履歴データから包括的な知識を提供するという精度と、ストリーム処理を使用してリアルタイムデータからresent変化を学ぶ遅延の両方を抽象化してバランスさせることにある。 0.65
Inspired by this design pattern, we propose a hybrid stream learning model to achieve adaptive learning. このデザインパターンに触発されて,適応学習を実現するハイブリッドストリーム学習モデルを提案する。 0.87
III. OVERVIEW OF HYBRID STREAM ANALYTICS III。 ハイブリッドストリーム分析の概要 0.66
FRAMEWORK In this section, we briefly introduce our proposed hybrid stream analytics framework from a high-level view. フレームワーク 本稿では,ハイレベルな視点から提案したハイブリッドストリーム分析フレームワークについて紹介する。 0.61
By combining edge resources’ “lower communication latency” with cloud resources’ “higher computational power”, we propose a novel hybrid learning framework that can achieve good latency and accuracy for stream analytics. エッジリソースの"低コミュニケーションレイテンシ"とクラウドリソースの"高計算能力"を組み合わせることで,ストリーム分析に優れたレイテンシと精度を実現するための,新たなハイブリッド学習フレームワークを提案する。 0.81
We summarize our hybrid stream analytics framework in Figure 1. 当社のハイブリッドストリーム分析フレームワークを図1にまとめます。 0.79
In our design, different functionalities are wrapped into multiple modules, which can be deployed on either edge or cloud. 私たちの設計では、異なる機能は複数のモジュールにラップされ、エッジまたはクラウドにデプロイできます。 0.76
Within the edge side, six modules are designed for flexible and dynamic stream analytics. エッジ側では、6つのモジュールがフレキシブルでダイナミックなストリーム分析用に設計されている。 0.63
The first three modules, namely batch inference, speed inference and hybrid inference, are the main functionality for the inference task of stream analytics. 最初の3つのモジュール、すなわちバッチ推論、スピード推論、ハイブリッド推論は、ストリーム分析の推論タスクの主要な機能である。 0.62
When stream data is injected, batch inference provides batch predictions based on a pre-trained ストリームデータがインジェクトされた場合、バッチ推論は事前トレーニングされたバッチ予測を提供する 0.64
Fig. 1: The overview of our proposed hybrid stream analytics framework. 図1:提案したハイブリッドストリーム分析フレームワークの概要。 0.66
model from historical data; speed inference enables predictions based on the latest model trained from the previous time window; and hybrid inference combines their inferred values to get a new prediction value. 履歴データからのモデル、前回のタイムウインドウからトレーニングされた最新のモデルに基づく予測を可能にし、ハイブリッド推論は推論された値を組み合わせて新しい予測値を得る。 0.79
We will explain in detail how we leverage our hybrid learning model to achieve adaptive prediction further in Section V. Next, we introduce the last three modules on the edge side. さらに、第5節では、エッジサイドに最後の3つのモジュールを導入することで、適応予測を実現するために、ハイブリッド学習モデルをどのように活用するかを詳細に説明します。
訳抜け防止モード: 詳しく説明します 当社のハイブリッド学習モデルを活用して,次節vでさらに適応的予測を行う。 エッジサイドに最後の3つのモジュールを紹介します。
0.80
For model synchronization, it synchronizes the models for speed inference from cloud to edge periodically. モデル同期では、クラウドからエッジへの速度推論のモデルを定期的に同期する。 0.73
For data synchronization, it synchronizes the streaming raw data and all inference results to the cloud storage. データ同期のために、ストリーミング生データとすべての推論結果をクラウドストレージに同期する。 0.74
All the synchronizations are achieved through the edge-cloud MQTT messaging [20] based on specific topics. すべての同期は、特定のトピックに基づいたエッジクラウドMQTTメッセージング[20]を通じて達成されます。 0.66
Module data injection acts as a transfer station to throttle the amount of streaming data in each time window and control them to the target modules. モジュールデータインジェクションは、各タイムウィンドウ内のストリーミングデータの量を絞り込み、ターゲットモジュールに制御するための転送ステーションとして機能する。 0.88
All these modularized functionalities can work both independently and cooperatively based on usage. これらのモジュール化された機能はすべて、独立して、利用に基づいて協調的に機能することができる。 0.47
With this modular design, our hybrid stream analytics framework can still work even if some modules are unavailable. このモジュール設計では、いくつかのモジュールが利用できない場合でも、ハイブリッドストリーム分析フレームワークが動作します。 0.68
Details of how our framework achieves flexibility with different deployment modalities including edge-centric, cloud-centric and edge-cloud integrated scenarios will be explained in Section IV. エッジ中心、クラウド中心、エッジクラウド統合シナリオなど、さまざまなデプロイメントモードを備えた柔軟性を実現するためのフレームワークの詳細は、セクションivで説明します。 0.58
Within the cloud side, two resources are used as the backend of the hybrid stream analytics framework: クラウド側では、ハイブリッドストリーム分析フレームワークのバックエンドとして、2つのリソースが使用される。 0.65
1) AWS IoT Core manages the edge-cloud communication, and 1) AWS IoT Coreはエッジクラウド通信を管理します。 0.83
2) AWS Lambda Function implements the pipeline of complex data processing. 2) AWS Lambda Functionは複雑なデータ処理のパイプラインを実装している。 0.77
AWS IoT Core provides resources and services that help users achieve edge-cloud computing with AWS IoT- AWS IoT Coreは、AWS IoTでエッジクラウドコンピューティングを実現するためのリソースとサービスを提供する 0.77
AWS CloudIoT CoreLambda FunctionsData ArchivingTriggering rule for dataTriggering rule for prediction resultsSpeed Trainingand ArchivingPrediction Results ArchivingEdge DeviceBatch InferenceModel SynchronizationSpeed InferenceHybrid InferenceData SynchronizationData InjectionMQTT SubscriberData LoggingEdge Access ControlMQTT Publishing for dataMQTT Publishing for prediction resultsS3 StorageEC2 VMsModel syncModel Sync AWS CloudIoT CoreLambda Functions Data ArchivingTriggering Rule for dataMQTT Publishing for predict results トレーニングとArchigeringPredictio n Results ArchivingEdge DeviceBatch Inference Model SynchronizationSpeed InferenceHybrid InferenceData SynchronizationData InjectionMQTT SubscriberData LoggingEdge Access ControlMQTT Publishing for dataMQTT Publishing for predict resultsS3 StorageEC2 VMsModel syncModel Sync 0.46
英語(論文から抽出)日本語訳スコア
work components, which achieves a proper trade-off between latency and accuracy for stream analytics. ストリーム分析のレイテンシと正確性の間の適切なトレードオフを実現するワークコンポーネント。 0.75
Based on different scenarios, we design three types of deployments for the hybrid stream analytics, edge-centric, cloud-centric and edge-cloud integrated deployments. 異なるシナリオに基づいて、ハイブリッドストリーム分析、エッジ中心、クラウド中心、エッジクラウド統合デプロイメントの3つのタイプのデプロイメントを設計します。 0.58
The summary of the three deployments is shown in Figure 3. 3つのデプロイメントの概要は、図3に示す。 0.70
We also summarize the advantages and limitations of the proposed deployments in Table I. また、提案されているデプロイメントの利点と制限をテーブルIで要約します。 0.63
Fig. 3: Flexible deployments of our hybrid stream analytics framework. 図3: ハイブリッドストリーム分析フレームワークの柔軟なデプロイメント。 0.65
A. Edge-centric Stream Analytics Deployment A.エッジ中心のストリーム分析のデプロイ 0.57
Because stream analytics needs to process incoming data continuously, it is common that the back-end cloud service will be temporally unavailable due to network disconnection or resource overload problems. ストリーム分析は、着信データを継続的に処理する必要があるため、ネットワークの切断やリソース過負荷の問題により、バックエンドのクラウドサービスが一時的に利用できないことが一般的である。 0.62
For this, we design an edge centric deployment modality, which allows the edge to execute stream analytics autonomously with local events, as shown in Figure 3a. このために、図3aに示すように、エッジがローカルイベントでストリーム分析を自律的に実行できるように、エッジ中心のデプロイメントモダリティを設計する。 0.68
We can summarize the unavailability of the cloud into two scenarios: part of cloud computational resources (like EC2) unavailable and the whole cloud service unavailable. クラウドの可用性を2つのシナリオにまとめることができる: クラウド計算リソースの一部(ec2のような)、クラウドサービス全体が利用できない。 0.74
During the first scenario, IoT Core and other Lambda functions still work well except for the Speed Training and Archiving. 最初のシナリオでは、Speed TrainingとArchiveingを除いて、IoT Coreや他のLambda関数はまだうまく機能している。 0.77
If the Lambda function cannot connect to any virtual machine in EC2, it will put the process event into its waiting queue and wait for the available resources. Lambda関数がEC2の仮想マシンに接続できない場合、プロセスイベントを待ちキューに配置し、利用可能なリソースを待つ。 0.70
At this time, although other services still work fine, the performance of speed inference may not have good accuracy since it still uses an “out-ofdate” model trained by the data from the time window before the unavailability of EC2. 現時点では、他のサービスは問題なく動作するが、速度推論のパフォーマンスは、ec2が使用不能になる前にタイムウィンドウからデータによってトレーニングされた“最新”モデルを使用するため、精度が良くない可能性がある。 0.64
When the whole cloud service is unavailable, that means the edge cannot get any update from the cloud. クラウドサービス全体が利用できない場合、エッジはクラウドからいかなるアップデートも取得できない。
訳抜け防止モード: クラウドサービス全体が利用できない場合、それは意味する。 エッジはクラウドから更新はできません。
0.75
In this scenario, all the flexible modules and the functionalities of Lambda Function are wrapped into AWS Greengrass runtime and deployed to the edge side. このシナリオでは、柔軟性のあるモジュールとLambda Functionの機能はすべてAWS Greengrassランタイムにラップされ、エッジ側にデプロイされる。 0.80
Based on the usage, if the stream analytics framework is only assigned to do model inference, the batch, speed and hybrid inference modules will wait for the data from data injection and output the results separately. 使用状況に基づいて、ストリーム分析フレームワークがモデル推論を行うために割り当てられている場合、バッチ、スピード、ハイブリッド推論モジュールはデータインジェクションからデータを待機し、結果を別々に出力する。 0.74
If the stream analytics framework also requires to do model training, the speed training module can be deployed to the edge device, subscribe to the data injection, fulfill speed training and synchronize the new model for next time window inference. ストリーム分析フレームワークがモデルトレーニングも必要であれば、スピードトレーニングモジュールをエッジデバイスにデプロイし、データインジェクションをサブスクライブし、スピードトレーニングを完了し、次回のウィンドウ推論のために新しいモデルを同期させることができる。 0.81
To achieve this usage, MQTT publishes and subscribes messages locally within the edge device. これを実現するためにMQTTは,エッジデバイス内でメッセージをローカルにパブリッシュし,サブスクライブする。 0.64
Specifically, the speed training 特に スピードトレーニングは 0.61
Fig. 2: The system sequence diagram for pipelines of Lambda functions for back-end processing in the cloud. 図2: クラウドでのバックエンド処理のためのLambda関数のパイプラインのシステムシーケンス図。 0.77
based solutions. Within AWS open source IoT edge runtime, called Greengrass [21], our pre-built modules can be deployed, communicated and managed on the edge through AWS web console or command line. ベースの解決策です AWSのオープンソースのIoTエッジランタイムであるGreengrass [21]では、ビルド済みのモジュールをAWS Webコンソールやコマンドラインを通じてエッジにデプロイ、通信、管理することが可能です。 0.61
Specifically, defined by AWS access control, all permitted edge-to-edge and edgeto-cloud communications are achieved by MQTT publishing and subscribing protocol. 具体的には、AWSアクセスコントロールによって定義されたすべてのエッジツーエッジとエッジツークラウド通信は、MQTTパブリッシングとサブスクライブプロトコルによって実現される。 0.49
Besides, IoT Core enables triggering rules that provide a SQL-based language to filter MQTT payloads and deliver them to the target services like Lambda Function. さらにIoT Coreでは,MQTTペイロードをフィルタリングしてLambda Functionなどのターゲットサービスに配信する,SQLベースの言語を提供するルールのトリガが可能になる。 0.73
As shown in Figure 2, filtering by the Lambda triggering rules, the incoming MQTT payloads will be delivered to different target Lambda functions as Lambda events (Step 1). 図2に示すように、Lambdaトリガルールによるフィルタリングでは、着信するMQTTペイロードはLambdaイベントとして、異なるターゲットのLambda関数に配信される(ステップ1)。 0.81
In Step 2, Lambda functions will execute these triggered events asynchronously based on their pre-defined pipeline. ステップ2では、ラムダ関数が事前に定義されたパイプラインに基づいて、これらのトリガイベントを非同期に実行する。 0.55
Prediction Results Archiving function only receives events from the inference results topic and directly stores the payloads to AWS S3 object storage. 予測結果アーカイブ機能は、推論結果トピックからイベントのみを受け取り、ペイロードを直接AWS S3オブジェクトストレージに格納する。 0.78
Data Archiving and Speed Training and Archiving functions both receive events from the streaming data topic. データアーカイブとスピードトレーニングとアーカイブ機能はどちらも、ストリーミングデータトピックからイベントを受け取る。 0.77
For Data Archiving function, just like the first function, it stores the payloads to S3 directly. データアーカイブ機能の場合、最初の関数と同じようにペイロードを直接S3に格納する。 0.81
For Speed Training and Archiving function, it will first check the AWS EC2 availability, deliver streaming data to an EC2 virtual machine for model training, and then upload the latest model to S3 when training finished. Speed Training and Archiving関数は、まずAWS EC2可用性を確認し、モデルをトレーニングするためにEC2仮想マシンにストリーミングデータを配信し、トレーニングが完了すると最新のモデルをS3にアップロードする。 0.86
In the meanwhile, in Step 3, this Lambda function will also publish a one-time pre-signed S3 URL to the edge. 一方、Step 3では、Lambda関数が1回にサインされたS3 URLをエッジにパブリッシュする。 0.71
This S3 URL is signed with cloud credentials, which grants temporary access to the edge’s model synchronization. このS3 URLはクラウド認証で署名され、エッジのモデル同期への一時的なアクセスが許可される。 0.76
IV. FLEXIBLE DEPLOYMENTS OF HYBRID STREAM IV。 ハイブリッドストリームの柔軟な展開 0.45
ANALYTICS FRAMEWORK To achieve the flexibility of the proposed hybrid stream analytics framework, we use a modular design for all frame- 分析フレーム 提案するハイブリッドストリーム分析フレームワークの柔軟性を実現するため,全フレームにモジュール設計を用いる。 0.68
Prediction results topic triggerProcess done, pre-signed URLPipelineStreaming data topic triggerProcess doneLambda function2: Data ArchivingProcess donealt[StorageToS3]Lambda function3: Speed Trainingand ArchivingStreaming data topic triggeraltInput1)MQT T subscriberreceives messages anddeliver them to thetarget Lambda function2) Lambda dataprocessing basedon pre-definedworkflowL ambda function1: Prediction Results Archivingalt[StorageToS3][SpeedTrainingOnEC2]& [ModelStorageToS3]3)MQTT publisher publish model's pre-signed URLOutput[CheckEC2Availability ]EdgeCloud Prediction results topic triggerProcess done, pre-signed URLPipelineStreaming data topic triggerProcess doneLambda function2: Data ArchivingProcess donealt[StorageToS3]Lambda function3: Speed Trainingand ArchivingStreaming data topic triggeraltInput1)MQT T subscriberreceives messages anddeliver them to thetarget Lambda function2) Lambda dataprocessing basedon pre-definedworkflowL ambda function1: Prediction Results Archivingalt[StorageToS3][SpeedTrainingOnEC2]& [ModelStorageToS3]3)MQTT publisher publish model's pre-signed URLOutput[CheckEC2Availability ]EdgeCloud 0.48
(a) Edge-centric (b) Cloud-centric (a)エッジ中心 (b)クラウド中心 0.41
(c) Edge-CloudIntegrated Batch/Speed InferenceHybrid InferenceData InjectionData SynchronizationSpeed TrainingModel/Data/P rediction ArchivingIoT CoreData InjectionData SynchronizationSpeed TrainingModel/Data/P rediction ArchivingIoT CoreBatch/Speed InferenceHybrid InferenceBatch/Speed InferenceHybrid InferenceData InjectionModel SynchronizationSpeed TrainingIoT CoreSensingSensingMo del SynchronizationSensi ng c) Edge-CloudIntegrated Batch/Speed InferenceHybrid InferenceData SynchronizationSpeed TrainingModel/Data/P rediction ArchivingIoT CoreData InjectionData SynchronizationSpeed TrainingModel/Data/P rediction ArchivingIoT CoreBatch/Speed InferenceHybrid InferenceBatch/Speed InferenceHybrid InferenceData InjectionModel SynchronizationSpeed TrainingIoT CoreSensingSensingMo del SynchronizationSensi ng 0.37
英語(論文から抽出)日本語訳スコア
TABLE I: Advantages and limitations of the proposed three deployment types for stream analytics. TABLE I: ストリーム分析のための提案された3つのデプロイメントタイプのメリットと制限。 0.66
Advantages Limitations アドバンテージ 制限 0.60
Edge Centric Cloud Centric エッジ中心 クラウド中心 0.58
Edge-cloud Integrated the computation is near to the source of data エッジクラウド統合 計算はデータの源に近い 0.67
quick respond since enough capacity and capability for high accuracy computation quick respond for inference and さっさと返事して 推論と高速な計算を行うのに十分なキャパシティと能力 0.61
high accuracy for training capacity and capability shortage for edge device 訓練の高精度化 エッジデバイスの容量と能力不足 0.78
high communication overhead 高い通信オーバーヘッド 0.77
between edge and cloud complex coordination between edge and cloud エッジとクラウドの複雑な調整は エッジとクラウドの間で 0.69
module is in a containerized Spark [22] based design. モジュールはコンテナ化されたSpark[22]ベースの設計です。 0.66
By default, it will initiate the training environment from a pulled docker image and allocate available edge resources to train the model in a Spark standalone mode. デフォルトでは、プルしたdockerイメージからトレーニング環境を開始し、利用可能なエッジリソースを割り当てて、sparkスタンドアロンモードでモデルをトレーニングする。 0.76
Our future work will study how this Spark-based speed training module can be extended to different edge devices as a distributed masterworker computing. 将来的には、このSparkベースのスピードトレーニングモジュールを、分散マスターワーカーコンピューティングとして、さまざまなエッジデバイスに拡張する方法について検討します。
訳抜け防止モード: 今後の研究は このsparkベースのスピードトレーニングモジュールは、分散マスターワーカーコンピューティングとして、異なるエッジデバイスに拡張することができる。
0.65
If there are idle edge devices, Spark will initiate these edges as workers and auto-scale the training tasks to them. アイドルエッジデバイスがある場合、Sparkはこれらのエッジをワーカーとして起動し、トレーニングタスクを自動スケールする。 0.59
This Spark-based parallel design of the speed training module also avoids the issue of limited computational capability of individual edge devices. このsparkベースのスピードトレーニングモジュールの並列設計は、個々のエッジデバイスの計算能力の制限の問題も回避している。 0.71
B. Cloud-centric Stream Analytics Deployment b. クラウド中心のストリーム分析の展開 0.58
To achieve the flexibility of the hybrid stream analytics framework, we also provide a cloud-centric deployment for stream analytics. ハイブリッドストリーム分析フレームワークの柔軟性を達成するため、ストリーム分析のためのクラウド中心のデプロイメントも提供しています。 0.64
In this scenario, as shown in Figure 3b, the edge device is only used to sense the streaming data and synchronize them to the cloud. このシナリオでは、図3bに示すように、エッジデバイスはストリーミングデータを検知してクラウドに同期するためにのみ使用される。 0.79
When the edge device cannot perform any data processing, the batch, speed, hybrid inference and model synchronization modules should be deployed on cloud computational resources like EC2. エッジデバイスがデータ処理を実行できない場合、バッチ、スピード、ハイブリッド推論、モデル同期モジュールは、EC2のようなクラウド計算リソースにデプロイされるべきである。 0.71
At this time, IoT Core service will mark the EC2 virtual machine (VM) as the substituted edge computational capability and subscribe to the MQTT payloads from EC2. このときIoT Coreサービスは、EC2仮想マシン(VM)を代替エッジ計算能力としてマークし、EC2からMQTTペイロードをサブスクライブする。 0.77
Leveraged by Lambda functions, our cloud-centric deployment achieves automatic data processing for each time window of stream analytics in the back-end cloud. lambda functionsを活用することで、当社のクラウド中心のデプロイメントは、バックエンドクラウド内のストリーム分析の時間ウィンドウ毎の自動データ処理を実現します。 0.66
Like the introduction in Section III, for the hybrid stream analytics framework, when an incoming MQTT payload triggers a filtering rule, IoT Core invokes corresponding Lambda functions asynchronously and passes the data payload from edge to the specific function. ハイブリッドストリーム分析フレームワークのセクションIIIで導入されたように、入力されるMQTTペイロードがフィルタリングルールをトリガーすると、IoT Coreは対応するLambda関数を非同期に呼び出し、エッジから特定の関数にデータペイロードを渡す。 0.80
After that, based on the pre-defined functions of data processing pipeline, Lambda will check the availability of AWS EC2 virtual machines, train the streaming data in EC2 and archive the model to the S3 object storage. その後、データ処理パイプラインの事前定義された機能に基づいて、LambdaはAWS EC2仮想マシンの可用性をチェックし、EC2でストリーミングデータをトレーニングし、モデルをS3オブジェクトストレージにアーカイブする。 0.77
Later, Lambda will reply with a one-time pre-signed S3 URL to edge, which grants the model synchronization module temporary access to synchronize the latest model from cloud. 次にLambdaは、エッジに1回の事前署名されたS3 URLで返信する。これにより、最新のモデルをクラウドから同期するためのモデル同期モジュールの一時的なアクセスが可能になる。 0.57
C. Edge-Cloud Integrated Stream Analytics Deployment C. Edge-Cloud統合ストリームアナリティクスのデプロイ 0.72
We first take a short summary about the advantages and limitations of the first two proposed deployments, as shown in Table I. 最初に、表1に示すように、最初の2つの提案されたデプロイメントの利点と制限について要約する。 0.69
For the edge-centric deployment, although all the hybrid stream analytics can run closer to the data sources, the limitation is that the weak computational capability and capacity of edge devices may cause process congestion or even crash during stream analytics. エッジ中心のデプロイメントでは、すべてのハイブリッドストリーム分析がデータソースに近づくことができるが、エッジデバイスの弱い計算能力とキャパシティは、ストリーム分析中にプロセス混雑やクラッシュを引き起こす可能性がある。 0.62
Whereas for the cloud-centric クラウド中心の立場から 0.73
deployment, all the data cannot be pre-processed before it arrivals to cloud. デプロイでは、すべてのデータがクラウドに到達する前に前処理できない。 0.73
In another word, the edge-centric deployment focus on the quick on-site response of the stream analytics and the cloud-centric deployment mainly benefits of the computing power and storage capacity of cloud. 別の言い方をすれば、エッジ中心のデプロイメントは、ストリーム分析のクイックオンサイト対応と、クラウド中心のデプロイメントは、主にクラウドのコンピューティングパワーとストレージ容量のメリットに重点を置いている。 0.54
In order to achieve the proper trade-off between these two deployment modalities, we propose a third deployment modality, namely edge-cloud integrated deployment. これら2つのデプロイメントモダリティ間の適切なトレードオフを達成するために,エッジクラウド統合デプロイメントという,第3のデプロイメントモダリティを提案する。 0.56
As shown in Figure 3c, with edge-cloud integrated deployment, all the inference and synchronization modules are developed on the edge, while speed training and all the archiving are developed on the cloud. 図3cに示すように、エッジクラウド統合デプロイメントでは、すべての推論と同期モジュールがエッジ上で開発され、スピードトレーニングとすべてのアーカイブがクラウド上で開発されている。 0.69
With this edge-centric deployment solution, hybrid stream analytics can enjoy not only the computing power and storage capacity of cloud, but also the low latency for edge resources. このエッジ中心のデプロイメントソリューションにより、ハイブリッドストリーム分析は、クラウドのコンピューティング能力とストレージ容量だけでなく、エッジリソースのレイテンシの低さを享受できる。 0.72
D. Flexible Deployment of our Framework d. フレームワークの柔軟な展開 0.78
In our hybrid stream analytics framework, we have six modules implemented as Python functions. 当社のハイブリッドストリーム分析フレームワークには,python関数として実装された6つのモジュールがあります。 0.63
For the flexible deployment, we use different ways to wrap these same modules to achieve proper coordination and trigger their invocations based on incoming stream data. 柔軟なデプロイメントでは、これら同じモジュールをラップして適切な調整を実現し、入ってくるストリームデータに基づいて呼び出しを起動します。 0.60
Specifically, we use AWS IoT Component with its Greengrass runtime for edge-based deployment and AWS Lambda function for cloudbased deployment. 具体的には、エッジベースのデプロイメントにはGreengrassランタイムでAWS IoT Componentを使用し、クラウドベースのデプロイメントにはAWS Lambda関数を使用します。 0.61
To deploy a module on edge, AWS IoT Component is required with an update interval configuration so the modules can be triggered by an AWS IoT event and the records of the time windows periodically. エッジにモジュールをデプロイするには、アップデート間隔の設定でAWS IoTコンポーネントが必要である。
訳抜け防止モード: モジュールをエッジにデプロイする。 AWS IoT Componentはアップデート間隔の設定で必要になる モジュールは、AWS IoTイベントとタイムウィンドウの記録によってトリガできる。
0.73
To deploy a module on AWS, it can be encapsulated into the docker container with its software environment. AWS上にモジュールをデプロイするには、ソフトウェア環境とともにdockerコンテナにカプセル化することができる。 0.81
In this way, the same modules and implementations can be reused when switching from one deployment to another. このように、同じモジュールと実装は、あるデプロイメントから別のデプロイメントに切り替えるときに再利用できる。 0.73
V. ADAPTIVE AND DYNAMIC HYBRID LEARNING MODEL V.適応及び動的ハイブリッド学習モデル 0.65
FOR STREAM ANALYTICS In order to tackle the challenge of concept drift, we propose a hybrid learning model, which can adapt to the changes in stream analytics by weighted combining the results from batch and speed inference. ストリーム分析用 概念ドリフトの課題に対処するために,バッチと速度推論の結果を重み付けすることで,ストリーム分析の変化に適応できるハイブリッド学習モデルを提案する。 0.63
Like the design pattern of Lambda architecture, hybrid stream analytics should contain a batch layer, a speed layer and a serving/hybrid layer. lambdaアーキテクチャの設計パターンと同様に、ハイブリッドストリーム分析はバッチ層、スピード層、サーブ/ハイブリッド層を含むべきである。 0.72
In this section, we will first provide an overview of our hybrid learning model. 本稿では,まずハイブリッド学習モデルの概要を紹介する。 0.64
Then, we introduce the orchestration of the hybrid stream analytics, and its two weight combination algorithms, namely static weighting algorithm and dynamic weighting algorithm. 次に,ハイブリッドストリーム分析のオーケストレーションと,その2つの重み付けアルゴリズム,すなわち静的重み付けアルゴリズムと動的重み付けアルゴリズムを紹介する。 0.77
英語(論文から抽出)日本語訳スコア
A. Overview of Adaptive Hybrid Stream Analytics A.Adaptive Hybrid Stream Analyticsの概要 0.92
Leveraging the lambda architecture, our hybrid stream analytics achieves adaptability of stream data concept drift. lambdaアーキテクチャを活用して、当社のハイブリッドストリーム分析は、ストリームデータコンセプトドリフトの適応性を実現しています。
訳抜け防止モード: ラムダアーキテクチャの活用 我々のハイブリッドストリーム分析は ストリームデータの概念の適応性を実現します
0.70
We first introduce problem statements of our hybrid stream analytics. まず,ハイブリッドストリーム分析の問題点ステートメントを紹介する。 0.70
In our hybrid learning model, we separate the inference tasks of stream analytics into three layers: batch layer, speed layer and hybrid layer. ハイブリッド学習モデルでは,ストリーム分析の推論タスクを,バッチ層,スピード層,ハイブリッド層という3つのレイヤに分離しています。 0.75
Batch layer tasks. For the batch layer, our hybrid learning model only trains the model once and reuses it for inference all received stream data. バッチ層タスク。 バッチ層では、ハイブリッド学習モデルは一度だけモデルをトレーニングし、受信したストリームデータを推論するために再利用します。 0.62
Its model is defined as そのモデルは定義されている 0.74
ˆyi = f (yi−1, yi−2, . . . , yi−n) yi = f (yi−1, yi−2, . , yi−n) 0.42
(2) We call the training in batch layer as the batch training and (2) バッチ層のトレーニングをバッチトレーニングと呼んでいます。 0.50
its inference as batch inference. バッチ推論としての推測です 0.40
Speed layer tasks. For the speed layer, there is no pre-trained model before the stream analytics begins. スピード層タスク。 速度層では、ストリーム分析が始まる前に事前トレーニングされたモデルはありません。 0.67
Instead, the speed layer re-trains a new model for every time window and uses it to infer the next time window data. 代わりに、スピード層は、時間ウィンドウ毎に新しいモデルを再トレーニングし、次の時間ウィンドウデータを推測するためにそれを使用する。
訳抜け防止モード: 代わりに、speed layer re - ウィンドウ毎に新しいモデルをトレーニングする そして、それを次のウィンドウデータの推定に使用します。
0.81
We define the inference task as follows. 推論タスクを次のように定義します。 0.63
For each time window t, the stream analytics trains a model ft and uses it to make predictions for the new time window t + 1. 時間ウィンドウtごとに、ストリーム分析はモデルftをトレーニングし、新しい時間ウィンドウt + 1の予測にそれを使用する。 0.69
For each timestep i within time window t + 1, the prediction value ˆyl can be defined as t+1, . . . , yi−n t+1 ) タイムウインドウ t + 1 内の各タイムステップ i について、予測値は t+1, yi−n t+1 と定義できる。 0.78
t+1 = ft(yi−1 ˆyi t+1 = ft(yi−1 )yi 0.34
t+1, yi−2 (3) t+1, yi−2 (3) 0.36
We call the training in speed layer as the speed training and スピード・レイヤーのトレーニングを スピード・トレーニングと呼んでいます 0.76
its inference as speed inference. 速度推定としての推測です 0.53
Hybrid layer task. ハイブリッドレイヤータスク。 0.63
For hybrid layer, in order to aggregate the inference results from both consistent patterns of historical data distribution and the hidden changes of streaming data distribution, its model works based on formula ハイブリッド層の場合、履歴データ分布の一貫性のあるパターンとストリーミングデータ分布の隠れた変化から推測結果を集約するために、そのモデルは公式に基づいて動作する。 0.88
P redhybrid = W s ∗ P redspeed + W b ∗ P redbatch where the weights W s +W b = 1. P redhybrid = W s ∗ P redspeed + W b ∗ P redbatch ここで、重み W s + W b = 1 となる。 0.94
The hybrid layer only has inference (no training), so that we call it as hybrid inference. ハイブリッド層は推論(トレーニングなし)しか持たないので、ハイブリッド推論と呼んでいます。 0.62
Because model training happens only once for the batch layer, referred to as Figure 4, the latency of batch training is not part of the latency occurred for incoming streaming data. モデルトレーニングは、図4と呼ばれるバッチ層で1度だけ行われるため、バッチトレーニングのレイテンシは、入ってくるストリーミングデータのレイテンシの一部ではない。 0.66
Instead, we only focus on the latency for batch inference, speed training, speed inference and hybrid inference for each time window in the paper. 代わりに、バッチ推論、スピードトレーニング、スピード推論、および論文の各タイムウィンドウのハイブリッド推論のレイテンシにのみフォーカスします。 0.57
Also, we run each module asynchronously to lower overall latency. また、各モジュールを非同期に実行して全体のレイテンシを下げます。 0.56
(4) B. Orchestration of Hybrid Stream Analytics (4) B.ハイブリッドストリーム分析のオーケストレーション 0.61
We explain how the modules of the hybrid stream analytics orchestrate, which is illustrated in Figure 4. 図4に示すハイブリッドストリーム分析オーケストレーションのモジュールについて説明する。
訳抜け防止モード: ハイブリッドストリーム分析のモジュールがどのようにオーケストレーションされるかを説明します。 図4に示します。
0.73
There exist a onetime batch training before the stream analytics start. ストリーム分析が始まる前に、一度のバッチトレーニングがある。 0.63
After that, the data injection module acts as a transfer station to throttle the amount of sensing streaming data into a payload for each time window, for example, catching streaming data every 30 seconds. その後、データインジェクションモジュールは転送ステーションとして動作し、例えば30秒毎にストリーミングデータをキャプチャするなど、時間ウィンドウ毎にペイロードにストリーミングデータをセンシングする量を制限する。 0.80
With data injection throttling, incoming streaming data can be temporarily stored in a buffer queue which avoids the receiver from the crash when absorbing the peaks of incoming data for a very short time lapse. データインジェクションのスロットリングにより、非常に短時間で受信データのピークを吸収する際に、受信側がクラッシュを回避したバッファキューに、受信したストリーミングデータを一時的に格納することができる。 0.66
Then, the data injection module delivers data based on the usages そして、データインジェクションモジュールは使用状況に基づいたデータを提供する。 0.73
Fig. 4: Module orchestration of our hybrid stream analytics. 図4: ハイブリッドストリーム分析のモジュールオーケストレーション。 0.57
(Rectangular box is for periodic operation and round box is for one-time operation.) (矩形箱は定期運転、丸箱はワンタイム運転) 0.53
of stream analytics, which contains two asynchronous phases: training phase and inference phase. ストリーム分析は、トレーニングフェーズと推論フェーズの2つの非同期フェーズを含む。 0.66
In the training phase, stream analytics executes the speed training based on the stream data in each time window. トレーニングフェーズでは、ストリーム分析が各タイムウィンドウ内のストリームデータに基づいてスピードトレーニングを実行する。 0.78
After receiving raw streaming data, the speed training module trains a new model based on the current payload batch. 生のストリーミングデータを受信した後、スピードトレーニングモジュールは、現在のペイロードバッチに基づいて、新しいモデルをトレーニングする。 0.66
Then this new trained model will be synchronized to the speed inference module for the prediction of the later stream analytics. そして、新しいトレーニングされたモデルは、後のストリーム分析を予測するために、速度推論モジュールに同期される。 0.71
In the inference phase, the stream analytics pipeline requires batch and speed inference, and the data injection module will deliver the streaming payload to the inference modules in each time window. 推論フェーズでは、ストリーム分析パイプラインはバッチとスピードの推論を必要とし、データインジェクションモジュールは各タイムウィンドウ内の推論モジュールにストリーミングペイロードを配信する。 0.74
With the design pattern of lambda architecture, batch inference module predicts results using a pre-trained model as the batch layer, which is learned from the historical dataset. ラムダアーキテクチャの設計パターンにより、バッチ推論モジュールは、過去のデータセットから学習したバッチ層として、事前トレーニングされたモデルを使用して結果を予測する。 0.64
As the speed layer, speed inference module updates its model for each time window, which uses a model learned from the previous time window and tests it in the current time window. 速度層として、速度推論モジュールは、前のタイムウィンドウから学んだモデルを使用して、現在のタイムウィンドウでテストする時間ウィンドウ毎にモデルを更新する。 0.84
And hybrid layer will aggregate the inference results both from the consistent patterns of historical data distribution and the hidden changes in streaming data distribution in both batch and speed layers. そしてハイブリッド層は、履歴データ分散の一貫性のあるパターンと、バッチ層とスピード層の両方におけるストリーミングデータ分散の隠れた変化から、推論結果を集約します。 0.76
The hybrid inference results will later be published by the MQTT publisher for archiving and further notification. ハイブリッド推論の結果は、アーカイブとさらなる通知のためにMQTTパブリッシャから公開される予定である。 0.66
C. Hybrid Learning Model With Weight Combination c. 重み結合によるハイブリッド学習モデル 0.80
In this section, we introduce the two weight combination この節では 2つの重みの組み合わせを紹介します 0.69
algorithms for hybrid inference. ハイブリッド推論のためのアルゴリズムです 0.71
Static Weighting Algorithm. 静的重み付けアルゴリズム。 0.61
The weight combination algorithm can be defined as the static weighting algorithm if the weights W s and W b (in Equation 4) are been set as a fixed value for every time window of the stream analytics. 重み付けアルゴリズムは、ストリーム解析の時間ウィンドウ毎に、重み付けWsとWb(方程式4)が固定値として設定されている場合、静的重み付けアルゴリズムとして定義することができる。 0.75
Because of the fixed weights, it is obvious that the hybrid learning model with the static weighting algorithm is hard to adapt to the dynamic changes of streaming data. 固定重み付けにより、静的重み付けアルゴリズムを用いたハイブリッド学習モデルでは、ストリーミングデータの動的変化に適応することが困難であることは明らかである。 0.84
To solve this problem, we provide an optimized approach to dynamically learn the weights during stream analytics, namely dynamic weighting algorithm. この問題を解決するために,ストリーム解析中の重みを動的に学習する最適化手法,すなわち動的重み付けアルゴリズムを提案する。 0.84
Dynamic Weighting Algorithm. 動的重み付けアルゴリズム。 0.73
We discuss our hybrid learning model with a dynamic weighting algorithm in this section. 本稿では,動的重み付けアルゴリズムを用いたハイブリッド学習モデルについて述べる。 0.86
In theory, finding the dynamic weights is a mathematical optimization problem that is used to find the best solution from all feasible solutions. 理論的には、動的重みの発見は、すべての実現可能な解から最良の解を見つけるために使われる数学的最適化問題である。
訳抜け防止モード: 理論上 動的重みを見つけることは 数学的最適化の問題です すべての可能な解決策から 最良の解決策を見つけるために使われます
0.77
Shifting it to a machine learning problem, stacking ensemble methods [23, 24] combine multiple machine learning algorithms to obtain a better predictive 機械学習問題にシフトし、アンサンブル手法[23, 24]を積み重ねることで、複数の機械学習アルゴリズムを組み合わせてより良い予測結果を得る 0.79
Speed InferenceHybrid InferencePredictionA rchivingSpeedTrainin gModel SynchronizationSensi ng DataData InjectionData SynchronizationModel ArchivingDataArchivi ngHistorical DataOne-time batchtrainingBatch Inference Speed InferenceHybrid InferencePredictionA rchivingSpeedTrainin gModel SynchronizationSensi ng DataData InjectionData SynchronizationModel ArchivingDataArchivi ngHistorical DataOne-time batchtrainingBatch Inference 0.11
英語(論文から抽出)日本語訳スコア
performance than that could be obtained from any of the constituent learning algorithms alone. それらよりもパフォーマンスは、いずれの構成要素学習アルゴリズムからでも得ることができる。 0.67
Based on these ideas, we propose our dynamic weighting algorithm. これらの考え方に基づき, 動的重み付けアルゴリズムを提案する。 0.83
Algorithm 1: Dynamic Weighting Algorithm (DWA) Input: M b, M s t−1, X test Output: W b t ,W s t アルゴリズム1:動的重み付けアルゴリズム (DWA) 入力: M b, M s t−1, X test 出力: W b t , W s t 0.83
t−1 , Y test t−1 t−1, y試験t−1 0.66
function DWA(): EnsembleM odels ← [ ] P red ← [ ] EnsembleM odels.append(M b, M s for model in EnsembleM odels do 関数 DWA() EnsembleM odels > [ ] P red > [ ] EnsembleM odels.append(M b, M s for model in EnsembleM odels do
訳抜け防止モード: 関数 DWA() EnsembleM odels > [ ] P red > [ ] EnsembleM odels.append(M b, EnsembleM odels におけるモデルのための M s
0.78
t−1) P red.append(model.pre dict(X test t−1) である。 P red.append(model.pre dict(X test) 0.38
t−1 )) end W init = [0.5] ∗ len(P red) cons = lambda W : 1 − sum(W ) bounds = [(0, 1)] ∗ len(P red) loss = LossF unc(Y test t−1 , P red) W b t−1) である。 end W init = [0.5] ∗ len(P red) cons = lambda W : 1 − sum(W ) bounds = [(0, 1)] ∗ len(P red) loss = LossF unc(Y test t−1 , P red) W b 0.44
t , W s return W b t, W s w b を返します。 0.47
t , W s t to Output t, W s t から出力する 0.65
t ← minimize(loss, W init, bounds, cons, Solver) 最小化(loss, w init, bounds, cons, solver) 0.33
As shown in Algorithm 1, for each time window t, taking the inputs of batch layer model M b, speed layer model M s t−1 at time window t− 1 with the test dataset X test t−1 , the dynamic weighting algorithm stacks the provided models and collects their predictions using the test dataset as the serving layer. アルゴリズム1に示すように、時間ウィンドウt毎に、バッチ層モデルMb、時間ウィンドウt−1における速度層モデルMst−1とテストデータセットXテストt−1とを合わせて、動的重み付けアルゴリズムは、提供されたモデルを積み重ねて、テストデータセットをサービス層として収集する。 0.75
By listing the constraints and bounds, like limiting the sum t = 1) and limiting the of weights to equal 1 (W b in range [0, 1], the optimization solver will weights W b find the optimum values that can minimize the objective loss function, starting from an initial guess W init (we choose 0.5 as our initial weights). 和 t = 1 を制限し、重みを 1 (w b in range [0, 1]) に制限するなど、制約と境界をリストアップすることで、最適化ソルバは、初期推定値 w init から始めて、目標損失関数を最小化できる最適な値を求める(初期重みとして0.5 を選ぶ)。 0.76
In our paper, we use Sequential Least Squares Programming (SLSQP) [25] as the optimization solver Solver, which is always used to solve nonlinear programming (NLP) problems. 本稿では,非線形プログラミング(NLP)問題を常に解くために使用される最適化ソルバーとして,SLSQP (Sequential Least Squares Programming) [25] を用いる。 0.81
We also use Root Mean Squared Error [26] regression loss as our loss function LossF unc that can be defined as 損失関数 LossF unc として Root Mean Squared Error [26] の回帰損失も使用しています。 0.73
t + W s t , W s t t + W s t, W s t 0.42
Lrmse(y) = Lrmse(y) = 0.43
(yj − ˆyj)2 (yj − syj)2 0.35
(5) (cid:118)(cid:117)(c id:117)(cid:116) 1 (5) (cid:118)(cid:117)(c id:117)(cid:116)1 0.39
n n(cid:88) j=1 n n(第88回) j=1 0.44
which is the square root of the average of squared differ- 正方形の差の平均の平方根です 0.59
ences between prediction ˆyj and actual observation yj. 予測yjと実際の観測yjの一致。 0.70
In our algorithm implementation, at each time window t, we stack two pre-trained models in the serving layer, which include one speed layer model at time window t − 1 and the batch layer model. アルゴリズムの実装では、各時間ウィンドウtで、時間ウィンドウt-1における1つの速度層モデルとバッチ層モデルを含む2つの事前学習されたモデルをサービス層に積み重ねる。 0.83
Since the ensemble method does not require a constant pattern for stacking models from batch or speed layer, the dynamic weighting algorithm also has its variants like stacking the most resent n speed layer models or stacking speed layer models continuously. アンサンブル法は、バッチ層やスピード層からモデルを積み上げるのに一定のパターンを必要としないので、動的重み付けアルゴリズムは、最も強い n 速層モデルやスタックング速層モデルを連続的に積み重ねるなど、その変種も持っている。
訳抜け防止モード: アンサンブル法はバッチ層や速度層からモデルを積み重ねるために一定のパターンを必要としない。 動的重み付けアルゴリズムには 最強のnスピード層モデルを積み重ねるか、または連続的にスピード層モデルを積み重ねる。
0.78
We will study these variants as part of our future work. 我々はこれらの変種を今後の研究の一部として研究する。 0.52
This section conducts the evaluation of our proposed flexible and dynamic hybrid stream analytics framework. 本稿では,提案するフレキシブルで動的なハイブリッドストリーム分析フレームワークの評価を行う。 0.72
We imple- VI. EVALUATION です。 VI。 評価 0.52
mented our framework and open-sourced it on GitHub at []. フレームワークをメンテッドし、githubで[]オープンソース化しました。 0.64
One real-world and two synthetic datasets are applied in our experiments and the metric includes latency and accuracy. 1つの実世界と2つの合成データセットを実験に応用し、測定基準にはレイテンシと精度が含まれている。 0.55
The evaluation compares the difference in two aspects: 評価は2つの側面の違いを比較する。 0.72
1) different types of hybrid learning framework deployment and 1)ハイブリッド学習フレームワークの展開と展開の異なるタイプ 0.89
2) different types of hybrid stream analytics approaches. 2)異なるタイプのハイブリッドストリーム分析アプローチ。 0.72
A. Datasets and Evaluation Settings A.データセットと評価設定 0.82
1) Dataset description: We use one real-world dataset and two simulated datasets for gradual drifts and abrupt drifts, in order to evaluate our proposed edge-cloud integrated framework. 1) データセットの説明: 提案したエッジクラウド統合フレームワークを評価するために,実世界のデータセットと2つのシミュレーションデータセットを段階的なドリフトと突然ドリフトに使用しています。 0.68
The data distributions of each dataset are shown in Figure 5. 各データセットのデータ分布を図5に示す。 0.78
One real-world dataset. 現実世界のデータセット。 0.64
Our application is designed for the real-world prediction of wind turbine temperature, based on the ENGIE’s open wind farm data [27]. 本研究は, ERIE のオープン風力発電データ [27] に基づいて, 実世界の風力タービン温度の予測を行うために設計されている。 0.76
For the actual data distribution of wind turbine temperature, as shown in Figure 5a, we use one turbine time series (from five temperature sensors) from January to December in 2017, recorded every 10 minutes, which has around 50,000 observations in total. 風力タービンの温度の実際のデータ分布については、図5aに示すように、2017年1月から12月にかけてのタービン時系列(5つの温度センサ)が10分毎に記録され、合計で約50,000回の観測が行われている。
訳抜け防止モード: 図5aに示す風力タービン温度の実データ分布について 2017年1月から12月までの1つのタービンタイムシリーズ(5つの温度センサーから)を使用します。 10分ごとに記録され 計5万回観測されています
0.82
In order to check concept drifts and data stationary for each variable in actual time-series, we perform the augmented Dickey-Fuller test [28], which is used to determine how strongly a series is defined by a trend by calculating the corresponding p-value [29]. 実時系列の各変数に対する概念ドリフトとデータの定常性をチェックするために,拡張ディッキー・フラー検定 [28] を実施し,対応するp値 [29] を計算することにより,系列がトレンドによってどの程度強く定義されているかを決定する。 0.76
The null hypothesis of the test is that the tested series have a certain time-dependent structure (namely not stationary). テストのヌル仮説は、テストされた系列が一定の時間依存構造を持つ(つまり定常ではない)ことである。 0.66
The p-values of the five variables, namely Db1t_avg, Db2t_avg, Gb1t_avg, Gb2t_avg to be 1.82 × e−22, 3.34 × e−17, and Ot_avg, 3.44×e−20, 2.38×e−17 and 4×e−6, respectively. Db1t_avg, Db2t_avg, Gb1t_avg, Gb2t_avgをそれぞれ1.82×e−22, 3.34×e−17, Ot_avg, 3.44×e−20, 2.38×e−17, 4×e−6とする。 0.61
Since these values are less than 0.05, we can reject our null hypothesis and conclude that the time series is stationary without concept drifts. これらの値は 0.05 未満なので、零仮説を否定し、時系列は概念のドリフトなしで定常であると結論付けることができる。 0.64
We use this actual dataset in our no drift scenario. 私たちはこのデータセットをドリフトのないシナリオで使用しています。 0.60
Two synthetic datasets. 2つの合成データセット。 0.59
In order to evaluate the adaptiveness of our hybrid learning dealing with streaming data concept drifts, we synthetically generate two datasets and simulate gradual drifts and abrupt drifts on each of them, as shown in Figures 5b and 5c. ストリーミングデータの概念ドリフトを扱うハイブリッド学習の適応性を評価するため、図5b,5cに示すように、2つのデータセットを合成し、段階的なドリフトと突然ドリフトをシミュレートする。 0.76
turn out Let GDi(t) and ADi(t) be the generated gradual and abrupt drift value of target variable at timestamp t, and Yi(t) be the true value of input feature, where i ∈ [0 . . . n]. オフにしろ GDi(t) と ADi(t) をタイムスタンプ t における対象変数の漸進的および突然のドリフト値とし、Yi(t) を入力特徴の真の値とし、i ∈ [0 .n] とする。 0.65
For gradual drift scenario and abrupt drift scenario, the simulation rule for all n variables is specified as Equations 6 and 7 separately, where αi is the drift value for variable i, ε is an invariant noise and λ is the random abrupt parameter. 段階的なドリフトシナリオと突然ドリフトシナリオでは、全ての n 変数のシミュレーションルールを方程式 6, 7 として別々に指定し、ここで αi は変数 i のドリフト値、ε は不変ノイズ、λ は乱数アブルプットパラメータである。 0.81
GDi(t) = αit + Yi(t) + ε GDi(t) = αit + Yi(t) + ε 0.46
ADi(t) = αitλ + Yi(t) + ε ADi(t) = αitλ + Yi(t) + ε 0.49
(6) (7) 2) Machine learning setting: For the evaluation of no-drift, gradual drift and abrupt drift scenario, we split the modeling dataset into training and testing subsets with the ratio of 4 : 6. (6) (7) 2) 機械学習の設定: ドリフト, 段階的ドリフト, 急激なドリフトシナリオの評価のために, モデルデータセットを4 : 6の比率でトレーニングおよびテストサブセットに分割した。 0.55
We use 20,000 observations to produce a pre-trained model for batch inference, and send 30,000 observations as streaming data in each time window to test our hybrid learning analytics. バッチ推論のためにトレーニング済みのモデルを生成するために20,000の観測結果を使用し、各時間に3万の観測データをストリーミングデータとして送信し、ハイブリッド学習分析をテストする。 0.64
英語(論文から抽出)日本語訳スコア
(a) No-Drift Data (for all five variables). (a) ドリフトなしデータ(5つの変数すべてについて)。 0.64
(b) Gradual-Drift Data (for target variable). b) Gradual-Drift Data(ターゲット変数) 0.69
(c) Abrupt-Drift Data (for target variable). (c)Abrupt-Drift Data(ターゲット変数) 0.72
Fig. 5: Data distribution for one real-world and two synthetic time-series of wind turbine temperature. 図5:風力タービン温度の1つの実世界と2つの合成時系列のデータ分布 0.85
The data from all five variables are been normalized using Min-Max Scaling to the range of [0, 1] during computation. 5変数すべてからのデータは、Min-Max Scalingを使って計算中に[0, 1]の範囲に正規化されます。 0.73
Settings for model training. モデルトレーニングの設定。 0.67
We run a multilayer-perceptio n long short-term memory (LSTM) network shown in Figure 6, which has one long short-term memory layer with 40 units, one fully connected layer with 10 units and ReLu activation, and one final output layer (10,981 total parameters). 図6に示す多層型long short-term memory (lstm)ネットワークは、40ユニットからなる1つの長期短期記憶層、10ユニットとreluアクティベーションを持つ1つの完全接続層と1つの最終出力層(合計パラメータ10,981)を有する。 0.83
For the pre-train model used in batch inference, we train the model using 50 epochs and 512 batch sizes with a 0.001 learning rate. バッチ推論に使用するプリトレインモデルでは,50エポックと512バッチサイズで0.001の学習率でモデルをトレーニングする。 0.80
For the speed model in each time window, we use 100 epochs and 64 batch sizes with a 0.001 learning rate. 各タイムウィンドウの速度モデルでは、100エポック、64バッチサイズ、0.0001の学習レートを使用します。 0.73
Because this study focuses on hybrid learning and its deployment on edge-cloud resources, we did not employ more complicated RNN deep learning models, which can be easily evaluated in future work. 本研究は,ハイブリッド学習とエッジクラウドリソースへの展開に焦点を当てているため,今後の作業で容易に評価可能な,より複雑なRNNディープラーニングモデルを採用できなかった。 0.81
Fig. 6: LSTM network architecture. 図6: LSTMネットワークアーキテクチャ。 0.70
Settings for model inference. Our batch inference loads the pre-trained model in each time window and makes predictions for the records in the current time window. モデル推論の設定。 バッチ推論では,事前学習したモデルを各タイムウィンドウにロードし,現在のタイムウィンドウにおけるレコードの予測を行う。 0.66
We set the time window size equal to 30 seconds in all experiments and throttle no less than 200 records in each time window. すべての実験でタイムウインドウのサイズを30秒に設定し、各タイムウインドウで200レコード未満のスロットルをしました。 0.72
For speed inference, we have three parallel processes, which include 速度推定には3つの並列プロセスがあります。 0.71
1) fetching the latest pre-trained model from S3 and saving it to the edge disk; 1) 最新の事前学習済みモデルをs3からフェッチし,エッジディスクに保存する。 0.69
2) loading the latest pre-trained model from the edge disk and making a prediction for the current time window; and 2)最新の事前訓練済みモデルをエッジディスクからロードし,現在の時刻ウィンドウの予測を行う。 0.81
3) training a new LSTM model based on the current time window and uploading the model to S3. 3) 現在の時刻ウィンドウに基づいて新しいLSTMモデルをトレーニングし、モデルをS3にアップロードする。 0.88
Because the three processes run in parallel, we cannot guarantee to use the model trained from the previous time window to infer the current time window. 3つのプロセスが並行して実行されるため、以前のタイムウィンドウからトレーニングされたモデルを使用して現在のタイムウィンドウを推測することは保証できません。 0.72
But this approach can improve the latency dramatically. しかし、このアプローチはレイテンシを劇的に改善できる。 0.59
For the hybrid inference, the predicted value of each record is calculated from its batch and speed inference prediction. ハイブリッド推論では、各レコードの予測値をそのバッチと速度予測予測から算出する。 0.60
t+1, yi−2 t+1, ..., yi−n t+1, yi−2 t+1, ..., yi−n 0.34
As the problem statement in Section V-A, assuming values for yi−1 t+1 are known when making predictions (same with batch inference without the time window t). 第v-a節における問題文として、yi−1 t+1 の値の仮定は、予測を行う際に知られている(タイムウィンドウ t のないバッチ推論と同じ)。 0.59
We evaluate the prediction performance by calculating RMSE between predictions ˆyi t+1. 予測間のrmseを計算することで予測性能を評価する。 0.69
In the t+1 and actual observations yi paper, we set the time lag to be 5, namely n = 5. t+1 および実際の観測 yi 紙において、時間ラグを 5 とし、すなわち n = 5 とする。 0.85
3) Hardware and software setting: 3) ハードウェア及びソフトウェアの設定 0.77
Hardware settings. For our experiments, we use a Raspberry Pi 4 as our front-end on-premise edge device, which is attached with the 32GB MicroSD memory card and 4GB RAM. ハードウェア設定。 実験では、Raspberry Pi 4をフロントエンドのオンプレミスエッジデバイスとして使用し、32GBのmicroSDメモリカードと4GBのRAMを搭載しています。 0.78
We use Amazon Web Services as our back-end cloud platform. バックエンドのクラウドプラットフォームとしてAmazon Web Servicesを使用しています。 0.61
A data analytics server is deployed on AWS EC2, which allocate to a compute-optimized c5.4xlarge instance with 16 virtual CPUs (vCPUs) and 32GB of memory. データ分析サーバはAWS EC2上にデプロイされ、計算最適化されたc5.4xlargeインスタンスに16仮想CPU(vCPU)と32GBのメモリを割り当てる。 0.75
Software settings. For the software environment on the edge, we use Debian 11 Bullseye OS with Python 3.8. ソフトウェア設定。 エッジのソフトウェア環境では、Debian 11 Bullseye OSとPython 3.8を使用します。 0.79
The dependencies on edge include Tensorflow-lite 2.5, Spark 3.0 and Pandas for inference learning, Kafka 3.1 for data injection, and AWS SDK Boto3 for edge-cloud data and model synchronization. エッジへの依存関係には、推論学習用のTensorflow-lite 2.5、Spark 3.0、Pandas、データインジェクション用のKafka 3.1、エッジクラウドデータとモデル同期用のAWS SDK Boto3などがある。 0.60
The Kafka data injection bandwidth is around 7 records/second in our experiments. Kafkaのデータインジェクションの帯域幅は、我々の実験で約7レコード/秒です。 0.64
Meanwhile, the software environment on the cloud is encapsulated in our public Docker image, which contains Tensorflow 2.2, Spark 3.0 and Pandas for model training and also Boto3 for synchronization. 一方、クラウド上のソフトウェア環境は、モデルトレーニング用のtensorflow 2.2、spark 3.0、pandas、同期用のboto3を含む公開dockerイメージにカプセル化されています。 0.72
Both our software environments support the Spark big data analytics engine, which enables parallel computation on two sides. 当社のソフトウェア環境はどちらもsparkビッグデータ分析エンジンをサポートしており、両サイドで並列計算を可能にしています。
訳抜け防止モード: 両方のソフトウェア環境はSparkビッグデータ分析エンジンをサポートしています。 両面の並列計算を可能にします
0.75
B. Latency evaluation for different types of deployment B. 異なる種類の展開のための遅延評価 0.75
We first evaluate the performance of hybrid learning framework with the three deployment types explained in Section IV. まず,第4節で説明した3つのデプロイタイプを用いて,ハイブリッド学習フレームワークの性能を評価する。 0.64
Since the deployment modalities, including edgecentric, cloud-centric and edge-cloud integrated, only change the resources where the modules are deployed in, the stream analytics still executes based on the same logic which results in the same accuracy performance. エッジ中心、クラウド中心、エッジクラウドの統合を含むデプロイメントのモダリティは、モジュールがデプロイされるリソースだけを変更するため、ストリーム分析は同じロジックに基づいて実行され、同じ精度のパフォーマンスが得られる。 0.66
Therefore, we only evaluate their latency. したがって、レイテンシは評価するだけです。 0.51
We separate the pipeline of stream analytics into two phases: inference phase and training phase. ストリーム分析のパイプラインを推論フェーズとトレーニングフェーズの2つのフェーズに分離します。 0.73
These two phases work asynchronously as illustrated in Figure 4. この2つのフェーズは図4に示すように非同期に動作します。 0.60
In inference phase, starting from data injection to prediction archiving, we record both computation latency and communication latency for each 推論フェーズでは、データインジェクションから予測アーカイブまで、計算遅延と通信遅延の両方をそれぞれ記録します。 0.72
01000020000300004000 050000Streaming data020406080Value05 00010000150002000025 00030000Streaming data010203040ValueNo driftGradual drift050001000015000 200002500030000Strea ming data0102030405060Val ueAbrupt driftNo driftLSTMFC2 +ReLu (10)Dense3 (1)LSTM1 (40)Data batch 1Data batch 1Data batch 1Inferenceprediction 1 01000020000300000000 00000000 ストリーミングデータ020406080value050005 00010000150000250003 0000 ストリーミングデータ010203040valueno ドリフト段階ドリフト05000500010000150002 00002500030000stream ingデータ0102030405060valueab rupt driftno driftlstmfc2 +relu (10)dense3 (1)lstm1 (40)data batch 1data batch 1data batch 1inferenceprediction 1 0.45
英語(論文から抽出)日本語訳スコア
TABLE II: The latency of inference phase for different stream analytics with three deployment (unit: second). 表 ii: 3つのデプロイによる異なるストリーム分析のための推論フェーズの待ち時間(ユニット:2)。 0.64
Speed Inference Batch Inference 速度推定 バッチ推論 0.57
Serving/Hybrid Inference サービス/ハイブリッド推論 0.44
Computation Communication Total Computation Communication Total Computation Communication Total 40.12 35.71 35.64 計算通信トータル計算通信トータル40.12 35.71 35.64 0.80
22.70 17.08 16.64 22.70 17.08 16.64 0.24
23.01 17.26 18.03 23.01 17.26 18.03 0.24
23.65 27.19 26.71 23.65 27.19 26.71 0.24
8.49 10.65 10.83 8.49 10.65 10.83 0.24
13.88 6.83 6.75 13.88 6.83 6.75 0.24
14.52 6.61 7.20 14.52 6.61 7.20 0.24
Cloud Centric Edge Centric クラウド中心のエッジ中心 0.61
Edge-cloud Integrated 8.82 10.25 9.89 エッジクラウド統合 8.82 10.25 9.89 0.50
16.47 8.52 8.93 16.47 8.52 8.93 0.24
time window, then we calculate their averages over all time windows and show the results in Table II. 時間ウィンドウでは、すべての時間ウィンドウ上で平均値を計算し、結果をテーブルIIで表示します。 0.76
The table shows edge-centric and edge-cloud integrated deployment are more efficient than cloud-centric deployment because of their small communication overheads. エッジ中心のデプロイメントとエッジクラウドの統合デプロイメントは、通信オーバーヘッドが少ないため、クラウド中心のデプロイメントよりも効率的である。 0.53
For edge-centric and edge-cloud integrated deployment, they have roughly the same latency in inference phase since their module deployments are exactly the same, except the speed training (refer in Figure 3). エッジ中心およびエッジクラウド統合デプロイメントでは、速度トレーニング(図3参照)を除いて、モジュール配置がまったく同じであるため、推論フェーズではほぼ同じレイテンシを持つ。 0.72
Next in the training phase, starting from data injection to model synchronization, we only measure the average computation and the communication latency for speed layer, since batch layer only trains a model once and hybrid layer does not have the training phase. 次に、トレーニングフェーズでは、データインジェクションからモデル同期まで、バッチ層がモデルのみをトレーニングし、ハイブリッド層がトレーニングフェーズを持っていないため、速度層の平均計算と通信待ち時間を測定するだけです。 0.74
For cloud-centric deployment, the average latency of speed layer are 14.73 seconds for computation, 14.47 seconds for communication, and 29.20 seconds in total. クラウド中心のデプロイメントでは、平均速度層のレイテンシは計算時間14.73秒、通信時間14.47秒、合計29.20秒である。 0.68
For the edge-cloud integrated deployment, the average latency are 15.69, 14.04 and 29.73 seconds, respectively. エッジクラウド統合デプロイメントでは、平均レイテンシは15.69秒、14.04秒、29.73秒である。 0.47
These two deployment modalities perform in the same trend since their speed training modules are both deployed in cloud. スピードトレーニングモジュールはどちらもクラウドにデプロイされるため、これら2つのデプロイモードは同じ傾向で実行される。 0.64
For edge-centric deployment, the speed training module should be deployed in edge resource (refer in Figure 3). エッジ中心のデプロイメントでは、スピードトレーニングモジュールをエッジリソースにデプロイする必要がある(図3参照)。 0.74
We also evaluated the edge-centric deployment with our Raspberry Pi edge device, but the experiment failed with out-of-memory error. 当社のraspberry pi edgeデバイスでエッジ中心のデプロイメントも評価しましたが、メモリ外エラーで失敗しました。 0.60
It shows the edge device with a limited capacity cannot supports this type of deployment. 限られた容量のエッジデバイスでは、この種のデプロイメントはサポートできない。 0.62
So, if we compare the total latency (inference and training), edge-cloud integrated deployment is the best. ですから,全体のレイテンシ(参照とトレーニング)を比較するならば,エッジクラウド統合デプロイメントが最も適しています。 0.66
In summary, for three deployment modalities, edge-cloud integrated deployment works best, as its efficiency in inference phase and the sufficient capacity in training phase. まとめると、3つのデプロイメントモードにおいて、エッジクラウド統合デプロイメントは、推論フェーズの効率とトレーニングフェーズの十分なキャパシティとして最適です。 0.57
Specially, comparing with the other two deployments, the edge-cloud deployment can achieve similar latency performance as edgecentric deployment without worrying about capacity limita- 特に、他の2つのデプロイメントと比較すると、エッジクラウドデプロイメントは、容量制限を気にすることなく、エッジ中心のデプロイメントと同様のレイテンシパフォーマンスを実現することができる。 0.44
tions. Therefore, for the rest of our evaluation, we only conduct experiments with the edge-cloud integrated deployment. イオンだ したがって、残りの評価のためには、エッジクラウド統合デプロイメントでのみ実験を行います。 0.45
C. Latency and accuracy evaluation for different stream analytics approaches c. 異なるストリーム分析手法のレイテンシと精度評価 0.84
We focus on both latency and accuracy aspects when evaluating our adaptive hybrid stream analytics approaches. 適応型ハイブリッドストリーム分析アプローチを評価する場合、レイテンシと精度の両方に重点を置いています。 0.60
For latency, we measure overhead created by stream analytics. レイテンシでは、ストリーム分析によって生成されたオーバーヘッドを測定します。 0.40
For accuracy, we compare its performance with the proposed dynamic weighting algorithm in different streaming concept drift scenarios. そこで,提案する動的重み付けアルゴリズムの性能を,異なるストリーミングコンセプトドリフトシナリオで比較した。 0.70
For the dynamic weighting algorithm, we evaluate the stacking of two pre-trained models (one latest speed model and one batch model) as explained in Section V-C. 動的重み付けアルゴリズムでは、セクションV-Cで説明されている2つの事前学習モデル(最新の速度モデルと1つのバッチモデル)の積み重ねを評価する。 0.78
1) Latency evaluation: We first discuss the latency of hybrid stream analytics with static weighting and dynamic weighting. 1)レイテンシ評価: 静的重み付けと動的重み付けによるハイブリッドストリーム分析のレイテンシをまず議論する。 0.76
As shown in Figure 7, we record the latency of execution in every streaming time window which includes around 200 streaming observations. 図7に示すように、約200のストリーミング観測を含むすべてのストリーミング時間ウィンドウにおける実行遅延を記録します。 0.80
The latencies of speed and batch inference are in the same trend and they are both lower than the latency of hybrid inference. 速度とバッチ推論のレイテンシは同じ傾向にあり、どちらもハイブリッド推論のレイテンシよりも低い。
訳抜け防止モード: 速度とバッチ推論の遅延は同じ傾向にあります どちらもハイブリッド推論のレイテンシよりも低いのです。
0.63
Since speed and batch inference are executing in parallel and their latencies have overlap, we also evaluate the total latency for the whole hybrid stream analytics. 速度とバッチの推論が並列に実行され,そのレイテンシが重複しているため,ハイブリッドストリーム解析全体のレイテンシも評価する。 0.74
With static weighting in Figure 7a, 図7aの静的重み付けで。 0.67
the latencies averaged from all time windows are: 10.43 seconds for speed inference, 9.93 for batch, 15.81 for hybrid and 26.63 for, respectively. 速度推定は10.43秒、バッチは9.93秒、ハイブリッドは15.81秒、ウィンドウは26.63秒である。 0.61
And with dynamic weighting in Figure 7b, the average latencies are 10.25, 10.63, 18.34 and 29.19 seconds, respectively. 図7bの動的重み付けでは、平均レイテンシはそれぞれ10.25、10.63、18.34、29.19秒である。 0.54
Since the weight combination algorithm is only applied in hybrid inference, the latencies of speed and batch inference are roughly the same in the two evaluations. 重み付けアルゴリズムはハイブリッド推論にのみ適用されるため,2つの評価において,速度とバッチ推論のレイテンシはほぼ同じである。 0.82
For the hybrid inference and the overall hybrid stream analytics, the percentage of average latency increment of dynamic weighting ハイブリッド推論とハイブリッドストリーム解析の全体について : 動的重み付けの平均レイテンシ増加率 0.68
Fig. 7: Inference and total latency of hybrid stream analytics for edge-cloud integrated deployment. 図7:エッジクラウド統合デプロイメントのためのハイブリッドストリーム分析の推論と全レイテンシ。 0.78
(a) Static weighting. (a)静的重み付け。 0.54
(b) Dynamic weighting. (b)動的重み付け。 0.73
020406080100Streamin g time window10152025303540 45Latency (s)SpeedBatchHybridT otal020406080100Stre aming time window10152025303540 45Latency (s)SpeedBatchHybridT otal 020406080100Streamin g time window101520253545La tency (s)SpeedBatchHybridT otal020406080100Stre aming time window101520253545La tency (s)SpeedBatchHybridT otal 0.39
英語(論文から抽出)日本語訳スコア
E S M R e s m r である。 0.45
0.15 0.14 0.13 0.12 0.11 0.1 9 · 10−2 8 · 10−2 7 · 10−2 6 · 10−2 5 · 10−2 4 · 10−2 3 · 10−2 0.15 0.14 0.13 0.12 0.11 0.1 9 · 10−2 8 · 10−2 7 · 10−2 6 · 10−2 5 · 10−2 4 · 10−2 3 · 10−2 0.31
Speed Batch Hybrid (3/7) 速度 バッチハイブリッド(3/7) 0.71
Hybrid (5/5) ハイブリッド(5/5) 0.74
Hybrid (7/3) ハイブリッド(7/3) 0.71
Hybrid (dynamic) ハイブリッド (ダイナミック) 0.72
(a) No-Drift Data. (a)ノドリフトデータ。 0.67
E S M R e s m r である。 0.45
0.13 0.12 0.11 0.13 0.12 0.11 0.29
0.1 9 · 10−2 8 · 10−2 7 · 10−2 6 · 10−2 5 · 10−2 4 · 10−2 3 · 10−2 2 · 10−2 0.1 9 · 10−2 8 · 10−2 7 · 10−2 6 · 10−2 5 · 10−2 4 · 10−2 3 · 10−2 2 · 10−2 0.35
E S M R e s m r である。 0.45
0.33 0.32 0.31 0.3 0.29 0.28 0.27 0.26 0.25 0.24 0.23 0.22 0.21 0.2 0.19 0.18 0.33 0.32 0.31 0.3 0.29 0.28 0.27 0.26 0.25 0.24 0.23 0.22 0.21 0.2 0.19 0.18 0.20
Hybrid (dynamic) ハイブリッド (ダイナミック) 0.72
Speed Batch Hybrid (3/7) 速度 バッチハイブリッド(3/7) 0.71
Hybrid (7/3) (b) Gradual-Drift Data. ハイブリッド (7/3) (b) 段階的ドリフトデータ。 0.65
Hybrid (5/5) ハイブリッド(5/5) 0.74
Speed Batch Hybrid (3/7) 速度 バッチハイブリッド(3/7) 0.71
Hybrid (7/3) (c) Abrupt-Drift Data. hybrid (7/3) (c) abrupt-driftデータ。 0.64
Hybrid (5/5) ハイブリッド(5/5) 0.74
Hybrid (dynamic) ハイブリッド (ダイナミック) 0.72
Fig. 8: RMSE box-plots for different inference approaches. 図8: 異なる推論アプローチのためのRMSEボックスプロット。 0.78
(a) No-Drift Data. (a)ノドリフトデータ。 0.67
(b) Gradual-Drift Data. (b)段階的なドリフトデータ。 0.57
(c) Abrupt-Drift Data. (c)突然のドリフトデータ。 0.60
Fig. 9: RMSE of each time window for batch, speed and dynamic hybrid inference. 第9図:バッチ、スピード、動的ハイブリッド推論のための各タイムウィンドウのrmse。 0.71
turn out to be 14.82% and 9.54%, compared with static weighting. 静的な重み付けに比べて14.82%と9.54%でした 0.78
The increment is because our dynamic approach requires time to find the best weights. インクリメントは、私たちの動的なアプローチが最高のウェイトを見つけるのに時間を要するためです。 0.44
2) Accuracy evaluation: To evaluate accuracy performance of hybrid stream analytics, we use Root Mean Squared Error (RMSE) metric to measure how far the predicted values ˆyj are from the ground-truth values yj, as mentioned in Equation 5. 2) 精度評価: ハイブリッドストリーム解析の精度評価のために, 式5で述べたように, 予測値 syj が接地値 yj からどこまで離れているかを測定するために, 根平均二乗誤差(rmse)指標を用いた。 0.82
We compare the performance of hybrid stream analytics in three data drifting scenarios with two weight combination algorithms. 2つの重み付けアルゴリズムを用いて3つのデータドリフトシナリオにおけるハイブリッドストリーム解析の性能を比較した。 0.73
We record the RMSE of inference results for each streaming time window (100 time windows in total), and convert them into the boxplots, as shown in Figure 8. 各ストリーミング時間ウィンドウ(合計100時間ウィンドウ)に対する推論結果のrmseを記録し、図8に示すように、それらをボックスプロットに変換する。 0.75
For the static weighting algorithm, we also measure the different weights in 3:7, 5:5 and 7:3 (speed:batch) of the accuracy performance evaluation. 静的重み付けアルゴリズムでは,精度評価の3:7,5:5,7:3 (speed:batch) の異なる重みを計測する。 0.73
Figure 8 assesses the accuracy of hybrid stream analytics and baseline approaches. 図8は、ハイブリッドストリーム分析とベースラインアプローチの精度を評価します。 0.73
In summary, for hybrid stream analytics, both static and dynamic weighting algorithm achieve better RMSE values than speed and batch inference. 要約すると、ハイブリッドストリーム分析では、静的および動的重み付けアルゴリズムは、速度やバッチ推論よりもRMSE値が優れている。 0.73
For nodrift scenario, the batch and speed inference get roughly the same RMSE since there are no unexpected changes in the concept or distribution or the streaming data. ノドリフトシナリオでは、バッチと速度推論は、概念や配信、ストリーミングデータに予期せぬ変化がないため、ほぼ同じRMSEが得られる。 0.58
For both gradualdrift and abrupt-drift scenarios, the speed inference works better than the batch inference since the latter cannot detect the changes in data distribution based on the model from historical data. gradualdriftとabrupt-driftの両方のシナリオでは、過去のデータからモデルに基づいてデータ分布の変化を検出できないため、バッチ推論よりも速度推論が優れている。 0.80
On the contrary, speed inference updates the model for each time window, using a model trained from the previous time window to test the streaming data in the current time window, which can catch the drifting in time. 逆に、速度推論は、以前のタイムウインドウからトレーニングされたモデルを使用して、現在のタイムウインドウでストリーミングデータをテストすることで、各タイムウインドウのモデルを更新する。
訳抜け防止モード: 逆に、速度推論は各タイムウインドウのモデルを更新する。 前のタイムウインドウから 訓練されたモデルを使って ストリーミングデータを現在の時間ウィンドウでテストし、時間内にドリフトをキャッチできる。
0.75
Besides, this evaluation also shows the hybrid stream analytics さらに、この評価はハイブリッドストリーム分析も示す。 0.72
with dynamic weighting algorithm achieves the best average RMSE in all three scenarios, and the improved percentages of RMSE are 10.73%, 12.73% and 5.20% respectively. 動的重み付けアルゴリズムは3つのシナリオで最高の平均rmseを達成し、改良されたrmseの割合はそれぞれ10.73%、12.73%、および5.20%である。
訳抜け防止モード: 動的重み付けアルゴリズムは3つのシナリオで最高の平均RMSEを達成する。 RMSEの改善率は10.73%、12.73%、および5.20%である。
0.80
We also record the RMSE for each time window in all three drifting scenarios, as shown in Figure 9. また、図9に示すように、各タイムウィンドウのRMSEを3つのドリフトシナリオすべてに記録します。 0.74
It also shows our dynamic hybrid approach achieves the best RMSE for most time windows. また、我々の動的ハイブリッドアプローチは、ほとんどの時間ウィンドウで最高のRMSEを達成することを示す。 0.60
TABLE III: Time percentage of each inference being the best in terms of RMSE for no-drift data. TABLE III: 各推論の時間パーセンテージは、非ドリフトデータに対するRMSEの観点でベストです。 0.74
Speed Batch Hybrid スピードバッチハイブリッド 0.71
Static (3:7) Static (5:5) Static (7:3) Dynamic 0.1648 0.088 0.7472 静的 (3:7) 静的 (5:5) 静的 (7:3) 動的 0.1648 0.088 0.7472 0.28
0.4757 0.1967 0.3275 0.4757 0.1967 0.3275 0.24
0.5460 0.1172 0.3368 0.5460 0.1172 0.3368 0.24
0.3311 0.2578 0.4111 0.3311 0.2578 0.4111 0.24
TABLE IV: Time percentage of each inference being the best in terms of RMSE for gradual-drift data. TABLE IV: 各推論の時間パーセンテージは、段階的ドリフトデータに対するRMSEの観点でベストである。 0.75
Speed Batch Hybrid スピードバッチハイブリッド 0.71
Static (3:7) Static (5:5) Static (7:3) Dynamic 0.0513 0.0252 0.9235 静的 (3:7) 静的 (5:5) 静的 (7:3) 動的 0.0513 0.0252 0.9235 0.28
0.2830 0.1332 0.5838 0.2830 0.1332 0.5838 0.24
0.3472 0.1093 0.5436 0.3472 0.1093 0.5436 0.24
0.1702 0.2230 0.6068 0.1702 0.2230 0.6068 0.24
TABLE V: Time percentage of each inference being the best in terms of RMSE for abrupt-drift data. TABLE V: 各推論の時間パーセンテージは、突然のドリフトデータに対するRMSEの観点でベストである。 0.71
Speed Batch Hybrid スピードバッチハイブリッド 0.71
Static (3:7) Static (5:5) Static (7:3) Dynamic 0.0290 0.0000 0.971 静的 (3:7) 静的 (5:5) 静的 (7:3) 動的 0.0290 0.0000 0.971 0.28
0.2106 0.0091 0.7802 0.2106 0.0091 0.7802 0.24
0.4839 0.0000 0.5161 0.4839 0.0000 0.5161 0.24
0.1129 0.0183 0.8687 0.1129 0.0183 0.8687 0.24
In order to verify above conclusions, we further draw Tables III, IV and V, which show the percentage of each inference 以上の結論を確認するために、さらに表III、IV、Vを描き、各推測の比率を示す。
訳抜け防止モード: 上記の結論を検証するために、テーブルIII, IV, Vを更に描画する。 それぞれの推測の比率が
0.74
05000100001500020000 25000Streaming data0.040.060.080.10 0.120.14RMSESpeedBat chHybrid(dynamic)050 00100001500020000250 00Streaming data0.040.060.080.10 0.12RMSESpeedBatchHy brid(dynamic)0500010 000150002000025000St reaming data0.220.240.260.28 0.300.32RMSESpeedBat chHybrid(dynamic) 05000100001500020000 25000 ストリーミングデータ0.040.060.080.100.12 0.14rmsespeedbatchhy brid(dynamic)0500010 000150002000025000 ストリーミングデータ0.040.060.080.100.12 rmsespeedbatchhybrid (dynamic)05000100001 50002000025000 ストリーミングデータ0.220.240.260.280.30 0.32rmsespeedbatchhy brid(dynamic) 0.25
英語(論文から抽出)日本語訳スコア
TABLE VI: Related works that support different of capabilities. TABLE VI: さまざまな機能をサポートする関連作業。 0.79
(cid:35)No (cid:32)Yes (cid:71)(cid:35)Some approaches support it. (cid:35)No (cid:32)Yes (cid:71)(cid:35)いくつかのアプローチがそれをサポートしている。 0.60
Model update Multi-model analytics モデル更新 マルチモデル解析 0.92
Inference Periodic model on edge エッジ上の推論周期モデル 0.83
training on cloud from cloud to edge クラウドからエッジへのクラウドトレーニング 0.68
for adaptability Flexible edge- 適応性 フレキシブルエッジ- 0.69
cloud deployment Approaches クラウドのデプロイ アプローチ 0.71
Machine learning based IoT stream data analytics [1, 30, 31, 31–34] 機械学習によるIoTストリームデータ分析 [1, 30, 31, 31–34] 0.91
Edge-Cloud Integrated Framework [9, 11–17] エッジクラウド統合フレームワーク [9, 11–17] 0.78
System or toolkit for deep learning 深層学習システムまたはツールキット 0.87
based inference [5, 21, 35–37] ベース推論[5, 21, 35–37] 0.78
Edge-cloud integrated framework エッジクラウド 統合フレームワーク 0.67
(cid:71)(cid:35) (cid:71)(cid:35) (cid:32) (cid:32) (cid:71)(cid:35) (cid:71)(cid:35) (cid:32) (cid:32) 0.36
(cid:35) (cid:32) (cid:35) (cid:32) (cid:35) (cid:32) (cid:35) (cid:32) 0.36
(cid:35) (cid:71)(cid:35) (cid:35) (cid:32) (cid:35) (cid:71)(cid:35) (cid:35) (cid:32) 0.36
(cid:32) (cid:35) (cid:35) (cid:32) (cid:32) (cid:35) (cid:35) (cid:32) 0.36
(cid:35) (cid:35) (cid:32) (cid:32) (cid:35) (cid:35) (cid:32) (cid:32) 0.36
being the best with no-drift, gradual-drift and abrupt-drift data separately. no-drift、gradual-drift、abrupt-driftデータを別々に扱うのがベストです。 0.46
For no-drift scenario, hybrid inference is the best approach only in dynamic weights and one static weighting (7:3) algorithm. ドリフトのないシナリオでは、ハイブリッド推論は動的重み付けと1つの静的重み付け(7:3)アルゴリズムでのみ最適である。 0.68
For both the gradual-drift and abrupt-drift scenarios, however, hybrid inference is always the best approach for every weight combination algorithm. しかしながら、段階的ドリフトと突然ドリフトのシナリオの両方において、ハイブリッド推論はすべての重み結合アルゴリズムにとって常に最善のアプローチである。 0.55
As a result, our hybrid stream analytics can adapt the gradual and abrupt concept drift effectively. その結果、我々のハイブリッドストリーム分析は、漸進的および急進的なコンセプトドリフトを効果的に適応させることができる。 0.59
VII. RELATED WORK There have been many studies related to the topics we discussed in the paper. VII。 関連作業 私たちが論文で論じた話題に関する多くの研究がなされている。 0.70
Based on their framework capabilities and main focused challenges, as shown in Table VI, we categorize them into different groups. 表6に示すように、フレームワークの機能と主な課題に基づいて、それらを異なるグループに分類します。 0.64
Next, we describe the details of these related work from the three aspects we listed in the table. 次に、表に示す3つの側面から、これらの関連作業の詳細を説明します。 0.75
A. Machine learning based IoT stream data analytics A. 機械学習に基づくIoTストリームデータ分析 0.87
When dealing with concept drift in stream data analytics, we study how to optimally integrate batch learning and stream learning in our paper. ストリームデータ分析における概念ドリフトを扱う際に,バッチ学習とストリーム学習を最適に統合する方法について検討する。 0.78
Paper [1] proposes a framework that generates improved time series forecasting by supporting batch-based, stream-based and hybrid time series forecasting, to tackle the adaptability challenges. paper [1]は、適応性の課題に取り組むために、バッチベース、ストリームベース、ハイブリッド時系列予測をサポートすることにより、時系列予測を改善するフレームワークを提案する。
訳抜け防止モード: paper [1 ]は時系列予測を改善したフレームワークを提案する 適応性の課題に取り組むために、バッチベース、ストリームベース、ハイブリッド時系列予測をサポートする。
0.70
Several papers [2, 30– 34, 38] study how to update the model based on streaming data and propose their solutions. いくつかの論文[2, 30– 34, 38]は、ストリーミングデータに基づいてモデルを更新し、そのソリューションを提案する。 0.76
Shao et al [30] proposes an adaptive strategy in conjunction with ensemble learning for the task of concept drift detection, while Puschmann et al [31] uses an online clustering mechanism to cluster the streaming data, which remains adaptive to drifts by adjusting itself as the data changes. Shao et al [30]は、コンセプトドリフト検出のタスクのためのアンサンブル学習と協調して適応戦略を提案し、Puschmann et al [31]はオンラインクラスタリング機構を使用してストリーミングデータをクラスタリングし、データの変化に応じて自分自身を調整することで、ドリフトに適応する。 0.78
Yang et al [32] proposes their drift adaptation method algorithm based on the combination of sliding and adaptive window-based methods, as well as performancebased methods. yangら[32]は、スライディングとアダプティブウィンドウベースの手法とパフォーマンスベースの手法の組み合わせに基づくドリフト適応法アルゴリズムを提案している。 0.79
All these studies focus on the algorithm design for training and updating one identical ML/DL model to deal with streaming concept drift with the best performance. これらの研究はすべて、ストリーミングコンセプトドリフトを最高のパフォーマンスで扱うために、同一のML/DLモデルをトレーニングおよび更新するためのアルゴリズム設計に焦点を当てている。 0.66
Some of these [31, 33, 34] did not consider the computational power of the edge computing environment, so the algorithms need to be further deployed in additional resources (like storage or computation optimized device). これらの[31, 33, 34]のいくつかはエッジコンピューティング環境の計算能力を考慮していないため、アルゴリズムをさらに追加のリソース(ストレージや計算最適化デバイスなど)にデプロイする必要がある。 0.88
In contrast, the adaptive hybrid stream analytics we proposed is a weight combination solution from two (batch and stream) inferences, which does not re-evaluate or adjust the layers of the neural network based on the results. これとは対照的に,我々が提案した適応型ハイブリッドストリーム分析は,2つの(バッチとストリーム)推論による重みの組み合わせソリューションであり,結果に基づいてニューラルネットワークのレイヤを再評価したり調整したりしない。 0.78
By periodically applying knowledge from two trained and compressed models, our work is more トレーニングと圧縮の2つのモデルからの知識を定期的に適用することで、私たちの仕事はより多くなります。 0.48
lightweight and portable for edge devices in real-time concept drift adaptation. リアルタイムコンセプトドリフト適応におけるエッジデバイスのための軽量でポータブル 0.72
B. Edge-Cloud Integration B.エッジクラウドの統合 0.58
There are also several studies [13–17] for workload management on edge-cloud integrated resources, more targeting an optimized cyber-infrastructure design but not much for machine learning related workload. エッジクラウド統合リソースでのワークロード管理に関するいくつかの研究も[13–17]あり、より最適化されたサイバーインフラ設計を対象としているが、機械学習関連のワークロードについては多くはない。 0.55
Luckow et al [9] studies how to manage distributed edge and cloud resources and studies the performance of machine learning models for the outlier detection. Luckow氏らは分散エッジとクラウドリソースの管理方法を研究し、異常検出のための機械学習モデルのパフォーマンスを研究しています。 0.82
However, the edge devices in the paper are simulated so it is yet to be seen whether the findings are the same in real-world. しかし、論文のエッジデバイスはシミュレートされているため、実世界における結果が同じかどうかはまだ不明である。 0.72
Also, the machine learning models are only deployed on the cloud side, not on the edge side. また、機械学習モデルはクラウド側にのみデプロイされ、エッジ側にはデプロイされない。 0.73
Osia et al [11] deploys deep learning models to predict images collected by the edge, where sensitive information is first pre-processed on the edge and its representation is sent to the cloud for complex inferences. Osia et al [11]は、エッジで収集された画像を予測するためにディープラーニングモデルをデプロイする。
訳抜け防止モード: Osia et al [11 ]は、エッジによって収集された画像を予測するディープラーニングモデルをデプロイする。 まず機密情報が事前に処理され その表現は複雑な推論のためにクラウドに送られます
0.65
Since the edge devices are only used for data pre-processing, not for actual machine learning based inference, the total latency of their framework will be higher than inferring directly on edge. edgeデバイスは、実際の機械学習ベースの推論ではなく、データの前処理にのみ使用されるため、edge上で直接推論するよりも、フレームワーク全体のレイテンシが高くなる。 0.68
Abdulla et al. アブドゥッラとアル。 0.59
[12] argues that using adaptive learning for streaming data processing could solve concept drift problems, and the proposed cooperative fog-cloud architecture shows updating machine learning models periodically can help reduce RMSE by about 20%. 12] ストリーミングデータ処理に適応学習を用いることで,コンセプトドリフトの問題を解決することができる,と論じ,提案した協調型フォグクラウドアーキテクチャでは,機械学習モデルを定期的に更新することで,RMSEを約20%削減することができる。 0.67
However, their experiments did not use portable edge devices such as Raspberry Pi, instead they used a local computer. しかし、彼らの実験ではraspberry piのようなポータブルなエッジデバイスは使用せず、代わりにローカルコンピュータを使用した。 0.70
The edge-cloud integrated framework we proposed is a general and flexible design, whose docker-based modules can be developed in either cloud or edge side even with different types of edge devices. 私たちが提案したエッジクラウド統合フレームワークは汎用的でフレキシブルな設計で、異なるタイプのエッジデバイスでも、クラウドあるいはエッジサイドでdockerベースのモジュールを開発することができます。 0.67
C. Complete system or toolkit for deep learning based inference c.深層学習に基づく推論のための完全システムまたはツールキット 0.65
There have been many systems or toolkits that support deep learning based inference on IoT/edge devices. IoT/エッジデバイスによるディープラーニングベースの推論をサポートするシステムやツールキットは数多く存在する。 0.64
NVIDIA’s DeepStream [5] is a streaming analytic toolkit that helps the user build and deploy video analytics applications onpremises, on the edge, and in the cloud. nvidiaのdeepstream [5]は、ユーザがオンプレミス、エッジ、クラウドでビデオ分析アプリケーションを構築およびデプロイするのを支援するストリーミング分析ツールキットである。 0.74
DeepStream features hardware-accelerated building blocks [39] that bring deep neural networks and other complex stream data processing tasks into GStreamer processing pipelines and maximize the computation using GPUs. DeepStreamはハードウェアアクセラレーションされたビルディングブロック[39]を備えており、ディープニューラルネットワークやその他の複雑なストリームデータ処理タスクをGStreamer処理パイプラインに持ち込み、GPUを使用した計算を最大化する。 0.62
Based on its design, DeepStream can be highly optimized to run on NVIDIA series or GPUenabled edge devices like Jetson Xavier NX and Jetson Nano. 設計上、DeepStreamはNVIDIAシリーズやJetson Xavier NXやJetson NanoといったGPU対応エッジデバイスで動くように高度に最適化できる。 0.79
英語(論文から抽出)日本語訳スコア
However, while DeepStream has multiple examples that are provided as source code, its SDK is not released as opensource software. しかし、DeepStreamにはソースコードとして提供されるサンプルが複数あるが、SDKはオープンソースソフトウェアとしてリリースされていない。 0.66
An alternative toolkit for deep learning based inference is Google Coral [35]. ディープラーニングベースの推論のための代替ツールキットとして、Google Coral [35]がある。 0.51
Coral is a complete toolkit for building intelligent devices with fast deep neural network inferencing. coralは、高速ディープニューラルネットワークによるインテリジェントデバイス構築のための完全なツールキットである。 0.69
Same with DeepStream, Coral can enable its peak capability with the proposed hardware and software solutions like Edge TPU coprocessor [36]. CoralはDeepStreamと同様、Edge TPUコプロセッサ[36]のような提案されたハードウェアおよびソフトウェアソリューションで、ピーク機能を有効にします。 0.69
More focused on deployment rather than inference learning, some Cloud platforms like AWS and Azure also provide their general-propose solution for edge devices inference even offline from the cloud. 推論学習よりもデプロイメントを重視するawsやazureといった一部のクラウドプラットフォームは、クラウドからオフラインでもエッジデバイス推論のための汎用ソリューションを提供する。 0.76
AWS IoT Greengrass [21] is an opensource edge runtime and cloud service for building, deploying, and managing edge devices. AWS IoT Greengrass [21]は、エッジデバイスの構築、デプロイ、管理のためのオープンソースのエッジランタイムとクラウドサービスである。 0.77
Greengrass manages and operates multiple edge devices in the field locally or remotely using MQTT or other protocols. GreengrassはMQTTや他のプロトコルを使用して、フィールド内の複数のエッジデバイスをローカルまたはリモートで管理し、運用する。 0.55
With the solution, inference can be deployed across edges using any language, packaging technology, or runtime. このソリューションでは、あらゆる言語、パッケージング技術、ランタイムを使用して、エッジ間で推論をデプロイすることができる。
訳抜け防止モード: ソリューションによって、推論はエッジにまたがってデプロイできる。 どんな言語でも パッケージング技術でも ランタイムでも使えます
0.60
Our hybrid learning framework is based on the Greengrass runtime. 私たちのハイブリッド学習フレームワークはGreengrassランタイムをベースにしています。 0.60
We further study how to deploy stream analytics among edge and cloud resources and improve their accuracies. さらに,エッジおよびクラウドリソース間のストリーム分析の展開方法や,その信頼性の向上についても検討する。 0.58
Microsoft also provides Azure IoT Edge [37] service to scale out inference learning by packaging the logic into standard containers, deploying these containers to any of the edge devices and monitoring it all from the cloud. MicrosoftはAzure IoT Edge [37]サービスも提供しており、ロジックを標準的なコンテナにパッケージ化し、これらのコンテナをエッジデバイスにデプロイし、すべてクラウドから監視することで、推論学習をスケールアウトする。 0.68
Different from Greengrass, the applications like inference learning in Azure IoT Edge need to be developed in one of the supported programming languages. Greengrassとは異なり、Azure IoT Edgeでの推論学習のようなアプリケーションは、サポートされているプログラミング言語のひとつで開発する必要がある。 0.74
VIII. CONCLUSIONS VIII。 コンキュレーション 0.64
Stream analytics aims to analyze and process high volumes of streaming data continuously. stream analyticsは、大量のストリーミングデータを継続的に分析し、処理することを目指している。 0.57
In this paper, we study how to best leverage edge and cloud resources to achieve better accuracy and latency for RNN-based stream analytics and better adapt concept drift in stream data. 本稿では、RNNベースのストリーム分析において、エッジリソースとクラウドリソースを最大限に活用して、精度とレイテンシを向上し、ストリームデータに適応するコンセプトドリフトを改善する方法について検討する。 0.58
We propose three flexible deployments for the hybrid stream analytics framework in order to achieve the proper trade-off between latency and accuracy for stream analytics. ストリーム分析におけるレイテンシと精度の適切なトレードオフを実現するために,ハイブリッドストリーム分析フレームワークに3つの柔軟なデプロイメントを提案する。 0.73
We also propose an adaptive and dynamic hybrid learning model with two weight combination algorithms for solving the concept drift during stream analytics. また,ストリーム解析におけるコンセプトドリフトを解くために,2つの重み組合せアルゴリズムを用いた適応的・動的ハイブリッド学習モデルを提案する。 0.75
The evaluation with real-world stream datasets shows the proposed edge-cloud deployment can archive similar latency performance as edge-centric deployment without worrying about capacity limitations, and our dynamic weighting algorithm performs the best among other hybrid learning model approaches for all three concept drift scenarios in terms of accuracy. 実世界のストリームデータセットによる評価から,提案するエッジクラウドデプロイメントは,キャパシティの制限を気にせずに,エッジ中心のデプロイメントと同じようなレイテンシパフォーマンスをアーカイブできることが分かった。
訳抜け防止モード: 実世界のストリームデータセットによる評価は、提案されたエッジ - クラウドデプロイメントは、キャパシティの制限を気にすることなく、同様のレイテンシパフォーマンスをエッジ – 中心的なデプロイメントとしてアーカイブすることができる。 我々の動的重み付けアルゴリズムは,3つの概念ドリフトシナリオすべてに対して,精度の点で,他のハイブリッド学習モデルアプローチの中でも最良である。
0.58
For future work, we will mainly focus on the following three aspects of the hybrid stream analytics framework. 今後の作業では主に、ハイブリッドストリーム分析フレームワークの次の3つの側面に注目します。 0.68
First, the Spark-based speed training module can be extended to multiple edge devices as a distributed master-worker computing. まず、sparkベースのスピードトレーニングモジュールを、分散マスターワーカーコンピューティングとして、複数のエッジデバイスに拡張することができる。 0.56
Second, we will study more variants of the proposed dynamic weighting algorithm, like stacking the most resent n speed layer models or stacking speed layer models continuously. 第二に、提案する動的重み付けアルゴリズムの変種について検討する。例えば、最も抵抗性の高いn速度層モデルの積み重ねや、連続的な積み重ね速度層モデルの積み重ねなどである。
訳抜け防止モード: 次に,提案した動的重み付けアルゴリズムの変種について検討する。 最強のnスピードレイヤーモデルを 積み重ねたり 連続的に スピードレイヤーモデルを積み重ねたり
0.83
Last, we will try more complicated RNN deep learning models with our framework. 最後に、我々のフレームワークでより複雑なRNNディープラーニングモデルを試します。 0.70
ACKNOWLEDGMENT This work is supported by the National Science Foundation (NSF) Grant No. 承認 この研究はNational Science Foundation (NSF) Grant Noによって支援されている。 0.53
OAC–1942714 and U.S. Army Grant No. OAC-1942714とアメリカ陸軍グラントNo。 0.78
W911NF2120076. w911nf2120076所属。 0.36
REFERENCES [1] A. Pandya, O. Odunsi, C. Liu, A. Cuzzocrea, and J. Wang, “Adaptive and efficient streaming time series forecasting with lambda architecture and spark,” in 2020 IEEE International Conference on Big Data (Big Data). 参考 [1] Pandya, O. Odunsi, C. Liu, A. Cuzzocrea, J. Wang氏は,2020年のIEEE International Conference on Big Data (Big Data)で,“ラムダアーキテクチャとスパークによる適応的で効率的なストリーミング時系列予測”を発表した。 0.60
IEEE, 2020, pp. 5182–5190. IEEE, 2020, pp. 5182-5190。 0.85
[2] E. Uchiteleva, S. Primak, M. Luccini, A. Refaey, and A. Shami, “The trils approach for drift-aware time-series prediction in iiot environment,” IEEE Transactions on Industrial Informatics, 2021. E. Uchiteleva, S. Primak, M. Luccini, A. Refaey, A. Shami, “The trils approach for drift-aware time-series prediction in iiot environment”, IEEE Transactions on Industrial Informatics, 2021。 0.44
[3] S. B. Qaisar and M. Usman, “Fog networking for machine health prognosis: A deep learning perspective,” in International Conference on Computational Science and Its Applications. S.B. QaisarとM. Usmanは、International Conference on Computational Science and its Applicationsで、“Fog networking for machine health prognosis: A Deep Learning perspective”と題している。
訳抜け防止モード: [3 ] S. B. Qaisar と M. Usman, “Fog Network for Machine Health prognosis : an Deep Learning perspective”. 計算科学と応用に関する国際会議」に参加して
0.92
Springer, 2017, pp. 212–219. 2017年、p.212-219。 0.54
[4] D. Li, T. Salonidis, N. V. Desai, and M. C. Chuah, “Deepcham: Collaborative edge-mediated adaptive deep in 2016 learning for mobile object IEEE/ACM Symposium on Edge Computing (SEC). D. Li, T. Salonidis, N. V. Desai, M. C. Chuah, “Deepcham: Collaborative edge-mediated Adaptive Deep in 2016 learning for mobile object IEEE/ACM Symposium on Edge Computing (SEC)”。
訳抜け防止モード: [4 ]D. Li, T. Salonidis, N. V. Desai, Deepcham : Collaborative edge - 2016年のモバイルオブジェクトIEEE / ACM Symposium on Edge Computing (SEC )の学習を取り入れた。
0.78
IEEE, 2016, pp. 64–76. 原著、2016年、p.64-76。 0.38
recognition,” available と認識する。 利用可能 0.60
[5] K. Purandare, “An introduction to deepstream sdk,” https: [5]K. Purandare, “A Introduction to Deepstream sdk”, https: 0.40
2018, //on-demand.gputechc onf.com/gtc/2018/pre sentation/ s81047-introduction- to-deep-stream-sdk.p df. 2018, //on-demand.gputechc onf.com/gtc/2018/pre sentation/ s81047-introduction- to-deep-stream-sdk.p df 0.11
at GStreamer Conference: gstreamerカンファレンスでは 0.52
[6] I. ˇZliobait˙e, M. Pechenizkiy, and J. Gama, “An overview of concept drift applications,” Big data analysis: new algorithms for a new society, pp. 91–114, 2016. a overview of concept drift applications, big data analysis: new algorithms for a new society, pp. 91-114, 2016) である。
訳抜け防止モード: 6 ]i・j・ガマ、m・ペチェニスキー、j・ガマ。 概念ドリフト応用の概要」ビッグデータ分析 : 新しい社会のための新しいアルゴリズム pp . 91–114 , 2016 .
0.67
[7] J. Gama, I. J. Gama (複数形 J. Gamas) 0.52
ˇZliobait˙e, A. Bifet, M. Pechenizkiy, and A. Bouchachia, “A survey on concept drift adaptation,” ACM computing surveys (CSUR), vol. ACM Computing Surveys (CSUR) vol., A. Bifet, M. Pechenizkiy, A. Bouchachia, “A survey on concept drift adaptation”. ACM Computing Surveys (CSUR)。
訳抜け防止モード: A. Bifet, M. Pechenizkiy, A. Bouchachia コンセプトドリフト適応に関する調査」ACMコンピューティングサーベイ(CSUR),vol。
0.58
46, no. 4, pp. 1– 37, 2014. 46, No. 4, pp. 1– 37, 2014。 0.87
[8] Amazon Web Services, Inc, “What is cloud computing?” 8] amazon web services, inc, “クラウドコンピューティングとは何か? 0.72
https://aws.amazon.c om/what-is-cloud-com puting/, 2021. https://aws.amazon.c om/what-is-cloud-com puting/, 2021。 0.19
[9] A. Luckow, K. Rattan, and S. 9]A. Luckow,K. Rattan,S. 0.33
Jha, “Pilot-edge: Distributed resource management along the edge-tocloud continuum,” in 2021 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW). Jha, “Pilot-edge: Distributed Resource Management along the edge-to cloud continuum” in 2021 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW)。
訳抜け防止モード: Jha, “パイロット - エッジ: エッジに沿った分散リソース管理 - クラウド継続”。 2021年 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW) に参加。
0.77
IEEE, 2021, pp. 874–878. IEEE, 2021, pp. 874-878。 0.92
[10] M. Mohammadi, A. Al-Fuqaha, S. Sorour, M. Mohammadi, A. Al-Fuqaha, S. Sorour 0.39
and M. Guizani, “Deep learning for iot big data and streaming analytics: A survey,” IEEE Communications Surveys & Tutorials, vol. そしてM. Guizaniは,“ビッグデータとストリーミング分析の深層学習:調査”,IEEE Communications Surveys & Tutorials, vol。
訳抜け防止モード: そしてM. Guizani氏は,“iotのビッグデータとストリーミング分析のためのディープラーニング : 調査”と題する。 IEEE Communications Surveys & Tutorials, vol。
0.80
20, no. 4, pp. 2923–2960, 2018. 20 no. 4, pp. 2923-2960, 2018年。 0.83
[11] S. A. Osia, A. S. Shamsabadi, A. Taheri, H. R. Rabiee, and H. Haddadi, “Private and scalable personal data analytics using hybrid edge-to-cloud deep learning,” Computer, vol. A. A. Osia, A. S. Shamsabadi, A. Taheri, H. R. Rabiee, H. Haddadi, “ハイブリッドエッジからクラウドのディープラーニングを使って、クリエイティブでスケーラブルな個人データ分析を行う。 0.78
51, no. 5, pp. 42–49, 2018. 51, No. 5, pp. 42-49, 2018。 0.44
[12] N. Abdulla, M. Demirci, and S. N. Abdulla, M. Demirci, and S. 0.36
¨Ozdemir, “Adaptive learning on fog-cloud collaborative architecture for stream data processing,” in 2021 International Symposium on Networks, Computers and Communications (ISNCC), 2021, pp. 1–6. sozdemir, “adaptive learning on fog-cloud collaborative architecture for stream data processing” in 2021 international symposium on networks, computers and communications (isncc), 2021, pp. 1–6。 0.42
英語(論文から抽出)日本語訳スコア
cance? a cautionary note,” Annals of Ibadan postgraduate medicine, vol. キャンス? と、イバダン大学医学部のAnnals氏は述べている。 0.54
6, no. 1, pp. 21–26, 2008. 6, No. 1, pp. 21–26, 2008 0.44
[30] Z. Shao, S. Yuan, and Y. Wang, “Adaptive online learning for iot botnet detection,” Information Sciences, vol. Z. Shao, S. Yuan, and Y. Wang, “Adaptive online learning for iot botnet detection”, Information Sciences, vol。
訳抜け防止モード: [30 ]Z. Shao、S. Yuan、Y. Wang iotボットネット検出のための適応的なオンライン学習。
0.63
574, pp. 84–95, 2021. 574, pp. 84-95, 2021。 0.89
[31] D. Puschmann, P. Barnaghi, and R. Tafazolli, “Adaptive clustering for dynamic iot data streams,” IEEE Internet of Things Journal, vol. D. Puschmann, P. Barnaghi, R. Tafazolli, “Adaptive clustering for dynamic iot data stream”, IEEE Internet of Things Journal, vol.[31] D. Puschmann, P. Barnaghi, R. Tafazolli。
訳抜け防止モード: [31 ]D. Puschmann, P. Barnaghi, R. Tafazolli IEEE Internet of Things Journal, vol.“動的アイオットデータストリームのアダプティブクラスタリング”。
0.66
4, no. 1, pp. 64–74, 2016. 4巻1頁、p.64-74、2016年。 0.60
[32] L. Yang and A. Shami, “A lightweight concept drift detection and adaptation framework for iot data streams,” IEEE Internet of Things Magazine, vol. IEEE Internet of Things Magazine, vol.[32] L. Yang, A. Shami, “Iotデータストリームのための軽量なコンセプトドリフト検出と適応フレームワーク”。 0.82
4, no. 2, pp. 96– 101, 2021. 4, No. 2, pp. 96– 101, 2021。 0.89
[33] L. Yang, D. M. Manias, and A. Shami, “Pwpae: An ensemble framework for concept drift adaptation in iot data streams,” arXiv preprint arXiv:2109.05013, 2021. [33]L. Yang, D. M. Manias, A. Shami, “Pwpae: an ensemble framework for concept drift adaptation in iot data stream” arXiv preprint arXiv:2109.05013, 2021。
訳抜け防止モード: [33 ]L・ヤン、D・M・マニアス、A・シャミ Pwpae : iotデータストリームにおけるコンセプトドリフト適応のためのアンサンブルフレームワーク” arXiv preprint arXiv:2109.05013 , 2021
0.82
[34] H. Mehmood, P. Kostakos, M. Cortes, T. Anagnostopoulos, S. Pirttikangas, and E. Gilman, “Concept drift adaptation techniques in distributed environment for realworld data streams,” Smart Cities, vol. H. Mehmood, P. Kostakos, M. Cortes, T. Anagnostopoulos, S. Pirttikangas, E. Gilman, “Concept drift adaptation techniques in distributed environment for realworld data stream”, Smart Cities, vol。
訳抜け防止モード: [34 ] h. mehmood, p. kostakos, m. cortes, t. anagnostopoulos氏、s. pirttikangas氏、e. gilman氏、"現実のデータストリームのための分散環境における概念ドリフト適応技術"。 スマートシティ、vol.1。
0.61
4, no. 1, pp. 349– 371, 2021. 4, No. 1, pp. 349– 371, 2021。 0.89
[35] Google LLC. [35] Google LLC。 0.41
, “Google Coral,” https://coral.ai/, 2020. google coral”、https://coral.ai/、2020。 0.38
[36] ——, “Google Coral Edge TPU,” https://cloud.google . Google Coral Edge TPU, https://cloud.google .com[36]—— “Google Coral Edge TPU”。 0.37
com/edge-tpu, 2020. 編集部注:2020年。 0.32
[37] Microsoft Azure, “Azure IoT Edge,” https://azure. [37] Microsoft Azure, “Azure IoT Edge”, https://azure.com 0.46
microsoft.com/en-us/ services/iot-edge/, 2022. microsoft.com/en-us/ services/iot-edge/, 2022 0.18
[38] G. Rocher, S. Lavirotte, J. [38] G. Rocher, S. Lavirotte, J. 0.50
-Y. Tigli, G. Cotte, and F. Dechavanne, “An iohmm-based framework to investigate drift in effectiveness of iot-based systems,” Sensors, vol. -y。 Tigli, G. Cotte, F. Dechavanne, “iotベースのシステムのドリフトを調査するためのiohmmベースのフレームワーク”, Sensors, vol。 0.53
21, no. 2, p. 527, 2021. 21,2,p.527,2021。 0.62
[39] NVIDIA Corporation, [39]NVIDIAコーポレーション 0.59
“DeepStream SDK,” https:// “DeepStream SDK” https:// 0.42
developer.nvidia.com /deepstream-sdk, 2021. developer.nvidia.com /deepstream-sdk, 2021 0.24
[13] D. Balouek-Thomert, E. G. Renart, A. R. Zamani, A. Simonet, and M. Parashar, “Towards a computing continuum: Enabling edge-to-cloud integration for datadriven workflows,” The International Journal of High Performance Computing Applications, vol. 関連スポンサーコンテンツ [13] d. balouek-thomert氏,例えば renart氏, a. r. zamani氏, a. simonet氏, m. parashar氏は,“データ駆動ワークフローのためのエッジ・ツー・クラウド統合を実現するための,コンピューティング連続体(compute continuum: a edge-to-cloud integration for datadriven workflows)”と題する。
訳抜け防止モード: [13 ]D. Balouek-Thomert, E. G. Renart, A. R. Zamani A. Simonet氏とM. Parashar氏は“コンピューティングの連続性に向けて : データ駆動ワークフローのためのクラウド統合を実現する”。 International Journal of High Performance Computing Applications, vol。
0.73
33, no. 6, pp. 1159–1174, 2019. 33, no. 6, pp. 1159-1174, 2019。 0.89
[14] Z. Nezami, K. Zamanifar, K. Djemame, edge-to-cloud [14]Z. Nezami, K. Zamanifar, K. Djemame, edge-to-cloud 0.39
and E. load balancing: Service placement for the internet of things,” IEEE Access, vol. ieee access, vol. “ロードバランシング: モノのインターネットのためのサービス配置。 0.45
9, pp. 64 983–65 000, 2021. 9, pp. 64 983–65 000, 2021. 0.50
“Decentralized Pournaras, 分散化」 Pournaras 0.37
[15] R. K. Naha, S. Garg, A. Chan, and S. K. Battula, “Deadline-based dynamic resource allocation and provisioning algorithms in fog-cloud environment,” Future Generation Computer Systems, vol. [15] R. K. Naha, S. Garg, A. Chan, S. K. Battula, “Deadline-based dynamic resource allocation and provisioning algorithm in fog-cloud environment”, Future Generation Computer Systems, vol。
訳抜け防止モード: [15 ]R. K. Naha, S. Garg, A. Chan, そしてS.K. Battula氏は,“デッドライン – 霧中の動的リソース割り当てとプロビジョニングアルゴリズムに基づく - クラウド環境”だ。 次世代コンピュータシステム
0.76
104, pp. 131–141, 2020. 104, pp. 131-141, 2020。 0.83
[16] M. AbdelBaky, M. Zou, A. R. Zamani, E. Renart, J. DiazMontes, and M. Parashar, “Computing in the continuum: Combining pervasive devices and services to support data-driven applications,” in 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS). M. AbdelBaky, M. Zou, A. R. Zamani, E. Renart, J. DiazMontes, M. Parashar, “Computing in the continuum: Combining pervasive devices and services to support data-driven applications” 2017年、IEEE 37th International Conference on Distributed Computing Systems (ICDCS)が開催された。
訳抜け防止モード: [16 ]m.abdelbaky,m.zou,a. r.zamani, e. renart, j. diazmontes, m. parashar, "continuumにおけるコンピューティング : 普及型デバイスとサービスを組み合わせてデータ駆動アプリケーションをサポートする" 2017年、ieee 37th international conference on distributed computing systems (icdcs) が開催された。
0.70
IEEE, 2017, pp. 1815–1824. IEEE, 2017, pp. 1815–1824。 0.46
[17] I. M. Murwantara and P. Yugopuspito, “An adaptive iot architecture using combination of concept-drift and dynamic software product line engineering,” TELKOMNIKA, vol. TELKOMNIKA, vol. [17] I. M. Murwantara, P. Yugopuspito, “コンセプトドリフトと動的ソフトウェア製品ラインエンジニアリングを組み合わせた適応型アイオットアーキテクチャ”。 0.85
19, no. 4, pp. 1226–1233, 2021. 19 no. 4, pp. 1226–1233, 2021。 0.87
[18] W. Zhang and J. Wang, “A hybrid learning framework for imbalanced stream classification,” in 2017 IEEE International Congress on Big Data (BigData Congress). W. Zhang氏とJ. Wang氏は、2017年のIEEE International Congress on Big Data (BigData Congress)で、“不均衡ストリーム分類のためのハイブリッド学習フレームワーク”と題している。 0.71
IEEE, 2017, pp. 480–487. IEEE、2017年、p.480-487。 0.79
[19] B. Krawczyk and A. Cano, “Online ensemble learning with abstaining classifiers for drifting and noisy data streams,” Applied Soft Computing, vol. Applied Soft Computing, vol.[19] B. Krawczyk, A. Cano, “オンラインアンサンブル学習は、ドリフトとノイズの多いデータストリームのための、控えめな分類器で始まる”。 0.68
68, pp. 677–692, 2018. 68, pp. 677-692, 2018。 0.87
[20] Andrew Banks アンドリュー・バンクス[20] 0.81
“MQTT Version 3.1.1,” http://docs.oasis-op en.org/mqtt/mqtt/v3. 1.1/ mqtt-v3.1.1.html, 2014, OASIS Standard. "mqttバージョン3.1.1", http://docs.oasis-op en.org/mqtt/mqtt/v3. 1.1/mqtt-v3.1.html, 2014 oasis標準。 0.36
and Rahul Gupta, そしてRahul Gupta。 0.63
[21] Amazon Web Services, Inc, “AWS IoT Greengrass,” [21]Amazon Web Services, Inc, “AWS IoT Greengrass” 0.39
https://aws.amazon.c om/greengrass/, 2022. https://aws.amazon.c om/greengrass/, 2022。 0.27
[22] “Apache Spark Project,” http://spark.apache. org, 2021, 関連スポンサーコンテンツ [22] “apache spark project” http://spark.apache. org, 2021, 0.67
accessed: 2021-5-28. アクセス:2021-5-28。 0.41
[23] R. Polikar, “Ensemble based systems in decision making,” IEEE Circuits and Systems Magazine, vol. R. Polikar, “Ensemble based systems in decision making, IEEE Circuits and Systems Magazine, vol.
訳抜け防止モード: [23 ]R. Polikar, “意思決定におけるアンサンブルベースのシステム” IEEE Circuits and Systems Magazine, vol。
0.83
6, no. 3, pp. 21–45, 2006. 第6巻第3巻、2006年、21-45頁。 0.34
[24] L. Rokach, “Ensemble-based classifiers,” Artificial intel- [24]L. Rokach, “Ensemble-based classifications, Artificial Intel- 0.45
ligence review, vol. リジェンス・レビュー Vol. 0.31
33, no. 1, pp. 1–39, 2010. 33, No. 1, pp. 1–39, 2010 0.44
[25] D. Kraft et al , “A software package for sequential [25]D. Kraft et al , “シーケンシャルなソフトウェアパッケージ” 0.78
quadratic programming,” 1988. 1988年:「二次プログラミング」。 0.57
[26] T. Chai and R. R. Draxler, “Root mean square error (rmse) or mean absolute error (mae)?–arguments against avoiding rmse in the literature,” Geoscientific model development, vol. T. Chai and R. R. Draxler, “Root mean square error (rmse) or mean absolute error (mae)?
訳抜け防止モード: [26 ] T. Chai と R. R. Draxler は次のように述べている。 あるいは、絶対誤差(前)?-文学における休息を避けるための問題」である。 地学モデル開発。
0.67
7, no. 3, pp. 1247–1250, 2014. 7,3,p.1247-1250,2014 。 0.66
[27] “Engie’s first open data windfarm: La haute borne,” https: [27]Engie初のオープンデータウィンドファーム:La haute borne, https: 0.56
//opendata-renewable s.engie.com/, 2017. opendata-renewables. engie.com、2017年。 0.39
[28] R. Mushtaq, “Augmented dickey fuller test,” 2011, avail- 28] r. mushtaq, “augmented dickey fuller test” 2011, avail- 0.38
able at SSRN: http://dx.doi.org/10 .2139/ssrn.1911068. SSRN: http://dx.doi.org/10 .2139/ssrn.1911068 0.21
[29] T. Dahiru, “P-value, a true test of statistical signifi- 29]t. dahiru著『p-value, a true test of statistical signifi』 0.44
                           ページの最初に戻る

翻訳にはFugu-Machine Translatorを利用しています。