トレジャーデータ 導入体験記 リブセンス編

トレジャーデータ 導入体験記 リブセンス編

1. 1. page 1. 自己紹介 2. 事業紹介 3. 導入当時 4. 活用方法 5. 導入前後 6. 安定運用化 7. 今後の期待 8. まとめ 本日の流れ 2
2. 2. page 1. 自己紹介 3
3. 3. page Fluentd歴 < TreasureData歴 5
4. 4. page 執筆書籍 6 サーバ/インフラエンジニア養成読本
 ログ収集∼可視化編 [現場主導のデータ分析環 境を構築!] (Software Design plus) 出版社/メーカー: 技術評論社 定価: 本体1,980円＋税
5. 5. page 7
6. 6. page 拙作の公開中Fluentdプラグイン 8 rewrite-tag-filter geoip mysql-replicator munin twitter anonymizer mysql-query gamobile watch-process twilio sentry feedly
7. 7. page 2. 事業紹介 9
8. 8. あたりまえを、発明しよう。
9. 9. 可視化された未来型 不動産プラットフォームサービス
10. 10. page 3. 導入当時 18
11. 11. page 導入当時 19 MySQL5.0系を利用。その構成にムリが生じ始めていた トランザクションテーブルとログテーブルの混在 分析クエリによるスロークエリの温床 本番のスキーマ変更のレビュー工数の手間 データのサイジング計画を建てる手間
12. 12. page 導入当時 20 MySQLへの高コストなINSERTクエリによるページ表示遅延 INSERTコストを下げる為に、可能な限りログを定期的に 消し込む必要がある。消し込みバッチが増殖。 消し込める範囲も限られるため、INSERTクエリと消し込 みクエリにより、レプリケーション遅延は常態化する 例え非同期化してもレプリケーション遅延は直らない
13. 13. page これじゃダメだ！ 21
14. 14. page 事業加速のスピードをさらに上げたい 22
15. 15. page Hadoop基盤が必要であることは明白 しかし少ない人員で誰が運用するのか 23
16. 16. page かの有名な太田さんや古橋さんが Bigdata as a Serviceを “TreasureData”として サービスインする を耳にする 24
17. 17. page 当時のトレジャーデータのメンバー 25 引用元 http://itpro.nikkeibp.co.jp/article/NEWS/20120928/426103/
18. 18. page 2012年5月 太田さんにメール 数営業日後、全サーバへの導入完了 26
19. 19. page 1つの社内スタートアップメディアを 先行事例として試験導入 27
20. 20. page 4. 活用方法 28
21. 21. page 活用方法 29 ユーザの行動ログの収集と分析 集計結果のGoogleSpreadSheet書き出しが圧倒的に多い さまざまな履歴データの保管と集計 A/Bテスト 不達メールアドレスのクリーニング 名寄せ処理、クロールデータ etc… 機械学習 (Hivemall)
22. 22. page 活用方法 30 行動ログの分析（A/Bテストや不正ユーザ検出） KPIダッシュボードへの書き出し(GoogleSpreadSheetベース) レガシーブラウザのコンバージョン数のモニタリング デグレが発生し取りこぼしが発生しても早期に検出可能 ロボットのクロール状況の追跡 ロボットからのクロールが意図通りかモニタリング レスポンスタイムや500エラーの発生率の追跡 JavaScript SDKを用いたWebビーコン型アクセス解析
23. 23. page A/Bテストなどの裏側ではTreasureDataが大活躍 31 活用方法
24. 24. page 単にABテストをすると必要な 計測回数を満たしていないこともある 32
25. 25. page あるメディアでのA/Bテスト事例 33 引用元：【テストツール不要】明日から試せる転職会議式ABテストのはじめ方
 http://qiita.com/kekekenta/items/8b1f9d2a17c4c6a6b638
26. 26. page 途中でクリック率が反転する例 34 引用元：【テストツール不要】明日から試せる転職会議式ABテストのはじめ方
 http://qiita.com/kekekenta/items/8b1f9d2a17c4c6a6b638
27. 27. page A/Bテストの計測量が足りているかは
 信頼区間を計算するべきである 35
28. 28. page 信頼区間の計算手法など、詳しくは 「転職会議 2倍」で検索！ 36
29. 29. page 参考になる弊社公開記事 37 【テストツール不要】明日から試せる転職会議式ABテストのはじめ方 http://qiita.com/kekekenta/items/8b1f9d2a17c4c6a6b638
30. 30. page 参考になる弊社公開スライド 38 登録数2倍にしてと言われた時の正しい対処法 http://www.slideshare.net/KurosawaChihiro/2-42758053
31. 31. page 39 「コンバージョン数を2倍にしてくれ」と言われた時の対処法 http://www.slideshare.net/tsuyoshika/2-52482724 参考になる弊社公開スライド
32. 32. page 5. 導入前後 40
33. 33. page 導入前後 41 スキーマやデータサイズの呪縛から解放された クエリの結果をURLとして参照できる GoogleSpreadSheet書き出しでリアルタイム更新される
 ダッシュボードが手軽に作れることに感激する Hadoopの運用が任せられるため事業に集中出来る サポートチャットの対応が素晴らしいため心強い 新規事業立ち上げに伴う導入支援にも応えていただけた
34. 34. page サポートチャット利用状況 42
35. 35. page いつもありがとうございます！ 43
36. 36. page 6. 安定運用化 44
37. 37. page 安定運用化 45 td-agentの監視はもちろん必要（Mackerl + PagerDutyなど） td-agentのバッファサイズなどのチューニングも必要 社内向けにクエリのクックブックを提供 社内向けにWebコンソールの運用ガイドラインを定める Teamユーザの発行方針 Saved Queiesの命名ルール 一部のノウハウはQiitaなどで公開中
38. 38. page 7. 今後の期待 48
39. 39. page 今後の期待 49 Pythonを用いた独自UDF対応 ストリーミングデータ処理の対応 環境変数への対応（Hivemallの乱数seedを固定したい） Hivemallを用いた予測結果をDynamoDBへ書き出したい 億単位の全組み合わせ予測結果を事前に計算しておきたい コンソールのスピードや使い勝手の改善 2016 Q1のNew Web Consoleが楽しみです
40. 40. page 8. まとめ 50
41. 41. page まとめ 51 TreasureDataを契約して良かった 導入によるメリットは計り知れない 今ではHiveよりもPrestoをメインに利用している 共に成長すること3年、今後の動向が楽しみです
42. 42. page Thanks! 52 ご清聴ありがとうございました。