データファースト開発

2015.10.14 @ Developers Summit 2015 Autumn

開発チームのためのデータ分析環境の構築と 継続的改善の仕組み

Presented By: Katsunori Kanda(@potix2) CyberAgent Inc.

自己紹介神田勝規（かんだかつのり） 株式会社サイバーエージェント アドテク本部 AMoAd所属 サーバーサイドエンジニア(OS/分散システムが専門) !

potix2@twitter/github ※1 毎月LispMeetup(shibuya.lisp)を開催してます

※2 SparkのMeetupや勉強会を開催してます

システム改善のサイクル

現状把握

改善案の策定設計・実装

今日の話はこの辺り

現状把握に何分かかるか？• 日別・週別のアクティブユーザー数 • ユーザーの平均広告接触回数/日 • など・・・

定型的な分析であれば即時

アドホックな分析だと1週間以上かかることも・・・

時間がかかることによる弊害(1/2)

本当に困るまで調査しなくなる

「根拠のない思い込みによる誤った判断」 「古い調査結果に基づく誤った判断」

時間がかかることによる弊害(2/2)

データを見るには特異なスキルが必要だと誤認 （実際は、ステップ数が多いだけで誰でもできる）

データ抽出&分析の属人化

どの行程に時間がかかるのか？

2.ETL1.仮説立案 （対象データ選定）

3.データ抽出 4.分析

※前提：すべてのデータを分析環境に置けない

分析対象のデータサイズに依存

理想的には、

誰でも、気軽に データ抽出＆分析ができるべき

理想に向けて必要なこと

1.データへアクセスが容易 2.高い応答性（理想的には5分以内） 3.手順の再現性 最重要

やったこと• データ分析の専用ログを出力するようにした • データ分析基盤の構築 • 計算エンジン: BigQuery + Spark(オンプレ) • ストレージ: Google Cloud Storage • UI: Apache Zeppelin + Jupyter

データ分析基盤の構成

どうしてこの構成になったのか？• 応答性を重視 • BigQueryではIndex的なものの定義が不要 • アドホック分析にはBigQueryを使うのがベスト

• 用途/データソースによって環境を使い分ける • 機械学習を使いたいときはSparkやscikit-learn • 分析ログに含まれないデータを調べたいときはSpark

応答性を重視する理由• フィーリングは重要 • 直感は、案外正しい • 根拠がない直感はダメ

• 結果を得るのに時間がかかると • 調査コストと得られるメリットを天秤にかけてしまい、遊びのある調査ができない

• 思いついてから10分以内には結果を見たい

データ分析環境ができてみて・・・

使われない・・・

何故、使われないのか？

1.使い方がわからない 2.何に使えるのかが分からない

「使い方」を共有するために

• チュートリアルを開催 • BigQueryハンズオン

• ドキュメント化 • QiitaチームにTipsを共有

• ノートブックを活用 • 他の人が分析した手順がノートブックとして残っているので、参考にしやすい

Apache Zeppleinのデモ

「何に使えるのか」を共有するために

• 基礎集計の結果と手順を共有 • チーム内のチャットグループで共有 • 有用なものは、定型ジョブとして自動化 • Tableauなどを使って可視化した結果を共有

結局、エンジニアは データ分析基盤を何に使うのか？• 開発項目の選定 • 現状をより正確に把握 • 開発すべき根拠を導出

• システム改善の事前・事後の評価 • 改善施策の効果を客観的に評価

• 運用フローの改善

絶賛試行錯誤中

これからの課題• データの評価/分析のレベルをあげる • 得られた結果から何が言えるのか？読み取る力をあげる。（統計学の基礎知識など）

• 可視化 • 可視化されることで新たな知見が得られる

• ワークフローの自動化 • 手順が複雑になるとデータ分析が属人化する • ノートブックを定期実行ジョブ化したい

まとめ• 速いことは正義 • BigQueryを使って人生が変わりました • 気軽にデータ抽出できることで新たな気付き

• 誰でもデータアクセスできるといいことがある • 開発者がリリースした機能を自分で評価できる • 改善サイクルを回すスピードがあがる（はず）

• データを見れないことをリスクと捉えるべき