IoT、エッジコンピューティング、分析ギャップの解消

エッジ コンピューティングでは、コンピューティング能力をデータ ソースの近くに配置できるため、分析機能の向上に役立ちます。しかし、企業がそれを導入するのを妨げているものは何でしょうか?

2015 年から 2020 年までの 5 年間で、モノのインターネットは他のどのカテゴリのデバイスよりも急速に成長すると予想されています。マシン間接続の数は、2015 年の 49 億から 2020 年には 122 億へと、約 2.5 倍に増加します。

しかし、IoTの世界では、ネットワーク上で送信されるデータ量を削減するために、データのソースにできるだけ近い場所で分析を実行できることが必須となっています。それだけでなく、企業の目標が、たとえ限定された目的であっても、エッジ コンピューティング デバイス (輸送車両、石油掘削装置、モバイル デバイスなど) に迅速なフィードバックを提供することである場合、これは非常に重要です。

データが応答ポイントに到達した瞬間から、ギャップが広がるにつれてデータの値が減少します。ビジネスの観点から見ると、企業はデータ ソースにできるだけ近いところで迅速に分析を行う必要があります。

時間範囲を短縮してリアルタイムの洞察とアクションを提供できれば、より大きな価値が生まれます。

エッジコンピューティング分析への移行

エッジ コンピューティング分析は、従来のデータ収集および分析方法を改善したものです。このアプローチでは、データが集中データ ストアに送り返されてバックグラウンドで分析が実行されるのを待つのではなく、センサー、ネットワーク スイッチ、またはその他のデバイスのデータに対して自動分析計算が実行されます。

洗濯機、ロボット掃除機、家庭用サーモスタットなどの WiFi 接続デバイスは、今ではよく知られています。これらの IoT デバイスは、統計情報やステータスを送信することが多く、スマート ホーム ハブ経由で使用したり、スマートフォンに表示したりできるので便利です。しかし、IoT デバイスの広範な導入は IoT 革命の半分に過ぎません。残りの半分は、自己診断と統計分析を実行し、その情報を企業に送信してさらに分析することで、最終的には接続性だけでなくスマート性も実現します。簡単な例としては、天気、到着時間、交通状況などの情報に基づいて予測を計算し、お風呂のお湯を沸かし始めたり、掃除機に掃除を開始するよう指示したりして、所有者が帰宅する前に掃除を終えることができるサーモスタットがあります。所有者に通知するのではなく、ソース デバイスまたはエッジ コンピューティング デバイスで決定とアクションが行われます。

すべての情報を単一のソースに送信し、変換と分析を適用してから他のデバイスにフィードバックを送信するのではなく、エッジ コンピューティング分析はより高速で柔軟なアプローチです。

たとえば、電気通信業界を例に挙げると、かつてはそのようなやり方で運営されていました。通常、電話オペレータがユーザーの通話に応答する中央通信ハブでは、ユーザーは事前に回線を「注文」する必要があり、回線が開いた後にのみ通話でき、すべての通話は中央の場所を経由してルーティングされ、その分析は中央ハブでのみ行われます。

今日では、モバイル デバイスに番号を入力するだけで電話をかけることができ、ルーティングはすべて自動的に、より速く実行されます。分析を行う前に情報が中央ハブに到達するのを待つ必要はありません。今では、ユーザーは自分のデバイスからでも、いつでも、任意の方法（部分的または全体的）で情報を分析できます。

もうひとつの現実の例を挙げてみましょう。たとえば、数十機の飛行機が空港の上空を旋回し、離陸や着陸の準備をしているとします。数秒または数ミリ秒単位でデータを分析する能力は、航空会社の収益だけでなく、他の分野にも影響を与えます。その真のビジネス価値は乗客の命に結びついています。したがって、一秒一秒が重要であり、わずかなミスや技術的な問題が大きなドミノ効果を引き起こす可能性があります。

理論的には、データを集中管理された場所、たとえば元のデバイス（航空機またはその他のコンピューター デバイス）に送信する前に、分析の初期プロセスが開始されていれば、初期の洞察に基づいてアクションを実行できるため、洞察とアクションのギャップが解消されます。

エッジ コンピューティング デバイス上でアルゴリズムまたは分析機能の一部を実行し、同時にエッジ デバイスのローカル グリッドからハブまたは集中グリッドにデータを非同期または同期で非侵入的に転送することができます。ハブまたは集中グリッドでは、生データまたは集約データに対してさらに多くの計算が実行されます。

品質分析プラットフォームの導入

リアルタイム分析を実行するには、効率性を引き出し、ワークフローを合理化し、コンポーネント アーキテクチャを削減して総所有コスト (TCO) を削減することが重要です。ここで重要なのは、ラムダ アーキテクチャやカッパ アーキテクチャは、すべての情報をデータ フローとして扱うことですべてを簡素化するのに優れているものの、アーキテクチャ内の可動部分の数が多いために予期しない複雑さが生じる可能性があることを理解しておくことです。

従来の分析ワークフローを採​​用し、重い処理をインメモリ プラットフォームに押し付けて、データ フローの収束または統合を実現することが、唯一の論理的な結論です。この「NoETL」ワークフローは、Spark の他のすべての利点に加えて、メッセージ ブローカーとしての Kafka と NoETL/ストリーム処理メカニズムとしての InsightEdge に完全に依存しています。

2 番目のフェーズは多言語分析です。これは、永続ストレージ層に保存されたアーカイブ データとリアルタイム データ ストリームを集約する品質分析の機能を定義します。

専門家は、2020 年までに世界で 40 ゼタバイトのデータが生成されると予測しており、この量のデータを処理できるプラットフォームが必要です。提案されたコンポーネントの簡素化されたアーキテクチャでは、これら 2 つのイベント ストリーム間の相関子が Kafka/Data Lake (またはより緩い用語で Data-Swamps) のキー プレーヤーになります。

このアーキテクチャにより、各データを返す可能性が保持されるだけでなく、Spark などのハイエンドかつ簡素化された分析ツールを活用してインメモリ コンピューティングを実行し、リアルタイムと履歴データの融合を実現できます。

最後に

あらゆる業界の企業にとって、データのリアルタイム分析が重要になっていることは明らかです。実際、急速に変化する世界や、要求の厳しい顧客体験、急速に変化する規制に対応するためには、それが不可欠になります。

しかし、ビッグデータの変革の可能性にもかかわらず、マッキンゼー・グローバル・インスティテュート（MGI）の 2016 年のレポートでは、ほとんどの業界がデータと分析の可能性をまだ十分に活用していないことがわかりました。