こんにちは。ソフトウェアエンジニアの田中です。
前回はevent timeとprocessing timeについて説明しました。順不同に受信されるデータ(unordered data)を処理する方法はいろいろあるのですが、今回はprocessing timeに基づくデータの保存方法(windowing by processing time1)について説明します。
前回の例を引き続き使用します。
例: スマートフォンアプリをリリースしており、そのアプリ内のボタンが、いつ、どれくらいクリックされているかを知りたい、という状況を考えます。システム構成は下図のような感じです。
システム概要 (version 1)
- ユーザがアプリ内で、対象となるボタンをクリックすると、そのクリックイベントがアプリ内のバッファに追加される。
- ある程度アプリ内のログが溜まったタイミングで、ログサーバに送信する。
- ログサーバは、スマートフォンから受信したログを処理し、ストレージに格納する。
- ストレージ内のデータを分析して、いつ、どれくらいクリックされているかを調べる。
下図で表示されている時刻はすべて日本標準時(JST)とし、2018-12-01時点での状態だとします。
このシステムのステップ3を、「processing timeに基づき、1日ごとにデータをまとめて保存する」に変更します。
システム概要 (version 2)
- ユーザがアプリ内で、対象となるボタンをクリックすると、そのクリックイベントがアプリ内のバッファに追加される。
- ある程度アプリ内のログが溜まったタイミングで、ログサーバに送信する。
- ログサーバは、スマートフォンから受信したログを処理し、processing timeに基づき、1日ごとにデータをまとめて保存する。
- ストレージ内のデータを分析して、いつ、どれくらいクリックされているかを調べる。
processing timeに基づきデータを分割して保存する方法のメリットには次のようなものがあります。
- データ分析時にすべてのログを読む必要がなくなる。例えば、event time 2018-11-30のデータは、processting time 2018-11-30以降のデータにしか存在しません。event time 2018-11-30のデータを取得する際には、processing time 2018-11-29以前のデータを読む必要がなくなる。
- ログサーバの処理がシンプル。受信したログを1日ごとにまとめて保存するだけ。
- 過去に保存したデータに変更を加える必要が無い。例えば、上図は2018-12-01時点の状態を表していますが、2018-11-30以前に保存されたデータに今後変更を加える必要はありません。
現実のビジネスでは、event timeに基づく分析が重要です。例えば、2018-11-30にログサーバが受信したイベント数(processing timeに基づく分析)よりも、2018-11-30のクリック数(event timeに基づく分析)が重要とされます。
processing timeに基づきデータを分割した場合、event timeに基づく分析は困難です。データはprocessing timeに基づき1日ごとに保存されています。例えば、保存された2018-11-30のデータは、2018-11-30 00:00:00から2018-11-30 24:00:00までの間にログサーバが受信したデータであり、2018-11-30に発生したイベントだけをまとめたデータではありません。前回説明した通り、event timeとprocessing timeには差(遅延)があります。このため、processing timeに基づきデータを保存した場合、event time 2018-11-30に発生したイベントは、processing time 2018-11-30以降のデータに散らばって保存されることになります。
データが散らばったままでは分析が困難なので、processting timeに基づき保存されたデータから、event timeに基づくデータを作成する方法について次回説明します。
今回はprocessing timeに基づく保存方法(windowing by processing time)について説明しました。
次回は、event timeに基づく分析を楽にするために、processing timeに基づき保存されたデータから、event timeに基づいたデータを作成する方法を説明します。