アクティベーターの待機時間

Fabric アクティベーターは、リアルタイム データに対してルールを実行します。 結果はほぼ瞬時ですが、さまざまな要因によって待機時間が発生する可能性があります。 ほとんどの場合、この待機時間には気付かないかもしれませんが、場合によっては最大 10 分になる場合があります。 ルールを作成して受信する際には、正確でタイムリーな情報の受け取りを考慮することが重要です。 この記事では、イベントとルール構造の包含のバランスを決定するプロセスと設定、および Activator がアクティブ化を送信する速度を確認します。 たとえば、アクティベーターはより多くのデータを受信して含めることを許可する必要がありますか、または Activator は受信者が設定された時刻にアラートを受け取ることを保証する必要がありますか? また、ルール構造は、アクティベーターが受信者にアクティベーションを送信する速度にどのように影響しますか?

ルールのアクティブ化の待機時間に影響する 3 つの重要な要因:

• 到着遅延許容度。
• バックエンド処理の待機時間。
• 集計の待機時間。

到着遅延許容期間

ストリーミング データでは、イベントが常に順番または時間どおりに到着するとは限りません。 イベントの イベント時間 (イベントが発生したとき) はルールの時間枠内にある可能性がありますが、その 到着時間 (アクティベーターが受信したとき) はそのウィンドウの外に収まり、イベントが遅れる可能性があります。 既定では、Activator はルールの評価から遅延イベントを削除します。

遅延到着イベントの待機時間設定は、評価ウィンドウを閉じる前に Activator が待機する時間を制御し、遅延イベントが到着する機会を与えます。 この設定は、ルール定義画面の [詳細設定] セクションにあります。 これを構成する方法については、「 到着遅延許容設定」を参照してください。

バックエンド処理の待機時間

アクティブ化する前に、アクティベーターでルールの処理が必要になることがあります。これにより、最大 1 分の遅延が発生する可能性があります。 たとえば、ルールが以前の一連のイベントと比較される場合、Activator は前のデータを取得し、比較を行い、結果を計算します。 別の例として、ルールが 1,000 万行のデータに対して実行される場合、そのボリュームの Activator の処理でも待機時間が発生します。

集計の待機時間

ルール定義で集計が使用されている場合、ルールは、指定された時間枠が完了したときにのみアクティブになります。 たとえば、4 時間にわたってデータを平均するようにルールが構築されるとします。 ルールの条件を満たすイベントが午後 12 時に取り込まれる場合、ルールは午後 4 時にトリガーされます。 待機時間は、集計設定の結果です。 ルールに average などの単純な集計が含まれている場合でも、アクティベーターでは、受信イベント データ全体で集計を実行するまで、アクティブ化を送信できません。

バックグラウンド時間のコンセプト

ディスカッションをより適切に組み込むには、いくつかの背景時間の概念を定義しましょう。

• イベント時間:元のイベントが発生した時刻です。 これはイベント ペイロードの一部です。 たとえば、料金所ブースに近づいている車をセンサーが検出した瞬間はイベント時間です。
• 処理時間: 処理システムがイベントを受信して観察する時刻。 たとえば、料金所センサーが車を見た後、コンピューター システムがセンサーの情報を受信して処理する時刻は処理時間です。
• 到着時間 (基準値または取り込み時間): イベント データがアクティベーターに到達するタイミングを示すマーカー。 ストリームの性質上、受信イベント データは停止しないため、到着時間は、アクティベーターがストリーム内の特定のポイントに対して行った進行状況を示します。 この時点で、アクティベーターは、取り消す必要のない完全で正確な、反復可能な結果を生成できます。 また、アクティベーターがデータの処理を開始できるのはこの時点です。 アクティベーターは、予測可能で反復可能な方法でデータを処理します。 たとえば、アクティベーターがエラー処理のためにデータを再カウントする必要がある場合は、到着時刻を安全な開始点と終了ポイントとして使用できます。 たとえば、料金所ブース システムが午前 9 時 5 分まですべての車検出を受け取ると、到着時刻マーカーは午前 9 時 5 分に進みます。 イベント 時間 が午前 9 時 5 分より前であった場合でも、その時点より後に到着した検出は遅れます。

