Fabric Activator は、データ ストリームを自動化されたアクションに変換するコードなしのイベント検出エンジンです。 データ ソースで特定のパターンまたは条件が検出されると、アクションが自動的にトリガーされます。 待機時間が短い (ストリーミング データのステートレス ルールの場合は 1 秒未満) これらのデータ ソースを継続的に監視し、しきい値が満たされるか、特定のパターンが検出されたときにアクションを開始します。 これらのアクションには、電子メールや Teams 通知の送信、Power Automate フローの起動、サードパーティシステムとの統合などがあります。
コア アーキテクチャ
アクティベーターは、Fabric Real-Time インテリジェンス スタックの中心にあるイベント検出およびルール エンジンです。 アーキテクチャ上、高度なオブザーバーとして機能します。高速データ ストリームを使用し、ほぼリアルタイムでルールの条件を評価し、イベント状態の変化に基づいて自動化されたダウンストリーム アクションを開始します。
継続的にデータが流れ込むリアクティブなイベントドリブンアーキテクチャによく適合します。アクティベーターは、イベントデータのステートフルな評価に基づき、ほぼリアルタイムで意思決定を行います。
イベント ソース
アクティベーターは、さまざまなプロデューサー (Azure Event Hubs、IoT デバイス、カスタム エンドポイント、およびその他のソース) からデータを取り込む eventstream に直接接続します。 これらのストリームはイベントのソースとして機能し、Activator は 1 つ以上のイベントストリームをサブスクライブしてデータの変更を監視できます。 その他のイベント ソースには、Fabric や Azure のイベント、Power BI レポートあるいはリアルタイムダッシュボードをリッスンするアクティベーターがあります。
イベントとオブジェクト
イベントは、eventstream を介して受信された個々のレコード (テレメトリシグナルやファイルドロップなど) です。 これらのイベントは、共有識別子に基づいてオブジェクトにグループ化されます (たとえば、同じデバイスのすべてのイベントが
device_idを使用してグループ化されたり、すべての自転車ステーション イベントがbikepoint_idでグループ化されたりします)。 その後、オブジェクトごとにルールが評価され、きめ細かい検出が可能になります (たとえば、センサーごと、資産ごと)。ルールと条件
各アクティベーターには、継続的に評価される 1 つ以上のルールが含まれています。 これらのルールには、単純な比較 (
value < threshold) や、BECOMES、DECREASES、INCREASES、EXIT RANGE、データの欠如 (ハートビート) などの時間の経過に伴う変化を追跡する条件を指定できます。 アクティベーターはオブジェクトごとの状態追跡を保証します。これにより、時間の経過に伴う複雑なパターン検出が可能になります。アクション
ルール条件が満たされると、アクティベーターは次をトリガーできます。
Fabric のパイプライン、ノートブック、データフロー、ユーザー データ関数 (UDF) (プレビュー) または Spark ジョブ定義。
Power Automateによる外部アクション。
個人、グループ、またはチャネルに Teams メッセージを送信します。
電子メールを送信します。
アラートの管理とルールのテスト
アクティベータは、ルールがアクティブ化される前にプレビューと影響を推定し、過去のデータに基づいてルールがどのくらいの頻度で発生したかを示します。 これらの機能は、アラートのスパムや過剰な発生を防ぐのに役立ちます。 内部的には、状態遷移はノイズを抑制するために管理されます（たとえば、値は単にしきい値を下回るのではなく、しきい値を超える必要があります）。
監視とコスト管理
アクティベーターがアクティブに実行されている場合にのみコストが発生します。 アクティベーター インスタンスはFabricのキャパシティにスコープされており、ワークスペースを通じて監視することができます。 ランタイム ログとテレメトリは、イベントストリームとパイプライン出力を介して使用できます。
デプロイメント モデル
ワークスペースごとにアクティベーター インスタンスをデプロイし、特定のデータ ソースにバインドします。 複数のアクティベーターが同じストリームを監視できるため、個別のビジネス機能に対して並列ルール評価を使用できます。 アクティベーターは容量に制限されているため、従量課金制の価格は、ルールがアクティブに実行されている場合にのみ適用されます。 この価格モデルは、断続的な検出シナリオのコスト効率を提供します。 既知の制約については、「 アクティベータの制限事項」を参照してください。
Real-Time インテリジェンス内の統合ポイント
| コンポーネント | アクティベーターとの対話 |
|---|---|
| Eventstream | パターンと条件を監視できるように、リアルタイム データを Activator に送信します。 アラートの作成とルール管理も Eventstream 内に直接埋め込まれているため、ユーザーはコンテキスト内でルールを作成および管理できます。 |
| アクティベーター | エンリッチされたデータや分類されたデータなど、別のアクティベーターをトリガーする新しいイベントを作成できます。 |
| パイプライン | ダウンストリーム処理を自動化する Activator のルール トリガーのターゲット。 |
| Power BI | テーブルビジュアルの行検出を含む、レポートビジュアルのアクティベータールールのイベントソースとして機能します。 また、トリガーされたパイプラインまたはノートブックの結果を使用して、リアルタイムの視覚化を行います。 |
| Power Automate | イベントが発生したときに事前構築済みワークフローまたはカスタム ワークフローを使用してタスクを自動化します。 |
| ファブリックイベント | セマンティック モデルの更新やパイプラインの失敗など、Fabric内で発生するイベントを提供します。 |
| Notebooks | アクティベーターはノートブックの実行をトリガーできます。 |
| Spark ジョブ定義 | アクティベーターは、Spark ジョブの実行をトリガーできます。 |
| ユーザー データ関数 | アクティベーターは、ユーザー データ関数 (UDF) の実行 (プレビュー) をトリガーできます。 |
| データフロー | アクティベーターは、ルール条件が満たされたときにデータフローの実行をトリガーできます。 |
オーケストレーターとしてのアクティベーター
大規模なシステムでアクティベーターを効果的に使用するには、他のFabricコンポーネントとの連携方法を調整します。 処理しているデータの量、追跡するオブジェクトの数、ルールの複雑さに基づいて設定を最適化します。 このセクションでは、アクティベーターを他のサービスと調整する方法と、検出ロジックとランタイム動作を最適化して、低待機時間 (高速)、コスト効率の高い大規模な自動化をサポートする方法について説明します。
アクティベーターは、到着時点でデータを評価し、ダウンストリームでアクションをトリガーすることで、イベント ドリブン パイプラインで中心的な役割を果たします。 一般的な オーケストレーション パターンは 次のとおりです。
| パターン | フローの説明 |
|---|---|
| インジェスト →検出→変換 | イベントは Eventstream から Activator に流れ、パイプラインをトリガーしてデータをエンリッチまたは移動します。 |
| インジェスト →検出→通知 | アクティベーターは、アラートを送信したり、状態を Teams、Outlook、または ServiceNow にプッシュしたりするPower Automateをトリガーします。 |
| インジェスト →検出→モデル スコアリング | アクティベーターは、ノートブックをトリガーして ML モデルにスコアを付けたり、リアルタイムの異常に基づいて高度な分析を実行したりします。 |
| アクティベーターを使用したフィードバック ループ (計画済み) | アクティベーターによって生成された分析情報 (秘密度ラベルなど) は Activator ルールにフィードされ、セマンティックにエンリッチされた自動化が可能になります。 |
主要な概念
Fabric Activator は、データを継続的に監視し、定義した条件が満たされたタイミングを、時間の経過と同時にデータが変化しても迅速に検出します。 アクティベーターは、イベントストリームを介して生成されたリアルタイムイベントを処理し、論理オブジェクトごとのルール条件を評価し、状態遷移に応答してアクションを開始します。
次の概念を使用して、Fabric Activator で自動化されたアクションと応答を構築してトリガーします。
イベント ソースとイベント
Fabric Activator は、すべてのデータ ソースをイベントのストリームとして扱います。 イベントはオブジェクトの状態に関する観察を表し、通常は、監視対象のフィールドのオブジェクトの識別子、タイムスタンプ、および値が含まれます。
Activator に取り込まれるイベントの発生元は次のとおりです。
- Eventstream。複数のアップストリーム ソース (Azure Event Hubs、IoT Hub、Blob Storage トリガーなど) をサポートします。 Eventstream は、Microsoft Fabric内の特定の項目の種類です。これにより、コードを記述することなく、リアルタイム イベントを取り込み、変換し、ルーティングできます。 Fabric Activator はイベントストリームを監視し、定義されたパターンまたはしきい値が検出されたときに自動的にアクションを実行します。 アクティベーターは、2 つ以上のイベントストリームをサブスクライブして、データの変更を監視することもできます。 Eventstream は頻度によって異なります。 たとえば、IoT センサーは 1 秒に複数回イベントを出力し、物流システムは、配送先でパッケージをスキャンするときなど、散発的にイベントを生成します。
- Fabricイベント。 たとえば、Fabricワークスペースアイテムイベントは、Fabricワークスペースに変更が加えられたときに発生する個別のFabricイベントです。 これらの変更には、Fabric項目の作成、更新、または削除が含まれます。
- Azureイベント たとえば、Azure Blob Storage イベントは、クライアントが BLOB を作成、置換、または削除したときにトリガーされます。
- ビジネス イベント。 ビジネス イベントに対してアラートを直接設定して、特定のビジネス条件が発生したときにアクションを自動化できます。
- Fabric オントロジーのビジネスエンティティ（プレビュー） オントロジのビジネス エンティティに対してルールを定義してアラートと自動アクションを開始し、モデル化されたデータに基づく運用上の意思決定を可能にすることができます。
- Power BIレポート。 この場合、イベントは、Power BIセマンティック モデル (旧称データセット) の更新スケジュールに基づく定期的な観察です。 これらの観測値は毎日または毎週発生し、動きが遅いイベントストリームを形成する可能性があります。 また、Activator はPower BI serviceと統合して、パブリッシュされたレポートのテーブル ビジュアルに新しい行が表示されたときにユーザーに通知し、ルールでビジュアル レベルの変更を監視し、通知またはダウンストリーム アクションをトリガーできるようにします。
- Fabric Real-Time ダッシュボード。
各イベントには次のものが含まれます。
- タイムスタンプ
- ペイロード (構造化データまたは半構造化データ)
- オブジェクト識別に使用される 1 つ以上の属性 (device_id、bikepoint_idなど)
オブジェクト
Fabric アクティベーターでは、監視するエンティティはビジネス オブジェクトと呼ばれ、物理オブジェクトまたは概念的なエンティティを使用できます。 たとえば、フリーザー、車両、パッケージ、ユーザーなどの物理的なオブジェクトや、広告キャンペーン、顧客アカウント、ユーザー セッションなどの概念オブジェクトなどがあります。
Activator でビジネス オブジェクトをモデル化するには、1 つ以上のイベントストリームを接続し、オブジェクト ID として機能する列を選択し、オブジェクトのプロパティとして扱うフィールドを指定します。
オブジェクト インスタンスという用語は、特定の冷凍機、車両、またはユーザー セッションなどのビジネス オブジェクトの特定の例を指します。 これに対し、オブジェクトは通常、一般的な定義またはクラス (たとえば、型としてフリーザー) を参照します。 用語「母集団」は、監視されているオブジェクト インスタンスの完全なセットを指します。
オブジェクトの作成は暗黙的です。アクティベーターは、指定されたオブジェクト キーを使用してイベントをグループ化します。 ルールのスコープはオブジェクトです。つまり、すべての評価ロジックはオブジェクトに対応し、インスタンス間で独立しています。 たとえば、ルール監視 bikepoint_id では、一意の自転車ステーションごとに個別の論理評価が作成されます。
ルール
ルールは、オブジェクトで検出する条件と、それらの条件が満たされたときに実行するアクションを定義します。 たとえば、フリーザー オブジェクトのルールでは、温度が安全なしきい値を超えたときに検出され、割り当てられた技術者に電子メール アラートが自動的に送信される場合があります。
Activator のルールは、ステートレスまたはステートフルにすることができます。
- ステートレス ルール は、各イベントを分離して評価します (たとえば、値 < 50)。
- ステートフル ルール では、オブジェクトごとのイベント間でメモリが維持されます (たとえば、値 DECREASES、BECOMES、EXIT RANGE)。
アクティベーターは、FABRIC DATA WAREHOUSE SQL クエリ結果 (プレビュー) に基づくルールの作成もサポートしています。 構成可能なスケジュールで SQL クエリを評価し、結果セットに対して条件をチェックし、条件が満たされたときにアクションをトリガーするルールを定義できます。 この機能により、ストリーミング ソースを必要とせずにウェアハウス データを監視できます。 詳細については、「 SQL クエリでアラート ルールを作成する」を参照してください。
ステートフル評価は次の事項に依存します。
- 差分検出: 以前のイベント値と現在のイベント値の間の変更を追跡します。
- 一時的なシーケンス処理: イベントがない (ハートビート検出) などの時間ベースの条件を評価します。
- 状態遷移: ルールは新しい状態に入ったときにのみ発生し、変更されていない条件での繰り返しの発生を防ぎます。
ルールは継続的に評価されます。 ストリーミング データのステートレス ルールの場合、システムはミリ秒以内に応答します。 集計を含むルールの場合、待機時間はルックバック ウィンドウと到着遅延許容度によって異なります。 詳細については、「 Activator の待機時間」を参照してください。
アクション
ルールの条件が満たされ、アクションが開始されると、ルールがアクティブになります。 アクションでサポートされるターゲットは次のとおりです。
- データ移動やデータエンリッチメント用のファブリックパイプライン。
- Fabricノートブック (機械学習スコアリング、診断用)。
- FabricプラットフォームでのSparkジョブ（バッチ/ストリーミングジョブ）
- Fabricデータフロー (データ移動と変換用)。
- Fabric ユーザー データ関数 (プレビュー) (コードを使用してカスタム ビジネス ロジックを作成するために)。
- Power Automateフロー (業務プロセス統合用)。
- Teams の通知 (テンプレート ベースのメッセージングを使用)。
- Email通知。
ルールがトリガーされると、アクティベーターは何が起こったかについての情報を送信し、アクションが完了するのを待たずに監視を続けます。 このアプローチにより、多数のイベントを同時に処理できるスケーラブルなワークフローが可能になります。
プロパティ
プロパティは、監視するビジネス オブジェクトの特定のフィールドまたは属性です。 これらは物理的または概念的な特性であり、例として次に示します。
- パッケージの温度
- 出荷の状態
- 顧客アカウントの残高
- ユーザー セッションのエンゲージメント スコア
プロパティは、IoT センサー、Power BI レポート、その他のシステムなどのソースからの継続的なデータ フローであるイベントストリームから取得されます。
Activator でビジネス オブジェクトを定義するときは、1 つ以上のイベントストリームを接続し、オブジェクト ID として機能する列を選択し、そのオブジェクトのプロパティとして扱う他の列を選択します。 これらのプロパティに対してルールを作成して、時間の経過に伴う変更の追跡、プロパティがしきい値を超えた場合や範囲外の場合の検出、アラート、ワークフロー、通知などのアクションのトリガーを行うことができます。
プロパティは、複数のルール間でロジックを再利用する場合にも便利です。 たとえば、フリーザー オブジェクトでは、1 時間の温度平均を計算するプロパティを定義できます。 定義したら、このプロパティを複数のルール (過熱、温度変動、メンテナンスしきい値を検出するルールなど) で、ロジックを複製せずに参照できます。 プロパティのロジックを一元化することで、ルールの管理が容易になり、一貫性が高く、時間の経過とともに更新が容易になります。
振り返り期間
ルックバック期間は、アクティベーターがルールを評価するために分析する履歴データの期間です。 これにより、データが遅延または不規則に到着した場合でも、パターンや平均などの計算集計を正確に検出できる十分な過去のデータが確保されます。
ルックバック期間は、次の方法で決定します。
- ルールを定義する方法 。たとえば、傾向の分析、異常の検出、時間の経過に伴う値の比較が必要かどうか。
- 受信データの量 (イベントストリーム内の 1 秒あたりのイベント数など)。
コールド チェーン内の医薬品パッケージを輸送する医薬品物流操作について考えてみましょう。 目標は、パッケージが暖かくなりすぎるときにアラートを受信することです。
次の規則を定義するとします。
- 各パッケージの平均温度を 3 時間で評価する
- 平均気温が 8°C を超えた場合にアラートをトリガーする
このルールを正確に計算するには、Fabric Activator は履歴データのより広い期間 (たとえば、3 時間の平均の 6 時間のルックバック期間) を分析する必要があります。 このプロセスにより、ある程度の遅延や不規則性でデータが到着した場合でも、任意の時点で 3 時間の平均を計算するのに十分なデータが確保されます。
ルックバック期間は、特にデータ パターンが時間の経過と同時に進化するシナリオで、状況をタイムリーかつ正確に検出するために不可欠です。
個別のアクティブなオブジェクト ID
属性に基づいて構築されたルールを使用して、オブジェクトの特定の属性が時間の経過とどのように変化するかを監視します。 医薬品物流の例では、各医薬品パッケージは一意のオブジェクト ID で表され、システムは各パッケージの定期的な温度測定値を受け取ります。
これらのルールを効果的に評価するために、Fabric Activator はアクティブなオブジェクト ID (つまり、定義されたルックバック期間内にイベントが到着するオブジェクト) を追跡します。 この動作により、ルールを適用するときに、システムは関連する現在アクティブなオブジェクトのみを考慮します。
たとえば、有料ステーションでは、通過する車両 (オブジェクト ID) を追跡できます。 各車両はイベント (入退出スキャンなど) を生成し、システムは最近のアクティビティを持つオブジェクトのみを評価します。
ルックバック ウィンドウ内で追跡する個別のオブジェクト ID の数 (パッケージの数) も制限を設定します。
一般的なユース ケース
Fabric Activator を使用できる実際のシナリオをいくつか次に示します。
- 同じ店舗の売上が減少したときに広告キャンペーンを自動的に開始し、パフォーマンスの低い場所でのパフォーマンスを向上させます。
- 腐敗が発生する前に、食品を誤動作するフリーザーから再配置するように食料品店のマネージャーに通知します。
- 顧客がアプリ、ウェブサイト、または他のタッチポイントを通じてネガティブな体験を示した場合、その対応としてパーソナライズされたアウトリーチ ワークフローを開始します。
- 定義された期間内に出荷の状態が更新されない場合は、事前に調査ワークフローを開始し、紛失したパッケージをより迅速に見つけることができます。
- 顧客が延滞に陥ったときに、顧客ごとの時間または未払いの残高に対してカスタマイズされたしきい値を使用して、アカウント チームにアラートを送信します。
- パイプラインの正常性を監視し、異常または障害が検出されたときに失敗したジョブまたはアラート チームを自動的に再実行します。