ビッグデータ分析の今

ビッグデータという流行と共に、Amazon Redshift、Amazon Elastic MapReduce、Google BigQuery、Treasure Data Serviceなど、ビッグデータ分析基盤を作る上でスモールスタートで始められる分析エンジンを提供するクラウドサービスが普及し、ビッグデータを用いた分析への敷居が下がりつつあります。

そこで、まずはクラウドで提供されているビッグデータ分析エンジンの特徴を比べてみましょう。

ビッグデータ分析エンジンを比較してみると、ビッグデータを処理する一般的なインターフェースとしてSQLが提供されていることが主となっています。こうして見ると、最近流行っているビッグデータを使った分析とは、SQLによる分析が主となっていることがわかります。

さらに、他の機能を見てみると、スケジューリングや依存関係を考慮したジョブの実行、データの可視化などは分析エンジン自体は備えておらず、別途用意する利用必要があります。

このように考えてみると、以下の点が気になってきます。

• ビッグデータ分析基盤で何をできるようにするのか？
• ビッグデータ分析基盤と考えたときに他にどういったツールが必要になるのか？
• SQLによる集計を基にした分析ではどういったことができるのか？

本稿では、ビッグデータ分析基盤を構築するために必要な分析エンジンではなく、主にその周辺のエコシステムについてを中心に紹介し、ビッグデータ分析基盤を構築する流れを通しながら、SQLを用いたビッグデータ分析の一連の流れを実際に行っていきます。

ビッグデータ分析基盤で何をできるようにするのか？

ビッグデータ分析基盤を作ることを考えたときに、そもそもビッグデータ分析基盤では何をできるようにするのでしょうか？

ビッグデータ分析という観点から考えると、レポーティング分析とアドホック分析の2つを行えるようにできることが挙げられます。

1つ目のレポーティング分析とは、ユーザが分析を始めるための最初の入り口です。レポーティング分析を通して、チーム全体に共有するための基本KPI（Key Performance Indicator）を用いた定型レポートを作り、同じ視点でデータを把握し、かつ簡単に情報を閲覧できるようにします。そして、この基本KPIを定期的に更新しながら、長期間にわたって、定点観測していくことにより、いつもと違う、という気づきを得ることができます。

図1は、レポーティング分析に向いたダッシュボードBI（Business Intelligence）ツールの一つであるMetricInsightsの画面です。このようにレポーティング分析ではさまざまなKPIを一元的に見て、全体を把握することが重要となるでしょう。

2つ目のアドホック分析とは、レポーティングで得られた気づきから、その気づきを元に、具体的な根拠を得るためにさまざまな条件や分析視点でデータを深掘りをしていくことを目的とします。また、それだけでなく、ユーザが今までに無い条件を元に分析をするようなケースでも当てはまります。そのため、レポーティング分析を始める際に基本KPIを見つけ出すためにも利用されます。

最後に、これらレポーティング分析とアドホック分析は相互に補完できるようにすることにも注意が必要です。レポーティング分析で得られた気づきから、違う視点で検証していくためには、別な条件でアドホックに分析をしていくことが必要になります。レポーティング分析によって発見された疑問を元に、アドホック分析によって疑問に対する更なる回答を得ることが可能になります。

その一方で、アドホック分析で得られた気づきや、その気づきを元にした知見を分かりやすい形で表現したレポートを、社内で共有することによって次の施策への一歩となります。そのためにはレポーティング分析の結果を保存、再利用できる環境が必要となります。

このように、ビッグデータ分析基盤では、レポーティング分析とアドホック分析の環境は相互に補完し合い、スムーズに連携できる環境を提供することが重要となります。

ビッグデータ分析基盤に必要なエコシステムとは？

さて、このようにスムーズに連携できるビッグデータ分析基盤を作るためには、ビッグデータ分析エンジンだけでは難しそうです。それではどんなエコシステムが必要になるでしょうか？ 以降では、ビッグデータ分析基盤のためのエコシステムを具体的なツールとともに紹介します。

データ収集

企業内では、さまざまな場所にデータが置かれています。Webサーバやアプリケーションサーバのログのようにリアルタイムに生成されるログだけでなく、マスターデータのように定期的に更新されるデータベースに格納されたデータ、外部サービスから定期的にCSVファイルなどで出力されるデータなどさまざまです。

これらを集めるためには、データの生成される頻度に着目して2つのツールを使い分けます。

Webサーバやアプリケーションログのようにリアルタイムに生成されるデータに対してはストリーミングログコレクタであるFluentdを利用します。また、1時間に1度や1日に1度、定期的にデータを収集するためにはEmbulkを用います。

可視化

分析エンジンで分析した結果は、目に見えるグラフ形にする必要があります。レポーティング分析であれば、多くのグラフを一元的に可視化できるツールが重要となります。また、大勢で参照することを考えると、ログデータすべてを参照させるのではなく、ログデータを元に集約された集計結果を参照させる仕組みにしておく必要があります。つまり、レポーティング分析のためのデータマートを参照させたり、データマート自体を内部に内包していることが望ましいです。

また、アドホック分析であれば可視化の切り口を簡単に変更できるツールが良いでしょう。こうした可視化に特化したツールは、多様なニーズに応えるために商用ツールを利用することが多いです。

たとえば、上記で図で紹介したMetricInsightsやMotionBoardやDomoなどがデータマートを内部に備え、一元的に可視化するのに便利です。また、アドホック分析という観点ではTableau Desktop/Tableau ServerやJupyter/Pandasの組み合わせが最近では人気です。

今回は、アドホック分析での可視化に焦点を当てて、JupyterとPandasというツールを紹介していきたいと思います。

ワークフロー管理/自動化

