データ分析の作業が、とにかく非効率的になっていた
かつて、XFLAG スタジオではAmazon Redshift（AWSが提供するデータウェアハウスサービス）の分析基盤にアクセスできるのは分析チームだけに限られていた。ビジネスチームのメンバーがごく簡単な分析をしたい場合でも、毎回、分析チームに依頼をする運用をしていたという。そのため、分析チームだけではタスクをさばききれなくなり、作業の待ちが発生していた。
「これではお互いにとってつらい状態です。そこで、分析チーム以外のメンバーでも分析基盤を利用できるようにする方針になりました。データウェアハウスにApache Zeppelinという分析ツールをつなぎ、誰でもデータにアクセス可能にしたんです」
しかし、この施策ではデータ分析の煩雑さが解消されなかった。理由は以下の5つにある。生島氏は順に解説した。
まずは「仕様書を読まないと分析できない」という課題。例えば、ビジネスチームのメンバーが「ステージのクリア数をカウントしたい」と考えたとする。そして、その情報を得るには「striker_stages」テーブルの「state」カラムの値が2になっている行をカウントする必要があるとしよう。アプリケーションの仕様を知らないメンバーがこの作業を行えるかといえば、到底無理だ。「コードを読まないと分析できない」という課題も同様である。非エンジニアのメンバーにとって、コードを理解する難易度は極めて高い。
また、分析に用いるSQLはどうしても長く複雑なものになりがちだ。あるメンバーから「キャンペーン施策のROIの算出に必要な値が欲しい」といった要望があったため、生島氏は半日ほどかけてクエリを書いたそうだ。その結果、300行ほどもある巨大なSQL文が出来上がったという。それほど長くなったクエリは、書いた本人ですらメンテナンスは困難だ。加えて、クエリを書くには複雑なテーブル構造を理解しなければならない。
これらの課題を解決するため、集計しやすいようにデータを整えたサマリーテーブルを作る方針となった。だが、それも良策とはならなかったという。
「例えば、『○○という分析がしたい』といった要望があれば、それに合わせたサマリーテーブルを作ります。『△△という分析がしたい』といった要望があれば、そのサマリーテーブルは使えなさそうなので新しくサマリーテーブルを作ります。お察しかと思いますが、これが延々と続いていくわけです。場当たり的にテーブルを作っていった結果、使いづらいサマリーテーブルが乱立する事態に陥りました」
BIツールをデータウェアハウスにつなげば全てが解決する。そう考えていたXFLAG スタジオのメンバーたちは、誤りに気づいたという。誰もが簡単にデータを分析できるようにするにはどうするべきか、方針転換の必要に迫られることになった。
ディメンショナル・モデリングの導入が分析業務を大きく変えた
さまざまな手法を探す過程で出会ったのが、「ディメンショナル・モデリング」だったという。
これは、データウェアハウスの特性に合わせたテーブル設計の手法だ。その手法は極めてシンプル。テーブルの種類を「ファクト」と「ディメンション」の2つに分け、ファクトテーブル1つにつき複数のディメンションを関連づけるだけである。ファクトテーブル同士やディメンションテーブル同士は結合しないルールになっている。
ファクトとは実際に発生したイベントや観測された事実を記録するためのテーブルだ。例えば、ゲームの分析においては各ユーザーのプレイログや課金ログなどがファクトに相当する。一方、ディメンションとはファクトに対する詳細情報を説明するテーブルだ。ゲームではプレイしたステージの情報や購入したアイテムの情報がそれにあたる。要するにマスタデータのことだ。
ファクトテーブル1つの周りに複数のディメンションが配置される星形のスキーマはスタースキーマと呼ばれ、ディメンショナル・モデリングではスタースキーマを中心にテーブルを組み立てていく。
ディメンショナル・モデリングには、以下の3つのメリットがある。
1つ目は「クエリのパフォーマンスが向上する」こと。スタースキーマの形にすることでテーブルのJOIN数が少なくて済むためだ。
2つ目は「分析軸を柔軟に追加できる」こと。イベントに関する属性情報がディメンションテーブルに分解されているおかげで、必要な分析軸を後から好きなだけディメンションテーブルに追加できる。ディメンションテーブルを充実させればさせるほど、データウェアハウスの表現力が上がり分析の柔軟性も向上するのがディメンショナル・モデリングの大きなメリットだ。
3つ目は「データを理解しやすい」こと。これは、ビジネスプロセスがテーブル設計に反映されていることに起因している。
例えば、モンストのステージ情報は、サーバサイドの実装上は正規化されたいくつかのテーブルに分解されている。だがモデリングをしていく過程において、ステージに関連するテーブルは非正規化され、ステージという1つのディメンションテーブルにまとめられる。
これにより、ステージの属性情報を知りたい場合は分割されたテーブルを一つひとつ調べる必要がなくなり、ステージのディメンションテーブルだけを用いれば事足りるようになる。
では、こうしたメリットを持つディメンショナル・モデリングを、どのようにしてモンストの分析基盤に取り入れていったのだろうか。
「導入を決めた時点では、データウェアハウスには数多くのテーブルがあり、それを利用している分析クエリも山のようにありました。いきなり全てのテーブルを設計し直して置き換えるのは無理があります。できるところから少しずつ進める方針にしました」
彼らはまず、KPIに直結するような重要なビジネスプロセスから優先的にモデリングしていった。DAUを集計するためにログインのイベントと、それにひも付くユーザー情報に関するディメンションテーブルを作った。
その次は、ゲームプレイに関するファクトテーブルとそれにひも付くステージ情報などのディメンションテーブル。さらにガチャプレイに関するファクトテーブルといった具合に、一つひとつビジネスプロセスを選んでモデリングを進めていった。
このプロセスは非常にうまくいったそうだが、その成功要因として「ビジネスプロセスを分析し、どれくらいの粒度でデータを扱うかを丁寧に決めたこと」が大きかったそうだ。モデリング推進の結果、分析環境は大きく改善した。
「まず、テーブルの構造が非常にシンプルになりました。今まではいくつものテーブルをJOINしたり複雑な関数を使ったりしてやっと分析できていたのが、簡単なSQLを書くだけになりました。ちゃんと計測したわけではないですが、体感ではクエリの長さは半分から3分の1程度になったと思います。エンジニア以外のメンバーでも、ある程度の分析ができるようになりました」
普段、なかなかオーソドックスなテーブル設計の技法が話題に上ることは少ない。だが、こうした技法を学び自社の環境に導入していくことで、日々の分析業務は劇的に改善する。そう総括し、生島氏はセッションを終えた。
お問い合わせ
株式会社ミクシィ
