LINE DEVELOPER DAY_2015 Tokyo「ビッグデータを活用するための分析プラットフォーム」レポート #linedevday

虎塚

2015.04.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、虎塚です。

昨日は、LINE株式会社さんが開催されたイベントLINE DEVELOPER DAY_2015 Tokyoへ参加してきました。

Taichi Hashimotoさんが講演された「B-5: ビッグデータを活用するための分析プラットフォーム〜データ集計した先に求められる分析技術」を聴きましたので、レポートします。

前半は、さまざまOSSを活用して構築された、社内の利用者のニーズに応じたデータ分析基盤の紹介でした。後半は、KPIを人間が見るのでなく、変化を自動検知して通知するシステムを開発中というお話でした。

以下、レポートです。

データ分析について

LINEにとってデータ分析とは何か

Collecting: データを集約する
Reporting: サービスの状況を的確に報告する
Analyzing: サービスの問題点や改善点を分析できるようになっている

この3つのことを実現するように技術や環境を提供している。

重要だと思うこと

Collecting
- リーズナブルなデータの集約
- 大量のデータを保持すること
Reporting
- 柔軟なデータの集計
- わかりやすいチャートでの可視化
Analyzing
- 簡便で高速なデータの抽出

異なるニーズ

データの利用者によって、求めるものが異なる。

エンジニアの声: UIなんてどうでもいいから、生のデータを1箇所に集めて、自分たちがアクセスしやすいようにしたい。
プランナーの声: KPIを出してほしい。データはきれいなグラフで可視化されていることが望ましい。そしてExcelでダウンロードできることが非常に重要。

プランナーはエンジニアよりもデータの加工を要望することが多い。これらをふまえて、どういった分析環境が必要か？

for エンジニア

エンジニアに対しては、凝ったことをする必要はないと考えた。SQLなどのクエリを柔軟に発行できるようにする。（エンジニアが自由に実行する）APIによるバッチ処理と連携できるようにする。

次のようなツールを利用している。

Fluentd: 柔軟なログ収集を可能にするフレームワーク
Norikra: リアルタイム集計処理システム。ストリーミングデータ処理としてSQLが利用できる
Shibu / Shibu UI: Webベースのクエリツールとジョブスケジュール。Hadoopに集約されたデータを扱う。

データをHadoopに集約して、クエリが叩けるインタフェースからアクセスしてもらう。リアルタイム処理にはNorikraを使っている。

For プランナー

可視化、ダウンロード、No SQL（SQLを書かなくてもなんとかできるようにする）がポイント。

次のようなツールを利用している。

Hadoop: 大規模分散データ処理環境。構成は、HDFS, MapReduce, YARN
Hive: 大規模データに対するDWH
Presto: 分散データ処理エンジン。Hiveより高速処理できるのでBIツールのバックエンドに利用
Prestogres: BIとPrestoをつなぐコネクタ
InfiniDB: MySQLベースのカラム型分散DB。BIツールやクライアントツールから利用するデータを格納
IBM Cognos: Webベースのレポートオーサリングツール。ランキング変動のヒープマップなど、複雑で手作業で作ると大変なグラフや表を、それなりのコストで作成できるので利用している。
Pentaho: OLAP（Online Analytical Processing）型の多次元分析用システム

エンジニア用に集計したHadoopクラスタのデータを、さらにプランナー用に流し、Prestoを経由して確認できるようにした。

ソリューション

このように、冒頭で挙げた課題を解決している。

Collecting
- リーズナブルなデータの集約 → fluentd
- 大量のデータを保持すること → Hadoop
Reporting
- 柔軟なデータの集計 → Hive / Shibu / Norikra
- わかりやすいチャートでの可視化 → IBM Cognos, Pentaho
Analyzing
- 簡便で高速なデータの抽出 → Presto, InfiniDB, Pentaho

重要視していること

上記のデータ分析基盤を構築、運用する上で、次の内容を重要視している。

API連携できるようにすること
OSSの採用。足りないものは自分たちで作ること
データをなるべく隠蔽すること。認証をしっかりした上で、ユーザ情報を見せる
ユーザトラッキングはしないこと。LINEのユーザは非常に多いため、1人のユーザをトラッキングしてもサービス改善に結びつかないと思っている。苦労が多いわりに利がないので、一切やっていない

分析プラットフォームの構成

グローバル化にともない、次のような課題が見えてきた。

サービスの変化: グローバル化、多様化に加えて、長寿化（サービスの延命）
人の変化: プランナーの増加

上記の変化を受けて何が起きるかというと、KPIがサービス × メジャー × ディメンジョンで爆発的に増加する。

国別、カテゴリ別などはもちろん、サービス運用を続けるうちに歴史的背景によるフラグが存在したり、人が増えることでいろいろな要望が出たりすることで、KPIが増加する。

KPIが増えると、忙しくなり、だれもKPIをつぶさに見なくなる。そして、サービス運営として何をすればよいかが、だんだんわからなくなってくる。

KPIの変化を人ではなく機械がみる

上記の対策としてチームで考えたのは、KPIを人間が見ずに、KPIの変化を伝えること。たとえば、数十ヶ国 × 数万個のスタンプのKPIを人手で見ると大変なので、自動化して、KPIに特徴的な変化が起きた時に、プランナーやエンジニアに通達する仕組みをつくる。

KPIモニタリングシステムの開発

KPIモニタリングシステムを絶賛開発中で、もう少しで運用をはじめようとしている。

すべてのKPIトレンド分析を自動化
時系列でトレンドを学習して予測値を算出
算出された値に対して、検出された値が異常かどうかをみる（ポジティブでもネガティブでも）
メールやチャットでアラートを伝達する

プランナー用のシステムと別に、KPIのトレンド分析システムを設置する。これには、KafkaとSparkを利用する。各KPIを時系列に並べ、Kafkaで予測値を算出する。実値を見て、通達すべきかそうでないかを判定し、処理をおこなう。

Timseries Producer: 次元ごとに分解してKafkaへ
Timseries Monitor: トレンドを学習してモデルを構築し、Kafkaに保存
Notification Monitor: 予測値よりも実値が大幅に異なる場合、通知する

まとめ

データ分析環境はHadoopをベースにして構築
- OSSベースで、足りない部分や要望に合わない部分は自分たちで手をいれる
- 認証を入れる（だれがどんなクエリを投げたか、監査ログをとるなど、データを保守的に扱う）
- ユーザ情報（ユーザID）は重要でないのでなるべく隠蔽する
KPIモニタリングを強化
- 増え続けるKPIを自動的に処理する仕組みをつくる