【BI】イベントログを PowerPivot に読み込んで分析ーその1 分析の計画


「イベントログを PowerPivot に読み込んで分析」シリーズです。
※ SSASと併用したデータマイニング については別の機会に..ということでご了承ください

    1. はじめに
    2. 計画 ← 今回はここ
    3. 分析軸の作成 ※2010/03/30 追記 
    4. PowerPivot for EXCEL 2010 の準備とデータの取り込み
    5. 計算列の作成とテーブル間リレーションの作成
    6. ピボットテーブルの作成

Business Intelligence という言葉から、BIに関連する機能って「なんか人口知能のようなもの」をイメージしてしまう方もいらっしゃると思います。え?いません!? じ、実は、何を隠そう、私がそうです(恥ずかしい….)。

ということで、今回は「分析の考え方」についてズブの素人なりに説明してみたいと思います。

分析を実行するには、はじめに「何を分析したいのか?」をざっくりと洗い出しておく必要があります。具体的に言えば、分析のための「メジャー(尺度)」と「ディメンジョン(軸)」が明確になっていないと分析に着手することができません。

メジャー(尺度)とは、分析したい数字です。イベントログであれば「イベントの数」が該当するでしょう。

もちろん、「イベントの数」といっても、単なる総数では意味がありません。「いつ発生した」「どのサーバーの」「どんなサービスが出した」イベントの数であるかを明確にすることで、はじめて分析が行えます。具体的には、例えば「3月1日から3月10日のあいだの、DNSに関連したエラー」の数 などです。

この「いつ」や「どの」、「どんな」に相当するのがディメンジョン(軸)です。

メジャーが「売上」であれば、ディメンジョンは「店舗」「商品名」「地域」「日時」「値引き額」などでしょう。

恥の上塗りになるので言いたかありませんが、「ディメンジョン」と聞いて「中学校で習ったXYZ軸」を思い浮かべてしまうと、かえって混乱します。だって、店舗、商品名、地域、日時、値引き額 で既に5次元ですから、立体を頭に思い浮かべようとするとワケが分からなくなります。わたしゃ馬鹿なので、その呪縛から抜け出すために相当な時間がかかりました…ほんとに恥ずかしい話です。だからいまだに Newton とか読めないんですよね…。

話を戻しまして。

イベントログの分析であれば、求められるのは以下のような結果かと思います。
※ 本当は、ここにパフォーマンスログを重ね合わせたいところですが、ひとまず今回はイベントログだけを見ていきます。

  • 時間帯およびサーバーごと、およびサービスごとのエラーの傾向
  • 不正なアクセスが発生している時間帯
  • 重大およびエラーイベントの発生履歴
  • サーバーの稼働状況
  • ・などなど

例えば「時間帯およびサーバーごと、およびサービスごとのエラーの傾向」を分析したいと考えた場合には、メジャーとディメンジョンは以下のようになるでしょう。

  • メジャー(尺度) = エラーの数
  • ディメンジョン(軸) = 日時、サーバー名、エラーを出しているサービス

ここに「サーバーのメンテナンススケジュール」などを組み合わせられると、SEの夜間作業の正当性を主張する際のネタにもなりますね。

メジャーとディメンジョンがざっくり決まったら、必要なデータを準備します。

メジャーとなる「エラーの数」は、イベントログが格納されているテーブルを集計することで取ってこられますから、事前に準備する必要はありません。

では、ディメンジョンはどうでしょうか?

これらもイベントログのテーブルに入ってはいます…が、はたしてそれは ディメンジョン として使用できるのかどうか?これは考えどころです。

ディメンジョンとは「軸」です。軸は絶対的な値でなければなりません。なんせ「軸」ですから。

イベントログのテーブルに「サーバー名」としてServer1、Server2、Server3 が入っていたとしましょう。分析対象のサーバーがこの3つだけならば、何とかなることも多いでしょう。では、Server4 について分析したい場合にはどうしましょう? 「Server4 に関するログが無いってことは分析の必要が無い」と判断するのもアリですが、たとえそうだとしても、分析結果には「Server4のイベントが0である」ことを可視化したいですよね。

時間についても同じです。2010/3/1 12:15 に発生したエラーはあるけど、2010/3/1 12:16 に発生したエラーは無いかも知れません。だとすれば、「2010/3/1 12:16 のエラーは0」であることを明に示したいはずです。

このようにデータとして存在しない場合でも、分析結果として可視化する必要があり、そのためには分析の「軸」であるディメンジョンをきちんと用意しておく必要があります。

話が少しそれますが、分析に必要なメジャーやディメンジョンは、時と場合、または人によって異なるはずです。こう言ってはなんですが、気分によっても違うでしょう。その都度、分析用のデータベースを作り直したり、ディメンジョンを変更したりといった作業を IT部門にお願いして準備してもらうといったプロセスでは、「そのときの、分析に対する熱い想い」が冷めてしまいます。IT部門だって、ちょっとイヤかもしれません。

PowerPivot のよいところは、分析を実行する人が、自らデータを準備できる点です。例えば、「時間帯ごとの値引き額」というディメンジョンに相当するテーブルが SQL Server に用意されていなくても、手元の EXCEL に保存されていれば、手元の EXCELファイルを直接 PowerPivot に読み込んで分析を開始することができます。自分で「あ、こんなディメンジョンがあったら、あんな分析ができるかも!」と思ったら、即対処できます。これはうれしいですよね。

ということで、次回は Excel を使用してディメンジョンを作ります。

Comments (2)

  1. 匿名 より:

    iczerone さん

    うわー、痛いところを突かれました…。

    おっしゃるとおり、綺麗に分かれていないのが現状です。

    Report BuilderでCUBEを使用するにはSSASが必要なので、どうしてもDEVなりITPROなりが介在することになります。

    それでは現場のIWが困ってしまうため、サーバーと完全に切り離すために考案されたのがEXCELを使用したPowerPivotなわけですが、「レポート」という観点ではReport Builerにかなわない状況です。

    ただ、IW が Report Builder を使うようになるとは(スキル的に)思えないので、EXCELとReport Builder の融合ではなく、それぞれが独自の進化になると、私は考えています。

    ・EXCELは「レポーティング」の機能が強化される

    ・Report Builder はCUBE作成機能を持つ

    となるのではないかと。完全に私見ですが。

  2. 匿名 より:

    安納殿

    PowerPivotなんですが、いまのところスライサーなどの最低限のツールしかみえてこないのですが、Report Builderと混同しそうで、PowerPivotとくっついてくれたいいのにと思ったりします。

    キューブ化したデーターをBIで分析するのであれば、そういった経営層へ視える化しやすくReportBuilderみたいなのを使えばいいとおもうんですが・・。

    他社さんでいうとQlikViewがちょうどそのような感じで動いていますね。

    SharePointでPowerPivotを見せる際にも同じだと思うのですが、うまくミックスさせて効果的なものを表示する方法がわかりやすく出来る(SIerや開発者として)できて経営層が便利に使えるとより一層ユーザーが増えていくのではないでしょうか。

Skip to main content