バッチ処理による分析では、通常分析対象のデータが出揃っていて目的の範囲で容易に取り出すことができる。 例えば、12/2に行うバッチ処理で「11月いっぱいの全取引データを分析する」とか。 しかし、ストリームを扱った分析では、データの対象範囲をどう決めるかがもっと重要になってくる。 流れてくるデータを次々にじゃんじゃか処理しないといけないので、対象範囲の切り方がうまくないと当然パフォーマンスに影響が出てしまう。
ストリームを対象とした分析において、ストリームをどのようなタイミングで分析するか、どのような範囲で区切って分析するかにはいくつかの分類があるようです。 以下を参照した自分なりの理解を書いてみます。
ストリーム分析の手法について HopSize と WindowSize という２つのパラメータで考える。
HopSize: ストリーム（対象データ）を、どのような時間間隔で分析するか。WindowSize: ストリーム（対象データ）を、どのような範囲に区切って分析するか。
例えばHopSizeが1秒でWindowSizeが5秒なら、「1秒間隔で直近5秒のイベントを対象に分析をする」という感じ。
そして、この２つのパラメータによって、分析手法をいくつかに分類している。
1. Hopping Window 分析
HopSize が定数で、かつ HopSize < WindowSizeの分析。
上記の「1秒間隔で直近5秒のイベントを対象に分析をする」というのはまさにこれ。 この場合に、分析の度に対象となるデータ範囲が重複することがある。 正確には WindowSize - HopSize の時間範囲のデータが前後の分析で重複した対象範囲となる。
例えば
- 14:00:10 に 14:00:05 以降 14:00:10 未満 のデータを分析し、
- 14:00:11 に 14:00:06 以降 14:00:11 未満 のデータを分析し、
- 14:00:12 に 14:00:07 以降 14:00:12 未満 のデータを分析し、
- ・・・
という流れ。 この場合に、1番目の分析処理と2番めの分析処理を比べると、 14:00:06 〜 14:00:10 の4秒間のデータが重複している。
2. Tumbling Window 分析
HopSize が定数で、かつ HopSize = WindowSizeの分析。
HopSize と WindowSize が同じ値の場合、分析の度に対象となるデータの範囲に重複が無く排他的となる。 この場合は、とくに Tumbling Window という呼ぶ。
3. Sliding Window 分析
HopSize を事前に決定することはせず（できず）、イベントが発生する度にWindowSizeの範囲を対象に分析を行う。 HopSizeはイベント発生によって（事後的に）決定されるイメージ。
Sliding Window は、分析処理の起動を分析側で制御できない（しない）ので、負荷などに対してかなり考慮が必要そう。
