データファースト開発

データファースト開発

1. 1. データファースト開発 2015.10.14 @ Developers Summit 2015 Autumn 開発チームのためのデータ分析環境の構築と 継続的改善の仕組み Presented By: Katsunori Kanda(@potix2) CyberAgent Inc.
2. 2. 自己紹介 神田勝規（かんだかつのり） 株式会社サイバーエージェント アドテク本部 AMoAd所属 サーバーサイドエンジニア(OS/分散システムが専門) ! potix2@twitter/github ※1 毎月LispMeetup(shibuya.lisp)を開催してます ※2 SparkのMeetupや勉強会を開催してます
3. 3. システム改善のサイクル 現状把握 改善案の策定設計・実装 今日の話はこの辺り
4. 4. 現状把握に何分かかるか？ • 日別・週別のアクティブユーザー数 • ユーザーの平均広告接触回数/日 • など・・・ 定型的な分析であれば即時 アドホックな分析だと1週間以上かかることも・・・
5. 5. 時間がかかることによる弊害(1/2) 本当に困るまで調査しなくなる 「根拠のない思い込みによる誤った判断」 「古い調査結果に基づく誤った判断」
6. 6. 時間がかかることによる弊害(2/2) データを見るには特異なスキルが必要だと誤認 （実際は、ステップ数が多いだけで誰でもできる） データ抽出&分析の属人化
7. 7. どの行程に時間がかかるのか？ 2.ETL1.仮説立案 （対象データ選定） 3.データ抽出 4.分析 ※前提：すべてのデータを分析環境に置けない 分析対象のデータサイズに依存
8. 8. 理想的には、 誰でも、気軽に データ抽出＆分析ができるべき
9. 9. 理想に向けて必要なこと 1.データへアクセスが容易 2.高い応答性（理想的には5分以内） 3.手順の再現性 最重要
10. 10. やったこと • データ分析の専用ログを出力するようにした • データ分析基盤の構築 • 計算エンジン: BigQuery + Spark(オンプレ) • ストレージ: Google Cloud Storage • UI: Apache Zeppelin + Jupyter
11. 11. データ分析基盤の構成
12. 12. どうしてこの構成になったのか？ • 応答性を重視 • BigQueryではIndex的なものの定義が不要 • アドホック分析にはBigQueryを使うのがベスト • 用途/データソースによって環境を使い分ける • 機械学習を使いたいときはSparkやscikit-learn • 分析ログに含まれないデータを調べたいときは Spark
13. 13. 応答性を重視する理由 • フィーリングは重要 • 直感は、案外正しい • 根拠がない直感はダメ • 結果を得るのに時間がかかると • 調査コストと得られるメリットを天 にかけてし まい、遊びのある調査ができない • 思いついてから10分以内には結果を見たい
14. 14. データ分析環境ができ てみて・・・
15. 15. 使われない・・・
16. 16. 何故、使われないのか？ 1.使い方がわからない 2.何に使えるのかが分からない
17. 17. 「使い方」を共有するために • チュートリアルを開催 • BigQueryハンズオン • ドキュメント化 • QiitaチームにTipsを共有 • ノートブックを活用 • 他の人が分析した手順がノートブックとして残っ ているので、参考にしやすい
18. 18. Apache Zeppleinのデモ
19. 19. 「何に使えるのか」を共有するために • 基礎集計の結果と手順を共有 • チーム内のチャットグループで共有 • 有用なものは、定型ジョブとして自動化 • Tableauなどを使って可視化した結果を共有
20. 20. 結局、エンジニアは データ分析基盤を何に使うのか？ • 開発項目の選定 • 現状をより正確に把握 • 開発すべき根拠を導出 • システム改善の事前・事後の評価 • 改善施策の効果を客観的に評価 • 運用フローの改善 絶賛試行錯誤中
21. 21. これからの課題 • データの評価/分析のレベルをあげる • 得られた結果から何が言えるのか？読み取る力を あげる。（統計学の基礎知識など） • 可視化 • 可視化されることで新たな知見が得られる • ワークフローの自動化 • 手順が複雑になるとデータ分析が属人化する • ノートブックを定期実行ジョブ化したい
22. 22. まとめ • 速いことは正義 • BigQueryを使って人生が変わりました • 気軽にデータ抽出できることで新たな気付き • 誰でもデータアクセスできるといいことがある • 開発者がリリースした機能を自分で評価できる • 改善サイクルを回すスピードがあがる（はず） • データを見れないことをリスクと捉えるべき