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

1. データファースト開発
2015.10.14 @ Developers Summit 2015 Autumn
開発チームのためのデータ分析環境の構築と
継続的改善の仕組み
Presented By: Katsunori Kanda(@potix2)
CyberAgent Inc.

2. 自己紹介
神田勝規（かんだかつのり）
株式会社サイバーエージェント
アドテク本部 AMoAd所属
サーバーサイドエンジニア(OS/分散システムが専門)
!
potix2@twitter/github
※1 毎月LispMeetup(shibuya.lisp)を開催してます
※2 SparkのMeetupや勉強会を開催してます

3. システム改善のサイクル
現状把握
改善案の策定設計・実装
今日の話はこの辺り

4. 現状把握に何分かかるか？
• 日別・週別のアクティブユーザー数
• ユーザーの平均広告接触回数/日
• など・・・
定型的な分析であれば即時
アドホックな分析だと1週間以上かかることも・・・

5. 時間がかかることによる弊害(1/2)
本当に困るまで調査しなくなる
「根拠のない思い込みによる誤った判断」
「古い調査結果に基づく誤った判断」

6. 時間がかかることによる弊害(2/2)
データを見るには特異なスキルが必要だと誤認
（実際は、ステップ数が多いだけで誰でもできる）
データ抽出&分析の属人化

7. どの行程に時間がかかるのか？
2.ETL1.仮説立案
（対象データ選定）
3.データ抽出 4.分析
※前提：すべてのデータを分析環境に置けない
分析対象のデータサイズに依存

8. 理想的には、
誰でも、気軽に
データ抽出＆分析ができるべき

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

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

11. データ分析基盤の構成

12. どうしてこの構成になったのか？
• 応答性を重視
• BigQueryではIndex的なものの定義が不要
• アドホック分析にはBigQueryを使うのがベスト
• 用途/データソースによって環境を使い分ける
• 機械学習を使いたいときはSparkやscikit-learn
• 分析ログに含まれないデータを調べたいときは
Spark

13. 応答性を重視する理由
• フィーリングは重要
• 直感は、案外正しい
• 根拠がない直感はダメ
• 結果を得るのに時間がかかると
• 調査コストと得られるメリットを天 にかけてし
まい、遊びのある調査ができない
• 思いついてから10分以内には結果を見たい

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

15. 使われない・・・

16. 何故、使われないのか？
1.使い方がわからない
2.何に使えるのかが分からない

17. 「使い方」を共有するために
• チュートリアルを開催
• BigQueryハンズオン
• ドキュメント化
• QiitaチームにTipsを共有
• ノートブックを活用
• 他の人が分析した手順がノートブックとして残っ
ているので、参考にしやすい

18. Apache Zeppleinのデモ

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

20. 結局、エンジニアは
データ分析基盤を何に使うのか？
• 開発項目の選定
• 現状をより正確に把握
• 開発すべき根拠を導出
• システム改善の事前・事後の評価
• 改善施策の効果を客観的に評価
• 運用フローの改善
絶賛試行錯誤中

21. これからの課題
• データの評価/分析のレベルをあげる
• 得られた結果から何が言えるのか？読み取る力を
あげる。（統計学の基礎知識など）
• 可視化
• 可視化されることで新たな知見が得られる
• ワークフローの自動化
• 手順が複雑になるとデータ分析が属人化する
• ノートブックを定期実行ジョブ化したい

22. まとめ
• 速いことは正義
• BigQueryを使って人生が変わりました
• 気軽にデータ抽出できることで新たな気付き
• 誰でもデータアクセスできるといいことがある
• 開発者がリリースした機能を自分で評価できる
• 改善サイクルを回すスピードがあがる（はず）
• データを見れないことをリスクと捉えるべき