Upgrade to Pro — share decks privately, control downloads, hide ads and more …

フリークアウトにおける大規模データの取り扱いのこれまでとこれから

0adc4facc8dd5623911ff6bbc4ed1884?s=47 s_wool
December 16, 2014

 フリークアウトにおける大規模データの取り扱いのこれまでとこれから

0adc4facc8dd5623911ff6bbc4ed1884?s=128

s_wool

December 16, 2014
Tweet

Transcript

  1. フリークアウトにおける 大規模データの取り扱いの これまでとこれから 加藤慶一 株式会社フリークアウト 2014/12/16

  2. about me

  3. Norikazu Kato ログ @ フリークアウト Hadoop, fluentd, elasticsearch あたりをさわっていま す

    経歴 2011.04 グリー株式会社 2013.01 株式会社フリークアウト 5月くらいからずっとログ担当 ID s_wool or s-wool 最近気になること:肝機能
  4. 念のため フリークアウトに ついて

  5. FreakOut 国内で初めてRTBによる広告枠の買付を行うDSP を開始 2011.01~ RTB -> Real Time Bidding DSP

    -> Demand Side Platform 関連する会社 Dobleas FreakOut Asia Pacific IntimateMerger M.T.Burn
  6. RTBの簡単なしくみ この間大体100ms

  7. 50ms or die.

  8. フリークアウトの大規模データ 大きく分けて2つ • オーディエンスデータ • 配信ログ

  9. オーディエンスデータ オーディエンス:広告を見ている人 オーディエンスデータ: 広告接触の情報 セグメント(属性) などなど オーディエンス数:単純な発行ID数で数十億

  10. 使うところ この間大体100ms

  11. 使うところ この間大体100ms オーディエンスデータから判断する

  12. AudienceDBの構成 現状 容量:約3TB(メモリ) get/set:およそ0.1ms(ささると数ms) 15000 get/sec

  13. KVSは Tokyo Tyrant

  14. Tokyo Tyrant はやい

  15. が、 • Expireできない • データが増え続ける • メモリに載らなくなる • 迂闊にサーバを追加できない 第4回

    memcachedの分散アルゴリズム:memcachedを知り尽くす|gihyo.jp … 技術評論社 http://gihyo.jp/dev/feature/01/memcached/0004
  16. が、 • Expireできない • データが増え続ける • メモリに載らなくなる • 迂闊にサーバを追加できない 第4回

    memcachedの分散アルゴリズム:memcachedを知り尽くす|gihyo.jp … 技術評論社 http://gihyo.jp/dev/feature/01/memcached/0004 失われるオーディエンス
  17. OKAWARI

  18. OKAWARI作戦 前世代へのgetがなくなってくればOKAWARI完了

  19. つらいところ • サーバ台数 • 前世代の退役に時間がかかる • 気軽に増やしたい • 分散データストア •

    riakの検証
  20. riak → 断念 • service inするも断念 • 徐々にwriteがしんどくなる • 再度TTに戻りOKAWARI作戦

    • おかわりしつつ次の作戦を練る
  21. 次世代AudienceDB

  22. ポイント • 書き込み性能 • スケーラビリティ • もう火山じゃない? • 少なくとも検証段階では… •

    現在検証中のHBaseは0.98.6
  23. 検討中の構成

  24. 乞うご期待 一緒に運用したい方お声がけください

  25. 続いて Log

  26. 配信ログ • bidding request • impression • click • conversion

    • tag • response time • etc …
  27. ログの役割 • 配信実績の分析 • 入札のA/Bテストっぽいもの • 数値を変えた配信設定を用意してバケットに分けて 比較(splitrunとか呼んでる) • オーディエンス分析

    • デモグラ • 興味関心 • セグメント同士の重複 • 開発側の指標作成 • などなど
  28. 構成(創生期) ※まだ動いてる仕組みです

  29. 構成(2013年なかば)

  30. 構成(ちょっと前まで)

  31. 主なUpdate • CDH 4 → CDH5 • Hivemall • Impala

    • Norikra • Elasticsearch + Kibana
  32. CDH 4 → CDH5 • Yarn対応済み • Cloudera Managerを採用してよりアップデー トしやすい体勢へ

    • Hadoop周辺のエコシステムの進歩が非常にはやい が追随していきたい • 移行の話をアドベントカレンダーに書きました • http://qiita.com/s_wool/items/4fa7932dda7e3f4738 15
  33. Hivemall • Hiveで動作する機械学習ライブラリ • 配信実績を利用したCTR予測など • 予測したCTRで入札価格決定したり

  34. Impala • 検証中 • 現状「爆速Hive」的な位置づけでの利用検討 • hue上でクエリ実行

  35. Norikra • fluentdのmetricsを送信してバッファの状況を 監視 • クエリが引っかかるとfluentdのnorikra input経 由で通知 • クエリ例

    SELECT agent_id, 'PLUGIN_NAME' AS tag, avg(data.plugins.PLUGIN_NAME.metrics.buffer_queue_length.value) AS avg_buffer_queue_length FROM fluent_monitoring.win:time_batch(1 minute) GROUP BY agent_id HAVING avg(data.plugins.PLUGIN_NAME.metrics.buffer_queue_length.value) > 76
  36. Elasticsearch + Kibana • 配信サマリーの可視化 • パフォーマンスの可視化 • マスターデータとjoinした定型のグラフは別UI を独自で作成

  37. 今後のUpdate

  38. 今後のUpdate • Spark(MLlib) • より高速に機械学習したい • HBase? • 分析しやすいオーディエンスDBを作成 •

    毎日→毎時→毎分の集計へ • ものによるけど • 開発側に訴えかけるログの可視化 • リリースの効果をわかりやすく • テンションあがるやつ