ブログ

こんにちは。ソフトウェアエンジニアの田中です。
前回はprocessing timeに基づく保存方法(windowing by processing time)について説明しました。今回はprocessing timeに基づき保存されたデータから、event timeに基づくデータを作成する処理について説明します。
前回の例を引き続き使用します。


: スマートフォンアプリをリリースしており、そのアプリ内のボタンが、いつ、どれくらいクリックされているかを知りたい、という状況を考えます。システム構成は下図のような感じです。

システム概要 (version 2)

  1. ユーザがアプリ内で、対象となるボタンをクリックすると、そのクリックイベントがアプリ内のバッファに追加される。
  2. ある程度アプリ内のログが溜まったタイミングで、ログサーバに送信する。
  3. ログサーバは、スマートフォンから受信したログを処理し、processing timeに基づき、1日ごとにデータをまとめて保存する。
  4. ストレージ内のデータを分析して、いつ、どれくらいクリックされているかを調べる。


前回、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)

  1. ユーザがアプリ内で、対象となるボタンをクリックすると、そのクリックイベントがアプリ内のバッファに追加される。
  2. ある程度アプリ内のログが溜まったタイミングで、ログサーバに送信する。
  3. ログサーバは、スマートフォンから受信したログを処理し、processing timeに基づき、1日ごとにデータをまとめて保存する。
  4. 4日分のデータを処理し、event timeに基づき、1日ごとにデータをまとめて保存する。
  5. ストレージ内のデータを分析して、いつ、どれくらいクリックされているかを調べる。


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)に固定していました。しかし、現実のシステムでは、タイムゾーン(特にアメリカなどの複数のタイムゾーンを持つ国のデータ)やサマータイムなどを考慮に入れてシステムを設計する必要があります。ログの時間の扱い方はチャレンジングなトピックです。
フライウィールではデータが好きな方を募集中です。