Docs Menu
Docs Home
/
MongoDB Atlas
/

ストリーム プロセッサ Windows

項目一覧

  • ダンプリング Windows
  • ホスティングWindows
  • Stream Processing タイミング
  • サーバーマーク
  • 許容レイテンシ
  • アイドルレス タイムアウト

Atlas Stream Processing Windowsは、データストリームの時間指定されたサブセットを取得する 集計パイプライン ステージであり、ストリーミング データに対して一定の入力を必要とする操作を実行できます。

こちらで説明されているサンプル ストリーム プロセッサを検討してください。 $matchステージは$sourceによって取り込まれたデータのストリームを直接操作し、ストリーム プロセッサが取り込む各ドキュメントを一致条件と照合します。

一方、 $groupステージとそれに含まれるさまざまな統計計算は、無制限データでは実行できません。最小値、最大値、平均値、中央値を決定するには、まず考慮する値のセットを制限する必要があるためです。 $push$topなどの多くの非数学演算子でも、境界のあるデータが必要です。

ストリーム プロセッサは、これらの限界を ウィンドウで提供します。 ウィンドウが開き、ストリーム プロセッサが取り込むすべてのドキュメントは、事前定義された時間が経過してウィンドウが閉じられるまで、そのウィンドウの状態に蓄積されます。 ウィンドウは、その間隔中にキャプチャしたすべてのドキュメントをバッチし、このセットを内部パイプラインに渡します。 このパイプライン内では、バッチ処理されたドキュメントは保管中のデータと区別できません。

Atlas Stream Processingは、 Windows の Windowsサポートと のWindows をサポートしています。

ダンプリングWindowsは、キャプチャされる時間間隔によって完全に定義されるWindowsです。 これらの時間間隔は重複しません。

3 秒間隔のローリング ウィンドウを定義します。 ストリーム プロセッサを起動すると、次のことを行います。

  • ウィンドウが 3 秒開きます。

  • 最初のウィンドウは、ストリームが 3 秒以内に生成するすべてのドキュメントをキャプチャします。

  • 3 秒が経過すると、ウィンドウが閉じ、そのウィンドウ内のすべてのドキュメントに集計ロジックが適用されます。

    allowedLatenessを構成する場合、Atlas Stream Processing は、ウィンドウが閉じられた後に遅延メッセージをデッド 文字キューに書込みます。

  • 最初のウィンドウが閉じるとすぐに新しいウィンドウが開き、次の 3 秒間ストリームからドキュメントがキャプチャされます。

Windowsを使用すると、個々のドキュメントを繰り返し処理することなく、データ ストリームを包括的にキャプチャできます。

ホスティングWindows Windowsあり、 opと呼ばれます。 期間は頻度から切り離されているため、ホスティングWindowsが重複したり、間隔が開いたりするように構成できます。

オーバーラップするホスティング ウィンドウを定義するには、 間隔よりも小さい請求書を設定します。

間隔が 20 秒で、ホスティングが 5 秒のホスティング ウィンドウを定義します。 ストリーム プロセッサを起動すると、次のことを行います。

  • ウィンドウが 20 秒開きます。

  • 最初のウィンドウは、ストリームが 20 秒以内に生成するすべてのドキュメントをキャプチャします。

  • 5 秒後に別のウィンドウが開き、次の 20 秒以内にすべてのドキュメントがキャプチャされます。 最初のウィンドウはまだ開いているため、次の 15 秒間にストリームが生成するすべてのドキュメントは、両方のWindowsによってキャプチャされます。

  • 最初のウィンドウが開かれてから 20 秒後に、ウィンドウが閉じられ、そのウィンドウ内のすべてのドキュメントに集計ロジックが適用されます。

  • 5 秒後に 2 番目のウィンドウが閉じ、最初のウィンドウで集計ロジックの対象となるドキュメントを含む、そのウィンドウ内のすべてのドキュメントに集計ロジックが適用されます。

allowedLatenessを構成する場合、Atlas Stream Processing は、ウィンドウが閉じられた後に遅延メッセージをデッド 文字キューに書込みます。

