2013年8月9日（金⁠）⁠、（⁠株）リクルートテクノロジーズ（東京都千代田区）において、Treasure Data社とCrocos社の共催で「データサイエンスの始め方・データ分析のデザインパターン」と題したイベントが行われました。

Treasure Data社の古橋貞之氏の司会のもと、同社の田村清人氏、Crocos社の柄沢聡太郎氏、（⁠株）リクルートテクノロジーズの西郷彰氏、楽天（⁠株⁠）の北川拓也氏が登壇し、各社におけるデータサイエンスの取り組みやノウハウが紹介されました。

その中からTreasure Data（以下、TD）のデータ分析ノウハウについて語った田村氏、柄沢氏の発表をピックアップしてレポートします。

「誰も語らないデータ分析の3つの現実」（Treasure Data社　田村清人氏）

田村氏は、データ分析の基盤を提供するベンダーとしての立場から、データ分析における3つの課題について発表を行いました。

データを集めるのはたいへん

1つめに挙げた課題はデータ収集の問題です。田村氏は、いざデータ分析を始めてみると、集めたデータに間違いがあって、正しく集計、分析ができないということがよく起きると言います。

その原因の1つは、アプリケーションを修正した結果、出力するログが変わっていたというものです。データ分析の現場では、「⁠業務でデータを集める人」と「データを分析する人」が異なるというのはよくあるそうです。そのため、前述のようにほかの担当者がログを分析していることをあまり意識せずに、アプリケーション開発担当者がログの内容を変更してしまうということが起こるのです。

また、データを集めるしくみが複雑過ぎる、というのも一因です。一般的にどんなサービスでも、複数のデータベースやアプリケーションがあり、それぞれがログを出します。そのログを各担当者が独自のスクリプトを書いて集計しているため、少しでもログのフォーマットが変わると、たちまち集計や分析ができなくなってしまいます。

では、どうすればいいのでしょう。ポイントは「統一されたシステムでデータを収集する」ことだそうです。TDのサービスを使えば、それができると言います。

データを眺めるのもたいへん

2つめの課題はデータ分析時の問題です。データ分析の現場では、データを集め分析可能な形に加工するのに長けた人間と、そのデータに対して意味のある分析ができる人間とは同じでない場合が多いと言います。両方できる人こそが、本来データサイエンティストと呼ばれるべき人材ですが、田村氏は自身の経験からも、TDの顧客との会話からも、実際にはそういう人は少ないと感じているそうです。

この課題の現実的な解決策としては、「⁠どちらかの仕事をアウトソースする」ことが挙げられます。データ分析に特化したサービスを利用することや、TDのようなデータを貯める基盤サービスを利用することなどが考えられます。

TDの顧客の1つであるMobFox社は、ヨーロッパで最大のモバイル系広告プラットフォームを提供する企業ですが、同社はTDのサービスを使うことで、1ヵ月に4,000億レコードのデータをさばけるプラットフォームを14日間で作り上げたと言います。

田村氏は、「⁠インフラ技術が会社のコアでない限り、内製するのは必ずしも正しいやり方ではない」と主張します。構築の費用だけでなく、何よりも時間が無駄になるからです。

もしMobFox社がTDと同じようなしくみを自社で作ろうとしたら、Hadoopや分散システムに精通した技術者を雇って、構築しないといけません。それには時間がかかります。TDを使えば、そんな手間を省いて、今すぐデータの分析が始められます。MobFox社はそこに価値を見いだしたようです。

データ基盤の整備は後回しにされやすい

3つめの課題は、データ基盤の整備です。

通常、新しいサービスを始めると、顧客数や売上などはサービス開始とともに徐々に成長していくものです。これに対して、データを使うことによって得られる価値というのは最初は何もありません。価値を享受できるのは、ある程度データが貯まってからになります。このように実際のサービスのリードタイムとデータ分析のリードタイムにはズレがあります。このズレこそが、データ基盤を構築するうえでのジレンマになるというのです。

そのため、データ基盤の整備は後回しにされやすいです。しかし、田村氏は「ないデータを分析することはできない」ということも忘れてはいけない、と指摘します。データ分析を始めたいと思ったときにそこからデータを集め始めるのと、サービス開始当初からのデータを持っているのとでは、データの持つ価値が全然違うからです。

田村氏が提案した解決のポイントは、データを集めるコストをサービス開始当初から下げる工夫をすることです。それを実現する具体的なツールとして、Fluentdを挙げました。

Fluentdは、オープンソースのデータ収集ソフトウェアで、TDの古橋氏が開発したものです。（⁠株）バンダイナムコスタジオ、LINE（株⁠）⁠、（⁠株）ディー・エヌ・エー、グリー（株⁠）⁠、（⁠株）サイバーエージェントなど国内の多くのWebサービス系企業で使われいます。

現在の最新バージョンは、v10ですが、まもなく新しいバージョンv11が出るとのこと。v11はまだ開発者向けのα版ですが、プラグインの機構が改善されているそうです。今まではWindows環境では動作しませんでしたが、v11ではWindows環境でも動作するようです。

田村氏の発表では、データ分析は、やりたいと思ってもデータ収集、分析、基盤整備などの場面でさまざまな課題に直面することが明らかにされました。すべて自社内で解決するのはたいへんなコストがかかります。TDのサービスやFluentdなどのソフトウェアがどのような場面で役立つのかなど、解決の手掛かりが垣間見られた発表でした。

