ストリーミング・システム

第4章. 高度なWindows

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

再びこんにちは！第3章を楽しんでいただけたなら幸いだ。透かしは魅力的なトピックであり、スラバは地球上の誰よりも透かしを知っている。さて、透かしについての理解を深めたところで、「何を」「どこで」「いつ」「どのように」という質問に関連する、より高度なトピックに飛び込んでみたい。

イベント・タイム・ウィンドウとどのような関係があるのかを理解し、実際にどのような場合に正しいアプローチなのかを知るために、まず、処理時間ウィンドウについて見ていく。次に、より高度なイベント・タイム・ウィンドウの概念に飛び込み、セッション・ウィンドウを詳しく見て、最後に、3つの異なるタイプのカスタム・ウィンドウ、すなわち、整列されていない固定ウィンドウ、キーごとの固定ウィンドウ、拘束されたセッション・ウィンドウを調べることで、一般化カスタム・ウィンドウが有用な（そして驚くほど簡単な）概念である理由を説明する。

いつ／どこで処理時間のWindows

処理時間のウィンドウ化は2つの理由から重要である：

• 使用状況のモニタリング（例：ウェブサービスのトラフィックQPS）のように、受信したデータのストリームを可観測性で分析したいような特定のユースケースでは、処理時間ウィンドウ化は絶対に取るべき適切なアプローチである。

• イベントが発生した時間が重要なユースケース（例えば、ユーザの振る舞い傾向の分析、課金、スコアリングなど）の場合、処理時間のウィンドウ化は絶対に間違ったアプローチであり、このようなケースを認識できることが重要である。

そのため、処理時間ウインドウウィングとイベント時間ウインドウウィングの違いについて、特に今日多くのストリーミングシステムで処理時間ウインドウウィングが普及していることを考えると、しっかりと理解する価値がある。

本書で紹介されているような、第一級概念としてのウィンドウウィング が厳密にイベント・タイム・ベースであるモデルで作業する場合、処理時間ウィンドウウィングを実現するために使用できるメソッドが2つある：

トリガー

イベント 時間を無視し（つまり、イベント時間のすべてにまたがるグローバルウィンドウを使用する）、トリガーを使用して、処理時間軸にそのウィンドウのスナップショットを提供する。

イングレス時間

イングレス時間を、到着したデータのイベント時間として代入し、それ以降は通常のイベント・タイム・ウィンドウを使用する。これは、Spark Streaming 1.xのようなものが本質的に行っていることだ。

多段パイプラインの場合は若干異なるが、この2つのメソッドは多かれ少なかれ等価性であることに注意されたい：トリガー・バージョンでは、多段パイプラインは各ステージで独立に処理時間 "ウィンドウ "をスライスするので、例えばあるステージでウィンドウNにあるデータは、次のステージではウィンドウN-1またはN+1になる；ingress-timeバージョンでは、データがウィンドウNに取り込まれた後、ウォーターマーク（Cloud Dataflowの場合）、マイクロバッチ境界（Spark Streamingの場合）、またはエンジンレベルで関与するその他の座標要素を介してステージ間の進捗が同期されるため、パイプラインの期間中はウィンドウNに留まる。

これまで述べてきたように、処理時間型ウィンドウ処理の大きな欠点は、入力の観測順序が変わるとウィンドウの内容（ ...