間隔のあるホスティングウィンドウを定義するには、間隔よりも大きいオプションを設定します。

間隔が 3 秒で、ドロップが 5 秒のホスティング ウィンドウを定義します。 ストリーム プロセッサを起動すると、次のことを行います。

  • ウィンドウが 3 秒開きます。

  • 最初のウィンドウは、次の 3 秒間のすべてのドキュメントをキャプチャします。

  • 3 秒が経過すると、ウィンドウが閉じ、そのウィンドウ内のすべてのドキュメントに集計ロジックが適用されます。

  • さらに 2 秒が経過すると、次のウィンドウが開きます。

  • Atlas Stream Processing は、この 2 秒中にストリームが生成したドキュメントを処理しません。

ストリーミングデータ処理では、ドキュメントは次の 2 つのタイミング システムの対象となります。

ネットワーク レイテンシ、アップストリーム プロセシングなどの要因により、特定のドキュメントのこれらの時間間の不整合が生じるだけでなく、ドキュメントがイベント時間順からストリーム プロセッサに到達する可能性もあります。 いずれの場合も、 Windowsはキャプチャする予定のドキュメントを失う可能性があります。 Atlas Stream Processing は、このようなドキュメントが遅延 しているドキュメントを考慮し、デッド 文字キューに送信します( 設定されている場合)。

Atlas Stream Processing は、こうした問題を軽減するためにウィンドウの動作を変更するさまざまなメカニズムを提供しています。

ウォームマークは処理時間を上書きし、以前に消費されたドキュメントよりも後のイベント時間が消費されたドキュメントをプロセッサが消費した場合にのみ更新します。 Atlas Stream Processing では、すべてのストリーム プロセッサが埋め込みを適用します。

5 分のWindowsでストリーム プロセッサを構成します。 プロセッサを 12:00 で起動するため、最初の 2 つのWindowsの期間は 12:00-12:0512:05-12:10 になります。 次の表は、どのWindowsがキャプチャするかどうかを示しています。

イベント時間
プロセシング時間
ウィンドウ時間(サーバーマークなし)
ウィンドウ時間(すかし)
12:00
12:00
12:00-12:05
12:00-12:05
12:00
12:01
12:00-12:05
12:00-12:05
12:01
12:03
12:00-12:05
12:00-12:05
12:03
12:04
12:00-12:05
12:00-12:05
12:02
12:05
12:05-12:10
12:00-12:05
12:01
12:06
12:05-12:10
12:00-12:05
12:04
12:06
12:05-12:10
12:00-12:05
12:05
12:07
12:05-12:10
12:05-12:10
12:06
12:07
12:05-12:10
12:04-12:10
12:06
12:08
12:05-12:10
12:05-12:10

ウォームマークが適用されないシナリオでは、ストリームプロセシングインスタンスのシステムクロックに従って、 12:00-12:05ウィンドウは12:05に閉じ、 12:05-12:10ウィンドウがすぐに開きます。 その結果、ソースは12:00-12:05間隔中に 7 つのドキュメントを生成しましたが、関連する ウィンドウは 4 つのドキュメントのみをキャプチャします。

ウォームマークが適用されるシナリオでは、 12:00-12:05ウィンドウは12:03 12:05で閉じない: 12:00-12:05ウィンドウは、システム クロックの12:07まで閉じない。ストリーム プロセッサが イベント時間が12:05のドキュメントを取り込むと、その時間までウォームアップを行い、 12:05-12:10ウィンドウを開きます。 各ウィンドウは適切なドキュメントをすべてキャプチャします。

イベント時間とプロセシング時間の差が十分に異なる場合、ウォームマークが予想されるウィンドウを閉じるのに十分に進んだ後に、ドキュメントがストリーム プロセッサに到達することがあります。 これを軽減するために、Atlas Stream Processing は 許可レイテンシ をサポートしています。これは、レプリカセットに対して一定の間隔でウィンドウを閉じるのを遅延させる設定です。