分析の最初ではあまり重要ではありませんが、集計の複雑さやインポート元の多様化が進むと、ワークフロー管理を行うツールが重要となります。それは、ジョブのスケジュール実行、依存関係の解決、エラー時の通知や自動リトライ、指定したジョブの再実行、過去の実行履歴の管理などを行う必要が有ります。

こうしたことを実現するには、Jenkinsや国内だとJP1などが有名です。また最近では、Azkaban、Luigi、Airflowなどさまざまなワークフロー管理のためのツールが作られています。

ビッグデータ分析基盤の構成イメージ

これまでの内容を踏まえると、ビッグデータ分析基盤はどのような構成になるのでしょうか？

まずは、Webサーバやアプリケーションサーバには、Fluentdを使ってユーザのログをリアルタイムに分析エンジンに貯めていきます。データベースのマスターデータは、Embulkをつかって1時間や1日に1度データを集めていきます。また、その管理はワークフロー管理ツールを使って行います。

これら2つのツールから収集されたデータは分析エンジンに集められます。データ量が数千万件くらいであれば分析エンジン上の一度のSQLで集計ができ、分析サーバにある可視化ツールで可視化が行えるでしょう。

しかし、分析エンジン上のデータ量が数億件以上になってきた場合には、処理が数時間かかってしまうケースもあるかもしれません。そうしたケースでは、可視化をしやすい形にデータマートを作る必要があります。このデータマートを作る集約クエリを管理するためにもワークフロー管理ツールは利用されます。

そうして考えると、下記のようなイメージになるでしょう。

ビッグデータ分析基盤を使った分析案

さて、ビッグデータ分析基盤を構成イメージの通りに作れたとしても、どんな分析をするのか、についてが何もなければ意味がありません。そこで、まずは自社のWebサイト上のユーザの動向を追うということをしてみたいと思います。Webサイトのユーザ分析における基本KPIを可視化し、自社サイトのユーザを俯瞰的に見ることにしましょう。

この「自社内で共通の認識として持つべき基本KPIを設定し、そこから自社独自の応用分析を行っていく」ということが重要になります。

Webアクセスログの基本KPI分析

Webアクセスログで重要なポイントとして、クッキーIDやユーザIDなど一意にユーザを区別できるデータを利用することで、ユーザがどの程度自社に来てくれているのか、ユーザに見て欲しい情報をユーザに届けられているのかを確認することができます。

ユーザ動向に関する基本KPI

ページビュー（PV: Page View）

ページビューは、一日のアクセス回数を表す最も基本的な指標です。

ユニークユーザ数（UU: Unique User）

ユニークユーザ数は、同日（または同月、同年）の一人のユーザの複数回のアクセスを1回と見なした指標です。

平均アクセス回数

PV / UU で計算される、一人当たりの1日の平均アクセス回数です。

新規ユーザ数

新規ユーザ数は、初めてサイトにログインしたユーザを日別にカウントしたものです。

直近と最終訪問日までの期間

特定の日付を基準日として、各ユーザの最終訪問日が何日前（日単位）だったのかを求める指標です。

最終訪問日の分布

こちらは各ユーザの最終訪問日ごとに集計し、分布をみるものになります。

直帰率

直帰は訪問はしたものの、他のページに移動せずに去ってしまったものおよび、同日に再訪問を行わなかったユーザの数を数えます。

高頻度訪問ユーザの一覧（週n日以上）

基準日までに n日連続訪問したメンバーの数を数えます。

連続訪問ユーザ一覧（直近n日連続）

基準日までの直近1週間で、n回以上ログインしているメンバーの数を求めます。

上記のようにあるWebページ全体の情報を点で分析するのが基本KPIと言えます。こうした基本KPIを毎日収集し、定型レポートして観測できるようにすることで、長期間での変化がわかるようになり、何らかのイベントによる変化などを通して新たな知見を得ることができるようになります。

Webアクセスログの応用KPI分析

さて、さらに深い応用KPIとはどのようなことをするのでしょうか？ それは点による分析を期間ではなく、ユーザがWebページ上を行動した点と点をつないだユーザの動線による分析、つまりパス分析が応用KPIの1つとなるでしょう。

パス分析とは、ユーザごとの流入からコンバージョン（ユーザにたどり着いて欲しいパスやアクションのこと、たとえば商品の購入やカタログダウンロードなど）に至るまでの「パス」そのものを分析の軸とする手法です。

ユーザのパス自身を見ることによって、点による基本KPIの分析のみを行ってきたユーザにとっては、下記のような新しい観点の分析ができるようになります。

パス平均長

コンバージョンまでにいくつのページを踏んでリーチしたのか、コンバージョンの「効率」に関して理解することができます。

コンバージョン時間

流入からコンバージョンに至るまでの時間（数分であるものもあれば数週間であるものもある⁠）⁠。同様に「効率」に関して理解することができます。

パス類型

長さや組み合わせが無限大のパスに対して、特定のルールに従ってパスを分類し、その分類の中でどのパス類型がコンバージョンに寄与しているかを知ることができます。

スコアリング

パスの概念をもって改めてページを評価するには、パスの中でどの位置に出現するかによって重みを変えることによってパスの中でも重要度を発見できます。

これらの基本KPIで長期的な変化をみながら、応用KPIを出すことによりパスの変化で基本KPIがどのように変わるかの変化も捉えることができるようになります。

まとめ

今回は、ビッグデータ分析基盤を作る上で重要なエコシステムについて紹介し、ビッグデータ分析の基本KPIと応用KPIについて紹介しました。次回以降は、実際にデータ収集を行うためのFluentdやEmbulkを用いたデータ収集を行っていきます。