「スキーマレスなログデータの収集と集計のためのデザインパターン」（Crocos社　柄沢聡太郎氏）

柄沢氏の所属するCrocos社は2011年に創業したソーシャルメディアを主としたオンラインマーケティングサービスの企画、開発、提供を行う企業です。同社が提供するサービスのログ解析基盤としてTDのサービスを利用しています。同社ではTDを利用して、どんなデータをどういう形で貯めているのか、これまでに培ったノウハウについて発表が行われました。

ログはスキーマレスな形式で持つこと

TDでログを集めよう、解析しようとしたときに最初にぶち当たる壁として、「⁠どんなログを集めるのか」という問題があります。単純にWebサーバやミドルウェアのログを集めればいいのでしょうか？　これらのログを分析したところでわかることは限られています。アプリケーションの観点で本当にほしいデータとして、柄沢氏は次のようなものを挙げました。

• どんなユーザが
• どんな端末で
• どこから
• いつ何をしたのか
• どんなボタンをクリック、タップしたのか

こういったユーザの行動履歴を集めるとなると、収集の対象として考えられるのはアプリケーションログでしょう。

では、アプリケーションログはどんな形式で集めるのが良いのでしょうか？　今までによくあるログの形式として、項目がタブで区切られたTSV形式があります。ただ、これを解析しようとすると、ログをオープンして行ごとに項目を分割して、カラムの1番目が日付で、2番目がステータスで……というふうに処理しなければならず、手間がかかります。

また、このような形式でスキーマを決めてしまったログは、項目を増やしたいときに容易に対応ができません。柄沢氏は、ログを解析するためのスクリプトやツールと、データが密な関係になっているのが問題だと言います。

それに比べて、TD（Fluentd）のログはJSON形式です。項目の順序などのルールはありません。項目名が付いているためデータの量は増えてしまいますが、そのかわり、人間が見てもわかりやすいですし、項目を容易に追加できます。

基本的なログ設計3つのポイント

次に柄沢氏は、基本的なログ設計のポイントととして3つ挙げました。

ポイント1：1イベント1レコードとなるように記録すること

Webアプリケーションの場合、ユーザの1アクションで、最初のリクエストのログのほかに、CSSや画像を取得するたびにトランザクションが発生することがあります。こういうアプリケーションの観点からは必要のないトランザクションのログがあると分析がうまくいきません。そのため、ユーザの1アクションが1レコードになるように記録します。

ポイント2：基本的なスキーマを決めること

ログの項目を決める際、スキーマレスとはいっても、どのようなデータを扱うかのルールはきちんと決めておく必要があります。具体的には、「⁠項目としてはWebサーバのログにあるような基本的なスキーマ（日付、ステータス、URIなど）を持つ⁠」⁠、「⁠項目名はLTSV（Labeled Tab-Separated Values）の名前に合わせる」などといったルールを決めて、項目を定義する必要があります。

さらに、Webサーバのログ情報以外にも、アプリケーションとして意味のある値（フレームワーク内でのルーティング名やコントローラ名、プロセスが始まってから終わるまでの実行時間など）を持っておくことが大事です。URIベースで分析しようとすると、TwitterやFacebookなどのようにサービスによってはURIに独自のパラメータを付けてくることがあり、解析に手間がかかります。しかし、アプリケーションの中できちんとルーティングが決まっていれば、ログのルーティング名でユーザのアクションを一意に決められます。

ポイント3：アプリケーションの知り得る属性を非正規化してレコードに含めること

ユーザがサービスを初めて利用する際に登録してもらった属性情報（ユーザID、性別、年齢、デバイスの情報など）は、本来ならデータベースに入っているデータですが、それらを正規化せずにログに含めておくと便利です。こうしておけば、JOIN（表結合）せずに集計関数にかけられるため、分析が楽になります。

ただ、セキュリティの観点からユーザIDやセッションIDなどはハッシュ化しておくほうが良いでしょう。

スキーマレスなアプリケーションログを扱うコツ

ログをスキーマレスにしておく利点は、特定のレコードに特別な意味をもたせることができることだ、と柄沢氏は言います。

たとえば、トランザクションを記録する場合、URIやルーティングの情報だけしか記録していないと、リクエストの数は数えられても、成功した処理の件数まではわかりません。こういう場合によく採られるのは、処理が成功したときに特定の画面を表示させるなどしてトランザクションを記録するという方法です。しかし、ログがスキーマレスになっていれば、そんな必要はありません。処理が成功したときに、ログに登録完了の記録を追加するだけで済みます。登録完了の記録とともに、属性情報（どんなユーザが、どこ経由できたのかなど）を一緒に入れておけば、経路別の登録完了数も簡単に集計できるようになります。

これは、JavaScriptによるイベント、TwitterやFacebookへのシェアなどユーザのアクセスに依存しないイベントの発生を記録する場合にも同じことができるとのことです。

発表を締めくくるにあたって、柄沢氏は、「⁠スキーマレスのログを扱ううえで最も重要なのは、ビジネス側（データ解析したいと思う人の側）で解釈のルールを決めることだ」述べています。また、「⁠スキーマレスと言えども、事前のログ設計はしっかりやりましょう」とも言っています。データ分析を行うためには、ログ設計の段階からすでにデータの利用方法を考慮しておかなければいけないと言うことでしょう。サービス開始時からデータ分析のことを考えておくべきというTDの田村氏の主張とも通ずるところがある発表内容でした。