サーバーマークはストリーム プロセッサのプロパティですが、許可されたレイテンシはウィンドウのプロパティであり、そのウィンドウが閉じられた場合にのみ影響します。 ストリーム プロセッサのウォームマークが、新しいウィンドウを開くtriggerとなる点まで進む場合、 許可されたレイテンシ はこれを防ぐことなく、以前のWindowsを開いたままにします。

5 分のローリングWindowsでストリーム プロセッサを構成します。 プロセッサを 12:00 で起動するため、最初の 2 つのWindowsの期間は 12:00-12:0512:05-12:10 になります。 許可されたレイテンシ を2分に設定します。

以下の表は、ストリーム プロセッサが説明されたドキュメントを取り込む順序を反映しています。

イベント時間
サーバーマーク
許可されたレイテンシ時間
ウィンドウ時間
12:00
12:00
11:58
12:00-12:05
12:01
12:01
11:59
12:00-12:05
12:03
12:03
12:01
12:00-12:05
12:02
12:03
12:01
12:00-12:05
12:04
12:04
12:02
12:00-12:05
12:01
12:04
12:02
12:00-12:05
12:05
12:05
12:03
12:00-12:15, 12:05-12:10
12:06
12:06
12:04
12:00-12:05, 12:05-12:10
12:04
12:06
12:04
12:00-12:05, 12:05-12:10
12:07
12:07
12:05
12:05-12:10

サーバー マークが12:05まで進むと、 12:05-12:10ウィンドウが開きます。 ただし、許可レイテンシの間隔が2分であるため、 12:00-12:05ウィンドウ内では実質的に12:03のみとなり、開いたままになります。 サーバー マークが12:07に進むとのみ、調整された時間は12:05に達します。 この時点で、 12:00-12:05ウィンドウは閉じます。

ウィンドウの動作をプロセシング時間から排除すると、ほとんどの場合、ストリーム処理の正確性が向上します。 ただし、ストリーミング データ ソースではアイドル状態が一定期間続く場合があります。 このシナリオでは、ウィンドウがアイドル状態の期間より前のイベントをキャプチャし、ウォームマークが閉じられるまで十分に進むのを待っている間は処理された結果を返すことができなくなる可能性があります。

Atlas Stream Processing を使用すると、ユーザーは Windows のアイドル タイムアウトを構成して、プロセシング時間を使用してこれらのシナリオを軽減できます。 アイドル性タイムアウトとは、プロセシング時間が経過し、開いているウィンドウの間隔が終了し、ストリーム プロセッサのソースがアイドル状態のときに開始される時間の間隔です。 ソースがアイドル状態タイムアウトと等しい間隔でアイドル状態を維持すると、ウィンドウは閉じ、ウォームマークはドキュメントの取り込みとは無関係に進みます。

3分の間隔と1分のアイドルタイムアウトでタームリング ウィンドウを構成します。 次の表は、ウィンドウの間隔中とその後のアイドル性タイムアウトの影響を示しています。

プロセシング時間
イベント時間またはステータス
サーバーマーク
ウィンドウ時間
12:00
12:00
12:00
12:00-12:03
12:01
ソース アイドル
12:00
12:00-12:03
12:02
ソース アイドル
12:00
12:00-12:03
12:03
ソース アイドル
12:00
12:00-12:03
12:04
12:02
12:02
12:00-12:03
12:05
12:05
12:05
12:03-12:06
12:06
ソース アイドル
12:05
12:03-12:06
12:07
ソース アイドル
12:00
12:06-12:09
12:08
ソース アイドル
12:00
12:06-12:09
12:09
12:09
12:09
12:09-12:12

12:00-12:03間隔中、ソースは 3 分間アイドル状態になりますが、ストリーム プロセッサはウィンドウを閉じないで、処理時間がウィンドウの間隔の終了を超えないため、ウィンドウの間隔が終了した後もソースはアイドル状態を維持しません。 ウォームマークが12:05まで進むと、ウィンドウは正常に閉じ、 12:03-12:06ウィンドウが開きます。

ソースが12:06でアイドル状態になると、 12:07を通じてアイドル状態のままになり、アイドルタイムアウトがトリガーされ、 ウォームマークが12:06に進みます。

戻る

はじめる