こんにちは。ソフトウェアエンジニアの田中です。
前回はprocessing timeに基づく保存方法(windowing by processing time)について説明しました。今回はprocessing timeに基づき保存されたデータから、event timeに基づくデータを作成する処理について説明します。
前回の例を引き続き使用します。
例: スマートフォンアプリをリリースしており、そのアプリ内のボタンが、いつ、どれくらいクリックされているかを知りたい、という状況を考えます。システム構成は下図のような感じです。
システム概要 (version 2)
- ユーザがアプリ内で、対象となるボタンをクリックすると、そのクリックイベントがアプリ内のバッファに追加される。
- ある程度アプリ内のログが溜まったタイミングで、ログサーバに送信する。
- ログサーバは、スマートフォンから受信したログを処理し、processing timeに基づき、1日ごとにデータをまとめて保存する。
- ストレージ内のデータを分析して、いつ、どれくらいクリックされているかを調べる。
前回、processing timeに基づきデータを保存した場合、event timeに基づく分析が困難であると説明しました。event timeに基づく分析を楽にするために、このシステムに、「processing timeに基づき保存されたデータを処理し、event timeに基づき1日ごとに保存する」ステップを追加します。
まず、2018-11-26にログサーバが受信したデータ内の、event timeでの分布を調べます。以下のような分布になったとします。
2018-11-26にログサーバが受信したデータの内、event timeが同日の2018-11-26のデータは1%で、event timeが1日前の2018-11-25のデータは2%、event timeが2日前の2018-11-24のデータが最も多く、90%となっています。この分布からは、このシステムではevent timeとprocessing timeには、2日間の遅延がある場合が多い、ということがわかります。
他の日のデータでも同様な分布であるとします。この場合、processing timeに基づき保存されたデータ中に、event time 2018-11-26のデータは以下のような分布で散らばっていることがわかります。
| processing timeで保存されたデータ | event time 2018-11-26のデータの割合 | event time 2018-11-26のデータの割合の累積値 |
|---|---|---|
| 2018-11-26 | 1.0% | 1.0% |
| 2018-11-27 | 2.0% | 3.0% |
| 2018-11-28 | 90.0% | 93.0% |
| 2018-11-29 | 4.0% | 97.0% |
| 2018-11-30 | 0.6% | 97.6% |
| 2018-12-01 (未確定) | 0.5% | 98.1% |
| 2018-12-02 (未確定) | 0.3% | 98.4% |
| 2018-12-03 (未確定) | 0.2% | 98.6% |
processing time 2018-11-26から2018-11-29までの4日間のデータの中に、event time 2018-11-26のデータの97%が含まれている事がわかります。今回の例では、97%のデータが取得できればOKだと考え、4日間のデータを処理し、event timeに基づくデータを作成することにします。
システム概要 (version 3)
- ユーザがアプリ内で、対象となるボタンをクリックすると、そのクリックイベントがアプリ内のバッファに追加される。
- ある程度アプリ内のログが溜まったタイミングで、ログサーバに送信する。
- ログサーバは、スマートフォンから受信したログを処理し、processing timeに基づき、1日ごとにデータをまとめて保存する。
- 4日分のデータを処理し、event timeに基づき、1日ごとにデータをまとめて保存する。
- ストレージ内のデータを分析して、いつ、どれくらいクリックされているかを調べる。
processing timeに基づき保存されたデータから、event timeに基づくデータを作成する際には、Data Wranglingやセッション化などの処理を行う場合が多いです。
本筋から外れますが、現実のシステムでは、event timeの方がprocessing timeよりも後になるデータが含まれる場合があります。つまり、ログサーバが未来のデータを受信する場合です。なぜそうなるかというと、event timeはユーザのスマートフォンの時計に依存している事が多いためです。スマートフォンの時計が正確でない場合(例えば2050-12-01などになっている場合)、ログデータ内のevent timeは2050-12-01となってしまい、このログデータをログサーバが2018-12-01に受信すると、event time(2050-12-01)の方がprocessing time(2018-12-01)よりも後になってしまいます。このような未来のデータや、大昔のデータの割合は、データ全体の1%未満である場合が多いですが、データ分析の前に取り除いておく必要があります。
これまで3回にわたり、時系列データのevent timeとprocessing timeについて説明しました。(第1回, 第2回)
これまでに使用した例では、システム内の時間はすべて日本標準時(JST)に固定していました。しかし、現実のシステムでは、タイムゾーン(特にアメリカなどの複数のタイムゾーンを持つ国のデータ)やサマータイムなどを考慮に入れてシステムを設計する必要があります。ログの時間の扱い方はチャレンジングなトピックです。
フライウィールではデータが好きな方を募集中です。