Implementing Google Analytics: A Case Study †
- Googleアナリティクスはウェブサイトに配置できるJavaScript?の一部で、どのページがどの訪問者に表示されたかを把握しています。 管理者は、図1-2に示すように、このデータを探索して、期間別、URL別などに分割することができます。
- Googleアナリティクスのようなものをどのように実装しますか？ まず入力をシステムに入力します。 ユーザーがページを表示するたびに、その事実を記録するためにイベントを記録する必要があります。 ページビューイベントは、図1-3の例のように見えるかもしれません（一種の擬似JSONを使用します）。
- ページビューには、イベントタイプ（PageViewEvent?）、イベントが発生した時刻を示すUnixタイムスタンプ、クライアントのIPアドレス、セッションID（これはCookieの一意の識別子で、 ページビューは同じ人物からのものです）、表示されたページのURL、そのページにどのようにアクセスしたか（たとえば、検索エンジンから、または別のサイトからのリンクをクリックして）、ユーザーのブラウザと言語設定 、 等々。
- 各ページビューイベントは、単純で不変な事実で、何かが起こったことを簡単に記録します。
- 今、これらのページビューイベントから、人々があなたのウェブサイトをどのように使用しているかを調べることができる見やすいグラフダッシュボードに、どのように動作するでしょうか。
- 概して、図1-4に示すように、2つのオプションがあります。
- オプション（a）
- すべてのイベントを単純に格納してから、大きなデータベース、データウェアハウス、またはHadoopクラスタにすべてダンプすることができます。 現在、このデータを何らかの方法で分析したい場合は、このデータセットに対して大きなSELECTクエリを実行します。 たとえば、URLと時間帯別にグループ化したり、ある条件でフィルタリングしたり、COUNT（*）をフィルタリングして、時間の経過とともに各URLのページビュー数を取得できます。 これにより、本質的にすべてのイベント、または少なくともいくつかの大きなサブセットがスキャンされ、その場でアグリゲーションが実行されます。
- オプション（b）
- すべての単一のイベントを格納することが大変な場合は、イベントの集約された集計を格納することができます。 例えば、あなたが物事を数えているなら、イベントが来るたびにいくつかのカウンターを増やしてから、実際のイベントを捨てることができます。 OLAPキューブに複数のカウンタを保持することができます。3次元がURLであり、別の次元がイベントの時間であり、別の次元がブラウザであるなどの多次元キューブを想像してください。 イベントごとに、特定のURL、その特定の時間などのカウンターを増分するだけです。
- OLAPキューブを使用すると、特定の日に特定のURLのページビュー数を検索する場合、そのURLと日付の組み合わせのカウンタを読み取るだけで済みます。 長いイベントリストをスキャンする必要はありません。単一の値を読み取るだけです。
さて、図1-5のオプション（a）はちょっと狂ったように聞こえるかもしれませんが、実際は驚くほどうまく機能します。 Googleアナリティクスでは実際には生のイベント（または大量のイベントのサンプル）が実際に保管され、データを見るとそのイベントに対して大きなスキャンを実行すると思います。 現代の分析データベースは、大量のデータをすばやくスキャンする上で非常に優れています。
- 生のイベントデータを保存することの大きな利点は、分析に最大限の柔軟性があることです。 たとえば、セッション中に1人のユーザーが訪問した一連のページをトレースすることができます。 すべてのイベントをカウンターに押しつぶしてしまえば、それはできません。 このような分析は、リコメンダシステムのトレーニング（「Xを購入した人もYを買った」など）のようなオフライン処理タスクにとっては本当に重要です。 そのような場合には、生のイベントをすべて保存しておき、後でそのすべてを魅力のある新しい機械学習システムに投入することが最善の方法です。
- しかし、図1-5のオプション（b）には、特に決定を下すか、リアルタイムで物事に反応する必要がある場合に、その用途があります。 たとえば、人々があなたのウェブサイトを傷つけないようにするには、レート制限を導入して、特定のIPアドレスから毎時100リクエストしか許可しないようにすることができます。 クライアントが制限を超えた場合は、ブロックします。 生のイベントストレージを使用して実装すると、イベントの履歴を絶えず再スキャンして、誰かが制限を超えているかどうかを判断するため、非常に非効率的になります。 時間枠ごとにIPアドレスごとのページビュー数のカウンターを保持し、その要求がしきい値を超えたかどうかを毎回確認できれば、はるかに効率的です。
- 同様に、警告の目的では、イベントがあなたに伝えていることにすばやく反応する必要があります。 株式市場の取引については、あなたはまた迅速にする必要があります。
ここで重要なのは、生のイベントストレージとイベントの集計合計が両方とも非常に有用であることです。
Aggregated Summaries †
- 集計された要約に焦点を当てましょう。どのように実装しているでしょうか。
- 最も単純なケースでは、図1-6に示すように、Webサーバーに集約を直接更新させるだけです。 レート制限の目的で、1時間あたりのIPアドレスごとにページビューをカウントするとします。 これらのカウンタは、memcachedやRedisのようなもので、アトミックインクリメント操作を行うことができます。 Webサーバーは要求を処理するたびに、クライアントのIPアドレスと現在の時刻（最も近い時刻に切り捨てられたもの）から構成されたキーを使用して、増分コマンドを直接ストアに送信します。
- もう少し洗練されたものにするには、図1-7に示すように、イベントストリーム、メッセージキュー、またはイベントログ（または呼び出すもの）を導入することができます。 そのストリーム上のメッセージは、先に見たPageViewEvent?レコードです.1つのメッセージには、特定のページビューの内容が含まれています。
- このアーキテクチャの利点は、同じイベントデータに対して複数のコンシューマを持つことができることです。 1つのコンシューマに、生のイベントを大容量のストレージにアーカイブするだけで済みます。 未処理のイベントを処理する機能がまだない場合でも、ストレージは安価であり、今後どのように使用するかを把握できるため、未処理のイベントを処理する機能がない場合でも、保存することもできます。 次に、集計（カウンタの増分など）を行う別のコンシューマと、監視している別のコンシューマ、またはそれらがすべて同じイベントストリームからフィードアウトできるようにすることができます。
担当者のつぶやき †
みんなの突っ込み †