遅延到着は、ルールに時間パラメーターがあり、 イベント時間 がその時間パラメーター内にあるが、 到着時刻 がそれ以外の場合に発生します。 料金所ブースの例を使用して:センサーは車を検出し、 イベント時間 はルールの時間枠内にあります。 ただし、ネットワークの輻輳などによってセンサーが検出を送信するのに時間がかかりすぎる場合は、ウィンドウが閉じた後にアクティベーターにイベントが到着します。 アクティベーターは、そのイベントを遅延と見な します。 遅延到着を含める場合は、[詳細設定] で到着遅延イベントの待機時間を設定します。

このテーマに関する追加リソースについては、Tyler Akidau 氏のブログ記事「Streaming 101」 (ストリーミング 101) と「Streaming 102」 (ストリーミング 102) を参照してください。

到着遅延許容の設定

到着遅延許容設定を構成できます。 既定値は 2 分です。 この設定は待機時間の影響を受けます。 待機時間で作成するルールには、構成された期間と同じ最小待機時間があります。 ルールを作成するときに、既定を使用するか変更するかを決定します。 この設定により、遅延イベントと順序外イベントをルールの評価に含めることができます。 イベントが構成された到着遅延許容値の範囲外の場合、Activator はそれを考慮しません。 そのしきい値を超える 到着時間 を持つイベントは、考慮されません。

全体的に、次の点が重要かどうかを検討します。

• 遅延しているデータポイントを待ちます。または
• 不完全な可能性があるデータに対してルールを実行して、ルールが早くアクティブ化されるようにします。 

この例では、データ ポイントは 15 分単位で測定されます。 青で示された最初の 3 つのドットは、時間枠内に収まっています。 4 つ目のドット (オレンジ色) はそうではありません。 "イベント時間" は 15 分以内ですが、イベントは 15 分以内にアクティベーターによって取り込まれていません。 アクティベーターは、15 分以内の "到着時間" のデータのみに対してルールを評価します。 到着遅延許容値を増やさない限り、ウィンドウが閉じた後に到着するデータ ポイントは含まれません。

アクティベーターは、データ ソースからの遅延を考慮に入れることはできません。 たとえば、IoT センサーが 1 時間オフラインになっているとします。 オンラインに戻ると、Activator はデータを受信できますが、そのオフライン状態から 1 時間遅延しました。これは Activator の外部で発生します。

次に別の例を示します。

平均温度を分単位で計算するルールを作成します。 到着遅延イベントの待機時間は、既定値の 2 分に設定されます。 アクティベーターは温度値20と30を含み、平均25を計算します。 ただし、Activator には、40 度のイベントが予定より遅れて到着する場合、次のルールがアクティブ化されるまでそれは含まれません。

Power BI ビジュアルに構築されたルール

組み込みの待機時間はサービスによって異なります。 イベントストリームの待機時間は、Power BIビジュアルの待機時間とは異なります。 Power BIビジュアルに基づいて構築されたルールの待機時間には、システムに組み込まれているビジュアルPower BIクエリを実行する頻度と、Activator のバックエンドによって発生する遅延という 2 つの要因が影響を受けます。

Power BI ルールは、新しいデータがアクティベーターに到着するたびに評価されます。 既定では、Activator は 1 時間に 1 回Power BI にクエリを実行します。つまり、ルール条件を満たすイベントは、イベントが発生してから最大 1 時間以内にアクティベーションをトリガーします。 この頻度は、データ ソースの設定で変更できます。 詳細については、「クエリ データ ソースのクエリ頻度とPower BIアラートを作成し、Fabric Activator で絞り込む方法を参照してください。