Loading article…
リアルタイムビジネスインテリジェンス（RTBI ）は、イベントと意思決定に使用される情報との間の遅延を短縮するビジネスインテリジェンスのアプローチです。 [ 1 ] [ 2 ]これは、通常履歴データからレポートを作成する従来のビジネスインテリジェンス（BI）とは異なります。RTBIは、アクティビティが発生した時点により近い時間にデータを利用可能にすることで、監視と運用対応をサポートできます。[ 2 ] [ 3 ]
RTBI システムは、更新された分析ストア、イベント ストリーム、イベント ログ、複雑なイベント処理、ビジネス アクティビティ モニタリング、または関連するアーキテクチャを使用します。[ 4 ] [ 5 ] [ 6 ]その出力は、ダッシュボード、アラート、プロセス モニタリング ツール、分析ビュー、または応答を通じて表示される場合があります。[ 2 ] [ 5 ]
「リアルタイム」は文脈によって異なります。一部のシステムはイベントを数秒以内に処理しますが、他のシステムはほぼリアルタイムと表現する方が適切です。したがって、RTBIには、速度、データの鮮度、コスト、複雑さ[ 7 ]、および分析時に利用可能な情報の信頼性[ 4 ]の間でのトレードオフ[ 1 ]が伴います。
従来のBIは、履歴データの報告の改善に重点を置いてきた。[ 3 ]しかし、RTBIは、データ収集から応答までの遅延を削減することに重点を置いている。[ 2 ] [ 8 ]
すべてのリアルタイムビジネスインテリジェンスシステムには何らかの遅延がありますが、その目的はイベント発生から情報利用までの遅延を減らすことです。アナリストのリチャード・ハッカソーンは、遅延を3つのタイプに分類しています。[ 8 ]
リアルタイム分析に関する最近の研究では、リアルタイム分析システムの重要な特徴として、速度と鮮度の両方が挙げられています。データの鮮度はレイテンシとは異なります。[ 1 ]システムはクエリを迅速に処理できますが、そのデータはすでに古くなっています。逆に、イベント直後に収集された運用データは、意思決定をサポートする前にさらに処理が必要になる場合があります。
「リアルタイム」の意味は文脈によって異なります。一部のシステムは数秒以内にイベントを処理しますが、データがタイムリーな意思決定をサポートするためにできるだけ早く利用可能になるため、他のシステムはほぼリアルタイムと呼ばれます。Hackathorn [ 8 ]は「リアルタイム」の代替として「ライトタイム」を挙げていますが、より重要な問題は、作成された情報のタイミングがビジネス価値を生み出すかどうかであると主張しています。
RTBI のアーキテクチャは、データの収集、処理、保存、および表示方法によって異なります。従来のビジネス インテリジェンス システムには、運用ソース、データ統合プロセス、分析ストレージ、クエリ処理、および表示ツールが含まれます。[ 3 ] RTBI では、これらの機能は依然として重要ですが、アーキテクチャはビジネス イベントとそこから得られる情報の使用との間の遅延を短縮するように設計されています。[ 2 ]
イベント駆動型アーキテクチャでは、状態の変化はイベントとして表現され、発生時に処理されます。イベントストリーム処理と複合イベント処理システムは、複数のソースから継続的に情報を処理します。これらのシステムは、すべてのデータが従来のデータベースにロードされる前に、イベントストリーム内のパターンをフィルタリング、集約、相関付け、または検出することができます。[ 6 ]
RTBI の場合、イベント処理は、現在のビジネス条件が定義されたルールを満たす場合にダッシュボードとアラートをサポートします。ストリーミングシステムは、順番に到着しないデータも処理する必要があります。レコードは遅れて到着したり、場合によっては不完全な場合もあります。継続的なクエリやタイムウィンドウなどの技術は、そうでなければ連続的なストリームの一定期間にわたって結果を計算するために使用されます。[ 6 ] [ 1 ]
一部のRTBIアーキテクチャでは、イベントログを使用して変更を他のシステムに渡します。イベントログは追記専用のレコードであり、他のシステムがこれを使用してダッシュボード、分析ストア、アラートシステム、検索インデックス、マテリアライズドビューを更新できます。[ 4 ]関連するアプローチには、変更データキャプチャとイベントソーシングがあります。
変更データキャプチャは、既存のデータベースからストリームを生成する方法の1つです。データベーステーブルに加えられた変更を記録し、データセット全体を再ロードすることなく、それらの変更を他のシステムで利用できるようにします。RTBIでは、これにより、分析ストアやイベント処理システムを最新の運用データに近づけることができます。[ 1 ] [ 4 ]
イベントソーシングは、アプリケーションの状態変更を現在の状態レコードとしてではなく、イベントのシーケンスとして保存するアーキテクチャパターンです。エンティティの現在の状態は、保存されているすべてのイベントを順番に再生することで再構築できます。[ 9 ] RTBIでは、イベントソーシングシステムは、派生読み取りモデルによるレポート作成と分析をサポートするイベント履歴を提供できます。これらのビューは、ダッシュボードやその他の分析ツールで使用できます。[ 9 ]監査可能性、以前の状態の再構築、同じイベント履歴からの複数のビューの作成をサポートできます。イベントストアを直接クエリすると非効率になる場合があり、レポート作成や分析用に個別の読み取りモデルが構築されるため、コマンドクエリ責任分離（CQRS）[ 9 ]と併用されることがよくあります。イベントソーシングでは、イベントスキーマの変更、再生、ストレージの増加、イベントストアと派生ビュー間の最終的な一貫性など、設計上の問題が発生する可能性があります。[ 10 ]
別のアプローチとしては、データウェアハウスや分析ストアをより頻繁に更新する方法があります。これにより、従来のBIに関連付けられている履歴比較やレポート機能が維持され、アクティビティとデータの利用可能性の間の遅延が短縮されます。[ 3 ]
クラウドデータウェアハウスやハイブリッドトランザクション処理システム、分析処理システムの中には、ほぼリアルタイムの分析をサポートすると説明されているものもあります。実際には、これは利用可能なデータの最新性、実行されるクエリの複雑さ、ソースシステムと分析システムの設計方法によって異なります。イベント駆動型システムと分析ストアは一緒に使用できます。たとえば、選択されたイベントはダッシュボードやアラートに直接送信され、同じ運用データは後で確認するために分析ストアにも保持されます。[ 4 ]
ビジネス活動監視(BAM) は、進行中のビジネスプロセスを追跡するため、RTBI と密接に関連しています。[ 2 ] [ 11 ] BAM は、後からの報告を待つのではなく、運用システムからのイベントを使用して、プロセスが期待どおりに実行されているか、注意が必要かを示します。[ 5 ]一部の文献では、BAM とイベント処理技術のこの重複をイベント駆動型 BI または運用インテリジェンスと説明しています。[ 5 ]この文脈では、運用インテリジェンスとは、ビジネス活動中の監視と対応をサポートするために現在の運用データを使用することを指します。[ 5 ]
BAMアーキテクチャでは、運用システムがイベントを生成し、それが事前定義されたルールやパターンに基づいて処理されます。結果として得られた情報は、ダッシュボードに表示したり、ワークフローやエンタープライズシステムでの応答を開始するために使用したりできます。[ 5 ]
RTBIは、遅延した情報によって意思決定や対応の有用性が低下する可能性がある場合に使用されます。イベント処理の研究では、不正検出、ネットワークセキュリティ、金融市場分析、センサー監視、在庫追跡、製造管理などの分野における例が議論されています。[ 6 ]これらの分野では、データが生成された時点に近いタイミングで処理されるため、後の報告サイクルの前に変更を特定できます。[ 6 ]
ビジネス活動監視システムは、エンタープライズアプリケーションやプロセスエンジンからのイベントを使用して、作業が進行中にその状況を追跡します。[ 5 ]これにより、プロセスの例外を後日のレポートだけでなく、ダッシュボードやアラートを通じて可視化できます。[ 5 ]
RTBIは、製造、小売、金融サービス、運輸、電気通信、公益事業、医療における運用支援など、ビジネスインテリジェンスに関連付けられている用途を拡張します。[ 3 ]その主な特徴は、運用活動と監視または対応に利用できる情報との間の時間が短いことです。[ 2 ]
小売環境において、RTBIは、店舗活動のタイミングに近い時期に販売や在庫移動の情報を提供することで、予測や補充などの分野で在庫状況をサポートすることができます。例えば、コープ・グループは、SAPのリアルタイムサプライチェーンシステムを使用してこれらの分野のデータを提供していると報告しています。[ 12 ]
金融協同組合や相互会社も、リアルタイムまたはイベント駆動型データシステムを使用していることが記録されています。ラボバンク[ 13 ]はバッチ処理からリアルタイムのイベント駆動型オペレーションに移行していると説明されており[ 14 ] 、ネーションワイド・ビルディング・ソサエティは、トランザクションデータへのほぼリアルタイムのアクセスを提供するためにApache Kafkaと変更データキャプチャを使用していると報告されています[ 15 ] 。
RTBI の制限には、データ処理の遅延や順序の乱れが含まれます。より完全な情報が利用可能になると、初期の結果でも更新が必要になる場合があります。[ 6 ] [ 1 ]これらの問題は、すべての情報が判明する前に連続的なデータフローが処理されるストリーミング システムで発生します。[ 7 ]
イベント駆動型およびログベースのシステムでは、イベントスキーマ、リプレイ、監視、ソースビューと派生ビュー間の一貫性のために追加の設計作業が必要になる場合があります。[ 4 ]イベントソーシングは以前の状態の再構築をサポートしますが、スキーマの変更とイベントストアから派生した読み取りモデルの管理に注意する必要があります。[ 9 ] [ 10 ]
即時の分析は必ずしも必要ではない。ハッカソーンは、ビジネスインテリジェンスの価値は、情報が可能な限り早い時点で入手できるかどうかではなく、適切なタイミングで入手できるかどうかにかかっていると主張している。[ 8 ]